Michael zur Muehlen posts a lengthy response to my post On How Much BPMN Do You Need. He elaborates on his data analysis procedure - their procedure, actually, as Jan Recker was a co-author - and it's actually kind of interesting, looking at statistical correlations between diagram elements in a sample of BPMN collected in the wild. Sort of an anthropological survey - maybe archeological, given where we are on the adoption curve - of which shards of BPMN are used, correctly or incorrectly, in diagrams today. And if it had been presented that way, it would have been interesting, maybe even mildly useful.
But that's not how it was presented, and that's why I still say Michael (and Jan) draw the wrong conclusions from the data. The part of BPMN that is no different than a swimlane diagram is not at all "the BPMN you need to know." It's better described as "the BPMN you already know."
In his new post, Michael says,
The process modeling efforts in most organizations at this stage are simply not advanced or mature enough to start specifying service-enable workflows with exception behavior in BPMN. No, most people use it simply for flowcharting. What we conclude from this observation is that the ecosystem of vendors, consultants and trainers should be aware of this and should plan, manage and employ their efforts (be it tool development, BPMN training or modeling workshops) accordingly.This is the conclusion I just vigorously disagree with. I would rewrite it as follows:
The process modeling efforts in most organizations still lack the knowledge and methodology required to document and analyze their business processes effectively in BPMN. Today most BPMN models are no more than flowcharts, omitting the exception paths that would be necessary to analyze them for potential improvement, either by simple visual inspection or quantitatively using simulation. And they offer no hope of serving as the business view of an automated implementation of the process in a BPM suite. That's too bad, because the real value of BPMN - the reason why it is important - is that it empowers business analysts, not just developers and architects, to do all of those things. But that requires training, on both the notation itself and a methodology for using it effectively. The BPMN you really need to know is NOT the BPMN you already think you know.I am not saying BPMN contains no nearly-useless parts. I'd happily get rid of transaction compensation, complex gateway, conditional (fka rule) event, conditional sequence flow, and multiple event (except in event gateway). I personally have little use as well for Link event, the off-page connector, although I have students who can't give it up. Even timer start event, signifying a scheduled process - harmless enough, but ok, I could live without it.
Those account for 15 of Michael's useless 17. It's the other two that get me: exception flow, which means any attached event; and intermediate error event. (In BPMN 1.0 that could mean either throw the error or an attached event, but in BPMN 1.1 just the attached is allowed.) Without attached events you can't specify deadline-triggered behavior; you can't let your process respond to an unsolicited event; you can't easily propagate exceptions from deeply nested levels of your model to a parent level, which makes hierarchical models very difficult to manage.
Michael, I can see you rolling your eyes: attached events, nested levels, propagating exceptions... Those are IT things, not business analyst things. But I have to tell you, having taught these concepts and practices to hundreds of students in the past 12 months, that that attitude is condescending to business analysts. Not to put too fine a point on it, it really pisses them off. The thing that's energizing BPMN in the marketplace is that it gives the business folks for the first time a seat at the table with IT, lets them go from documentation to analysis to implementation without changing the notation, just layering on more properties.
Can you do this with the flowcharting you already know? No you can't. It takes a bit of education and practice. And it takes more than your core set or core + extended. To say subprocesses, intermediate timer and message events, event gateways, and repeating activities (loop and MI) are just for "specialists" sets the bar too low. Way too low.
The vendor side of the equation is off target also. Given that no BPMS supports all of the BPMN spec, Michael says:
So which constructs can a vendor neglect initially and which need to be supported? We would argue that it is of best interest to vendors to focus on those constructs heavily used in practice.Beating a dead horse though, since I doubt I could name one BPMS that claims to support BPMN but doesn't support all of Michael's core + extended core set already. The area of interest is what Michael calls the BPMN Specialist Set. These are the constructs at the heart of BPMN-ness, bridging the business-IT divide. To be so dismissive of them is just wrong. And is he saying users should be familiar with them before they are available in the tools? I don't get it.
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. The core set diagrams - start, end, task, gateway - from his sample give a truer view, he says, of the "problems real users face. Instead of the problems we think exist in practice."