Conrad Bock of NIST picks up the defense of BPDM where Fred Cummins left off. Since I don?t see much other discussion on the web about this important topic, I?m going to renew the thread here. Here are Conrad?s points:
The calls for a BPMN metamodel started two or three years ago, including OMG reopening the BPDM submitter list to the new BPMI members, and invitations from the BPDM submitters at the time. Only one new vendor chose to participate, not among the major ones. IBM and SAP were in attendance at those meetings, and perhaps Oracle also. It?s unclear why they did not to participate, but there was nothing preventing them, certainly not an ?insider? group.
BPDM was conceived to cover common process languages including BPMN, rather than something unrelated or different from BPMN. BPMN and its precursors were widely known in the process modeling world during BPDM development. The calls mentioned above requested the BPDM submitters to include BPMN as a special case, which they did. BPDM includes a notation mapping to BPMN.
Adoption of process modeling tools would increase significantly if they worked with other tools, such as process analytics, monitoring and management, as well as processes defined textually rather than graphically. Simply capturing notation will not achieve this, because these tools are most often concerned with semantics, rather than notation. For example, process monitoring tools are concerned with how the process is expected to be performed or executed, rather than whether it was specified with a particular notation. Process modeling tools needs much more integration with other tools to achieve wider adoption than the occasional use they receive now (see the BPTrends 2008 survey), This is not possible with a purely notational metamodel.
BPMN can only be changed when there is agreement on which changes to make, and they are adopted through the Object Mangement Group process. This is facilitated by extensions developed outside the standard that are shown to be useful in practice. BPDM enables semantic extensions, and with the diagramming capabilities in the upcoming BPMN 2 submission, extensions to notation also. Users and vendors can develop their own additions to BPMN and suggest them to the OMG for adoption. This makes it easier for OMG to respond to user requests for new features.I did not mean to suggest that the BPDM ?insiders? were excluding other voices, but I suspect the IBM-SAP-Oracle contingent?s vigorous disagreement with BPDM on basic principles came as a surprise. At last year?s OMG Think Tank, for instance, the BPDM people simply announced as a fact that BPDM would be renamed BPMN, which would now stand for Business Process Metamodel and Notation.
On the second point, it?s not that the BPDM group was unaware of BPMN, but rather that BPDM was conceived at a more abstract level in order to accommodate other languages as well. This simple fact, upon which both sides agree, is at the heart of the disagreement expressed by David Frankel.
Conrad avoids the undeniable fact that BPMS vendors, with the exception of Lombardi, favor the IBM-SAP-Oracle approach over BPDM, and instead says let?s not forget about the process monitoring vendors. But I don?t get that. For one thing, except for a few tools like ARIS PPM, the process monitoring vendors are the BPMS vendors. Second, what monitoring vendors need is standardization around runtime data, not modeling notation semantics. And OMG tried to get that off the ground, called BPRI. They built it? or started to? and no one came. So I?m sticking with my story that if tool adoption of BPMN is the goal, BPDM is not the right strategy.
On his last point that the BPMN notation is standardized by the BPMN spec, regardless of BPDM?s extensibility, I say Absolutely correct! (Please inform your colleagues.)
There is one final element I would like to add to this discussion, even though I may not have many supporters on this one. The BPMN schema proposed by IBM-SAP-Oracle is just so much cleaner than the one used by BPDM. The element names match BPMN names. The serializations are human readable. You can use regular XSLT tools to map them, to validate them. I realize many - perhaps most - people say there is no need for the XML to be human-readable. But I suspect those people have never had occasion to map XML. In any case, I don?t have the tools to manipulate BPDM serializations, whatever they are (EMF?). I do know how to use standard XML tools