Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

R.I.P. Straight-Line, Old-School Processes!

Consider the business rule: A vehicle must not exceed the posted speed limit. Some of the issues for this business rule are (a) how do you detect a violation and (b) how do you respond to a violation. These issues raise the question, whose process is it? Are we talking about the process of the person driving down the street, or the process of the policeperson operating the speed trap? The two processes are obviously related in some way, but definitely not the same. The cop’s process is best viewed as interrupting the driver’s process. Let me come back to that point in a minute. There are two fundamental kinds of business rules[1]:
  • Decision rules (or a little more broadly, definitional rules). These are the kind of business rules that expert systems traditionally addressed. It’s the kind you find in decision tasks – e.g., whether someone should be given credit.
  • Behavioral rules. These are business rules that can be violated – e.g., speeding down the street, or being off-sides in football. For behavioral rules you need cops or referees or whatever to interrupt a more basic process when a violation occurs. It’s just the natural way to do things (if you don’t want anarchy).
Aside: You might say the examples of behavioral rules I’ve cited (speeding and off-sides) are not automatable. Well, I’m less and less sure about that these days. I see a lot of cameras where I live ‘watching’ for cars running red lights. The camera takes a picture of your license plate and the position of the car in the intersection and you get a ticket in the mail. For the record, I haven’t gotten one. But they do make me more careful about yellow lights. In any case, a great many behavioral rules are automatable. They arise as interpretations of some law, act, statute, regulation, contract, agreement, business deal, MOU, business policy, license, certification, warranty, etc.  For these kinds of business rules, you need a ‘watcher’ outside the process, standing ready to interrupt the process if a violation occurs. A classic example: The fuel rods in a nuclear power plant must be covered with water. If a process of operating the power plant ever violate that rule, I want an immediate violation response to interrupt the guilty process(!). That business rule is about operating a power plant, but the same idea holds true for business processes in general. Detecting violations of behavioral rules is how you can stitch together dynamic processes in real time. Such dynamic processes cannot be achieved by embedding business rules in either a model of the business process, or the process itself. The ‘watcher’ must be on the outside, protecting the interests of the larger (business) community. Such rule independence is the fundamental idea of business rules, as expressed by the Business Rule Manifesto[2]. R.I.P traditional, hard-wired processes!    

[1] Based on SBVR, the OMG standard Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section on www.BRCommunity.com for more information. [2]http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto (2 pp, free) been translated into 15 languages.

Tags: , , , , , , , ,

Ronald G. Ross

Ronald G. Ross

Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.

Comments (4)

  • Karl Walter Keirstead


    I agree with the suggested setup for business rules.

    We do this in BPM implementations where system level process steps are positioned at Key Process Points.

    When one of these steps becomes current, the system independently looks up a checklist that either evaluates to TRUE or FALSE and then depending on the desired behavior, you get a hard stop or a warning. In the case of a hard stop, the user must remedy the deficiency (i.e. the rule set calls for 8 deliverables but finds only 6) OR seek supervisory override which results in an explanatory note doing into the process log.

    The source checklist for TRUE/FALSE is off limits to users so its not possible for an ordinary user to “trick” the rule set.

  • Dave Duggal


    My condolences to the BPMN community! ; )

  • Bruce Silver


    I’m with you up to a point, but disagree with your conclusion. Decisions are not the same as event rules, and are not especially dynamic. In a BPMS, event rules have historically been limited to operational BAM, i.e. monitoring process KPIs in real time and triggering some action. But monitoring external event streams with rules and analytics is the heart of the “i” in Gartner’s iBPMS, so it will shortly be on every BPMS vendor’s checklist. To the “BPMN RIP” guy, I say better read up on the standard. BPMN has loads of places to hook event-triggered behavior to a process, but that just shows the event-triggered behavior. The event listener, or “watcher” as you call it, is definitely outside the process. Who ever thought it was not?? The challenge now is to extend the BPMS point-click design metaphor to the event-rule-action configuration, so it doesn’t take Java code to implement.

Comments are closed