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

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Q&A: Simplifying Business Process Models and Achieving Dynamic Business Processes – All By Using Business Rules

The OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:
    • Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
    • Behavioral rules are about shaping conduct (and can be violated).
Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:
    • When the first order is placed by a customer.
    • When an agent leaves the company (which could leave an order-placing customer without an agent).
How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:
    • Detect violations of behavioral rules (like cops and referees).
    • Permit dynamic invocation of selective (read “selectively different”) responses.
Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/


[1]Semantics of Business Vocabulary and Business Rules. Release 1.0 of SBVR came out in Dec, 2007. For more information see the SBVR Insider section on BRCommunity.com.
[2]For logic wonks, the distinction is based (very carefully) on necessities (alethic modal logic) vs. obligations (deontic modal logic).
[3] For more on flash points see my blog post: Flash Points: Where Business Rules Meet Events http://goo.gl/pl9sT

Tags: , , , , , , ,

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.