This is starting to get good. Let's face it, not many people care about BPM standards, other than wouldn't it be nice if we could agree on some. I'm really no different, although at this point I would admit to having a vested interest in getting quickly to a version of BPMN that was portable between tools. So I've tried to publicize and opine on some of the issues behind the normally secret deliberations over BPMN 2.0, now being hashed out in OMG. There are two competing proposals, one a longstanding OMG project called BPDM, and the other a joint submission from IBM, SAP, and Oracle that looks a lot like current BPMN but with a defined XML schema.
Until recently what commentary existed in the blogs on this topic was from the IBM-SAP-Oracle side, but in the past couple weeks the BPDM supporters have begun to tell their side, beginning with Fred Cummins, Conrad Bock, and now Lombardi's Phil Gilbert. Of the three, Conrad's for me is the most persuasive, probably because he concedes the point on what was my biggest objection to the BPDM vision for BPMN, which said that the notation could mean whatever the modeler intends it to mean, as long as the serialization in conjunction with MOF fully describes the semantics. That, for example, was the argument of Antoine Lonjon (BPDM editor) in his BPMN wish list featured white paper on the OMG site. But Conrad concedes that no, even though BPDM provides a ready framework for describing any new diagram behaviors, the notation for such would have to be agreed upon and published in the BPMN spec. (I haven't figured out how that works if BPDM is just renamed BPMN, but that's another story).
I have two other reasons for favoring the IBM-SAP-Oracle proposal myself: One, it seems to be the one favored by most other BPMS vendors, who are also the ones making the low-cost (some free) BPMN tools available to me and my training students. I think that's because it looks so much like the BPMN we have now, not a "brand new language." If all tool vendors don't rally behind BPMN 2.0, that would be a bad thing, and I think universal adoption is more likely with the IBM-SAP-Oracle one.
Two, and I admit that I might be alone in this one, it is based on standard XML, and can be mapped with regular XML tools, as opposed to mapping based on MOF and XMI, which to me are foreign languages. Others have expressed their own objections. Oracle's Vishal Saxena, for instance, advances the "simplicity" argument (compared to BPDM), but I think that he really means more "like today's BPMN" than "dumbed-down." SAP's David Frankel expresses the view that BPMN should have its own schema and metamodel, based on the BPMN spec, and that BPDM is a new abstract language to which BPMN and many other platform-specific languages can be mapped. Maybe that's just another way to express the simpler/more-familiar argument.
Anyway, now comes Phil's defense of BPDM, which adds a new twist, suggesting that opponents of BPDM are really vendors out to kill BPM and its notions of business empowerment. It's true that some of them were not on board with BPMN in the beginning and bet on UML instead, but I wasn't prepared for this:
It's only been in the last 12 months or so that some major stack vendors and application vendors have announced support for BPMN.... When OMG approved BPDM, once again their world was challenged. All the sudden, a legitimate, useful, long-term alternative to technology-based diagramming (like UML) was a reality. Business-facing diagramming... with power? Big problem.Is the IBM-SAP-Oracle proposal BPMN's Manchurian candidate? Phil continues:
There is no question that the power of BPDM - the explicit aspect of it that you are worried about - was a key contributor to the movement of some of these vendors into a "hey we better beef up BPMN with a simple serialization" mode. Could it be that they recognize that crippling the power of an alternative model to UML might be in their strategic interest?While Phil's suggestion seems to me over the top, I welcome it. Because if the other side takes the bait, we should finally have what has been missing for two years - a real public discussion of the issues shaping the next generation of BPM tools.