The Great Rules Impedance Mismatch                          

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

Modeler-Invoked Evaluation of Rules

Evaluation of rules under OMG's Decision Model and Notation (DMN) is modeler-invoked. Evaluation of a set of designed rules occurs where and only where someone (a modeler or coder) indicates that the evaluation should occur, usually at some point in a process model.

Overtly-designated decision points for evaluation of rules works well for the kind of business decisions where waiting as long as possible to make a decision tends to produce the best business results. Those are indeed important cases. One noteworthy variety is what I call best-fit match problems.[1]

Modeler-invoked evaluation does not work well for behavioral business rules (and many definitional rules as well). For these business rules, which are legion, not catching violations as early as possible — preferably as soon as they occur — can cause snowballing errors downstream in the work being conducted and therefore extensive rework.

An additional issue is that modeler-invoked evaluation depends on the ability / wisdom / good intentions of the modeler or coder to decide where (in a business process) to invoke the decision. In the age of AI, that just doesn't seem very smart. In any case, why should anyone at all be involved in the choice of where to evaluate rules (again, except in those select cases where it can provide better business outcomes)?!

State-Based Evaluation of Rules

Visualize a soccer game. Behavioral rules (no tackling from behind, offside, etc.) are basic to the game. Formal soccer games always feature a referee, watching the game close-up but not actually part of the play. When this 'watcher' sees a violation, they stop the on-going activity, reset the play, and issue a warning or penalty. If you left the monitoring of rules to the players, just imagine the chaos! (Yes, the referee presumably does have some sort of decision process or mechanism in their head to decide when a violation has occurred, but that abstracts the basic issue of the behavioral rule itself being violated several steps too far.)

In state-based evaluation of rules, current states of affairs are captured and monitored in real-time by a 'watcher' external to processes. This 'watcher' automatically intervenes whenever a violation of a rule occurs. The watcher resets the activity — i.e., the state of affairs is corrected if possible, some sanction(s) are perhaps issued, messages are possibly sent, procedures may be invoked, etc.[2] By this means, errors are corrected automatically and ASAP, so they don't compound themselves downstream.

No modeler or coder has to indicate when state-based evaluation of rules is to occur — the external watcher is completely automatic. State of affairs reigns supreme. What a boost to productivity! It also makes evaluation of rules very smart. What do I mean by watcher and state of affairs? The watcher is some kind of software platform — possibly a rules engine; in an SBVR-style approach[3] the state of affairs would be a factbase.[4]

Another reason state-based evaluation is so important is that the great majority of behavioral business rules can be violated at multiple events. Consider the simplest example you could possibly imagine:

Behavioral Business Rule: An employee must have a name.

The obvious event where this rule could be violated is upon first learning an employee exists. According to the rule, they must have a name from the onset. (You might say some decision is involved at that point, but it's not really a natural or basic one. It's certainly not a rich business decision.)

Far less obvious is the fact that if anyone tries to remove or discontinue the name of an existing employee, that too produces a violation of the rule. Catching violations at this second event is just as important as at create-time in maintaining a valid state of affairs. What 'decision' does this second event correspond to? Certainly not anything remotely obvious. Even if there were one, however, why depend on a modeler or coder to ensure that the 'decision' is invoked? That's definitely not smart.

This example is by no means rare or exceptional. In fact, the large majority of rules from laws, regulations, contracts, agreements, service level commitments, MOUs, business policies, etc. follow the very same pattern. Here are two additional, somewhat more involved, examples.[5]

Behavioral Business Rule: A student with a failing grade must not be included in a sports team. What happens when a student already on a sports team (who presumably didn't have any failing grade to begin with), now receives a failing grade in the current semester?

Behavioral Business Rule: A customer must be assigned to an agent if the customer has placed an order. What happens when an agent currently assigned to a customer retires or leaves the company?

I call the events where a behavioral business rule can be violated flash points. Flash points are inevitable when you treat behavioral business rules as a first-class citizen.

Note that the various flash points for any given rule can occur in different process models, procedures, use cases, etc. — or at various points in random (unmodeled) business activity. Who or what is responsible for ensuring consistent results across all the flash points of each rule? Is it really any mystery why business processes often give such inconsistent results on things you'd think are basic? Or that data quality only seems to get worse and worse?

Conclusion

In modeler-invoked evaluation of rules, the burden of validating states of affairs for behavioral business rules is shouldered by modelers or coders. That's simply not smart. It's also a major factor in why business software remains so complex and brittle. The solution requires a paradigm shift — adding state-based evaluation as equal partner in rule platforms. For the record, it's not a question of one or the other — you need both for truly smart systems.

References

[1] "Best-Fit Decision Points ~ How They Fit into the Business Rule Approach," Business Rules Journal, Vol. 5, No. 7, (Jul. 2004), URL: http://www.brcommunity.com/a2004/b200.html

[2] "Breaking the Rules: Breach Questions," Business Rules Journal, Vol. 14, No. 2, (Feb. 2013) URL: http://www.brcommunity.com/a2013/b688.html

[3] For explanation and discussion of SBVR, refer to the SBVR Insider section under Standards on www.BRCommunity.com.

[4] USoft implemented such an approach over two decades ago using SQL databases.

[5] Ronald G. Ross, Business Rule Concepts: Getting to the Point of Knowledge (4th ed), (2013), p. 99-104.

# # #

Standard citation for this article:


citations icon
Ronald G. Ross, "The Great Rules Impedance Mismatch                          " Business Rules Journal, Vol. 20, No. 6, (Jun. 2019)
URL: http://www.brcommunity.com/a2019/b994.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.