This column is inspired by one of my recent consulting assignments.  In this project I reviewed the work of a couple of novice rule authors.  I believe you may learn (as they did) from the notes I made.

Actually, I will only discuss one example rule — the same example rule I used during a 45-minute lecture at the Building Business Capability Conference in 2010.  For me, it was quite an improvement to discuss only one rule in 45 minutes and to experience that the audience was satisfied.  There have been conferences where I have tried to discuss at least 20 quality issues and examples in 45 minutes, resulting in an exhausted audience!  As a novice presenter, I too had to learn the hard way….

My dear novice rule author wrote the following rule.

The policy end-date of an insurance X must be the most recent date of the following dates:

• the derived end-date of an insurance X,
• the day before the day on which the person belonging to insurance X reaches the age of 65,
• the policy effective date of the insurance X plus the number of days left,
• the day before the policy effective date of insurance Y of the person belonging to insurance X,
• the first day of the fourth month after the due-date of the invoice where the open amount on the amount owing is greater than zero,
• the latest due date of an information request with a request due date of the person belonging to the insurance X, not being about income, on insurance X when the information request does not have an answer date,
• the date of death of the person belonging to insurance.

This has been translated from Dutch and slightly modified.  The terminology may be a little strange, which may be caused by the translation, but I have to say that the rule was already strange in Dutch.  Imagine that I was to validate the rule on correctness with the business expert!  The business expert read the rule but said, after the third try, "I don't like to read this rule."

I agree with her, so let's analyze why this rule is not nice to read.

The rule is complex because there are so many different concepts involved in the statement — twenty-three.  In my previous column, I argued that the number of concepts (and not the number of rules) is a measure of complexity in a domain.  It turned out that these 23 concepts could be grouped in 3 'kinds' by the role they play in the criteria for the policy end-date.  This grouping is the key to managing the complexity (that does exist).

I managed the complexity by asking, for each of the criteria in the list, "Why is this criterion relevant?"  Below is part of the transcript from the resulting conversation:

Novice rule author:  "...  the day before the day on which the person belonging to insurance X reaches the age of 65"

Expert rule author:  "Why is this criterion relevant?"

Business expert:  "… because the eligibility ends at the age of 65."

Expert rule author:  "And the next one, why is that criterion relevant?"

Business expert:  "… also because the eligibility ends."

I grouped the answers and found out that there were only three relevant criteria for determining the end-date of a policy:

1. the customer is not eligible (anymore),
2. the customer stopped paying,
3. the customer does not want to be insured (anymore).

We ended up with four atomic rules that are easy to understand and validate.  The general rule states:

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.

Now we can write three additional rules to define the different criteria.  As an example, I will give you one of them:

The date an insurer stops payment for his insurance must be equal to the day after the due-date of an open invoice for the insurance.

Nowadays there is renewed interest in graphical ways to state rules (compared with the textual format used in these examples).  In my next column, I will assess whether these graphical methods would have helped our novice rule analyst as much as asking the 'WHY? question'.

# # #