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.

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

# # #