What’s Wrong with If-Then Syntax For Expressing Business Rules

13320 Views
12 Comments
18 Likes

What’s Wrong with If-Then Syntax For Expressing Business RulesMany IT professionals currently prefer the if-then form 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 expressions of rules from the business perspective as business people would naturally prefer them. But what effect does that have on the rules? Highly undesirable consequences result. This month's column reviews these consequences and explains step-by-step how they come about.

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 Manifesto1 says it this way: Rules should be expressed declaratively in natural-language sentences for the business audience. This is the guiding idea behind RuleSpeak2, 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!

Context of Enforcement for Business Rules

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? As discussed in a previous article, 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 Violation3

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.

Using the If-Then Style for Expressing Business Rules

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 Business Rules Manifesto puts it quite simply, "'More rules' is not better"(!).

Acks to Gladys S.W. Lam, Principal, Business Rule Solutions, LLC, who co-developed the ideas presented in this discussion.

Ronald G. Ross

Author: Ronald G. Ross - Featured Speaker, www.AttainingEdge.com.   Ron is also Co-Founder & Principal, Business Rule Solutions, LLC
Chair, Business Rules Forum Conference

For more about the author, see www.RonRoss.info.


1 Available at www.BusinessRulesGroup.org, now in a dozen languages.

2 Basic RuleSpeakR guidelines are available for free in English, Spanish, German and Dutch on www.RuleSpeak.com.

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.

Article Image: Bosse Sudenburg | IF THEN | 2009 | Lightbox | 167×120x15 cm

 

Like this article:
  18 members liked this article
13320 Views
12 Comments
18 Likes

COMMENTS

baldrick posted on Tuesday, December 14, 2010 3:52 PM
Of great interest to my current position:
I liked the example -
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?

But the insurance claim example will confuse readers who have never made an insurance claim, and the autrhor assumes that everyone will automatically understand the abbreviations GT, LE, etc.

Before attempting to model a business rules, try rewriting it in a positive sense. It is much easier to model the finite restriction, than it is to model the infinite negatives outside of the restriction (and impossible to test).

A simple rule - 'Nothing is allowed, unless I say it is'. This is the basis for my requirements. Using this rule, a student cannot register for ANY classes until I write a requirement saying that they can.

Ok, so I have the requirement that (on top of my basic rule, that nothing happens), a student can registier for classes. Then a regulatory person comes along and adds a Business Rule, restricing this requirement to a maximum of 6.

So now my requirement reads,
A student may registier for 1 to 6 classes (zero being out because 0 implies they are not a student).

Notice the requirement is written in a positive manner, saying what students may do (bounded) and not what they may not do (unbounded).

Writing in this manner one does not need to consider what happens if they try to apply for more than 6 classes (note; more than 6 includes 8,9,10,11 .. not just 7).

The same thing that would happen if they tried to apply for less than 1 class .. it can't happen!

Remember a business rule is a restriction on a requirement, because without that requirement .. 'nothing happens'.
rross posted on Tuesday, December 14, 2010 4:23 PM
A couple of responses to baldrick, who says:

1. "A simple rule - 'Nothing is allowed, unless I say it is'. This is the basis for my requirements. Using this rule, a student cannot register for ANY classes until I write a requirement saying that they can."

>> You are making what is sometimes called a dark-world assumption: Everything is disallowed unless specifically allowed. That's appropriate in some circumstances ... for example, authorization. Generally, however, business operates on a light-world assumption: Anything is allowed unless specifically disallowed.

Can you imagine how many business rules you would have to have if business operated on a dark-world assumption?! Besides, you would take away all the discretion and creativity that business depends on.

I believe you have fallen into the common trap that confuses a business rule with a requirement. A business rule is what you need to run the business, with or without machines. A requirement is a design element for building a system. Very different things.

2. "Remember a business rule is a restriction on a requirement, because without that requirement .. 'nothing happens'."

>>Somehow businesses did manage to operate before there were computer systems. Stuff definitely did happen. (Some of us are even old enough to remember.)

A business rule is a restriction on the business, not 'on' any requirement. What requirements for a system result from a business rule is another question.

There is an awful lot of confusion on this point.

P.S. The discuss of dark world vs. light world is based on SBVR Clause 12.4.2.
baldrick posted on Wednesday, December 15, 2010 2:09 PM
Thanks for taking the time to respond:

Yes, my comments are based on implementation of the business and its rules. The fact that I am modeling sort of implies an implementation. (A model is an implementation, not necessarily an executable one, but an implementation nontheless.)

When modeling we start with a blank sheet, with nothing on it. (The dark world.) It is only when you add to that model that things start to happen.

If you start with a light world (where everything can happen), and you take away the bits that you don't want - well I can't imagine that you'd ever come up with a complete model.

Does business really operate on the principal that everything can happen and we need business rules to restrict our operations?

I do not see that as a feasible way to operate, with or without a model. Take my current business for example.

I work with ferry public transport. In the beginning there was no ferry (dark world). We put a ferry into service and now we have functionality concerning a ferry service. We make up business rules that restrict the way the ferry service operates in order t make it efficient, safe, etc.

What we do not do is consider business rules for restricting the way an airline or a bus public transport service works, because they do not affect us. In the light world we would consider all public transport operations - no?

Maybe I misunderstood the definition of light world, but I prefer to start from the assumption that 'nothing happens' (dark world), whether capturing the business operations or implementing requirements for a system.

Leslie.

P.S. Now I am searching for SBVR Clause 12.4.2., so I may have to add to my reply.
rross posted on Wednesday, December 15, 2010 5:55 PM
Responses to Leslie who says:

"If you start with a light world (where everything can happen), and you take away the bits that you don't want - well I can't imagine that you'd ever come up with a complete model."

RGR: Without rules you have anarchy, literally. You can't tell a bunch of guys (and gals?) to go out and "play football". You might have lots of activity, but it would literally be chaos. So what do you do? You create a rulebook. In the game of football, pretty much everything is allowed unless explicitly not allowed. That's a "light world". The same holds true for just about any social endeavor you can think of that humans create.

"Does business really operate on the principal that everything can happen and we need business rules to restrict our operations?"

RGR: Yes. Think contracts, agrements, laws, regulations, business policies, do's & don'ts, etc. That's the way it does work.

"I work with ferry public transport. In the beginning there was no ferry (dark world). We put a ferry into service and now we have functionality concerning a ferry service. We make up business rules that restrict the way the ferry service operates in order t make it efficient, safe, etc."

RGR: Business rules are not about modeling or creating something (especially IT systems). They are about shaping and guiding on-going activity (of ferries and captains and passengers, etc.). Look around. I bet you can find a lot of those kind of business rules.

zarfman posted on Wednesday, December 15, 2010 10:37 PM

Hi:

Most of the companies that I’m familiar with have some kind of relational data base. In the last decade middleware has reared its head. In this case SQL has no business evaluating business rules. The rules belong in the middleware. Unfortunately, this is not always the case.

With regard to the “if then statement”, what is the programmer to do? As has been pointed out languages like VB, Java, C++, C# and F# all have some form of the if statement. Case and switch statement can work, however, it depends on how the language implemented them.

Depending on the language, other alternatives are try catch; try with, raising exceptions etc. However, the foregoing should not be blindly applied. Try catch in some languages is fast in others it’s a performance killer. The same goes for SQL; the DBA absolutely needs know how query is handled internally. The performance difference between well written and poorly written queries from the internals standpoint is astounding.

So, what do you want the programmers to do?

This SBVR thing from OMG, does this mean that business persons, accountants and lawyer have to change their vocabulary? Hmmm, that should prove interesting.

Regards,

Zarfman
rross posted on Thursday, December 16, 2010 10:15 AM
Zarfman wrote:

"So, what do you want the programmers to do?"

>>These days, not using a business rule engine (BRE) to evaluate your rules is like building your own data management instead of using Oracle or DB2 or whatever. The translation from RuleSpeak to If-Then statements has been described as "trivial". It's the reverse that's really, really hard. Business intent gets lost.

"This SBVR thing from OMG, does this mean that business persons, accountants and lawyer have to change their vocabulary? Hmmm, that should prove interesting."

>>No, you have it wrong. SBVR is about enabling machines to 'understand' the vocabulary of business persons, accountants and lawyers directly, so that vocabulary doesn't have to be translated into any IT language or database design. I'm not talking about Star Trek technology, but why shouldn't machines understand real business vocabulary and business rules?! In the future they wil. It's not a question of if, but of when. And probably a lot sooner than most people think.

baldrick posted on Thursday, December 16, 2010 12:38 PM
Responding to rross:
I don't really have anything to add, but you started the football analogy, so I am unable to resist :-)

RGR: Without rules you have anarchy, literally. You can't tell a bunch of guys (and gals?) to go out and "play football". You might have lots of activity, but it would literally be chaos.

Actually, I do have a little knowledge about the history of football - (originating from the home country of the sport) - and what you describe is pretty much exactly how the sport was born.

In the early days, there was a ball (well a pigs bladder actually), a field, and a whole bunch of people that were supposed to represent one of 2 sides on the field. There were no rules, just an objective - get the 'ball' to one side of the field before the other team.

That is how football started. At first there was nothing. Then someone came up with a function (move the ball to one end of the field). As the game evolved, more and more business rules were introduced in order to restrict the methods by which the ball could be moved - until today - when we have umpteen different versions of football all with their own set of business rules.

They may all be different games in the eyes of some, but to me they are the same function, with different business rules.
zarfman posted on Thursday, December 16, 2010 6:23 PM
Hi:

The question still stands what do you want the programmers to do?

IBM, Oracle, Microsoft and others all have business rules engines. If the economic/legal entity chooses not to make them available for what ever reason i.e. economics, current languages meet our needs, etc. It seems that IT practices would continue on as usual.

This brings up the question how do the business rules get into the BRE and who puts them there? Is it the end user, BA, or someone with a different skill set?

Another question is what happens to the VB, Java, C++, C# and F# programmers when the BRE appears on the scene and replaces or starts to replace the legacy systems?

I would suggest trivial versus hard and really hard is in the eye/mind/skill set of the beholder.

With regard to vocabulary translation, I suspect some sort of compiler will be involved because the computer and it chips understand only ones and zeros or on and off.

Business intent gets lost, does this mean the application doesn't work properly?

These SBVR things from OMG, I now understand what you mean. IBM and their computer named Watson are going to compete with humans on some game show. This should be an interesting test and a step in the direction you’re talking about.

Regards,

Zarfman
rross posted on Thursday, December 16, 2010 6:39 PM
Zarfman said:

"The question still stands what do you want the programmers to do? IBM, Oracle, Microsoft and others all have business rules engines. If the economic/legal entity chooses not to make them available for what ever reason i.e. economics, current languages meet our needs, etc. It seems that IT practices would continue on as usual."

>>The current IT paradigm no longer scales and is not sustainable. It's a recipe for more bad legacy. Only service providers benefit from that. Having said that, you hit on a solution that works for some organizations -- bypass current BREs using fast recompile-and-redeploy techniques. But that's outside my area.

"Another question is what happens to the VB, Java, C++, C# and F# programmers when the BRE appears on the scene and replaces or starts to replace the legacy systems?"

>>Yes, what.

"Business intent gets lost, does this mean the application doesn't work properly?"

>>Define "work properly". A lot of business analysts spend much of their time trying to rediscover original business intent (so changes in business rules can be made).

"These SBVR things from OMG, I now understand what you mean. IBM and their computer named Watson are going to compete with humans on some game show. This should be an interesting test and a step in the direction you’re talking about."

>>I doubt it. Business rules are not the same as rules in expert systems that try to mimic (and best) individual human behavior. Business rules are about operating businesses (organizational behavior). Turns out the former is a hugely more difficult problem (order of magnitude). It's a cool problem for researchers and academics, but its not what business needs.

zarfman posted on Thursday, December 16, 2010 10:46 PM
Hi:

Ross wrote: >>The current IT paradigm no longer scales and is not sustainable. It's a recipe for more bad legacy. Only service providers benefit from that. Having said that, you hit on a solution that works for some organizations -- bypass current BREs using fast recompile-and-redeploy techniques. But that's outside my area.

Zarfman writes: I would suggest that it depends on what part of the current IT paradigm one is talking about. Languages range from 1GL to probably 5GL, hardware ranges from PC’s to computers the process in area of teraflops or petaflops. Various operating systems, relational databases and other kinds of file structures as well as the various combinations of the foregoing.

Ross wrote: >>Yes, what.

Zarfman writes: Business rules man, business rules.

Ross wrote >>Define "work properly".

Zarfman writes: I’m not interested in the Ross/Zarfman version of President Clinton’s depends on what is is with regard to Define "work properly". I’ll leave that judgment to unknown stakeholders or whom ever.

Ross wrote: A lot of business analysts spend much of their time trying to rediscover original business intent (so changes in business rules can be made).

Zarfman writes: One would hope (perhaps in vain) that someone had reduced to the written word the communications between stakeholder, BA’s, systems analysts and programmers. As well as some sort of record retention system.

Ross wrote >>I doubt it. Business rules are not the same as rules in expert systems that try to mimic (and best) individual human behavior. Business rules are about operating businesses (organizational behavior). Turns out the former is a hugely more difficult problem (order of magnitude). It's a cool problem for researchers and academics, but its not what business needs.

Zarfman writes: According to an IBM press release Watson, named after IBM founder Thomas J. Watson, was built by a team of IBM scientists who set out to accomplish a grand challenge – build a computing system that rivals a human’s ability to answer questions posed in natural language with speed, accuracy and confidence. The Jeopardy! format provides the ultimate challenge because the game’s clues involve analyzing subtle meaning, irony, riddles, and other complexities in which humans excel and computers traditionally do not. “Beyond our excitement for the match itself, our team is very motivated by the possibilities that Watson's breakthrough computing capabilities hold for building a smarter planet and helping people in their business tasks and personal lives."

I like the natural language and business tasks bit.

Regards,

Zarfman
vulcan2 posted on Friday, December 17, 2010 3:13 PM
Recently we were told to write business rules in the "If ..., then format" to which I reluctantly agreed. This article bolsters my case for using the correct format for stating business rules. Thanks.
zarfman posted on Friday, December 17, 2010 9:25 PM

Hi vulcan2

What was the rational behind behind writing the business rules in the if - then format.

Regards,

Zarfman
Only registered users may post comments.




Latest Articles






Copyright 2006-2019 by Modern Analyst Media LLC