In my previous post I argued that the term “Data” is a barrier to linking Business Processes and Business Rules to … well “Business Data” and that as a consequence of this “missing link” it is difficult to involve the business (and not IT) as the key responsible for “Business Data”.
We have known for some time that Business Processes and Business Data are irrevocable intervened. After all it is the Business Processes that generate and use Business Data, hopefully in the form of well-presented information.
If we take that thought a bit further it can be inferred that insufficient data quality is the product of insufficient Business Processes; once data is captured it does not spontaneously go bad in the IT system.
This brings us to business rules. Getting in control of your Business Data requires many prerequisites; however there is one in particular that is traditionally hard to manage: Business rules.
Business rules are usually kept in one of three ways:
I. In the minds of employees
II. In binders and manuals
III. In the program code
All of these are ways to document and manage business rules are in a word “bad”. Luckily there are alternatives.
So what should you require of the alternative? I have some requirements:
It should not distinguish between the rule and the documentation: Once the rule is documented, in a format that can be read by anyone, it is ready for execution.
The format must be easy to read and understand because it must be easy to update. In fact it should be so easy that today’s IT release cycles will remind us all of the preindustrial age. The mere fact that rules changes all the time makes the speed to (rule) change a key parameter.
Rules in an organization should be shared and implemented in a uniform way across divisions. This must obviously be supported. After all it is so 2012 to have a set-up where you have to coordinate and release multiple updates across different IT systems in order to keep your business execution synchronized!
If the input needed to reach a decision is available the decision should be automatic. There is no reason in today’s time and age to enforce human interference if not needed (e.g. for ethical reasons). Let humans make the decisions that really matter.
Once executed the cause and effect of the business rule should be documented. What was the decision and why was it made? Whether rules are stored in binders or in the minds of employees they are subject to interpretation. I would require from my rule management that all the “interpretation” is objective and visible with a full audit trail.
To sum it up: Business rules can and should be implemented in a way that doesn’t bind you to obscure code in IT systems, are easy and fast to update and can be shared across the organization in an open format.