We have spoken often of the necessity of separating business rules from business process. For those new to business rules, consider two points:
- The need to manage business rules independently from the process: Business rules tend to change more frequently than does business process. When rules are embedded in process, changes are significantly more difficult to execute than when they are managed in a Business Rules Management System (BRMS).
- Single point of maintenance: A business rule may be used in many different processes, and/or at several points in a single process. By maintaining business rules in a BRMS, the change may be made once, and sometimes simply by a business analyst.
More importantly, an organization may aim to trace its business rules to the business policies that motivate them so that a change in policy could be implemented rapidly and efficiently with proper impact analysis and little programming. Organizations that accomplish this are said to have reached level 2 of the KPI Rule Maturity Model (KPI RMM™), the business value of which is organizational agility.
Beyond this, when organizations manage their business rules across organizational silos and lines of business, the organization reaches KPI RMM™ level 3, the business value of which is organizational consistency.
At a minimum, this requires a well developed business rules governance capability and supporting technology (Source Rules Repository and Business Rules Management System.) Even then, the management of very large groups of business rules, and implementing those rules into technology across a wide range of platforms is a challenge. Not surprising, only a handful of corporations have reached these levels, although the evidence is that those who do certainly reap significant rewards.
Readers intimidated by the scope of commitment to an enterprise level approach should look closely at the promising new developments of “decision services”. This promises to provide enterprise level business rules services on an incremental basis.
What is a “decision service”?
A business decision is, in essence, a business judgment made about a business concept, such as “Claim”, or some attribute of the business concept, such as “Claim Payment Eligibility”. This judgment is made based upon the business rules that underlie the business decision, which is the principal – sometimes the exclusive – means by which business rules are implemented in the business.
Business decisions have specific distinguishing characteristics. Consider the judgment ‘Do we grant a particular person a loan?’ This is a business decision that must be made frequently, and the answer may be relatively brief – in this case a simple yes/no. The business rules supporting that decision could be quite complicated, not to mention numerous – and they probably change frequently with the business environment. They could also depend on other business rules that aren’t governed within the organization (e.g. credit scores, regulations), which could also change in unpredictable frequency and manner. But the decision itself will probably seldom alter.
The business decision shares all these characteristics with its system analog, the decision embedded in a business process management suite: however lurking under the surface of a simple icon is the complex and often changing world of business rules.
There is a rapidly growing awareness of the importance of business decisions emerging today, with announcements from Fair Isaac, Ilog, and Oracle in support of ‘Decision Services’ or ‘Enterprise Decision Management.” For the most part, the approach is similar: groups of rules are exposed in the web services layer of conventional SOA stack as ‘Decision Services’, to be consumed by the business process layer.
Figure 1: Typical Architecture of Decision Services showing some of the possible dependencies
This approach solves the strategic problem of providing enterprise business rules by allowing an incremental approach. Key business decisions can be targeted for the provisioning of a service and the discovery of the underlying business rules. The targets may be ones of opportunity, based on a convenient project or may be strategic, based upon a business initiative.
Some challenges still remain, most importantly a lack of mark-up language standards to augment BPEL that will support the business rule invocation by the decision service objects. In the absence of approved standards today, vendors – and practitioners – are moving ahead with their own implementations. The target solution should always ensure that the decision service is truly decoupled from the underlying BRMS (i.e. no APIs, please!) so that the service is agnostic as to underlying BRMS vendor.
Finally, and importantly, a clear methodology should be followed to identify, harvest and manage business rules in a decision oriented fashion. The critical challenge becomes that of cross-organizational governance over important business rules. After all, in the real enterprise, real business decisions reach across the traditional application and functional silos….and that is how it should be.
