Related Links

Web Seminars

A major goal of the business rules movement is to capture business rules in ways that express the business logic of the rules, rather than describing the mechanics used to execute them. As Chris Date has put it, business rules should be about "what, not how." A significant problem with this goal is that many IT professionals - perhaps the majority - tend to have mind-sets that think in terms of the "how" of implementing business rules. This seems to be based primarily on the experiences of individuals as programmers, and a view that creating source code by hand is the only way to get things done in practice. Source code is, of course, procedural. That is to say it is a sequence of instructions that a computer will execute, e.g., "first do A, then B, then C and if D is true then do E, otherwise do F."

While procedural source code seems natural to anyone involved in programming, it is very difficult to look at it and determine where one business rule begins and ends. In fact, quite a bit of most source code is concerned with doing things that have nothing to do with business logic, such as setting up an environment for a program to run in. Even if business rules can be discerned, it is difficult to understand what their business significance is, unless the source code is well documented (which is rare). Perhaps as a reaction to all of this there has been a general condemnation of things that are "procedural" in the business rules movement. Yet, these are serious grounds to question whether "procedure" really should stigmatized as something that is in natural opposition to business rules.

Dependency

A central idea of the business rules movement is that rules can be declared individually and the dependencies between the rules can then be worked out automatically. In my practice, I have found that this is not so easy to implement in rules engines that I have built. I have been able to get it to work by determining if the output of one rule is used as an input to another rule among rules confined to a single business process. Exactly how other rules engines do it, particularly the commercially available ones, is a mystery to me - and likely to remain so as long as the vendors want to protect their intellectual property. However, the problem that arises from creating mechanisms to determine rule dependency is a false promise that simply by defining rules we can always automatically determine the sequence in which they will fire in all circumstances. This is not to decry the tremendous importance of rule dependency, but simply to say that it may not always be possible to automatically infer it.

Paying the Bills

A good example of what I am talking about occurs in my household when I pay my bills. I pay them in a sequence that makes sense to me. First I pay my mortgage, since I want to keep a roof over my family's heads. Next I pay all utility bills, since I want warmth, light, a working telephone and cable TV. If I have any money left over I pay the minimum balance due on each of my credit cards, in a sequence based on their interest rates (those with the highest rates get paid first). If there is still money left after that, I go back over my credit cards and try to pay the full balances, again beginning with the cards that have the highest interest rates. What is important to note is that the sequence in which I make all of my payments cannot be inferred from more basic underlying business rules.

Why Procedure Matters

In the world of finance there thousands, perhaps millions, of legal contracts that specify payment priorities that are very similar in nature to the way I pay my bills. For instance, when a company goes bankrupt there is a sequence in which different classes of creditors get paid, e.g., bondholders get paid before stockholders. The business rules movement should not get itself into the position where it condemns things that are procedural in nature just because program source code has problems and program source code is procedural. In reality, sequences or procedures can themselves be business rules. Of course, in other circumstances, procedure is not specified by the business and we can indeed automatically infer the dependencies among individual rules. Yet, we need to recognize that there are situations where procedure can be of paramount importance and not take some kind of religious stand against it. Procedure, in its true sense, is still alive and well and must be accommodated by the business rules movement.

Malcolm Chisholm, Ph.D. has over 25 years of experience in enterprise information management and data management and has worked in a wide range of sectors. He specializes in setting up and developing enterprise information management units, master data management, and business rules. His experience includes the financial, manufacturing, government, and pharmaceutical industries. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and Definition in Information Management. He writes numerous articles and is a frequent presenter on these topics at industry events. Chisholm runs the websites http://www.bizrulesengine.com, http://www.refdataportal.com and http://www.data-definition.com. Chisholm is the winner of the 2011 DAMA International Achievement Award.