Rules vs. Processes (Again) — Part 1: There's Simply No Need for Confusion

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

I recently reviewed on-going standards work in the area of business process modeling.  The good news is that the work seems to be moving toward accommodation of rules.  The bad news is that some fundamental confusion remains over the difference between processes and rules.  Why is something so simple in the real world so hard for some to understand?!  In any case, I think revisiting the issue is useful for just about any professional doing business analysis.  Here is how it goes.

A rule is something that removes a degree of freedom.[1]  Consider the commandment (rule) "Thou shalt not kill."  Practical issues aside (e.g., is it O.K.  to kill in self-defense?), the rule precludes the act of murder.  That doesn't mean the rule can't be violated, of course — that's why we have courts and prisons.  But in the real world there is no way you could mistake the commandment for the act (process) of murder itself.  Murder is when you kill someone.  The rule tells you not to.  Pretty simple.

Looking more closely, a 'process' is a transform that produces output (new things) from inputs (existing things).  The process 'murder' produces a dead person from a live one.

What can the definition or description of a process include?  Clearly a process definition does need to specify what things must exist for it to be performed.  It does need to indicate which inputs are mandatory — because if not present the process simply wouldn't 'work'.  Without a live person, you cannot commit murder.

Where you get into trouble is if the process description includes any conditions or constraints beyond that — for example, to indicate when it should or should not be performed.  In SBVR terms, that's the job for operative rules (ones dealing with behavior where there is the possibility of violation).  A process that includes or owns operative rules can get complex and contorted quite fast — not least because in a real business, there are lots of such rules.

To put it another way, 'processes' (transforms) produce things (outputs) having states.  If you want to talk about these states, you need vocabulary.  Vocabulary is how operative rules are expressed.  So operative rules, in effect, constrain the states that processes are permitted to produce.  (Use of 'permitted' here is deliberate.)

The worst kind of confusion is if processes are equated to operative rules.  No!  Operative rules don't 'do' anything (i.e., transform anything); they simply tell you whether what's being done (produced) is within the bounds of desired or acceptable organizational behavior.  Literally, without transforms (processes), nothing would ever happen.  Processes entail events that produce (potential) states; operative rules evaluate whether those states (and hence the events that produce them) are permissible.  Business vocabulary naming those states is the glue holding things together.  Simple, clean, and completely non-redundant.

Well, I say nothing would ever happen without processes, but that's not quite the whole picture.  Structural rules (ones that indicate when something is or is not a member of a class) can do automatic classifications and computations.  That's what they are about.  "Is this fruit an apple or not?"  "Is this customer a gold customer or not?"  "What disease, if any, do these symptoms suggest?"  "How much does this customer owe in total?"  Here, structural rules are 'doing' certain kinds of transforms (classifications and computations) automatically.

'Automatically' is not quite the right word here (although sure, there could be a rule engine 'executing' them).  What I really mean is declaratively as opposed to procedurally.

In other words, structural rules can substitute for some or all of the activities the process would otherwise specify and perform.  Just define the rules, mention the output in the context of some process, and, voila, the results from the rules appear when the process is executed.  In short, structural rules are much closer to being process-like than operative rules, if you must make the comparison.

I think of processes as recipes for doing work.  If you're a poorly trained cook (like me), you'd do really well to follow the recipe.  But that wouldn't be the case for the great chefs of Paris.

Even if recipes are not followed, there are still inevitably operative rules the chefs should obey — for example:  "Milk must be fresh."  "Bowl must be large enough so that the ingredients do not spill out when stirred."  "Batter may be considered 'entirely free of lumps' only if there are no visible masses of congealed butter larger than 2 cm in diameter."[2]

So, you can have operative rules without processes (common), and you can have processes without operative rules (rare).  Could you create a process model for every possible scenario that could happen in a real business?  No way!  That's one major reason we have operative rules.

Part 2 of this two-part series examines how operative rules relate to events, and by extension, to processes,

References

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), 1.0, Clause 12. return to article

[2]  These examples are from Principles of the Business Rule Approach, Addison-Wesley (2003), pp. 186-188. return to article

# # #

Standard citation for this article:


citations icon
Ronald G. Ross , "Rules vs. Processes (Again) — Part 1: There's Simply No Need for Confusion" Business Rules Journal Vol. 9, No. 6, (Jun. 2008)
URL: http://www.brcommunity.com/a2008/b422.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 IPSpeak 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.