It's no surprise that business-oriented people and system-oriented people think differently, but what impact does that difference have on writing rules?  Why do so many system people believe they are writing rules in "natural language" while the business people just shake their heads in disbelief?  This article explores some of the differences in the way each group approaches writing rules.

Vocabulary

If you have any experience with writing rules, you know the importance of using a consistent vocabulary.  And, of course, that vocabulary should consist of defined business terms.  Everyone seems to agree on these important points; however, here is where we actually have the first divergence in thinking.

Business people use natural language to express themselves and to write business rules.  They put words together into (hopefully) coherent sentences using the rules of grammar.

System people think in terms of data and, more specifically, data elements.  This perspective is important because any automation of the business rules will need to access data in order to determine if a rule is being violated.  Many system people believe that naming the data elements in a more business-friendly way (e.g., insurance_policy rather than INS_POL), and providing definitions for the data elements is the same as using the business vocabulary.  It is not.

Once you look at things from the perspective of storing data, it forces you to create data "things" to support the richness of the business language.  For example, in a car rental company, there may be a business rule that states:

A vehicle must not be rented if it is damaged.

From a business perspective, the rule builds on the facts "vehicle is rented" and "vehicle is damaged".^[1]

From a system perspective, the way to know that a vehicle is damaged is to check whether a flag or indicator is set to a certain value.  So, a system person may write the rule as:

If damaged_flag = "Y" then disallow rental.

Although flags and indicators are a very useful way to store information about the state of something, business people simply do not think in those terms.  To them, a "flag" is a rectangular piece of cloth used as the symbol of a nation, state, or organization!

Nor do business people think in terms of things having "values."  From a systems perspective, the values in a data element or field need to be checked to determine whether or not a rule is being violated.  For example, a business person might write the following rule:

A customer renting a vehicle in New York must be over the age of 21.

A system person might write the same rule as follows:

If rental_state = "NY" and customer_age <= 21 then disallow rental.

Not only is New York expressed as a value of rental_state, but it is also a code -- another system "thing" that is not used in natural language.

So you can see how the concept of "business vocabulary" is interpreted differently from a business and a system perspective.

Providing Guidance vs. Checking for Violations

In business, high-level policy is set by management and is then interpreted into business rules that guide business behavior at the operational level.  These business rules often support various decisions such as whether a customer qualifies for a discount, a claim is valid, or a purchase order requires approval.  In order to do this, the rules often need to be expressed in a positive form to indicate what is allowed.  Some examples are:

1. A rental with a rental charge greater than $2,000 must be approved by a branch manager.
2. A discount greater than 15% may be given to a customer only if the customer is a platinum loyalty program member.

The main objective in automating rules is to ensure that they are consistently enforced.  In order to do this, it is necessary to detect violations of the rules and take the appropriate action in response.  Note that none of the business rules above indicate what action to take if the rule is violated; they only deal with what needs to be true.  This important difference in perspective changes the rule from simply stating the rule to including the violation action.  This is where the use of the "if…then" statement comes in, which provides the structure to express the rules in the format "if the rule is violated, then take this action".  The rules above would likely be written as follows from a system perspective:

1. If rental_charge > $2,000 then send_for_approval.
2. If discount > 15% and loyalty program level < > "platinum" then display_error_message.

Both "send_for_approval" and "display_error_message" are likely subroutines that automatically send the rental to the manager for approval and display an error message of some sort, respectively.

Note that, in the second example, the system version treats the outcome (i.e., the discount given) the same as the condition (i.e., platinum level) whereas the business version keeps them distinct, with the condition(s) at the end.  Another key difference is that the business version expresses the condition in the positive (customer is a platinum…) whereas the system version is expressed in the negative (customer is not platinum) because it is checking for cases where the rule is violated.^[2]

Use of the Rules

As you can see from the examples above, the two perspectives result in very different expressions of a rule.  Both of these perspectives are required in order to effectively manage the rules.  Business people need the business form to:

• Manage the business,
• Ensure compliance with regulations,
• Provide direction to employees,
• Think through business intent before implementation,
• Manage all the rules whether they are manual or automated.

System people need the system form to:

• Ensure that the rules are not being violated,
• Ensure data integrity,
• Respond appropriately to violations of the rule,
• Manage the automated rules.

Note that it is important that the two forms are related in order to maintain traceability.  The business form of the rule should always be the starting point for any analysis or changes.

Conclusion

There is often resistance in organizations to having both the business and system forms of a rule.  This is due to a lack of understanding of the difference between the two forms, but also stems from a reluctance to invest the additional effort required to maintain them both.  With a better understanding of the business and system perspectives, it is clear that, as both forms are essential to properly manage the rules, the additional investment is warranted.

References

[1] For a detailed discussion on writing rules using facts, please see: Ronald G. Ross, Principles of the Business Rule Approach, Boston, MA:  Addison-Wesley, (2003), ISBN:  0-201-78893-4  

[2] For a more thorough exploration of the impact of the "if...then" statement on the treatment of conditions and the reversal of logic, please see 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   

# # #