There was a time when process modellers didn’t “do” business rules. They made process flow diagrams. The only thing that really mattered was “processes”. The assumption was that any rule important enough for a process would surface in the process flow. You could have a rule saying that a client’s creditworthyness had to be checked before he or she was allowed to buy a house. This rule would show up as a diamond in the diagram with a label “Credit OK”? A “yes” line would branch off to the left for preparing the deal, and a “no” line to the right for sending a rejection letter.

Then, about three years ago, the BPMN community discovered that there was a whole lot of “business logic” out there that was relevant to processes, but that you would never want to write into flow diagrams, for the simple reason that the diagrams would grow much too big for comfort.

To solve this practical impossibility, it was easy to leap to a misguided theoretical conclusion, namely, that underlying rules must somehow be different animals from process steps. But look at the following different ways of stating the same idea:

  1. The “Check Credit” sub-process must be executed prior to the “Sign contract” activity.
  2. A Check Credit procedure must be executed before a customer may sign a contract.
  3. A credit check must be executed before a customer may sign a contract.
  4. A customer may only sign a contract after his or her credit has been checked.
  5. A customer must have credibility status when he or she signs a contract.
  6. Only customers with a credibility status may sign a contract.

The statement at the top is “process-speak”. It is the kind of thing people say when pointing at a BPMN diagram.

The statements near the bottom are the sort of thing that we think of as typical “business rules”, but what they say is very close to what is expressed by process flow symbols in a diagram.

This is why Graham Witt in his rule taxonomy (in Writing Effective Business Rules , 2012, [1]) distinguishes a category called “activity rules”, which could perhaps also, more loosely, be termed “process rules” [2]. One of Witt’s examples is:

“A daily ticket may be used only until 2 AM on the day after the day on which the ticket is validated.”

BPMN is spectacularly good at visualizing processes. Consecutive actions and events are plotted from left to right on paper. Parallel “swimlanes” show who is responsible for what. The order in time in which activities and events take place is immediately apparent. So is task division among various participants, and incoming and outgoing message traffic. What BPMN brings to the table is not something else than business rules. It’s a visualization of business rules.

There’s an intriguing difference between rule expression and process flow depiction. A rule implies allowed leeway that an organization gives itself. Process flow tends to be much more directive in terms of what activity must come next. A rule like:

“A credit check must be executed before a customer may sign a contract.”

says step 1 must somehow occur BEFORE step 2, leaving open the possibility that other steps come in between. This particular kind of leeway is very easy to express in language. In process flow diagrams it requires considerable gymnastics, introducing such things as symbols for ad-hoc sequencing, which are not common in BPMN practice.

[1] Witt, Graham, “Writing Effective Business Rules”, Morgan Kaufmann 2012, ISBN 978-0-12-385051-5.
[2] Witt has a finer-grained subdivision of process rules than discussed in this short blogpost. He used the term “process rule” in his earlier “A Practical Method of Developing Natural Language Rule Statements (Part 10),”Business Rules Journal, Vol. 10, No. 11 (Nov. 2009),

Leave a reply