Organizations whose core business relies on the quality of a large number of business rules, or whose main objective is to apply and regulate processes based on business rules, feel the need for quality measurement of their utilization of these rules.  The rules may be utilized in software, but they might as well be utilized in company policies or procedures.

How can an organization be sure that its business rules are consistent, complete, and accurate when rules are subject to change, are applied in a changing environment, and have different sources (who are sometimes not aware of each other)?  The answer to this question is quite difficult and in the next paragraphs I will provide some guidelines for a business rules practitioner who wants to make an effort to measure the quality of a set of business rules.

Definitions

In this article I will use the following definitions:

Verification is the process that aims for the detection of inconsistency, incompleteness, or redundancy in a set of business rules, without consideration of the 'meaning' of the rules.

This means that 'verification' does not care about the correctness of the business rules, e.g., whether their effect is indeed the intention of the business.  Even if it can be proved that the rules are logically consistent and complete, the rules may still lead to incorrect results ... but they will do so in a consistent way.

Validation is the process that aims for the detection of incorrect results or undesired behavior.

The most common way of validating rules is to just pass the (changed) rules to another member of the organization.  In the context of an IT-project, validation is often done by testing the application and assessing the results, or comparing the results with previous results that were believed correct.  Validated rules or business cases are approved by members of the organization responsible for the rules.

Inconsistency is a condition in a set of business rules that occurs when two or more rules lead to a conflicting result or behavior.

Incompleteness is a condition in a set of business rules that occurs when there exists a business case that leads to undefined results or behavior.

Redundancy is a condition in a set of business rules that occurs when there exists a business rule that has no significant contribution to the possible results or behavior.

Anomaly is a more general term for inconsistency, incompleteness, or redundancy.

The quality of a set of business rules is high when:

1. Every distinct business case leads to only one possible result or behavior.
2. Every possible business case leads to some result or behavior.
3. Every rule, applied on any business case, has a significant contribution to the result or behavior.

Informal business rules are statements or declarations in natural language.

Formal business rules are statement or declarations in a logical or mathematical language.

Rules must be precise

In order to verify a set of business rules, it is essential that they be formulated in a non-ambiguous way.  The best way to achieve this is to translate the (informal) business rules into declarations in a formal language.^[1]  I will not elaborate on this formal language because the practitioner can choose from a broad variation of languages that have been developed in the last 50 years.  There are modeling languages as well as software implementation languages suitable for this task.

In my experience, however, it is recommended that the language is declarative.  In a pure declarative language every 'declaration' has an equal priority.  This property of a declarative language is extremely helpful when you try to translate the informal business rules to formal rules because, if two business rules must always be applied in a particular order, the organization has a potential problem when one ore more of these rules (have to) change.  So, the quality of a business rule set is higher when the rules can be applied on a business case in no particular order.

Terms must be unambiguous and constrained where possible

Another prerequisite for the quality assessment of a business rule set is the preciseness of the definition of the various terms used in the rules.  Of course, these terms must be an unambiguous.  Furthermore, it is of great importance that many terms can be constrained to possible values or ranges of values.^[2]  In my definition of verification, we do not care about the meaning of rules, nor do we care about the meaning of the terms used in these rules, so we have to depend on what we can derive from the business rules' logic and the definition of the terms.

Thus, in order to verify the rules as thoroughly as possible, we also need the definition of obvious terms.  The term 'Age' (for example) could be constrained to a value greater or equal to zero.  In the case that there are business rules that lead to unpredicted results when the age is less than zero, we can just ignore that condition.

If we consider the term 'Percentage' it is not obvious at all how to constrain it to possible values.  Is it a value between 0 and 1, or is it a value between 1 and 100?  Or even more importantly, can it be less than zero or greater than 100?

The business rule practitioner must have an answer to these questions, which (in some cases) can lead to discussions between business experts.  This is another example of how the quality of a set of business rules can be improved even before the verification process has started.

Constraints for impact analysis

In many cases, the business expert will argue that a term must not be constrained to, for example, only positive values (i.e., even the yearly income of a citizen can be negative).  In my opinion it would be invaluable to find out which cases would be problematic (e.g., lead to unpredicted results) when the term is actually constrained to positive values!

With verification we can actually search for business cases that are not properly handled, by assuming that there are no extremities.  In this way, if we do not allow negative values for a specific term we are able to find holes in the business rules' coverage.  After identifying these problematic cases, the business rules are adjusted and then we can safely remove the constraint from the term.

Some business rules are compressed

Consider the following business rules:

'If the customer buys more than 5 items, the discount is equal to 20 percent of the total check.'

'If the discount is less than 5 Euro, the discount is 0 Euro.'

Remember that in a declarative language, the second business rule cannot be right since a discount cannot be 4 Euro and 0 Euro at the same time.  These two business rules are actually compressed from three business rules that more exactly express what the business means:

'If the customer buys more than 5 items, the calculated discount is equal to 20 percent of the total check.'

'If the calculated discount is less than 5 Euro, the given discount is 0 Euro.'

'If the calculated discount is greater or equal to 5 Euro, the given discount is equal to the calculated discount.'

The actual verification

In the verification process, the business rules practitioner must prove that:

1. Every distinct business case leads to only one possible result or behavior.
2. Every possible business case leads to some result or behavior.
3. Every rule, applied on any business case, has a significant contribution to the result or behavior.

These three requirements are the 'business rules' for an engineer who wants to prove that a set of rules is of high quality.  For each requirement there is, of course, a set of techniques that one can apply in order to detect violations to the requirement.  I will discuss them briefly so that the reader knows the kinds of task that are involved in a verification algorithm.

1. If a term is defined or assigned a value in two or more rules, these rules are subject to investigation if the definition or assigned value is different.  We have to prove that these rules do not apply to the same business case at the same time.  If you can find one business case for which two or more of these rules apply -- and thereby define the term differently -- you have detected an inconsistency.

   Example business rule:  If the applicant's age is less than or equal to 18, the form must be signed by one of the applicant's parents; if the applicant's age is greater than or equal to 18, the form must be signed by the applicant.

   Detectable problem:  If the applicant' age is exactly 18, it is unclear what the desired behavior of this business rule is.  Note:  It may not be a problem at all since you can argue that both rule parts apply and the application will be signed by both the applicant and one of his/her parents.

2. A term can be used to define other terms, or to calculate a value for another term.  We must prove that all possible values of that term will lead to a valid conclusion.  We must also prove that each possible value of that term is a reachable conclusion.

   Example business rule:  If the applicant's age is less than 18, the form must be signed by one of the applicant's parents; if the applicant's age is greater than 18, the form must be signed by the applicant.

   Detectable problem:  If the applicant' age is exactly 18, it is undetermined what the desired behavior of this business rule is.

3. Every applied business rule should have a significant contribution to the results of every possible business case.  So if we can find a business case that causes two or more business rules to apply, where just a subset of these rules is sufficient, we have found a case of redundancy.

   Example business rule:  If the applicant's age is less than 18, the form must be signed by a parent; if the applicant's age is less than 21, the form must be signed by one of the applicant's parents; if the applicant's age is greater than 20, the form must be signed by the applicant.

   Detectable problem:  If the applicant' age is less than 21, there are two (sub) rules that apply.  They both have equal results, so one of them is redundant.

Note:  The examples are all very simple, but you can imagine how a problem can be hidden in a complex chain of logic reasoning.  In the examples, the business rule could be an article from an insurance policy, but many articles in such policies use terms defined in other articles or calculated by other rules, making the potential inconsistencies hard to find.

Some anomalies are not problems

As I stated in earlier in this article, the verification process does not bother with the meaning of the business rules or of the terms being used in these rules.  This means that the results of the verification process have to be validated by applying business knowledge.  This also implies that not all detected problems are errors in the rules per se.  I would rather call them 'attention points.'

Many organizations deal with necessarily redundant rules.  It is a fact that all variations of rule utilization (policies, procedures, or applications) contain overlap, e.g., they do not deal with a distinct set of rules.  For example, some business rules are applied both in the front office and in the back office.  In multi-lingual countries, on the other hand, it is essential that exactly the same rules be defined in their respective languages.  It is important, though, that this redundancy of business rules does not lead to inefficiency, so a redundancy-scan should always be performed in the context of a business process.

In the medical world it is perfectly normal that a diagnosis can lead to more than one (and thus inconsistent) possible causes and cures.  The experienced doctor will make the right decision.

In much legislation there exists incompleteness because the legislation only regulates the desired actions in certain cases.  You will not soon find a rule in legislation that describes the actions to be taken by the government if a citizen has not violated any law.

Assessment of verification results

When the business rules practitioner detects a problem in the rules, he/she will first verify whether the formal rules were translated correctly from the informal rules.  If the translation is correct, then a dialogue has to be set up with the business expert(s) about the detected problem.  In some cases this will lead to additional business rules that the business expert forgot to mention; in other cases there will be a topic of discussion between business experts because they have to decide whether the problem is really a problem and, if so, how to deal with it.

If you choose to use an automated verification process, you can use the verification program also to perform impact analysis in the conceptualization (or design) phase of new business rules.  If you want to know the impact of a modification in your business rules, you can check whether your suggested modification gives rise to logical problems in other rules.

Automated verification

In previous sections, I emphasized the importance of translating the informal business rules to a formal language.  This formal language is almost always interpretable by a computer.  An interpreter uses a formal syntax description to which the language must comply.  The interpreter is thus able to detect syntax errors when a business rule was not written according to the particular syntax description.

Many interpreters have been developed over the years for different purposes.  The interpreters of modeling environments often have the capability to simulate the models with business cases; others are able to translate the models to software languages.  Software languages in turn, are interpreted to generate a computer program.  The technology used for interpreting the formal languages is as old as these languages and is fairly sophisticated.

Although there are many formal languages and interpreters, there are not many verification techniques applied that are able to detect the kind of problems that I have described in this article.  It is clear, though, that the need for these techniques is ever growing.

LibRT has developed a system that is able to search for anomalies in a set of formal business rules.  The rules must be provided in a clearly-defined way, which we call the Rule base Markup Language (RBML).^[3]  This language is downloadable from our website (www.LibRT.com), and you can use it to describe business rules in a non-ambiguous way and in a verifiable way.

Correction of detected problems in business rules

Some people will argue that if you can detect a problem in the business rules, you should also be able to fix the problem.  I often use the following example to prove that this is really a task of the business experts (or, more specifically, the owner of the business rules).

An exemplary classification rule set:

If the animal builds a nest then it looks for straws.

If the animal is a bird then it lays eggs.

If the animal lays eggs then it builds a nest.

If the animal looks for straws then it is a horse.

If the animal has wings then it is a bird.

The verification process should detect a problem since the classification rules determine that the animal is a horse when it looks for straws, but if it has wings the rules will determine that it is a bird.

There are no rules that state the fact that a horse cannot have wings.

Remember that the rules are written in no particular order.  If these rules were translated to a formal language and then translated into a computer program, this program would probably lead to different results when the same properties of the (to-be-classified) animal are passed to the program in a different order.

This example also shows that it is not obvious at all how we must change the rules in order to make them consistent.  We can add an extra premise to the fourth rule, stating that the animal must have wings as well; we can change the existing premise of the fourth rule, stating that it must eat straws.  We can add an extra rule, stating that an animal that does not have wings does not look for straws.  And, of course, we can simply delete the fourth rule.  A business rules practitioner can propose these options to the expert, and it is really the expert's task to choose one.

Storing the verification results

In this final section, I will outline the importance of storing the verification results for future reference.

If the organization is able to store the results, it is also able to:

• Track the history of a business rule, or a set of business rules.

  If someone asks:  "what is the purpose of this business rule?" the reason might be that it was introduced to prevent inconsistent behavior of other business rules.

• Store the acknowledged (but not solved) verification problems, in order to revise them in the future.

  They can also be used as a reference to future verification sessions:  if a problem is detected that is already acknowledged, we can ignore it this time.  On the other hand it would be interesting to know whether existing problems have disappeared after changing the business rules, although the changes were not made for that purpose.

• Analyze the cause of newly-detected problems (a very advanced application for stored verification results).

  A change in the business rule may lead to unexpected behavior cause the 'reasoning-path' to go into another direction, which may include known inconsistencies or incompleteness.

Conclusions

Verification techniques can be of great help if an organization wants to measure the quality of its business rules.  IT systems can be of great help to perform verification since one of the prerequisites of verification is that the rules are translated into a formal language.  This formal language may also be suitable for embedding the rules into software, but verification techniques can be applied even before an IT system attempts to automate the business rules.  And, then again, verification techniques can be applied on business rules without having in mind, a specific application for these rules.

References

[1]  R. Ross.  "A Tutorial on the Formal Basis for Business Rules and Business Rules Notations," Principles of the Business Rules Approach (Part V).  Addison Wesley, 2002.  

[2]  Michael H Brackett.  Data Resource Quality.  Addison Wesley, 2000.  

[3]  Drs. Silvie Spreeuwenberg, "Using Verification and Validation Techniques for High-quality Business Rules," Business Rules Journal, Vol. 4, No. 2, (February 2003), URL:  http://www.BRCommunity.com/a2003/b132.html 

# # #