One Notation to Rule Them All

Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while "alternative approaches" like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view.

I come down strongly on the side of Paul and Sandy, and in fact go farther to say it should be BPMN not UML Activity Diagrams, and in fact it should be an improved BPMN that resolves the inherent conflicts between an anything-goes drawing notation and a "modeling language" with precise execution (and analytical) semantics.

I hope Paul doesn't mind that I'm using a diagram from his article to illustrate the problem.

BPTrends1.gif

Here is an example of what he calls a "high-level BPMN diagram of a supply chain." Well, it's certainly a diagram with rectangles and arrows, I'll grant that, but is it really BPMN? In BPMN, arrows like that are called Sequence Flows and they mean that the activity (which could be a subprocess) at the arrow head starts when the activity at the arrow tail ends. You don't have to be a supply chain expert (and I'm not) to know that's not how it works. Source, Make, Deliver, and Return are all in fact running concurrently, although there is communication between them. And BPMN can describe that concurrency (get rid of the sequence flows), and even describe the communication ("choreography") between them (put each subprocess in a "pool" and interconnect them with message flows).

If BPMN is going to win in the standards game, it has to become more of a design language and less of a cocktail napkin.