How many 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 beginning to realize that they have a problem with Rule Management.   Often, the perception didn't start off that way.   Instead, it may have fallen initially under some other label such as "change management," "data quality," "knowledge retention," "communication gap," or so on.   Nonetheless, the underlying problem was eventually discovered to be the same -- namely that the units of business logic the company wishes to follow in its day-to-day operation (a.k.a business rules) are not being managed in any consistent, coherent manner.

The purpose of Rule Management is to provide the infrastructure necessary to correct that problem.   This assumes, of course, that rules can be managed.   But why not?   In one sense, rules are just "data" (or "meta-data" to be more precise), and in general, we already certainly know how to manage data.

So the first and most basic idea in Rule Management is that your rules should be databased.   In other words, you should store the rules in an automated facility where they can be managed and readily accessed.   Actually, that's the easy part.   The hard part is knowing what to store, and then how to get at it.

The key to the answer lies with remembering that business rules represent business logic -- not programming logic.   The intention of Rule Management is to give business analysts the ability to manage and access that business logic directly.   So the focus should be on the types of challenges these business analysts face and types of questions they might pose.

Perhaps most fundamental in this regard is vocabulary management.   When you have a thousand or ten thousand rules -- or even a hundred -- exercising control over the consistent and correct use of business terminology becomes paramount.   Imagine trying to understand and coordinate that much business logic where each rule is expressed in isolation from the others.   Literally, the result would be a Tower of Babel.   So in practice, Rule Management is not only about rules, but business vocabulary and its usage as well.

Beyond that, many of the questions about a rule that rule analysts might ask are quite predictable, as the following list illustrates.   Although the importance of these questions is self-evident, most of this type of knowledge has never before been managed in any coordinated fashion.

• Where can more information about the rule be found?
• To what areas of the business does the rule apply?
• What work tasks does the rule guide?
• Where is the rule implemented?
• What new design deliverables need to address the rule?
• In what jurisdictions is the rule enforced?
• Who can answer particular questions about the rule?
• When was the rule created?
• Over what period of time is the rule enforced?
• What influenced the creation of the rule?
• What purpose does the rule serve?

Another question crucial to managing rules is being able to address relationships between rules -- that is, rule-to-rule connections.   There are many ways in which rules can be interconnected, as the following list suggests.   Being able to trace these relationships is also crucial to Rule Management.

• A rule is an exception to another rule.
• A rule enables another rule.
• A rule subsumes another rule.
• A rule is semantically equivalent to another rule.
• A rule is similar to another rule.
• A rule is in conflict with another rule.
• A rule supports another rule.
• A rule is interpreted from another rule.

What this list and the earlier list of questions point out is the need for comprehensive traceability in the Rule Management environment.   'Databasing' the rules is just one part of the solution -- equally important is providing business analysts with tools to access the information once stored.   In part, this can be addressed by offering predefined reports and queries providing canned support for typical needs. Beyond that, visualization techniques are useful, especially for making the front-ends more friendly and for communicating the knowledge more effectively.

In one way or another, we believe that every company will discover the need for Rule Management capabilities in the coming decade.   Although there is much still to learn, the good news is that pioneering companies have already discovered how to achieve the basics.   Good tools are now available -- and more are on the way.

# # #