The Great BPMN Debate

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.

16 thoughts on “The Great BPMN Debate

  1. A fair summary of the arguments on both sides. I would just add that in versions 1 and 2 of my course, I used to teach the “basic” set (Michael’s core + core extended) in the first half, and offered certification at that basic level, before getting into events and exception handling. In the new v3, just released, I don’t do that any more. The reason is that students were making errors in the basic-level certification exercise that I hadn’t covered yet in the training. It is very difficult to judge competence in a limited-vocabulary limited-syntax environment when the errors go beyond that vocabulary and syntax. Do you just let the errors go and certify anyway, or do you have to individually give help on items taught in subsequent sections? Or just dumb down the test? So now I have the same 2 exercises, but both are at the end of the training.

    The other thing about v3 is that most of the new additions to the content – the piece on managing complex nested models, nonaborting scoped events, use of the new signal event – were solutions to questions raised by students in the classroom: “how can I model this scenario?” Maybe by Michael’s statistics my students are not typical, but they are the user reality I deal with every day.

  2. Bruce, I think that it would have been useful if Michael and Jan had had access to the type of BPMN diagrams that your students are creating as part of their research in order to balance out the usage statistics a bit, but consider the results of Jan’s survey last year: only 13.6% of BPMN modelers have any sort of formal training, so it’s not surprising that the remaining ones are only using basic constructs.

    It’s a bit of a chicken-and-egg problem: most people don’t use the extended BPMN constructs because they’ve never been trained in them: they likely don’t even know that they exist, even if they’re using a BPMN tool that shows them in a palette. If they were trained in them, would they use them? Maybe.

    The students in your classes are likely there because they have reached the limitations of what they could do with the basic set, and recognize not only that their processes are more complex, but that there has to be a better way to model them. That level of self-awareness about their own shortcomings does make them atypical.

  3. Sandy,

    Thank for keeping us honest. I think Bruce, Jan and I do not disagree as much as the whole debate makes it look like. It boils down to the question of whether you can control the use of a language after it has been released.

    On the one hand, a lot of work went into BPMN and it is a very powerful vehicle, if you know how to use it properly.

    On the other hand, users may appropriate and extend the language in ways its designers could not foresee. For instance, Garrett Hunter has presented a great case study how Sony used a mashup of BPMN and IDEF0 to save a failing IT project. Should we tell them “you can’t do that because it’s not how BPMN was intended to be used?”

    I believe that yes, there is great merit to structured BPMN education that explains the intention behind the language, its vocabulary, and shows how to use it in a well-formed way. But I also believe we need to keep an eye on how the larger BPM community uses BPMN and feed that information back into the development process. If you read Bill Bryson’s entertaining account on the history of the English language you’ll understand where I’m coming from.

    Best

    Michael

  4. Regarding what Michael says about the IT project in Sony: I use the presentation to support the need for the modeling etc… But please note that still IT people are the ones who perform the process analysis. As an X-programmer, I tend to think that system analysis or process analysis are not the strong side of programmers. (maybe it relates to a right/left brain thing..) On the other hand – business people have hard time with operating the tools. I think that the optimal target audience for this phase, which includes BPMN, better be clearly defined, identified and trained.

  5. After reading Bruce Silver’s article “Organizing Complex BPMN Models” I was asking myself at some point why should life be so hard?
    For example: “Exceptions at child levels should be propagated to top level to return a response..That often requires propagating the success or failure indication from its source at a deeply nested level up to the top level, and then sending the response from there…”
    Why does such a complexity has to be drawn? Isn’t it better at some point to eave the graphical tools? I figure that if we need to write code
    to such case, we would do it in a much more elegant way. I guess the true need for the visual language is caried to the wrong places.
    I must confess that I am still considering myself a BPM beginner, but I punched on cards my first Fortran program.

  6. BPM Addict, I agree that there’s some question over who should be doing what in the entire spectrum of process discovery, modeling and design, although I disagree that programmers don’t normally have strong systems analysis skills: if so, then they picked the wrong profession, since most programmers that I know (including me in a past life) always had to do some degree of systems analysis. Process analysis is a different story, and mostly programmers aren’t going to do that primarily because they don’t understand the nuances of the business process itself, not that they don’t understand process analysis per se.

    The issue (as Tom Baeyens has stated) is that even though business and IT people might both use BPMN to model a process, the business people are modeling the most effective business process, and the IT people are modeling the most efficient code (albeit from an abstracted viewpoint). That doesn’t always produce the same models in BPMN, which means that somehow you have to be able to take the business process that the business person modeled and tweak it so that it will generate an efficient/complete executable without corrupting the original business process.

  7. Light BPM, I appreciate your comment, although notice that it comes from the same IP address as “BPM Addict”. I would much prefer if you use your real name, since I have had comment trolls who use this same technique before (multiple fake names from the same IP address).

    It sounds like you don’t have a problem with (for example) propagating errors up to the top level for reporting, but rather are saying that maybe it doesn’t need to be graphically represented that way, correct? Propagating errors up to a higher level in order to facilitate appropriate error handling is a common coding technique not because it’s particularly efficient (which it’s not) but because the person who designs the code needs to specify where the error handling will occur and how it will manifest. Business analysts who are modeling business processes need to think about the same thing: if an error occurs at some level, how will it be handled? BPMN provides a graphical method for them to propagate the errors up so that they’re visible at correct level of the diagram, both for presentation purposes and to put the management of the error in the right place.

  8. “A good system analyst is a bad programmer” was the opening phrase of my system anlysis course. I am glad it was said loudly. Of course every programmer needs to do some of it sometimes.
    Right now it seems that BPM approaches create vagueness about the who is the right person to do what. I am concerned about companies don’t see a consolidated methodology and therefore won’t be excited about BPM implementation.
    Please read this myth-breaking article:
    “The State of BPM: Perspectives of an Industry Insider”
    http://www.bpm.com/BriefingRO.asp?Briefingid=31

Leave a Reply

Your email address will not be published. Required fields are marked *