Monday, September 10, 2012

SBVR vs If-Then-Action Rules

I just found a nice interview with Ronald G. Ross about SBVR, that helps shed some light on how this works in relation to If-Then format's.

More on the If-Then Format for Expressing Business Rules

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.



  1. I'm in a quandary right now on how to proceed with a business rules effort with an organization that is rules-immature.

    Option A is to go down the Ron Ross path using a fact model and rules documented in RuleSpeak.
    Uses a business-driven approach
    I can use Ron's book to teach the team the process.
    I've found few tools that support Ron's approach (two so far)
    Testing the rules may be challenging due to the previous item

    Option B is to use a UML class diagram along with rules in Drools (using Guvnor).
    Free tools that are widely used
    Easier ability to test the results
    Drools uses different terminology for things like facts and fact models (big issue). This is guaranteed to cause problems.
    The tooling will be more techie and more confusing

    It would be really great if Drools would migrate more towards SBVR terminology.

    Thoughts or experiences from anyone on this topic?

  2. We wouldn't move away from engineering terminology, such as classes and beans - because that's the bulk of our users. However there is no reason why we can't develop alternative approaches around say SBVR, and adopt the SBVR terminology for this. But so far we haven't had the resouces to take on SBVR yet.

  3. The if then vs Rulespeak approaches contrasted here do not seem all that new, especially if one thinks of the familiar publish subscribe pattern - atleast when it comes to declaration vs implementation of business rules and business actions.
    With the rulespeak approach , it seems clearer that the business rule declaration should only recognize (maybe by publishing a 'conditions satisfied' message) when rule conditions are satisfied. Then multiple action subscribers/listeners would be activated to carry out consequences of the rules conditions being met.
    This also clearly recognizes the decoupling of rules activation and actions/consequence taken.

  4. Great article!! I enjoyed it so much. thanks for sharing. Taxi