On How Much BPMN Do You Need

Michael zur Muehlen posts a strange bit of analysis called How Much BPMN Do You Need? The method of research consisted of collecting 126 BPMN 1.0 diagrams from "consultants, seminar participants, and online sources," and counting the frequency of various diagram objects in them. His conclusion is that the BPMN that you "really need" consists of task, start and end event, sequence flow (he calls it "normal flow"), exclusive gateway, and pool. It's a bit like saying e, t, a, o, i, and n are the letters you "really need" to communicate in English.

The methodology is not detailed in the post, but several things Michael does say suggest that the analysis focuses purely on the diagram, not the semantics. For example, the spec says a pool is implied even if not drawn, but Michael seems to just count it if drawn. (He also says the spec requires the pool to be drawn if lanes are used; I don't agree.) Also, exclusive (XOR) gateway. The spec says this gateway may be drawn either with an X inside or with no icon inside; there is no semantic distinction. Michael counts them as different flow objects and says one is core and the other not.

The data presented suggests that Michael is not looking at semantics, just counting shapes and symbols. The parallel split gateway falls into the "extended core" set, but in BPMN two sequence flows out of an activity has the same semantics as a parallel split. Many older notations use multiple connectors out of an activity to mean alternatives, not parallel paths, and students beginning my training incorrectly think that applies to BPMN. I'll bet those errors are in the 126 diagrams, but it's not clear how they were counted.

The tables do not distinguish between intermediate events used in sequence flow, which pause the process to wait for an event, and intermediate events attached to activities, which abort the activity and redirect processing on an exception flow. However, the data suggests very few attached events, since exception flow - the required sequence flow out of any attached event - is so infrequent that Michael consigns it to the lowest category, "BPMN Overhead," which is clearly meant to mean "useless appendages."

Stepping back, what he calls the core set of BPMN has, to me, absolutely zero BPMN-ness to it. It's just flowcharting. In fact, except for message start event, his core plus extended core set is still just swimlane diagrams that have been around for decades. My conclusion from this study is not that this is all the BPMN you need, but that understanding of BPMN, even among consultants, seminar participants, and publishers of online sources, is pretty poor. (If you remember my What's Wrong With This Picture? posts a while back, BPMN blunders by tool vendors and online tutorial authors alike were more the rule than the exception.)

Michael draws different conclusions, and since he is a respected academic, I find them really troubling:

  • "Practitioners" should start learning BPMN using the core set - start, task, gateway, end, that's it - and leave the other "more specialized" constructs to those who need special training. (In my BPMN classes, business people are totally offended by the suggestion that they can't understand events and other "specialized" constructs.)
  • Tool vendors who don't support all of BPMN today should use his frequency chart as a measure of importance. (Let's see, that would mean no event gateways, no attached events - attached error event had a frequency of 0% in his sample! Really! - and no multi-instance activities. That's absurd.)
  • "Standards makers" - read OMG - should reconsider whether putting things like the above-mentioned constructs in the standard was useful since they make BPMN more complex than traditional swimlane diagrams. "How much time," he asks, "was spent on defining those seventeen symbols that we found are hardly used?" Those 17 include exception flow (needed for attached event of any kind), error intermediate event, timer start event, and off-page connector (Link event). (Oh, man...)