An example

Assume the following small set of rules in a premium specification.  A company wants to give a premium to its employees, depending on employee age and last performance evaluation.  There are two kinds of premium:  the Normal Premium and the Super Premium.  Here is the story behind the premium specifications:

• A Super Premium is installed for all employees with a good evaluation (only).
  
  
• At the same time, some Normal Premium is invented as a consolation (for moderate workers or loyal workers), admitting that if they do not receive the Super Premium, they should at least receive some Normal Premium.  That means:  employees with a moderate evaluation (irrespective of age), or loyal employees (Age>=45) with a bad (or moderate) evaluation, who would otherwise receive nothing extra.
  
  
• Then, suddenly, someone realizes that if a good young worker receives a Super Premium, the good loyal older worker should receive more, and at least also the Normal Premium that a loyal but bad guy gets.  Hence, also the Normal Premium is added for an employee>=45 with a good evaluation.  Does it not sound credible?  Once you scrutinize it, it is a little strange, of course.  But I can think of a lot of regulations like this.

Indeed, there is no indication that the premiums are exclusive, so an employee could receive both.  And indeed, the original specifications are not perfect, but isn’t that normal?

The story shows the following rules:

1. The Super Premium must be given if and only if the employee Evaluation is Good.
   
2. The Normal Premium must be given if employee Evaluation is Moderate or (employee Age>=45 and Evaluation is not Good).
   
3. The Normal Premium must be given if Age>=45 and Evaluation is Good.

After splitting up the ‘or’ in rule 2:

1. The Super Premium must be given if and only if the employee Evaluation is Good.
2. The Normal Premium must be given if employee Evaluation is Moderate
3. The Normal Premium must be given if employee Age>=45 and Evaluation is not Good.
4. The Normal Premium must be given if employee Age>=45 and Evaluation is Good.

We can simplify further, because it is now clear that rules 3 and 4 complement each other.  But let us first have a look at the decision table.

Decision table representation

From the given specification rules, the following decision table is obtained (Figure 1):

Figure 1.  Resulting decision table

As can be checked in the decision table, the rules can be combined into:

1. The Super Premium must be given if and only if the employee Evaluation is Good.
2. The Normal Premium must be given if employee Evaluation is Moderate or employee Age>=45. (or both, of course)

How many rules?

Now, how many rules do we count? 

• 1 rule (the entire decision table)?  Not really.  We would rather call this a rule set.
• 2 rules (one for the Normal Premium, and one for the Super Premium)?  OK, if you can easily formulate them, without having a look at the decision table.  Try it again from the original specifications.
• 3 rules (the original specifications we started from)?  Note that the last rule was added later and could be combined.
• 4 rules (the simplified list)?
• 5 rules (because the table contains 5 rows)?  Note that the number of rows may depend on the order of the conditions.
• 6 rules (because the table represents 6 possible combinations)?

How many tables?

Maybe you prefer two distinct decision tables, one for the normal premium and one for the super premium.  

Figure 2. Decision table for super premium
(note that Person.Age is irrelevant and should be deleted)

Figure 3. Decision table for normal premium
(note that rows 1 and 3 could be combined, but it is not advised because of the "meaning gap")

This might change the count.  But it will be much harder to figure out in which cases someone gets both premiums.  Actually, for business purposes, it does not provide the same simple overview as presented in Figure 1.  Suppose, for example, that the premiums were exclusive — how would you check this?  So, for validation and verification purposes we prefer to not limit the decision table to one conclusion only.

Which form of rules?

Sometimes the decision table is used to generate decision rules or programming statements.  In that case, the numbers can be different again, depending on how the table is converted (if at all necessary).  The rules can, for example, be organized on a result-oriented basis (one for each result type), or on a case-oriented basis (one for each row or even one for each specific row result) starting from the decision table in Figure 1:

• 2 rules (one for each premium)?
• 4 rules (one for each non-empty case or branch)?
• 6 rules (one for each row, but two for the last row)?

Intermediate conclusion:  The business logic in all these rule sets is the same.  Some rules are very simple and some are more complex, but the number of rules only is not a good indication of complexity.  Other useful counters will be:  the number of conclusions, the number of combinations, …

Different viewpoints for different purposes

Depending on our role and goals, we look at a set of business rules from different perspectives (Figure 4):

Figure 4.  Different perspectives on rule sets

Although the same business knowledge is expressed, different rule set representations serve different purposes (and may lead to different counts).  Some representations are easier to verify than others; some are easier to specify because they are closer to the business specification, and some are easier for making decisions.

The example could, for example, be expressed in the following table (Figure 5).  It looks simple, but this is not considered a good decision table because the condition combinations overlap.  So, verification and validation are then very difficult.

Figure 5.  A table of rules

When modeling business knowledge, designing new regulations, or checking and improving the quality of regulations, business rule sets are often expressed in the form of one or more decision tables, in order to indicate which combination of criteria leads to which outcomes, thereby guaranteeing combinatorial completeness and consistency.  The decision table formalism allows bridging between the different viewpoints:  from the early specifications, to the verification and validation, and finally to decision making.^[1]

Different kinds of rules

There is more to it.  As indicated in [2], a business rule is different from the enforcement rules that indicate what should happen if the rule is violated.  One business rule, expressing a business constraint, may lead to multiple enforcement rules, for example, linked to relevant business events.^[3]  Then we are at the IT developer perspective.  The number of rules will be different (typically a multiple), but also the content and the purpose of the rules is different.  Enforcement rules typically express responses to violations of a business rule and are often formulated in the if-then style.  To make sure that the distinction between these rule types is not overlooked, a word of caution is issued for the if-then style.^[4]

Conclusion

Modeling business knowledge implies the specification of a set of concepts and rules.  The raw specification may contain default rules, exceptions, and exceptions to exceptions (as in a lot of legal texts).  Business rules constrain and define knowledge and behavior in the business perspective.  Decision tables will help to represent different viewpoints and offer flexibility to model, simplify, verify, and maintain the business knowledge.  In the IT developer perspective, enforcement rules, event rules, or implementation rules may enter the scene.

But whenever you are counting, make sure to count and compare the correct things.

References

[1]  Jan Vanthienen, "What business rules and tables can do for regulations," Business Rules Journal, Vol. 8, no. 7 (July 2007), URL: http://www.BRCommunity.com/a2007/b355.html  

[2]  Ronald G. Ross, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), August 2009.  

[3]  Willem De Roover and Jan Vanthienen, "Unified Patterns to transform business rules into an event coordination mechanism," 4th International Workshop on Event-Driven Business Process Management, BPM 2010, Hoboken, NJ, USA September 13-16, 2010, forthcoming.  

[4]  Ronald G. Ross, "What's Wrong with If-Then Syntax For Expressing Business Rules ~ One Size Doesn't Fit All," Business Rules Journal, Vol. 8, No. 7 (July 2007), URL:  http://www.BRCommunity.com/a2007/b353.html  

# # #