Excerpted from Chapter 3, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross (August 2009). ISBN 0-941049-07-8   http://www.brsolutions.com/publications.php

How many business rules does your company have?  A hundred?  A thousand?  Ten thousand?  More?  How easy is it to change any one of those rules?  How easy is it to determine where the rule is implemented?  How easy is it to find out why it was implemented in the first place?

Many companies today are starting to realize they have significant problems in managing their business rules.  Often, this perception did not start off that way.  Initially, the perception might have fallen under some other label such as change management, data quality, knowledge management, or so on.  Call it what you will, these companies are discovering that the business guidance at the core of their day-to-day operations, their essential decision logic, is not being managed in any consistent or coherent manner.

One way or another, every organization will eventually discover the need for managing its business rules.  New skills must be acquired and appropriate work environments implemented.  Fortunately, pioneering companies have already discovered what these techniques are, and good commercial tools have emerged to support them.  These tools and techniques are already paying off handsomely.

General Rulebook Systems (GRBS)

We call the kind of automated, specialized, business-level platform your company needs to manage its business rules a general rulebook system (GRBS).  The purpose of a GRBS is to record, develop, and coordinate business rules, but not 'execute' them per se.  Think of a GRBS as more or less the counterpart of a general ledger system, except that the GRBS is for business rules.

What should a general rulebook system (GRBS) look like?  In one sense, a GRBS is simply a database or repository — one whose interfaces must be business-person-friendly.  What should be recorded in it?  What additional kinds of support are needed?

Remember that business rules represent business-level decision logic — not programming logic or rules specified for implementation under a rule engine or other software platform.  The goal is to give business workers and business analysts the ability to access and manage decision logic directly.  So the focus should be on the kinds of challenges these business workers and analysts face on a day-in and day-out basis.

Repositories supporting IT professionals doing software development or rule authoring under rule engines do not measure up in that regard.  Most were engineered primarily for use by IT staff with the goal of designing software applications.  The difference is not a trivial one.

Fundamental to supporting business-level decision logic is an integrated capability to manage business vocabulary and fact models.  When rules number in the thousands — or even 'just' in the hundreds — coordinating terminology is essential.  Imagine trying to understand and apply that much decision logic without such coordination.  It's hard to emphasize too much the need for business-level coordination of business vocabulary.

Traceability and Corporate Memory

Many questions about business rules (and business vocabulary) that business workers and business analysts will have are quite predictable.  Frequently asked questions include those in Table 3–1.  Although the importance of these questions is self-evident, most companies have never managed this kind of core knowledge in any coordinated or comprehensive manner.

Another question crucial to rulebook management is being able to address relationships between business rules — that is, to easily trace rule-to-rule connections.  Business rules can be interconnected in many ways, but the most important are:

• A rule has been interpreted from or into another rule.
• A rule acts as an exception to another rule.
• A rule supports a computation or derivation used by another rule

The first kind of connection above is particularly important.  Many business rules areinterpretations of what we call governing rules — laws, acts, statutes, regulations, contracts, business policies, legal determinations, and so on.  Knowing the who, when, and why of such interpretations is crucial in supporting impact assessment when a rule changes.  By the way, most business rules do change, sooner or later!

In today's world, discovering or reconstructing the pedigree of a business rule is time-consuming, error-prone, and sometimes impossible.  Worse, once discovered or reproduced for a particular need at a point in time, the history is often not retained in any organized fashion for future use.  That means the whole process must be repeated the next time it is needed, ad nauseam.

To be blunt, our corporate memory about business rules is deeply flawed. And consider this — without memory there can be no accountability.

What we have today is actually a risky and very expensive way to do business.  The valuable resources consumed could certainly be put to better use.  Think of rulebook management as a practical means to create pinpoint corporate memory, always keeping it right at your fingertips.

Rulebook Management:  the skills, techniques, and processes needed to express, analyze, trace, retain, and manage the decision logic used in day-to-day business operations Focus:  Manage decision logic as a business problem rather than a technical problem. Goals:  Ensure that... Basic business know-how is always accessible to those duly authorized. Business policies, regulations, and contractual obligations are interpreted in a faithful, repeatable, and transparent fashion.

All the items listed in Table 3–1 illustrate various forms of traceability.  A GRBS can provide basic support for traceability by means of predefined reports and queries.  Beyond that, visualization techniques are quite useful for presenting more complex or highly-interrelated information.  Comprehensive support for traceability is a key ingredient in successful rulebook management.

Another important aspect of rulebook management is the difficulty of validating large sets of rules, and ensuring that the decision logic is complete, internally consistent, and non-redundant.  Automated support in this area is a must have.  Examples of rule quality items:

• A rule is similar to another rule.
• A rule subsumes another rule.
• A rule is logically equivalent to another rule.
• A rule is in conflict with another rule.

Rather than a new chore for the company's thinly stretched resources, such support should be viewed as an important new area of efficiency.  Never before has the company's decision logic been in a form that could be checked before deployment for true quality by business workers and business analysts from the business point of view.

# # #