This is the third in a series of columns inspired by one of my recent consulting assignments.  In that project I reviewed the work of a couple of novice rule authors.  So now you have listed all your rules whereas before you did not have an overview of them.  You really feel comfortable.  It was worth the investment.  The next time someone wants to know more detail it can be seen at a glance!

It's true; you may be in a better situation than before, now that you have all your rules in one listing — especially when 'before' means:  no overview at all; rules in different places; rules not traced to documentation, process, and usage.

I question, however, if a list is a good way to get an overview.  Very often it is not because it does not show how the rules are related.  You may order rules in a list, but that means you have to maintain and update that order as well.  Let's look at some alternatives.

Recently, some diagram forms were presented by Ross (Q-Chart) and by von Halle and Goldberg (Decision Model).  These diagrams show a hierarchical structure of rule sets based on the dependency between the rules in the sets.  The most commonly-shown dependency depicts one criterion in a rule set depending on the outcome of a rule in another rule set.  For example, Figure 1 shows the dependencies between the criteria that determine the end-date for the rule set that was introduced in Part 1 of this Learn from the Expert series.^[1]

The end-date of a policy must be equal to the most recent date of the following dates: 
   • date insurer is not eligible,
   • date insurer stops payment of the insurance,
   • date insurer ends the insurance.

Figure 1. Dependencies in determining the end-date of a policy.

This diagram is useful for understanding the structure of the logic and is complementary to the natural language expression of the rule.  Since we failed to find other graphical representations that worked to represent this logic (decision tables and decision trees), we are really happy with these diagrams that provide more of an overview.

But the drawback of this kind of diagram is that it is another thing that needs to be created, validated, and maintained.  Oops!  So while a diagram is helpful when sketching a new piece of business logic, once the details are in place should we maintain the graphical representation?

Let's revisit where we began this column.  The hierarchical structure diagram may help you get a better overview of your rules than you have with a flat list.  But you should look for a tool that will generate that hierarchical representation for you, based on the detailed logic expressed in the rules (no matter what representation has been chosen for the details).

References

[1]  Silvie Spreeuwenberg, "Learn from the Expert (Part 1) — A Business Analyst must ask 'Why?'," Business Rules Journal, Vol. 12, No. 3 (Mar. 2011), URL: http://www.BRCommunity.com/a2011/b584.html

# # #