A central idea of the business rule approach is that business rules should be expressed with business people in natural language.  That seems self-evident.  The Business Rules Manifesto^[1] says it this way:  Rules should be expressed declaratively in natural-language sentences for the business audience.  This is the guiding idea behind RuleSpeak^[2], which I use for the business examples in this discussion.

Is the difference between business-speak and system-speak for expressing (and managing) business rules really that big?  Yes!  And the gaps are much wider and more fundamental than you might think.  It's no surprise then that business people and IT people often feel the other side is speaking Greek. 

Let's first examine a simple rule expressed from the business side to see why.

Rule:  A student must not register for more than 6 classes in a semester.

A key question is what happens if the rule is violated -- i.e., a student tries to register for a 7th class?

The business needs at least two things -- a response to the violation and an explanation for that response.  The natural defaults of the business rules approach are as follows.

• Response to the violation.  The 7th registration is disallowed.  In other words, circumstances or events that violate the rule are to be rejected outright.  Isn't that exactly what you would usually expect?!  It almost goes without saying.
  
  
• Explanation for the response.  "A student must not register for more than 6 classes in a semester."  That's basically it!  Stating the rule itself gives the business explanation.  In other words, the statement of the rule is the most basic part of any 'error' or guidance message to be returned to the worker/user (assuming he or she is authorized and capable) upon any violation.

These two fundamental 'defaults' of the business rule approach greatly simplify business requirements as expressed from the business perspective.  That doesn't cover all business requirements, of course -- just the 100's or 1000's most naturally expressed as business rules.  But that's a pretty big deal!

Before focusing directly on the if-then style, we need to dig a little deeper.  To do the issues involved real justice, we need to look at a more complex rule.  From health insurance we might have the following rule.  (On a personal note, I broke my arm several years ago, so this one really hits home!)

Rule:  The amount claimed for a "sling" must be LE the special limit for an incidental if the claimant is out-of-state and the claim amount is LE $500.

This rule is just one out of 1000s of claim rules.  It is a richer example, coming from an organization that is clearly knowledge-intensive.

Again, a key question is what happens if the rule is violated?  The answer is probably 'it depends'.  In other words, both the response to the violation and the explanation for that response may be selective to circumstances.  That's especially true if we consider re-use of the rule cross-functionally.  (Re-use, of course, is always a pretty good idea!  For rules in particular, it produces business consistency.)  From a business perspective, re-use of the rule means the rule is to be applied at different points with the company's business process(es).

For example, the rule might be used both in responding to customer queries (e.g., "Would I be covered if …?") and for validating actual claims.  Clearly, the appropriate response depends on the situation.  For the former, it might be a polite message.  For the latter, the hammer comes down and the claim gets paid or not paid.  Here then is a fuller view of the business rule.

Rule:  The amount claimed for a "sling" must be LE the special limit for an incidental if the claimant is out-of-state and the claim amount is LE $500.

	Applicability Condition	Response to Violation[3]
1.	The claim is submitted for inquiry only.	Return polite message to the submitter.
2.	The claim is submitted for payment.	Mark the claim non-payable.

This more complete view of the business rule introduces the notion of applicability conditions.  Essentially, applicability conditions represent a certain kind of externalized "if" condition.

Notice that the rule statement remains exactly as it was before.  No changes.  Think of the actual business rule as that part of the business logic that remains constant even if responses to violations vary for different circumstances.

Why is that important?  In a business with 1000s of rules, keeping your eye on the 'constants' is not merely helpful, it's essential.  Otherwise, the number of rules starts to balloon out of control.  That's one of the undesirable consequences that results from the if-then style, to which we now turn.

Clearly, many IT professionals do prefer the if-then style for expressing rules.  Why?  Put simply, it's closer to what they need for implementation, whether under a rule engine or a programming language.  Consequently, they often resist expression of the rules from the business perspective.

What does that do to the rules themselves?  There are two highly undesirable consequences.  One, as above, is that the number of rules balloons.  Second, the business intent of the rules often goes missing.  These effects aren't necessarily obvious when you look at only one rule at a time.  But the problem compounds.  It really hits you hard when you scale up to 100's or 1000's.  At that threshold (or even before) there are simply too many rules to keep straight in your head.

The if-then style of expressing rules generally involves three major departures from business expression.  To illustrate I'll use the 'sling' rule above.  Again, keep in mind that analysis of a single rule can't completely convey the true magnitude of the problem.

1.  Reversed Logic.  Business people express rules focusing on the condition(s) not to be violated.  Common use of the if-then style, in contrast, focuses on the condition(s) causing a violation, forcing you to switch the logic around.  Most rule engines and programming languages today require that switch.  For the 'sling' rule, this means reversing "less than or equal to" (LE) to "greater than" (GT).  Doing a lot of that can give you mental whiplash!

Business Perspective … The condition not to be violated	The amount claimed must be … LE the special limit …
IT Developer Perspective … The condition causing a violation	If the amount claimed is … GT the special limit …

2.  Different Lead-Off.  Business people naturally tend to express rules focusing on the constraint to be enforced.  That comes first.  Rules expressed in if-then style always start off with "if" -- that is, they always put any and all condition(s) first.  That's because most rule engines and programming languages are looking (step one) to determine whether these condition(s) are satisfied, in order to know (step two) whether to take some action.  Unfortunately, that means in reading the rule you don't get a real sense of where it's headed until you actually get there (and maybe not even then).

Business Perspective … The constraint comes first	The amount claimed must be … LE the special limit …
IT Developer Perspective … The condition comes first	If the claimant is out-of-state and the claim amount is LE $500 …

3.  Mandatory response.  Business people often express business rules assuming the default response, disallow violations.  (Let's ignore potential re-use for the moment.)  The if-then style does not have any such default, so some relevant response or action must always be specified.  Otherwise, most rule engines and programming languages simply won't work.  As a consequence, IT developers often have to invent responses, which naturally tend to be system-ish.  Ironically, IT developers often criticize business expression of rules as not being 'sufficiently detailed' because they lack these very responses.  Of course, it's detail without any real business purpose.

Business Perspective … "Disallow violation" assumed	(Disallow violation)
IT Developer Perspective … Action taken if the rule is violated	If … then set don't-pay-flag(?)

To summarize the points above, transforming rules expressed in business form into counterparts expressed in if-then style therefore requires (1) reversing the main condition, (2) putting the conditions first, and (3) giving an action even if none was indicated.  Applying these transformations to the "sling" rule, we arrive at the following.

Business Perspective …	The amount claimed for a "sling" must be LE the special limit for an incidental if the claimant is out-of-state and the claim amount is LE $500.
IT Developer Perspective …	If the claimant is out-of-state and the amount claimed for a "sling" is GT the special limit for an incidental and the claim amount is LE $500 then set don't-pay-flag.

What has happened?  In the original rule, the constraint part ("The amount claimed for a "sling" must be LE the special limit for an incidental …") was clear.  In the transformed rule, the constraint part loses its pre-eminent status and becomes just another condition.  Do you see it?  I purposely stuck it in as the second of the three ANDed conditions (with the LE reversed to GT) just to make the following point more forcefully.  In a rule with many conditions (which covers the majority of rules), the true sense of the rule gets lost very easily.

Unfortunately, that's not the end of the bad news for the if-then style.  Let's now factor in re-use of the business rule for different business functions and the selective responses to violations such use might require.  A key point made earlier is that the expression of the business rule should remain the same even if different responses to violations are required at different points.  One rule, multiple responses.

That's not how it works with the if-then style.  Rather, you must create a separate rule for each selective response because the appropriate applicability condition must be ANDed in.  For the 'sling' rule, this results in the following two rules.  By the way, in each case I placed the applicability condition last among the ANDed conditions for the sake of clarity, but nothing (other than perhaps sanity) compelled me to do that.  Are you beginning to see how business intent gets lost so easily using if-then?

	Applicability Condition	'Sling' Rule in If-Then Style
Rule 1.	The claim is submitted for inquiry only.	If the claimant is out-of-state and the amount claimed for a "sling" is GT the special limit for an incidental and the claim amount is LE $500 and the claim is submitted for inquiry only then display "We're sorry, you wouldn't be covered".
Rule 2.	The claim is submitted for payment.	If the claimant is out-of-state and the amount claimed for a "sling" is GT the special limit for an incidental and the claim amount is LE $500 and the claim is submitted for payment then set don't-pay-flag.

To conclude, let's turn the tables and ask why business people often find the IT-friendly if-then style of rules so hard to follow and validate on any large scale.  First note that in the analysis of the sample rules above, I propagated natural business terminology into the if-then rules, rather than substituting system names for corresponding data fields or equivalent.  That, of course, is an inevitable complication, but a fairly obvious one. 

A deeper reason, illustrated above, is that all conditions are treated equal in the if-then style; that is, no kind of condition has any special standing.  That approach obscures which conditions represent (a) the original constraint part of the rule, and (b) applicability condition(s), if any.  In other words, business intent is quickly obscured.

That problem is aggravated by a second reason -- the ballooning number of rules.  That's harder to illustrate.  However in the one-rule example above, using the if-then style doubled the number of rules. 

Is that a reasonable estimate for a larger scale?  I believe this hidden 'balloon factor' might sometimes be much worse.  In any case, ask yourself whether you would rather analyze and manage 100 rules or 200?  A 1000 or 2000?  10,000 or 20,000?  It's obvious.  The Manifesto puts it quite simply, "'More rules' is not better"(!).

References

[1] Business Rules Group, Ronald G. Ross, ed., Business Rules Manifesto ~ The Principles of Rule Independence. 1.2 ed., The Business Rules Group (2003), Updated Jan. 8, 2003.  PDF.  Available at www.BusinessRulesGroup.org, now in ten languages.

[2] Ronald G. Ross, Principles of the Business Rule Approach, Boston, MA:  Addison-Wesley, (2003), ISBN:  0-201-78893-4, Chapters 8-12.

[3] In general, responses to violations can take the form of processes or actions (as in this example), and/or other rules or rule sets.

# # #