Business rules people may not really like this architecture. It is pretty technical. But I am not trying to build pretty documents, draw pictures, or talk to users for the sake of making them feel loved and understood. I am trying to build a system. I am looking for an architecture that allows me to completely articulate what the system needs to do and use that articulation to communicate back to the users what I think they told me.
The rules should be understandable by mortals (functional users) and these users should be able to participate meaningfully in the design. However, I don’t have any illusions that functional users can build a business rules-based system. This is a job for IT professionals. Users do not think precisely enough to be able to see the ramifications of their decisions and need to be guided in the articulation of a system.
My first understanding of a rules-based system was an ERD. Indeed, ERDs do capture some number of rules. Even business rules types have something that looks a lot like an ERD (a fact model). What the ERD was really doing was allowing us to describe our “stuff” and the interesting attributes about that stuff. In the rules world, I call those “structural rules”.
Structural rules describe the “objects” of interest to our system, so I classify them as object rules. Process and data validation rules also pertain to the objects so this provides the outline of our architecture:
I. Object Rules
A. Structural rules
B. Process rules
II. Data Validation Rules
For a long time, I thought that if I just knew enough about the objects in a system, I would know enough to build the whole system. It took quite a few years before I gave up on that idea. Eventually, I looked at projects such as data migrations and ETL (now called web services) and noticed that I had no nice way to articulate those kinds of rules. The problem was that the rules were not about a single collection of objects, they described how one set of objects related to a different set of objects. Therefore, a primitive rule in this way of thinking involved two or more sets of object attributes and how they related to each other. To handle these rules, I added another rule type:
III. Object Interaction Rules
At this point, I thought I had it. I took all of these rules and found that I could successfully generate everything to make the system work. The UI was somewhat generic, but I figured that if I kept pushing it further and further, I would eventually get there. I was wrong. At the end of the day, screen layout and behavior requires a totally different set of rules:
IV. User Interface Rules
Now, finally, I had created a complete rules architecture (at least from 30,000 feet):
I. Object Rules
A. Structural rules
B. Process rules
II. Data Validation Rules
III. Object Interaction Rules
————————————————————-
IV. User Interface Rules
The really important thing to keep in mind is the separation of object rules from UI rules. The fact that a purchase order goes through three levels of approval has nothing to do with the screen layout. That type of rule is intrinsic to the nature of a purchase order. ANY interface to the object should be subject to the same rules. Having the object rules separated from the UI really helps keep your thinking clear.
In the next few posts, I will go into more detail about this architecture.
Leave a Reply