Business Rules Concepts 4th edition – by Ron Ross – Chapter 2 Review

This post is a review of the second chapter of Ron Ross’ new book Business Rules Concepts – 4th edition. The first two chapters can be downloaded.

Here is where Ron Ross and I will have to respectfully agree to disagree.  Ron thinks that processes and rules are different things. I could not disagree more with that statement. One of his main points is that rules and processes are independent.

I would instead say that process rules are simply a different kind of business rule.

My perspective is to generate systems from my rule repository rather than feeding the development process with the rules. Clearly, you can’t talk about a system without talking about processes.

Ron’s declaring that rules and processes are independent just mystifies me.  Including process as part of the rules architecture makes for a much sounder approach.  If processes are independent of the rules, you run into the quandary “What is a rule?” If the rule is a process thing, then it is not a rule.

My focus on process as a rule type goes back to Dulcian’s first rules based system which was designed to support tax return process flow.  We created our own process flow tool that allowed us to articulate the process flow of a tax return.

Once you decide that object rules can be divided into structure and process types, an interesting idea pops-out:

Structural rules and process rules do not inherently exist. “Structure” and “process” are two approaches to articulating business rules. Rules can be expressed as structure or process.  Usually, it is more convenient to express them as structure or process, but the rules themselves are not inherently structural or process.

Imagine the rule: “An employee must have a last name.”  The obvious thing to do is to implement this structurally as a NOT NULL class attribute.  However, you could make this part of the process: “When an employee is created, validate that the last name field is not null.”

I first encountered this idea in real life when implementing what we called an “outreach” to a customer.  Customers could be reached via a phone call, an office visit, or an email. The obvious thing to do was to create a generalization class called “Outreach” with various specializations under it (phone call, visit, email).  However, it turned out that it was much easier to articulate this as a process rule.  The first step in the process was to identify what type of outreach it was and then enable attributes based on the type in the process.

To be fair, this is pretty rare. Things that feel “structural” are almost always represented as such, and things that feel like a “process” rule are almost always represented as you would suspect.  But the exception is what makes life interesting.

My other disagreement with this chapter is the idea of keeping the rules as independent objects from the processes.  In our meta-model, the rules and actions that occur in a process are attached directly to the transitions and events associated with the process. Dulcian has been doing it that way for almost 15 years now and have had very few instances where rule reuse was needed (Boolean expression or actions, i.e. lines of PL/SQL code). In the few cases where we did reuse rules, this was accomplished with a stored procedure that we could invoke in the rules. That took care of the problem.

Conceptually, I can understand creating rule primitives as independent objects, but in practice my experience is that this is almost never necessary.  If you consider that what we are trying to do is to minimize complexity in development, there is no reason to add a primitive when none is needed.  It just means that you have to do more work to articulate your process with little value.

My last quibble about this chapter is that it is not really a general theory of business rules.  It is a theory based on a particular flavor of the rules world view. My world is different from Ron Ross’ world.  I don’t claim that it is better, but it is certainly different.  For example, I have never used a decision table, and don’t really see their value. I don’t encounter things like “flash points” for rule violations.  I understand that his is a way of viewing the rules space, but I think we need to recognize that there are different ways of viewing the rules world that do not use these constructs.