After a few months without much BPM discussion, then I blinked and found that I have been missing the Great BPMN Debate. To bring you up to speed: Michael zur Muehlen and Jan Recker have been studying how people actually use BPMN to draw business processes, and have counted the occurrance of rate of various elements. He summarized this in a blog post,which came to the conclusion that practitioners could focus on learning and using a small subset of a dozen BPMN elements, that vendors could prioritize implementations to get the more common elements first, and that some elements were used so rarely that the value of their existence was questioned.

To me this intuitively makes sense if you consider the way that such standards get developed. A group of people get together bringing with them different ideas of how to draw a meaningful diagram. Common ground has to be found between all of the different approaches by taking the specifics of several different approaches and abstracting to a higher level concepts and groupings. Compromises have to be forged in order to include all of the most important parts, and to exclude ideosyncracies of a given approach. The committee aims for a suitable level of completeness. Given that each committee member is coming from a slightly different background and with a slightly different concept of how the various elements might be used, there are clearly differing priorities. Committees will tend to err on the side of including too much because it is easy to argue that a capability is needed, and give an example that requires it, than it is to argue that that example is not common enough to warrant inclusion. It is only natural that the core of a few items will represent the bulk of the usefulness, while there will be some elements that are not useful at all. It is the nature of standards, as it is for high tech products, that the exact way it will be used can not be fully determined until they are actually in use.

Bruce Silver responded with a spirited post raising questions about the method and conclusions. Bruce certainly must be counted among the handful of top BPMN experts that exist today. Bruce has a point: the study was done from existing BPMN diagrams. Who can say for sure that the elements were missing because they were not needed, or because simply the modeler did not understand how to use them? Who can say whether they were missing from the diagrams because the modeling tool vendor did not implement them, or did not implement them correctly. The diagrams themselves may not actually comply to the BPMN syntax. The model might comply to BPMN syntax, but the the modeler might have intended to represent something else. Given the likelihood of these diagram flaws, how can you then conclude that something is not needed simply because it is not used? This is beginning to sound a bit like an argument that designers often use: “They would be useful if the standard had been implemented correctly in line with the original vision of the standard.”

Michael responded with a thorough post which can be brutally reduced to: “Like it or not this is actually how BPMN is used today.” His intent was not to criticize the standard (quite the opposite) but to provide helpful empirical data to guide practitioners, vendors, and even the standards committee to the most important aspects of the standard. Implicit in this is the implication that a subset of the entire standard is acceptable. Bruce responded by admitting that there were superfluous elements of BPMN, but that we should be a bit more careful on how we select the most important set. Tom Bayens weighed in with another well considered perspective. Sandy Kemsley’s summary of this debate is far better than mine, so I will stick to a few comments.

As I have said many times, I consider BPMN to be a dictionary of symbols which can be used to represent concepts. Just as a writer will write a novel without using every word in the English dictionary, so it is suitable to pick and choose a subset of these symbols for use in modeling processes. I have never quite understood those who argue that a modeling tool is useless unless 100% of the specifications are supported (which is arguably not possible given ambiguities and redundancies that exist in such standards.) It goes without saying that your expressibility is limited the more you limit the available symbols. Yet Michael’s main point is that you can say quite a bit with a surprisingly small subset of the BPMN language. I do hope the BPMN group will take to heart as they consider extensions to the existing set, because it is important to step away from the theory of how you would like a standard to be used, and be guided by the more pragmatic knowledge of how it is being used in practice.

That being said, for models to be portable, there must be a broadly agreed upon subset which is sufficiently expressive to handle all the cases you are likely to encounter. If tools choose too narrow a subset, then they will not be able to understand diagrams from another tool with a different subset. Thus Bruce argues quite effectively that the process design ecosystem is best served by encouraging implementation of as much of the specification as possible, well beyond a minimal subset. So I can identify with the concern that a narrow approved subset might encourage vendor to stop short of a useful implementation.

Let me conclude this post with a quick acknowledgment of the tremendous work which Bruce has been doing recently on the XPDL 2.1 specification which has been approved for release by the working group last month. He drove the development of a model portability conformance guideline which he touches on in his most recent post. This ground breaking work will allow us finally to measure the extent to which a tool supports BPMN, and to assure that there is a certain minimum level of consistency, without requiring 100%-or-nothing. Thanks Bruce.