This is a review of the latest edition of Ron Ross’ Business Rules Concepts book in relationship with our thinking at Dulcian about business rules. Ron Ross offers a free download of the first two chapters of this 4th edition of his book. We previously reviewed Chapter 1 – What You Need to Know About Structured Business Vocabularies – and Chapter 2 – What You Need to Know About Business Rules. Below is a review of Chapter 3 – What You Need to Know About Rulebook Management.
This is a very good chapter. It lays out a wonderful structure for doing business rules-based analysis. I really like the FAQ template that the author shows in Table 3. It helps you to ask all of the right questions when thinking about a rule.
However, rules-based analysis (just like any analysis process that is natural language based) is not going to give you enough information to code the entire system. Ron Ross states right up front in the chapter: “Remember that business rules provide business level guidance –not programming logic or rules specified for implementation….”
The problem is that there are just too many rules. Consider a simple example of a rule: “Only a department manager is allowed to edit the discount after the purchase order is approved.” This rule means that, for each object, attribute, and processing state that object can be in, as well as each role or privilege that a user can assume, we need to know whether or not the attribute can be edited. If you consider the facts that there are usually 10,000 or more attributes in a system, each object can be in several states, and there are usually at least 10 roles or privileges in each system, you can quickly see that hundreds of thousands of rules are involved for just this one type of rule.
To be fair, it is not quite that bad. You can use default values for rules. For example, if a user with a specific role can edit an object, they can edit all of its attributes and sub-objects unless otherwise specified. Also, some rules are pretty simple to specify with a diagram such as a Class Model (what the book calls a “Concept Model”). However, no matter how you slice it, there are a LOT of rules.
In our BRIM® environment, the rules mostly ARE the code. This provides a very accurate count by rule type of how many rules there are in a system. One of our biggest systems (recruiting for the US Air Force) is a good example of a “big” system. It includes thousands of attributes, hundreds of classes, a very complex process flow, thousands of data validation rules, etc.
To summarize:
- Classes: 300
- Attributes: 5000
- Process flow states: 300
- Process flow transitions: 1000
- Process flow rules: 2000
- Complex data validation rules: 1500
- Simple data validation rules: 500
- Other rules: 300
In this situation, there are over 5000 rules that are not simple class/attribute types of rules. Also lots of editing/visibility rules are stored in the Formspider™ UI repository, which are not even counted here. Clearly, I can’t write a page for each one of these without getting buried in text.
This has always been my issue with any kind of “analysis” artifact. So I have an analysis document. Now what? As the project matures, I will have hundreds, if not thousands of rules. Those rules will mature, change, combine, etc. They will do all of the things that traditional requirements do. Do I maintain these rules for the life of the system? Or are they only part of the analysis phase?
I guess what I am hoping for now in the book is to put it all together. Where does this business rules analysis approach fit into a good software architecture? My first reading of the book did not seem to answer that question.
Over the years, I have gotten much more Agile in my approach. I am not sure that I want to bother gathering all of these text rules that must subsequently be translated into something precise and rigorous later on. As it says in the Manifesto for Agile Software Development, “We value working software over comprehensive documentation.”
Leave a Reply