Keeping Business Rules Separate from Their Enforcement
IBM ILOG Blogger 270002NTYA Visits (1709)
Here is an article that I wrote for publication in the Business Rule Community web site in 2003. I thought some of you might find it interesting.
Keeping Business Rules Separate from their Enforcement
by Oscar Chappel
This article from The Business Rules Manifesto raises a very important question. "What is the difference between a business rule and its enforcement?" It seems that it is difficult to get strong agreement on exactly what represents a business rule. I have found that it is even more difficult to reach agreement on the definition of a business rule's enforcement.
When I think of a business rule, I think of the many possible definitions that Ron Ross published in The Principles of the Business Rule Approach. Ron provided 10 different definitions on pages 183 and 184. These definitions range from the very simple "...[A]n explicit statement of a constraint that exists within a business's ontology" to the very complex "...[A] statement that defines or constrains some aspect of the business ... [which is] intended to assert business structure, or to control or influence the behavior of the business. [A business rule] can not be broken down or decomposed further into more detailed business rules.... [I]f reduced any further, there would be a loss of important information about the business." Regardless of the definition used, it is very difficult to explain exactly what a business rule really is. It seems that we should be able to agree that business rules describe the way business people want their business to operate.
Business rules are stated in many different ways but always using natural language. They can be stated in business procedure manuals, where they are often stated in terms of business policies. They can be stated in government regulations and manuals such as the Hospital Prospective Payment System Manual from the Centers for Medicare and Medicaid Services, CMS. They can be stated in business contracts where they are represented by the terms and conditions of the contract. They can be stated in service level agreements. They can be 'common knowledge' among the business executives, management, and staff, "this is the way we always do it." Regardless of the source for the business rules, little attention is given to the enforcement of those rules. What is to be done if the business rule is violated? This example from the health care domain is illustrative.
These business rules leave the enforcement up to the reader's imagination. The enforcement rules are missing. What actions should be taken, by whom, and when, when these business rules are violated?
The traditional approach to dealing with the missing enforcement rules is to bury the business logic in application software, stored procedures, database constraints, and other application source code, essentially hiding the enforcement rules from the business people and the software developers. Over time, the rules become increasingly unmanageable and costly to maintain. Any change in business rule or policies results in a software change project that can take months to complete and cost the business in both dollars and lost revenues. This scenario is the reason for the renewed interest in business rule systems.
It is no wonder that it is difficult to achieve consensus on the meaning of Enforcement Rules. When I think of the enforcement for business rules I think of software that has a base of knowledge, facts, business policies, and, yes, business rules that express 'what should be' in the business environment. I think of objects that represent this knowledge, that are stored in some form of fact repository, most probably a relational data base. I think of a persistence service that facilitates the insertion and extraction of these fact objects. I think of interfaces that allow business people to create these fact objects using natural language. I think of objects that are created by a business application to represent 'what is' at the point in time enforcement rules are expected to be employed. I think of a few, well-organized, logical enforcement rules that match the objects representing 'what is' to the objects that represent 'what should be'. I think of business rule systems that help a business run smoothly by enforcing the business rules and policies. I think of economic solutions that empower the business people to control their business.
The business rule community seems to suffer from a handicap when we attempt to codify the enforcement rules for business rules. We are constrained by the things we know, our past experiences, and the habits we have developed over years of embedding business logic within business applications. We see business rules as "if ... then ... else" branching control statements like those we would write in COBOL, Java, C, C++, C#, or any other programming language, and we write business rules in this style believing it a good way to enforce the business experts' visions of the way the businesses should operate. Our rule systems become bloated and begin to perform poorly. We struggle to find ways to process thousands, tens of thousands, even hundreds of thousands of rules rather than finding a way to reduce the number of rules while simultaneously achieving the desired result.
Over a period of nearly two decades I have had the opportunity to learn about both rules and object-oriented technologies and to apply the things I have learned in several industries including defense, insurance, manufacturing, entertainment, finance, and health care. Over the years, I have observed that an understanding of object-oriented programming technologies and predicate logic is invaluable in implementing successful business rule applications. I have learned that a rule engine is, first and foremost, an optimized pattern matching algorithm. I have learned that the pattern matching algorithm must test at least one of the conditions of each and every rule in a rule set to determine if the rule conditions should be tested further and if the rule can become a candidate for firing. I have learned that the more rules I provide the rule engine, the longer it takes to process those rules. I have learned that objects embody business facts, 'what should be' and business observations, 'what is'. I have learned that Classes can implement predicates, methods that return a Boolean value and that these predicates can be used in the conditions of enforcement rules. I have learned that good enforcement rules provide patterns that enable a rule engine to efficiently compare 'what is' to 'what should be' and to recommend the appropriate actions when 'what is' is not 'what should be'. I have learned that good enforcement rules can be reused across multiple industries when the business knowledge and policies are represented in a consistent manner. I have learned that good rule engine implementations will replace variables in rules with business objects and create 'virtual' rules that can replace the thousands, tens of thousands, even hundreds of thousands of rules that can cause poor performance.
Using the health care examples in Table 1 we can develop the following business rules.
These business rules are not enforcement rules, they do not describe the actions to take when the rules are violated. These rules tell us 'what should be' when a Revenue Code with a value in the range 420 to 429 occurs on a health care claim. But they do not tell us what to do when 'what is' -- i.e., the codes reported on an actual claim -- doesn't match 'what should be'. The usual approach is to reject a claim that violates the business rule and to provide a message explaining the cause for the rejection.
These business rules have additional problems. For example, the use of the X to signify a 'wild card' would lead the uninitiated to believe that a Revenue Code with a value 426 would be a valid code. This is, in fact, not the case. The Revenue Codes in the 42X range can actually take on valid values of 420 to 424 and 429. So Revenue Code 42X does not mean the continuous interval 420 through 429. The same holds true for the Revenue Codes with values in the 43X and 44X ranges.
There are many approaches to writing the enforcement rules for the business rules stated above. Among the most common, is writing one rule similar to these:
There will be a total of six such rules, one for each of the Revenue Code value sets. This doesn't appear to be too large a challenge, but when one considers that there are currently more than 890 revenue codes that interact with other codes -- e.g., Value Codes, HCPCS Codes and so on -- the number of rules can quickly become unmanageable. This example illustrates how claim clearing houses end up with tens of thousands of health care claim edit rules.
Change is continuous in the health care industry. So imagine what happens when the format for Revenue Code values changes to a four digit format containing a leading zero, as happened in 2000. Now all the rules must be changed to insert a leading zero for all Revenue Code values. If a new Revenue Code with value 0426 is implemented a new condition ("or Revenue Code 0426") could be added to the current rules. Alternatively, completely new rules might be written to account for the new facts: "Revenue Code 0426 requires Occurrence Code 11" and "Revenue Code 0426 requires Occurrence Code 35." Either way, the maintenance headaches, costs, and delays begin to mount.
A more efficient alternative lies in the exploitation of object technologies and unification, a technique that causes variables to be instantiated in rules, much like dynamic, parameterized SQL. Using these approaches one might create relationships between the various codes and enable the codes to 'know' about and find effective relationships. One might use a model similar to that in Figure 1. From this model, one might write a single enforcement rule similar to this:
where Claim, Reported Code, and Required Code are all variables that will be instantiated through unification as the rule is evaluated by an inference engine.
When supported with a 'knowledge base' of fact objects that implement the model in Figure 1, the single rule described above can be used to replace hundreds of 'one-off' rules. The rule is reusable because it can be applied equally well to the health care and warranty claim processing domains. In fact, this one rule can be applied in any domain where there is a proliferation of codes that are involved in relationships with other codes.
Business rules and their enforcement can and must be separated in order to achieve the results that business people demand from their rule based applications. This task requires a thorough understanding of object-oriented and rule engine technologies, and predicate logic. Business experts must be pressed to describe the actions that must be taken when 'what is' doesn't match 'what should be'. Thorough analysis, the application of the principles of object-oriented technologies, the use of predicate logic, and a good understanding of rule engine operating characteristics can relieve rule bloat and enable businesses to achieve the advantages of business rule applications.
 The Business Rules Group, Business Rules Manifesto ~ The Principles of Rule Independence (Ver. 1.2), January 2003. Available at www.