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.
July 15th, 2008 at 10:25 am
I think maybe you’re confused about what “merging” BPDM and BPMN means. It doesn’t mean “renaming” the BPDM spec. The BPMN 2.0 spec will define the notation and the metamodel - adopting today’s notation, plus extending it to include the new elements contemplated in BPDM. The problem with BPDM today is that it is simply a language, it needs to be given what I call the “voice of notation” in order for it to be more broadly understood and consumed. The problem with BPMN is it has no language, it is simply the graphical picture. It needs to be given an explicit body of language in order to be a useful aspect of enabling the model-driven business. Joining these two into a single spec advances the state of the art.
In the non-IBM/SAP/Oracle proposal, the metamodel would look a lot like the BPDM metamodel (semantics that are different between the two specs today would have to be normalized, of course… and I think generally the BPMN semantics would be retained), but of course the focus of the spec would still be the notation - which would be today’s BPMN plus more, especially in the choreography area, an area that needs significant enhancement. Broad notation-based adoption of the concepts included in BPDM that aren’t present in today’s BPMN would accelerate the pace at which advanced business modeling could occur. There is no question that the powerful concepts in BPDM - when they are given the voice of notation - will change the way in which business can be modeled, moving us faster and farther down the road of business process management.
July 15th, 2008 at 10:47 am
Phil,
I agree with most of what you say here. It is a much better position than what was presented at Think Tank 2007, where I think “renaming” would be a fair characterization… to take advantage of, as you correctly point out in your blog, BPMN’s superior “branding” in the marketplace.
I hope that in the next round of proposals, the BPDM submission includes a major overhaul of the notation section to clarify the semantics of all the diagram elements and patterns in BPMN. I re-read that section today and I still can’t make heads or tails of much of it. As long as it takes a PhD in computer science to understand the notation semantics, BDPM will continue to suffer from the charge of “complexity.” And rightly so.
July 15th, 2008 at 11:29 am
Bruce,
Definitely agree that the notation semantics must be [at least] as accessible as they are in today’s BPMN spec. I am proposing that as much as possible we use the existing BPMN semantics, only changing them when they offer ambiguity when merged with the BPDM concepts.
Phil
July 18th, 2008 at 7:59 am
Standards always move in fits and starts and this is especially the case when looking at complimentary standards that are evolving on their own time lines such as BPDM and BPMN.
If the proposal now is that BPDM would go forward in a way that provides similar notation semantics to what exists in BPMN today and that then BPMN should evolve to work well with the proposed BPDM meta-model then that should be workable. This is simialr to how many vendors use XPDL, but would appear to offer more flexibility. That would be much better proposal then what was generally perceived last year to be a “just rename BPDM to BPMN” and get rid of the old stuff.
I’m still curious to see how the pure-play and stack players all get together to make this work. Standards is a bit of a vendor game trying to protect or create perceived advantages in the market and this is just one of many examples. For customers, the modeling and meta-model standards can provide a lot of value to the business in terms of skills portability which generally is just as important or more important then actual code portability. Let’s just hope that whatever happens all the people that have found real value in leveraging BPMN as the basis for their BPM modeling have a good path forward.
July 18th, 2008 at 8:57 am
Great comment, Shane. I agree 100%.