Category: standards

I really didn’t sit down this afternoon to write that last enormous post on the Great BPMN Debate, I remembered that Jan Recker (co-author on the research paper that sparked the debate, although not a participant in the debate) had sent me a pre-release copy of a paper that he authored, “BPMN Modeling — Who, Where, How and Why”, which summarizes the results of the survey that he conducted last year. One thought led to another, and before you know it, I’d written an essay on the most exciting thing to happen in BPM standards in ages.

Back to Jan’s paper however, which will be published this month on BPTrends. He surveyed 590 process modelers using BPMN from over 30 countries, and found some interesting results:

• BPMN usage is split approximately in half over business and IT, which is a much higher percentage of IT users that I would have guessed. Business people are using it for process documentation, improvement, business analysis and stakeholder communications, whereas IT people are using it for process simulation, service analysis and workflow engineering.
• As you might expect given that result, there’s a wide variation in the amount of BPMN used, ranging from just the core set for basic process models, to an extended set, to the full BPMN set. It would be interesting to see a correlation between this self-assessment and usage statistics based on the actual BPMN diagrams created, although as far as I know, the survey respondents didn’t submit any examples of their diagrams.
• Not surprisingly, only 13.6% received any formal BPMN training, and I believe that this is the primary reason that most people are still using only a tiny subset of the BPMN constructs in order to create what are effectively old-fashioned flowcharts rather than full BPMN diagrams.

He finished with a list of the major obstacles that the respondents reported in using BPMN, or places that they would like to see improvement:

• Support for specifying business rules, which echoes many of the other discussions that I’ve seen around having some standardization between process and rule vocabularies and modeling languages.
• Support for process decomposition, although I really didn’t follow his argument on what this means.
• Support for organizational modeling, particularly as that relates to the use of pools and lanes: sometimes, for examples, a lane indicates a role; other times, a department. There are some things happening at OMG with the Business Motivation Metamodel and Organizational Structure Metamodel that may help here.
• There are some BPMN constructs that are less often used, although it’s not clear that anyone recommended getting rid of them.
• The large number of different event types is problematic: “ease of use of process modeling is sacrificed for sheer expressive power”. This is a variation on the previous point (and on the crux of the Great BPMN Debate), indicating that actual BPMN users are a bit overwhelmed by the number of symbols.

I’ll publish a link to the paper when it appears on BPTrends; it’s fairly short and worth the read.

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.