A few months ago, I wrote about perfection with respect to a "perfect" deliverable.  Now I'd like to address the "perfect" Rule Management Tool.  Those of you who have been following this series know that the titles to the articles are ironic — there is no such thing as a "perfect" methodology, a "perfect" deliverable, or, as I maintain in this article, a "perfect" tool.  Just as you evaluate any software, you need to understand your requirements; but how do you do that if you are new to managing business rules?  This two-part article explores some key features that a rule management tool should have (but often doesn't).

I recently did market research for a client to evaluate state-of-the-art rule management tools.  There were two things that surprised me:

1. There is still a general lack of understanding of the difference between a tool to manage business rules and a tool to execute them.
   
   
2. Very few tools that manage business rules have strong vocabulary support.

Let me deal with each of these in turn.  Along the way, I'll talk about some of the things you need to think about when evaluating a tool to manage your business rules.

Management vs. Execution

Most people who have been around business rules for a while have an awareness of rule execution tools — that is, software that "runs" or "executes" the business rules in a production environment.  These tools are also referred to as Business Rules Engines (BREs), Business Rules Management Systems (BRMS), or even Decision Management Systems (DMS).^[1]  And therein lies the problem.  "Management" is built right into two of the names of this class of tools, leading to all kinds of confusion over the years.

Many rule execution tool vendors claim that their software allows you to manage business rules (sometimes even in a business-friendly environment), and that is true but only up to a point.  What they allow you to do is manage the rules that have been implemented in their tool using their specification language.

Firstly, in my experience, only a small percentage of the business rules in any given organization are implemented in a rule or decision engine.  Most rules are buried in legacy systems, in policy manuals, etc.  All of an organization's business rules need to be externalized and managed, not just those that happen to be implemented in a rule execution tool.

Secondly, the specification language is generally only somewhat (if at all) business-friendly.^[2]

So how do you manage all the business rules in your organization, not just those implemented in a rule execution tool?  You need a tool that is:

• designed to manage business rules from a business perspective using structured business vocabulary.
• able to manage business rules independently from any implementation (i.e., execution) of the rules.
• able to manage rules through their entire life cycle, from capture to retirement.
• targeted to Business Analysts and business people.

Requirements

In evaluating these tools, you want to focus your requirements on how you intend to manage your business rules across their entire life cycle.  You need to think about the following:

1. What do you need to know about a business rule?


• Do you need to know who authored the business rule?  Who approved it?


• Do you need to know how strictly the rule needs to be enforced?  What action needs to be taken if the rule is breached?


2. How will you "trace" the business rule from its source through to its implementation(s)?


• What to you need to know about the source of a business rule (e.g., the details of a source document, information about the subject matter experts in a facilitated session, the application code or legacy system, etc.)?


• What to you need to know about where it is implemented or deployed (e.g., the specific component of an application system, in a publication, etc.)?


3. What do you need to know about where a business rule is used?


• Do you need to know if it's used in a task in a process?  In a decision?  To define a product?


4. How will you track changes to a business rule over time?


• What is the life cycle of the business rule as it is captured, reviewed, approved, implemented, and retired?  How are you going to track that life cycle (e.g., using statuses)?


• How do you need to handle different versions of a business rule?


• Do you need to know who changed a business rule, what was changed, when it was changed, and who signed off on the change?


5. How will you ensure your business rules reflect the true business intent and that the overall rule logic is sound?


• What kind of reporting do you need to support activities such as impact assessment of changes to the rules, validation of the business rules by the business, handover to development, etc.?


• What kind of verification of the logic do you need for rules and decision tables to ensure that there are no conflicts, redundancies, etc.?


6. How will you ensure your defined business vocabulary is being used in a business rule?


• Do you need instant, visual feedback that proper terminology is being used?


• Do you need to ensure that the proper synonym is being used in a rule?


• Do you need to be able to identify derived or computed terms in a business rule (and identify the rule that actually derives or computes the term)?

This is not a complete list of requirements, but it should be enough to get you started.

Next month, I'll explore how different kinds of tools support these requirements.

Notes

[1]  DMS execute business rules but packaged up within a decision.  

[2]  I can hear my vendor friends protesting!  I will acknowledge that rule engines have improved over the years, that many are much friendlier than they used to be (e.g., with support for decision tables), and that it can be extremely helpful to run rules to test the logic; but I still stand by my statement.  

References

Ronald G. Ross, "General Rulebook Systems (GRBS):  What's the General Idea?" Business Rules Journal, Vol. 10, No. 7 (July 2009), URL:  http://www.BRCommunity.com/a2009/b488.html

"Chapter 3," Business Rule Concepts:  Getting to the Point of Knowledge (4th Edition, 2013) by Ronald G. Ross.

Building Business Solutions:  Business Analysis with Business Rules (2nd Edition, 2015, An IIBA® Sponsored Handbook) by Ronald G. Ross with Gladys S.W. Lam.

# # #