The Business Rules Approach

One of the characteristics of the business rules approach is that business people are in charge of specifying business rules.  A business rule is a statement that defines or constraints some aspect of a business.^[1]  The business rules approach makes a business aware of business logic that is often buried in legacy systems, legislation, memos, informal local practices (and so on), and offers a method for gathering the rules.

Once you have gathered all the rules and have written them down in declarative statements, you can use the rules in a variety of ways:  to guide day-to-day work, to assist business in decision-making, to formulate procedures, or as the "business logic" implemented in IT systems.  But before you do so, you should guarantee that your business rules have the right quality.

A quality check is especially important for the acceptance of the business rules by other people -- people who where not involved in the process of gathering the business rules but who need to continue their work based upon the rules, for example, an IT department that is supposed to implement the business rules in a new IT system, or a manager who must communicate the rules to workers who will use the rules in their day-to-day work.

We will see in the coming examples that the quality check is also important when rules change, so that the effects of a new rule on an existing set of rules can be assessed.  Furthermore, let us not forget that gathering rules is a human activity that is not error free.  Humans make typing errors, forget things, and can read over errors any number of times without noticing them.

What Do We Mean by 'High-quality'?

High-quality business rules are well structured, consistent, and correct.  The first property (well-structured) can be enforced by using rule templates or a well-defined rule syntax.

The second property of high-quality business rules (consistency) means that the business rules are expressed in the right way.  Checking this property is called 'verification.'  A verification process looks for "attention points" that might give hints for incorrect rules or wrongly expressed knowledge.  An overview of attention points is given in the Sidebar, "Verification Checks."  If one of the listed attention points is found in a ruleset, the statement should be checked to see if it needs modification.  Which checks call for modifications is very much a function of the knowledge domain.  In some domains contradictions are legitimate; in others, not.

Business rules are correct (the third property of high-quality business rules) if they express what the business wants to express.  Checking this property of business rules is referred to as 'validation.'

Validation and verification are often confused.  The statements in Figure 1 can help in avoiding this confusion.

What is a 'Low-quality' Business Rule?

The definition of 'low-quality' depends on the knowledge domain and the way the rules are going to be used.  Imagine that we have the following business rule:^[2]

Each car must be serviced every three months or 5,000 miles, whichever occurs first.

This rule is readily understood by humans, so it has the right quality when humans use it.  However, for a computer program to deal with this rule we need to make the rule more formal.  In a formal rule, each term has one well-defined meaning.  The above rule can be translated into the following two formal rules:

Service rule 1 for car

IF months since last service date = 3     THEN must be serviced = TRUE

Service rule 2 for car

IF number of miles since last service date = 5000     THEN must be serviced = TRUE

At first sight this seems to be a very good translation of the business rule.  However, verifying this rule results some 'points of attention.'  First of all, the two rules are redundant because they share the same action.  You can combine them into a single rule to improve the maintainability of the rule.

Another point of attention is that the rule is not complete with respect to the possible values that the variables can take.  We should define what should happen when more than three months or more than 5000 miles have passed since the last service date.  Finally, we should define when the car must not be serviced to have a complete, non-redundant, and consistent set of rules.

Here is the result of this improvement:

Service rule 1 for car

IF months since last service date => 3   OR number of miles since last service date => 5000         THEN must be serviced = TRUE

Service rule 1 for car

IF number of miles since last service date < 5000   AND months since last service date < 3         THEN must be serviced = FALSE

This example shows that verification helps us in creating more precise formulations.  In the next section we will explore the benefits of being so precise and formal.

Can We Make an Automatic "Quality Checker"?

Checking whether a business rule is well structured can be done automatically.  The quality and difficulty of the check depends on the structure you have chosen for your business rule.

You can choose to use natural language as your expression language for business rules and apply some constraints on how you structure the statements.  An example of a constraint is requiring a business rule statement to have a subject.  Such constraints can be automatically checked using natural language processing (NLP) techniques, but natural language gives so much flexibility that the rule may still be poorly structured even when the check is successful.

At the other end of the scale you can choose for highly structured formal business rules -- for example, the rules that are used by an inference engine.^[3]  These rules have a well-defined structure and you can automatically check if a rule fulfills this structure.  All the tools supporting this kind of rule will check if the structure of the rule is correct.

Verification -- checking if a (set of) business rule(s) is correct -- can be done automatically when the rules are formally-structured.^[4]  In a formally-structured rule, each element (word) of a rule has a well-defined meaning and role.  Figure 2 gives an example of the structure of a formal rule of a rulebase XML schema.

Validation is another matter.  Rules cannot be validated automatically because, for validation, someone needs to confirm that the rules do indeed express what should be expressed.  So for validation we need knowledge about the world and about the purpose of the system.

However, we can support two aspects of validation:

1. Validation by reviewing
2. Validation by testing

Reading through hundreds of business rules can be boring and tiring.  Sometimes it is much easier to see the correctness of a rule by viewing the rules in combination with other (related) rules in a compact way.  Validation by reviewing rules can be supported by generating one or more highly readable and compact representations of a set of business rules.  Decision trees and decision tables are examples of this kind of representation form.

Validation by testing can be supported by automatically generating and selecting a minimal set of test cases for a set of rules.  The process of presenting the test cases to business users who can confirm their correctness can also be supported by smart software.

Again, automatically supporting validation can only by achieved when the business rules are represented in a formal way.

Examples of the Use of Automatic Verification

This section gives two examples of the use of an automatic verification engine (VALENS) in some practical domains.

The first example is an insurance company that wanted to check the quality of their 'policy conditions.'  The text was first translated to UML/OCL models.  Since these models are highly formal they can be automatically translated to formal rules.  The formal rules where then verified.  We found a lot of redundancy in the rules -- something that was very important for the business to know.  It was an indication that some terms where defined more than once and in more than one way in the text.  As a result of these checks, the text has been changed to eliminate the redundancy.

In the second example, the verification engine was applied to the rulebase system of a Dutch insurance company, the Postbank.  We got the first version of the customer's rulebase to verify when the Postbank development team had finished the rulebase and the testing phase was at hand.  Although the verification engine can be applied earlier in the application development lifecycle it was perfect timing for comparing the results of parallel verification and testing phases.  Here is a summary of what we found:

• The verification engine did not detect any real errors in the knowledge base.  Although this might look disappointing, the testing phase also did not reveal any error that could have been detected by verification.  Remember that technical or logical verification cannot take into account any domain knowledge that is not present in the knowledge base.  (For this reason, a verification engine cannot be used for user acceptation tests.)
   
• The verification engine did find many redundant and obsolete constructs in the knowledge base.  Some of these constructs were intentional, others were not.  But everyone was impressed with the fact that the verification engine was able to highlight all of these 'points of interest.'
   
• The verification engine proved to be useful in maintaining the integrity of the functional specifications of the knowledge base, as well as the realized (and revised!) knowledge base.

When Should You Use Automatic Verification?

Verification can be used and integrated into several aspects of a software development or rule development process.  Figure 3 presents the different steps in a development process and the possible uses of verification and validation techniques.

In general, verification and validation should be used as early as possible in the development process because the cost of repairing mistakes tends to rise exponentially along the course of system development.  We recommend the use of verification when business users create (semi-)formal business rules.  Business users do not typically have a background in logic and therefore can be helped with the use of verification techniques.

Another step in the development process where verification is highly recommended is in rule maintenance.  The original designers of the business rules are often not involved in changes to the rules a couple of years later.  Often, people who do not have a complete overview of all the rules in the system perform these changes, meaning they do not know what the effect is on existing rules when a rule is added or changed.  In this case, verification techniques can help to assess the effect of a change on an existing ruleset.

Conclusions

Quality management of business rules has not gotten much attention in the past.  This is unfortunate because:

1. The fact that business rules can be verified and validated before implementing the rules in IT systems is a selling point for the use of the business rules approach.
2. When your business rules are going to be implemented in IT systems, the development phase can be expedited by delivering verified and validated rules to the IT department.

In this article, I have given several ways to integrate verification and validation into an organization's process.  How you should integrate verification and validation into your own organization depends on the way your business rules gathering process and your system development process are organized.  In any case, you should try to use verification and validation as early as possible since making corrections becomes increasingly expensive the farther you are into the development process.

References

[1]  definition from "Defining Business Rules ~ What Are They Really?" (formerly known as the "GUIDE Business Rules Project Report," 1995), (3rd ed.), July 2000.  Available at:  www.BusinessRulesGroup.org. 

[2]  This rule is from the EU-Rent Car Rental case study, documented in IBID. 

[3]  An inference engine is a software component that can reason with a set of knowledge rules in a formal way. 

[4]  LibRT has developed a verification component ('verification engine') called VALENS, which automatically performs all the verification checks described in the table on a set of formal rules.  VALENS is available as an add-on for CleverPath® Aion® Business Rules Expert, or it can be integrated into the specific environment in use. 

# # #