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…)
Bruce, I interpreted some of Michael’s conclusions a bit differently than you:
1. The recommendation for “practitioners” (not including systems analysts who likely are primarily responsible for the creation of the BPMN diagrams) to start with a small group of objects is based on the reaction that most people have when faced with the full BPMN spec: outright terror at having to memorize what appears to be a huge set of complex symbols. Anyone doing any serious modeling is going to eventually learn many more than what he defines in the core set, but they have to start somewhere.
2. His statement is “vendors that are not supporting the entire BPMN vocabulary can assess what percentage of BPMN diagrams can be represented in their tool, and where enhancements should be made”, which I interpret to mean that vendors would use this to set priorities in their development efforts. Given that vendors don’t have infinite development resources, they sometimes need to make some decisions about what gets implemented when, and that quite sensibly should be based on what people actually want to do with the product.
As BPMN becomes more widely known and used, I expect the “core set” of most commonly used objects to expand significantly. What Michael seems to be observing is that people are really just starting to make some small steps from their old swimlane diagrams into BPMN, and really need to learn a lot more about BPMN in order to make it worth the trip.
Sandy,
The 2 points you make – that the spec is ovewhelming and practitioners have to start somewhere, and that tool vendors have to prioritize their R&D – well, does anyone think otherwise? That’s not the issue. The issue is what is in Michael’s “all you need to know” bucket vs what he considers 6 years’ time wasted by OMG. You hit it (inadvertently) in your phrase “steps from their old swimlane diagrams into BPMN.” I am saying Michael’s core set PLUS the extended core set equals no more than “old swimlane diagrams.” All the BPMN-ness of the notation is in the “you don’t need to know this” bucket. It’s just the wrong conclusion to draw from the data.
i would like to know more about sap
Bruce,
thank you for your feedback. Jan and I appreciate the time you took to look at our findings, even if you do not agree with our interpretation of the results.
We have posted a detailed response that strives to clarify several issues raised here.
Besides the points mentioned therein, let me explain a few things:
a) It is not our intention to discredit or badmouth the results of the BPMN standards process. I have been part of the BPM standards community for more than 10 years and I know how long it takes to produce a thoroughly vetted specification. But I see with concern the size explosion of standard specifications (BPMM 1.0 is 500+ pages…) and I have to ask whether it is more valuable to be feature-complete or to be extensible. Guy Steele gave an excellent talk at OOPSLA 1998 on the thinking behind Java, and I would be happy if more people actually read it.
b) Our research is not a critique of BPMN. It is simply a report on how practitioners use BPMN, based on empirical evidence. We are reporting on the actual count of BPMN constructs. Your point regarding the implied semantics that result from the use of multiple sequence flows originating from the same activity is well taken – we did not look at those modeling conventions. But we were interested in whether more people would use the Data-based XOR Gateway with the X or with a blank symbol, and found that even though the blank version is part of the BPMN core set, the X-marked version is more popular in the models we analyzed.
c) Our analysis follows the linguistic analysis of word frequency (not character frequency, as implied in your post – characters don’t have meaning or formation rules in most languages, but words do). Our study shows that the frequency of word usage in BPMN follows closely Zipf’s law, which applies to the words in the English language (and many other natural languages). So what does it mean when people use BPMN constructs like they would use words in a natural language? One could infer that they might form dialects, popular phrases, and creoles (or mashups) by borrowing phrases from other languages. An interesting finding from our data is that this distribution of usage frequency holds true even if we look a clusters of BPMN constructs – and the cluster analysis in our response post shows what the popular clusters are.
d) We have explained our research method in detail in the full paper that is linked from the original post.
BPMN : jusqu’où aller ?…
Si vous vous intéressez à BPMN (pour Business Process Modeling Notation), lisez avec attention cette note de Michael zur Meuhlen et Jan Recker.
L’article original joliment illustré, détaille quel peut être (doit être ?) votre connaissance e…
[…] previous post on the frequency of BPMN construct usage has generated a passionate response by Bruce Silver who we know and respect as a very active contributor not only to BPM blogging in general but also […]
[…] Select Business Solutions, I’m drawn to elements of the separate arguments and research of Bruce Silver and Michael zur Muehlen and Jan Recker. There’s a great summary of the discussions by Sandy […]