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.

 

Share this!
Tagged with: ,
Posted in BLOG, Business Rules, Publications
2 comments on “Business Rules Concepts 4th edition – by Ron Ross – Chapter 2 Review
  1. CJ says:

    I’m somewhat confused. You start w/ “Ron thinks that processes and rules are different things.” The next paragraph states “… process rules are simply a different kind of business rule.”

    At what point did processes and process rule become the same thing? Is that the source of the disagreement?

    It would seem more correct to say that processes cannot exist w/o rules. If you don’t have any rules then you also don’t have a process. Further, a rule cannot exist w/o a process.

    Or have I missed something?

    CJ

  2. Paul Dorsey says:

    In the second paragraph I state “I would instead say that process rules are simply a different kind of business rule.” This is indeed the source of the disagreement.

    So, no I do not agree that your statement… at several levels. A structural rule can easily exist independent of any process (except the trivial one: create-destroy). For example: “US addresses all have zip codes.” Rather than saying processes have rules, I would say that processes are themselves articulated via rules.
    The whole point of the rules approach is that you have a rules grammar that allows you articulate the entire system in a technology independent way. Rules span the entire functional system articulation space.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Disclaimer
The information presented on this blog is presented to provide general technical information. If, while attempting to apply any of the ideas, procedures, or suggestions herein, you experience any kind of programming or system problems or failure, it will be as a result of your own actions. Dulcian, Inc. and all authors of text found anywhere on this site, and all internally-linked Web sites, Mail Lists, Blogs and/or e-mail group discussion, disclaim responsibility for any user's actions and any damage that may occur based on information found on this website and associated Mail Lists, Blogs and/or e-mail group discussion. Any technical advice or directions found on or through this site is provided AS IS and its provided without warranty or any guarantee of its accuracy. You perform any modifications to programs or software AT YOUR OWN RISK.