If you have even a passing interest in BPMN, you’re probably aware of the great debate happening amongst a few of the BPM bloggers in the past week:
Michael zur Muehlen and Jan Recker publish an academic research paper on BPMN usage, “How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation”, to be presented at an upcoming conference. To quote the introduction in the paper, its aim is “to examine, using statistical techniques, which elements of BPMN are used in practice”, and they laid out their methods for gathering the underlying data. They used some standard cluster analysis techniques to identify clusters of BPMN objects based on usage, and determined that the practical complexity (what’s really used) was significantly different from the theoretical complexity (the total set) of BPMN. Michael teaches in the BPM program at Stevens Institute of Technology, so I wasn’t surprised to see a stated objective related to BPMN training: “BPMN training programs could benefit from a structure that introduces students to the most commonly used subset first before moving on to advanced modeling concepts.” Note that he says “before moving on to”, not “while completely disregarding”.
Michael then blogged about the paper but went further by listing three implications that were not expressed in the paper:
- Practitioners should start with the more commonly-used BPMN elements, and leave the more specialized constructs for analysts who will presumably be doing more complex modeling.
- Vendors that support BPMN can make a realistic determination of what percentage of BPMN diagrams can be represented in their tool based on today’s usage of BPMN.
- Standards bodies should consider if they should be creating additional complexity if no one is using it.
It was these implications that sparked the arguments that followed, starting with Bruce Silver’s post directly challenging much of what Michael said in his post. It appeared to me that Bruce hadn’t read the full research paper, but was commenting only on Michael’s blog post, hence didn’t fully appreciate that the paper was really just analyzing what people are doing now, not making any value judgements about it. Bruce was a bit harsh, especially where he suggests that Michael’s “BPMN Overhead” label on the least-used objects was “clearly meant to mean ‘useless appendages’.” Bruce had some valid rebuttals to Michael’s three implications, and although I disagree somewhat with Bruce’s first two points (as I commented on his post, and was rewarding by Bruce telling me that I was stating the bloody obvious), I agree that the standard makers have not included unnecessary complexity, but that they have created a standard that the market still needs to grow into. However, I find the BPMN specification to be overly verbose, creating a greater degree of perceived complexity than may actually exist.
Michael responded to Bruce’s post by pointing out that the aim of their research was to find out how people actually use BPMN, not how vendors, consultants and standards bodies think that they use it (or think that they should use it). Michael restates his three implications in greater detail, the first two of which seem to align with what I thought that he said (and stated in my comment on Bruce’s original post). His clarification on his third point was interesting:
We actually like BPMN’s advanced vocabulary. But have you asked end users what they think? Well, we did. Not only in this study but also in Jan’s large-scale BPMN usability studies we did find that users are in fact very troubled by the sheer number of, for example, event constructs. Are they used at a large scale? No. Do users understand their full capacity? Typically not. Why is this not at all reflected in BPMN development? That is exactly our point. Sure, our argument is a somewhat provocative statement. But if it helps to channel some attention to end usage, that’s fair by our standards.
Bruce responds in turn, saying that if Michael had presented this as “statistical correlations between diagram elements in a sample of BPMN collected in the wild”, then it would have been okay, but that the conclusions drawn from the data are flawed. In other words, he’s saying that the research paper is valid and interesting, but the post that Michael wrote promoting the paper (and including those unintentionally provocative implications) is problematic. As it turns out, in terms of Michael’s group of the 17 least-used BPMN constructs, Bruce could live without 15 of them, but will fight to the end for the other two: exception flow and intermediate error event. However, Michael doesn’t say that these are useless — that’s Bruce’s paraphrasing — just that they’re not used.
There’s a bit of chicken-and-egg going on here, since I believe that business analysts aren’t using these constructs because they don’t know that they exist, not because they’re useless. Many analysts don’t receive any sort of formal training in BPMN, but are given a BPMN-compliant tool and just use the things that they know from their swimlane flowcharting experience.
Anyway, Bruce finishes up by misinterpreting (I believe) the conclusion of Michael’s post:
Michael ends his piece by asserting that the real BPMN is not what vendors, consultants, and trainers like me say it is, but the way untrained practitioners are using it today.
What Michael actually said was:
[O]ur own experiences with BPMN and with those organizations using it gave us this hunch that the theoretical usage (what vendors and consultants and trainers tell us) often has little to do with what the end users think or do (the practical usage). And why is it important to know what the end users think and do? Because it can help the researchers, vendors, consultants and trainers of this world to channel their attention and efforts to those problems real users face. Instead of the problems we think exist in practice.
Although it’s not completely clear, I believe that Michael is saying that we need to understand what people are doing with BPMN now in order to design both training and systems.
This was an interesting debate to watch, since I know and respect both Michael and Bruce, and I found merit in the arguments on both sides although I don’t fully agree with either.
There was an interesting coda on the validity of BPMN for model-driven development with Tom Baeyens weighing in on the debate and stating that BPMN should stick to being a modeling notation and not be concerned with the underlying execution details: “[t]he properties can be removed and the mapping approach to concrete executable process languages should be left up to the vendors.” Bruce responded with some thoughts on model portability, and how that drives his categorization of BPMN constructs.
If you’re at all interested in BPMN, it’s worth taking the time to work your way through this debate, and keep and eye on Bruce and Michael’s blogs for any further commentary.