More on the If-Then Format for Expressing Business Rules
Questions and Answers

by Ronald G. Ross

Ron's column on problems with the If-Then syntax for expressing business rules several years ago[1] generated more comments (and angst) on a continuing basis than perhaps any other he's ever written.  A storm was expected and the forecast proved correct.  Is the problem one of procedural vs. declarative?  Business vs. IT?  Meaning vs. implementation?  Ron revisits the key issues in this special Q&A.

Question:  A large majority of all business rules are currently expressed using the If-Then format.  How can RuleSpeak^[2] and SBVR^[3] succeed in the real business world when so many existing statements are expressed with a leading condition rather than a leading subject?  Are you really telling clients that to use this wonderful approach they must first rewrite/reword everything in their existing documents and software?

RGR:  I've looked at a great many source regulations, legal contracts, agreements, business policies, game books, etc.  That 50% figure just doesn't hold up at all.  The If-Then format is simply not natural for expressing rules in the real world.

With respect to other kinds of artifacts, who wrote them?  The answer is mostly IT.  Our biggest challenge in introducing RuleSpeak is almost always with IT professionals or people heavily influenced by them.  A whole generation of IT professionals is writing If-Then statements for business rules simply because that's what they know how to do.

AI/expert systems didn't help either.  They were aimed at mimicking the behavior of individuals, not encoding the business rules of organizations.  These are fundamentally different problems.  I wrote about this important distinction in the March BRJ.^[4]

The main challenge on the business side is different.  Business people often find understanding and writing full-fledged fact-based statements difficult.  The level of precision it requires can be time-consuming and demanding.  The industry desperately needs interactive tools based on SBVR to guide business people and business analysts through dialogs that achieve precision in specifying business practices step-by-step.

Here's the irony.  The same level of precision about business practices is ultimately required whether you use RuleSpeak or an If-Then format.  RuleSpeak simply encourages people to achieve the precision much earlier in the development cycle.  It also ensures the conversation remains business-based before getting into the details of implementation.

Question:  Isn't there any alternative to verbalizing business rules so carefully as in RuleSpeak?  How about using decision tables instead?

RGR:  Let me be very clear.  You should always use decision tables whenever you can.

Does using decision tables mean you can forego well-developed business vocabulary (fact models) as prescribed by SBVR?  No.  You still need to capture business meaning.  By the way, developing good business vocabulary always proves harder than writing business rules in RuleSpeak.

Can all or most business rules be represented in decision tables?  No.  A significant majority cannot be handled naturally by decision tables.

Will we ever stop needing words — nouns, verbs, adjectives, and participles — to write business rules?  No.

Business will need words and sentences to express business rules for as long as they continue to sign written agreements, follow regulations, verbalize business policies, capture product/service know-how, write guidelines and instructions, etc.  Words and sentences literally provide the "sense" needed for traceability.  And traceability is required whenever you need to demonstrate compliance, fidelity with business intent, or validity of reasoning.  People need words and sentences.

So machines should learn to 'talk' more like humans, not the other way around.  That's what SBVR is about.  It will be with us for a long, long time.

Question:  When it is important that the literal form of the statement be retained (e.g., for legal considerations) doesn't this rewrite pose a problem?

 RGR:  Legal contracts, agreements, regulations, etc. today are not computable (directly automatable).  So one way or another they must be translated.  Wouldn't it be nice if the translation were in a form that helps you spot misinterpretations right off?  Of course!  That's exactly what RuleSpeak gives you.

Question:  When you approach a new client, do you tell them they need to reword their business rules for the approach to work?

RGR:  You're assuming the rules are actually written down somewhere in a form consistent with all the source code.  How many companies actually have that?!  It usually just doesn't work that way.

In addition, a disturbing number of companies feature nothing more than use cases in their requirements approach.  So they can often be enticed by anything that helps them capture and understand business rules and business requirements better.

Question:  Do you have a rote way to translate an If-Then statement into declarative form?

RGR:  You can't translate If-Then-Action statements into declarative form because the business intent is missing.  Translating If-Then-Fact back and forth from RuleSpeak, on the other hand, is trivial.  We do that often.  One client described it "embarrassingly easy."

Question:  What would RuleSpeak do with the business rule, "If the news is bad, shoot the messenger."?

RGR:  As currently structured, that statement uses the If-Then-Action format.  In declarative form it would read:  The messenger of bad news must be shot.  Or if you prefer the If-Then-Fact format then:  If the news is bad, the messenger must be shot.

By the way, the business rule in its present form is not practicable.  For example, does the messenger need to be shot dead?  And does the messenger actually need to be shot, or is just killing him sufficient?

Question:  What would RuleSpeak do with the business rule, "If a rental car is returned more than one hour late, charge a late-return penalty."?

RGR:  That statement again uses the If-Then-Action format.  In declarative form it would read:  A late-return penalty must be charged for a car rental if the rental car is returned over one hour late.  Or if you prefer the If-Then-Fact format then:  If a rental car is returned over one hour late, a late-return penalty must be charged for the car rental.

As soon as you let any actions creep into business rules, all bets are off on side effects.  As the statements become more and more slanted toward programming, they become less and less comprehensible to business people and to most business analysts as well.

Question:  Is the If-Then-Action vs. If-Then-Fact distinction something new?

RGR:  Not really.  Under SBVR and RuleSpeak, business rules always refer to facts rather than actions.  In any event, RuleSpeak disfavors If-Then simply because it's not the most natural way to verbalize real-world rules.  I've looked at a lot of examples.

Question:  Is it hard to teach business people to distinguish between If-Then-Action vs. If-Then-Fact?

RGR:  You are much less likely to get into trouble writing a business rule if you pick a clear subject, then get to a rule key word as fast as possible.  (In RuleSpeak the rule keywords are must and only.)  This guideline goes double if you have an IT or AI background.  Any if should appear in the sentence only after the subject and rule keyword.

An if clause represents what the renowned linguist Steven Pinker calls 'heavy lifting'.  A good guideline for formal writing of all kinds is to put the heavy lifting toward the end of the sentence.  It's simply easier on the brain.  That's the real reason RuleSpeak disfavors If-Then.

Question:  Should you avoid wording business rules in the form of a command or order?

RGR:  Yes.  That issue is largely orthogonal to If-Then though.

Question:  How can business analysts test for what's okay vs. what's not okay in writing business rules?

RGR:  Examine the statement for any actions.  If any actions are evident, not good.  Actions (or processes) do things; business rules just guide things.

Question:  Is the business rule from earlier — The messenger must be shot. — talking about the state of the messenger?

RGR:  Yes.

Question:  In an SBVR-style fact model, the state could be represented by a unary fact type worded as messenger is shot, right?

RGR:  Yes. 

Question:  Regardless of word-play, isn't the business rule ultimately ordering the messenger to be shot?

RGR:  Yes — be shot.  Shot in the sense of is or has been, not in the sense of do.  The messenger should be in the state of having been shot.

State is at the very heart of the matter.  Processes try to produce new states; business rules tell you which states are valid and which are not.  Maintaining a clean separation between processes and business rules is crucial.  Putting state in-between processes and business rules is a clean, simple, and elegant approach.

Question:  If a case of a messenger being shot went before a jury, would you really try to say that the statement "The messenger must be shot." is not actually ordering the shooting of the messenger?  For example in The Lion in Winter we hear, "Who will rid me of this turbulent priest?"  The next thing you know Becket is dead.  Can you really argue the average human wouldn't hear the statement as a command?

RGR:  Whether some action results is outside the scope of business rules.  That's getting into speech acts (or something).  For business rules there are only the words you use.

Question:  When the 'action' is taken out from a business rule statement what do you do with it?  Do you simply toss it away?  Do you put it somewhere?

RGR:  If the action is about enforcement or sanction, it should be specified alongside the business rule, but separately, preferably in a rule repository (what I call a General Rulebook System or GRBS).  I talked about how we do that in the original If-Then column cited earlier.

In most cases though, first you'll have to recapture the original business intent.  The If-Then-Action format inevitably mangles or buries true business meaning.

References

[1]  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

[2]  RuleSpeak^®, Business Rule Solutions, LLC, 1996-2009.  PDF available at http://www.RuleSpeak.com

[3]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF 

[4]  Ronald G. Ross, "Operational Business Decisions — Whose Decisions Are They Anyway?" Business Rules Journal, Vol. 12, No. 3 (Mar. 2011), URL:  http://www.BRCommunity.com/a2011/b583.html