One of my employees asked me to review the latest edition of Ron Ross’ Business Rules Concepts book and discuss my thoughts. He offers a free download of the first two chapters of this 4th edition of his book.
First, let me state that Ron Ross and I think about business rules pretty differently (at least we did the last time we talked years ago). Ron is much more of an “analysis rules” kind of guy. So his focus is more on communication. My rule repositories allow for 100% generation of the system, so I regard business rules as a formal representation of the specifications of the system.
For those of you from the Oracle world, this is the same difference that exists between David Hay and myself when creating ERDs. David creates analysis models that are meant to nicely communicate with users while I build models that are fairly good representations of the logical design, but can also be used to generate the physical database. For these reasons, my comments about Business Rules Concepts may be colored by that “precise specification versus good communication” perspective.
Chapter 1 largely discusses what I remember Ron calling the “fact model” but is now called a “Concept Model”. It includes classes, properties (attributes), categorization (generalizations), and verbs (associations). A data modeler may look at this and say, “Aha! This is just an ERD with different terminology”.
This is the point where I think that Ron should have gone into much more detailed discussion. A concept model is NOT just an ERD. This is a HUGE point that I think needs to be discussed seriously. I would say that Ron is writing about “structural business rules.” These kinds of rules describe our objects of interest, how they are structured, and how they relate to each other. It is fair to say that this looks a lot like an ERD, but it is NOT a data model.
It turns out that Ron’s Concept Model does have most of the information that you need to create the database design, but you can almost think of this as a coincidence.
When BRIM® first started capturing structural rules, it didn’t generate any tables at all. We used the repository as a metadata structure and implemented our entire system in a few different subject matter based “STUFF” and “STUFF ATTRIBUTE VALUE” tables. When we started doing performance tuning, we changed our generator to generate tables, views, and packages, but the rules did not change. Only what we chose to do with those rules changed.
As is always the case with business rules: “The articulation of the rules is independent of the implementation of the rules”.
The other point I wanted to make is about the notation shown in the book. I use UML class diagrams for my structural business rules because when I did the same exercise of defining terms and concepts that Ron does in the book, I noticed that the terms and concepts that I was defining fit very nicely into the structure of a UML class diagram. Class diagrams are also a well defined and well recognized notation system and there are many available tools that allow you to build class diagrams. Figure 1-1 in the book conforms exactly to a UML class diagram system except that it doesn’t show the cardinalities on the associations and the generalization is missing the triangle. I am not sure why Ron just doesn’t use UML class diagrams for his model.
Leave a Reply