The Two Faces of BPMN
David Chappell, who long ago took the position that BPEL isn’t portable so it doesn’t matter, now amplifies it with the conclusion that portability should be at the design language level, not the execution language, and the best candidate for that is BPMN. I’ve come to the same conclusion myself, on both points. John Evdemon, BPEL TC co-chair, sealed point #1for me at Think Tank when he said portability is not, and never was, a goal of BPEL. A look at Cordys, Lombardi, and Intalio offerings — all of which use BPMN as a notation for executable design — convinced me of point #2.But the goals of a pure modeling notation and an executable design notation are not one and the same. So what is BPMN anyway? And can it simultaneously serve two masters?
I believe in its earliest beginnings, BPMN was conceived as a Third-Wavish business-oriented executable design notation upon which additional implementation detail could be layered - the design surface for BPM based on service orchestration. But after BPEL left BPMI in ruins, the BPMN banner was picked up by the analytical modeling vendors, who actually got the spec out the door. It was around that time that Gartner blessed us with the BPM Suite concept, in which modeling and simulation analysis were seen as distinct from, but exporting directly into, executable process design.
This odd history probably provides much of the reason behind both BPMN’s quirky gaps — no properties to hold the simulation parameters used by virtually all business process analysis tools, no XML schema to store the diagram, and most crippling of all, no methodology behind the diagram – and its sophisticated design features, like intermediate events, transaction compensation, and collaborating processes synchronized through messages — features often viewed as “too technical” to be understood by the folks actually drawing the process models, and which most simulation engines have no idea how to handle.
I convinced myself, and tried to convince BPMS Watch readers, that BPMN would eventually outgrow its personality disorder as soon as it got a schema and precise semantics - a metamodel! - either from OMG’s BPDM (the “official” one) or WfMC’s XPDL 2.0 (the “pirate” one). But now I see a post from Francis McCabe of Fujitsu Labs and the “BPMN team” at OMG that sounds like bad news.
There is something of a fracas about the relationship between BPMN and BPDM: is BPMN ‘only’ a notation or does it have some semantics. This whole thing was news to the BPMN team as they (including me) were blithely assuming that we were trying to define a language. For us, the major issues seem to revolve around the execution semantics of a BPMN diagram; for others, it is only a diagram notation and we needn’t worry our little heads about execution.
Hmmm. Sounds familiar. He concludes:
The BPMN effort does seem to be a bit stuck right now. Personally, I think that the issue is that we are trying to have it both ways: have an easily understood execution semantics and allow the business modeler to do whatever …
OMG’s natural constituency is enterprise architects and business analysts, i.e. the modeling side of the equation, but BPMS vendors have more to gain by making BPMN a standard notation - with rich and precise semantics - for executable process design. We’ll see who carries the day. More thoughts on this later…
2 comments July 3rd, 2006
