As the number of business rules we model increases, effective means to capture, visualize, and manage entire sets of rules at a time become more important for the business.  A significant number of rules share the same subject, have similar evaluation terms, or similar outcomes.  Although each business rule can (and should) be considered on its own, there are good reasons to study an entire set of rules.

As long as the set of rules is known to be valid, complete, and consistent, we do not really care which part of the business is in which rules.  OK, there might be some performance issues on the technical side, but as long as the rules are correct, the rule engine will come up with the correct results.

However, the representation of the set of rules is important for quality reasons:  we prefer business representations that make it easy to specify the business rules, to verify the specifications, and to maintain the business rules when the business changes.  And not every representation is equally suited for each of these purposes.

Different Types of Rules

Rules are not just rules.  They can be organized in different ways.  We could (for example) include one rule for each distinct outcome, or a number of rules for each outcome.  

A. One rule for each outcome:

• A credit check must be performed for a customer if the order total is between $800 and $1000
  or (if the order total is more than $1000 and a waiver has not been authorized)


• A credit check must not be performed for a customer if the order total is less then $800
  or (if the order total is more than $1000 and a waiver has been authorized)

B. Multiple rules for different outcomes:

• A credit check must be performed for a customer if the order total is between $800 and $1000


• A credit check must be performed for a customer if the order total is more than $1000 and a waiver has not been authorized)


• A credit check must not be performed for a customer if the order total is less then $800
  or (if the order total is more than $1000 and a waiver has been authorized)

We could also organize the rules according to the evaluation terms and specify one rule with all the outcomes for each simple combination of evaluation terms or each relevant combination of evaluation terms.  

C. One rule for each simple combination of evaluation terms:

• A credit check must not be performed for a customer if the order total is less then $800 and a waiver has been authorized

• A credit check must not be performed for a customer if the order total is less then $800 and a waiver has not been authorized

• A credit check must be performed for a customer if the order total is between $800 and $1000 and a waiver has been authorized

• A credit check must be performed for a customer if the order total is between $800 and $1000 and a waiver has not been authorized

• A credit check must not be performed for a customer if the order total is more than $1000 and a waiver has been authorized

• A credit check must be performed for a customer if the order total is more than $1000 and a waiver has not been authorized

D. One rule for each relevant combination of evaluation terms:

• A credit check must not be performed for a customer if the order total is less then $800

• A credit check must be performed for a customer if the order total is between $800 and $1000

• A credit check must not be performed for a customer if the order total is more than $1000 and a waiver has been authorized

• A credit check must be performed for a customer if the order total is more than $1000 and a waiver has not been authorized

In the previous examples, there is only one type of outcome (performing or not performing a credit check), but when there are multiple outcomes that can occur for the same combination of evaluation terms, we have the option to:

1. separate the rules for each outcome (outcome oriented view)


2. organize them by evaluation terms (evaluation oriented view), or


3. supply some outcomes for some evaluation terms in turn, and leave it to the rule engine to combine the relevant evaluation terms (mixed view).

We could also supply default rules, and specific exceptions to the default rules.

E. Default rules and exceptions:

• A credit check must not be performed for a customer if the order total is less then $800

• Default: A credit check must be performed for a customer if the order total is $800 or higher, unless there are any exceptions

• Exception: A credit check must not be performed for a customer if the order total is more than $1000 and a waiver has been authorized

Is This Distinction Important?

All previous examples exhibit the same business knowledge, so why would we care?  Because there are different rules for different purposes.  Some sets of rules are easier to verify than others, and some are easier to maintain because they are closer to the business.

The point is that, depending on our role and goals, we look at at a set of rules from different perspectives (Figure 1):

Figure 1: different perspectives on rule sets

• As a modeler, we are interested in a set of rules that closely matches the business specification.  When the business changes, we want to be able to easily spot and update the relevant rules;

• As a business rule manager, we want to be able to guarantee that the rules are consistent and complete, and that updates do not create anomalies.  So we want a good overview of the combined evaluation terms.

• As a software designer, we want to make sure that the set of rules can be implemented for efficient evaluation.

These perspectives on rule sets may require different representations for different purposes

Do Tables Help?

Rule tables (and decision tables) offer a way to represent a set of rules that share the same subject, have similar evaluation terms, or similar outcomes.  But also tables come in different forms.  Looking at the earlier sets of rules, we could (for example) construct the following corresponding tables:

For A,B. One (block of) columns for each outcome:

For C,D. One column for each (relevant) combination of evaluation terms:

For E. Default rules and exceptions (evaluate from left to right):

These tables look rather similar, but they are very different.

• The first table enumerates all possible outcomes and the combinations of evaluations terms for each outcome.


• The second table enumerates all relevant combinations of evaluation terms and their resulting outcome(s).


• The third table should be evaluated from left to right.  Once we have reached a match, there is no need to evaluate other columns.  If no special cases (exceptions) match, the default rule (last rule) applies.

The major distinction between the three tables is the question whether columns overlap.

• The first table enumerates the combinations of evaluation terms for each outcome, so some combinations might be present in multiple columns.  The table is usually ordered by outcome.  When making a decision, we will have to look for and apply all matching columns.


• In the second table each possible combination of evaluation terms is included in only one column.  There are no overlapping columns and, therefore, there is no risk of redundancies or inconsistencies.  Moreover, it is easy to guarantee that the table is complete if the number of combinations evaluated in all columns is equal to the total number of possible combinations.


• The third table may contain overlapping columns, but when making a decision the first match (from left to right) is used.

The first and third tables are called multiple-hit tables.  At evaluation time, we will have to examine all hits (first table) or the first hit only (third table).  The second table is called a single-hit table.

Homework

The three types of tables have different characteristics and advantages.

As an exercise to the reader:

1. Which table is rather easy to build because it is outcome oriented, but is difficult to verify, and takes a lot of effort to make a decision?


2. Which table is rather difficult to build and difficult to verify, but is easy to make a decision?


3. Which table requires some effort to build, but is easy to verify and easy to make a decision?

References

Ronald G. Ross, "Decision Tables, Part 1 ~ The Route to Completeness," Business Rules Journal, Vol. 6, No. 6 (August 2005), URL:  http://www.BRCommunity.com/a2005/b240.html

Ronald G. Ross, "Decision Tables, Part2 ~ The Route to Completeness," Business Rules Journal, Vol. 6, No. 8 (August 2005), URL:  http://www.BRCommunity.com/a2005/b243.html

Ronald G. Ross.  Principles of the Business Rules Approach. Addison-Wesley (2003).  ISBN:   0-201-78893-4.

J. Vanthienen and E. Dries, "Illustration of a Decision Table Tool for Specifying and Implementing Knowledge Based Systems," International Journal on Artificial Intelligence Tools, 3(2), 1994, 267-288.

# # #