To the surprise of nearly everyone, OMG’s Business Process Modeling Notation (BPMN) has emerged as far and away the most important standard in BPM, driven in large part by the BPM Suite vendors who recognize its value as a bridge between business-oriented process modeling and implementation design. Today, for example, BPMSs ranging from Appian, Savvion, and Lombardi to BEA, Oracle, SAP, SoftwareAG, TIBCO, and Vitria layer rely on BPMN-based modeling as the underpinning of their process implementation design. Certainly no one could have imagined this after IBM and Microsoft put the BPM Initiative – the originator of BPMN – out of commission with their BPEL power play several years back.
And BPMN’s success is all the more remarkable given that there is still no generally accepted XML storage and interchange format for BPMN models. You want to create a process model in tool A and later edit it in tool B? Good luck.
OMG interpreted the growing public clamor for a BPMN XML serialization as giving new urgency to its Business Process Definition Metamodel (BPDM) initiative, an “abstract” process modeling language that could be mapped to BPMN or pretty much any other modeling notation as well, such as UML, and then serialized in XML. OMG’s position was that BPDM would become the official serialization of BPMN, in competition with XPDL, the “unofficial” one from the Workflow Management Coalition. Unfortunately, when the draft of BPDM was published a few months ago, it did not take very close inspection to see that it didn’t line up very well with the newly published BPMN 1.1 spec.
No worries, said OMG. BPDM actually represented the long-awaited BPMN 2.0 not 1.1. In fact, it not only represented BPMN 2.0, it was BPMN 2.0, which would now stand for Business Process Metamodel and Notation. I guess that’s one way to eliminate the conflict between the two. But a funny thing happened on the way to BPMN 2.0. A competing submission arrived from the team of IBM, SAP, Oracle, and BEA, companies that rarely lose in high-stakes standards battles. Thus, unlike most standards approval processes, the outcome of this one is not preordained. There are two submissions, quite different, and it could go either way. And the way it goes, I believe, will greatly affect the role BPMN will play in the next generation of BPM tools.
So what’s the fuss all about? The competing proposals represent distinct visions for what BPMN is and should be. The IBM-SAP-Oracle-BEA proposal reflects the desire of those vendors to more closely integrate process modeling and implementation design in their respective BPM Suites, and reduce the gap between business and IT. It looks a lot like today’s BPMN, but with a bit of cleanup in the semantics, an explicit metamodel and XML schema. The BPDM proposal would be of less value to the BPM Suite approach to solution implementation, certainly to those that have already standardized on BPMN as it is today. BPDM is instead aligned to OMG’s programmer-oriented MDA vision, in which models are just a more efficient way for developers to generate code.
SAP’s David Frankel gets to the heart of the technical difference:
The BEA-IBM-Oracle-SAP submission takes the position that BPDM is not a metamodel of BPMN; rather, it says, BPDM is a metamodel of a new, abstract language for process that, as envisioned by the BPDM RFP, was intended to be mapped to multiple concrete languages. BEA-IBM-Oracle-SAP approach is that BPMN, as one of those concrete languages, requires its own metamodel, whose constructs are clearly recognizable as BPMN elements.
Oracle’s Vishal Saxena calls their own proposal “a simple solution, because in the end it does not change much for the BPMN user. The implicit execution semantics are just made explicit, but they are not modified. [The BPDM approach] is more complicated, because a second language is added to the stack and new concepts are introduced. Having more and new concepts might contradict BPMN’s current strength – simplicity. This will increase the learning curve for BPMN modelling and might hinder a further adoption.”
And I think this hits it on the head. A key element is that in the IBM-SAP-Oracle-BEA approach, the execution semantics of shapes in the diagram are specified by the BPMN standard, while in BPDM they can be redefined by the user. Because BPDM can formally describe a wide variety of behaviors, users can define new ones without losing semantic precision. Yes, that’s very nice, but it loses the true essence of BPMN, which is that the process diagram – not the XML serialization – conveys the shared understanding of how the process works. That doesn’t work when everyone can create their own custom – although explicitly defined – notation.
The BPDMers are unmoved by the need to standardize the BPMN notation and strongly defend their abstract approach, which it claims provides capabilities that “capabilities cannot be supported by typical language modeling techniques that simply capture pictures in XML with a computation-dependent semantics.”
Ouch. But apparently, despite the trash talk, merger negotiations between the two submitting groups have been ongoing since March, in which the goal is a unified submission. We’ll see.
