I'm taking a break from my governance blogs for a post to respond to Bruce Silver, who wrote this piece to register his objections to the use of BPDM.



Bruce,



There's several points you make in the post, but I'd like to take exception to a couple of them: (1) that BPDM took over BPMN and (2) that simplicity is a strategy.

 For a long time now the goal has been to get BPMN to include an explicit metamodel and serialization mechanism. All the groups inside the OMG agree on this, and it was a joint decision to use the BPMN 2.0 spec to do this. On the latter point, the simplicity argument coming from some, shall we say simple-minded, vendors isn't a strategy, it's a tactic to divert attention from their real strategy, which is to kill BPM.

You say that Conrad "picks up the defense" of BPDM. But BPDM doesn't need defending. What needs explanation is why we are where we are.

BPDM vs. BPMN


First I'll address your implication that "the BPDM people simply announced as a fact that BPDM would be renamed BPMN." This isn't correct. In fact, the head of the BPMN group, Stephen White of IBM, has been part and parcel of the long-term vision that BPMN 2.0 would include the serialization mechanism and was part of the name change. This wasn't done by "the BPDM people" but, rather, by the larger group within OMG (called BMI) that runs the spec processes for both BPDM and BPMN. IBM and SAP both play a major role in the BMI group, and were part of the consensus that (a) one spec was better than two, and (b) BPMN was the better spec to move forward with. The reason for the name change isn't sinister. Here's 
the thinking:

1. Most everyone in the "post-BPDM" world wants the notation spec to include an explicit metamodel and serialization format, so that these diagrams can be interoperable.
2. The notation spec has the more widely known and adopted "brand" (BPMN).

3. The BPMN and BPDM teams both agreed that we could and should live with BPMN.

4. The chairman of the main BPMN group has been (and is) Stephen White of IBM. Within OMG it's acknowledged that Steve "owns" BPMN. So if anything, the concept of an OMG-based BPMN serialization - something that until now is only contemplated in the BPDM spec - was pulled in by the BPMN group.

The BPDM group has always been willing to let the separate BPDM spec go by the wayside if the BPMN metamodel is explicit, powerful and, like all OMG models, MOF-based.


In summary, most everyone at OMG wants a more mature BPMN spec, one that includes an explicit metamodel and serialization, and we all think BPMN is the right mechanism for that consolidation.



MOF-based BPMN vs. simple XML-based BPMN


So we are all aligned that BPMN should be serializable using a standard format. The debate is now centered on "what should that format be"? This is a legitimate question and, like anything, both sides have valid points to be made. There is not a "right" answer. As a person who believes that direct manipulation of XML is not a desired end-user requirement, I've never bought the argument that BPDM "is too hard... too complex." Vendors add value by taking powerful abstract objects (like a file format) and making tooling that allows easy manipulation of those things. And so I think the best way forward is the one offering the most reasonable chance for robustness and future-proofing (ie. the standard will live a long time, making my investment as a vendor pay off).

Software vendors don't make technology decisions based on how easy something is. We make decisions based on corporate strategy. In this case, watch out for the simple-minded vendors who claim they are for "a simpler" file format. Most likely they are simply for a format that doesn't threaten their vested interest.

At Lombardi, we've already announced our strategy: we're in the BPM industry for keeps. We will support BPMN 2.0 in whatever form it takes. Period. We prefer the BPDM metamodel and serialization, but will work with any adopted standard, because this is good for the industry. It would be nice to hear other major vendors make the same commitment.



Some vendors, though, will tell you that "the MOF-based XMI of BPDM is 'too hard,'" implying, I guess, that they won't support BPMN 2.0 if it contains BPDM. These same vendors have hundreds, even thousands, of developers building complex BPM platforms. They have messaging platforms and/or complex materials masters and logistics algorithms. But BPDM is too hard? Come on. This isn't a complexity issue, it's a control issue. It's a business strategy issue.

Powerful elements of major companies were against BPMN itself to begin with. By acquiring BPMN, and then seeing it massively adopted, OMG changed their world. It's only been in the last 12 months or so that some major stack vendors and application vendors have announced support for BPMN.

And then, 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.

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?

I don't know everyone's motives in this discussion, but I do know the following:

1. Powerful non-user interests have been aligned against an explicit non-UML metamodel for BPMN - and voted against BPDM, killing it the first time around.
2. At the same time, these same people proposed a MOF-based UML metamodel for BPMN, and would have been happy with that. This would not have been "simple," it simply would have been strategically aligned with their interests.
   
3. Once BPDM was on the brink of adoption these interests all the sudden started talking about how BPMN serialization isn't a bad thing, but this BPDM thing is just too hard... we need a simple, non-abstract metamodel.
   
4. Once BPDM was passed, the simple-minded vendors all the sudden got religion and started preaching this "simplicity."
   

So as you consider the state of the world in July 2008 and look at the tooling around MOF manipulation (which, as you say, is limited), also consider what we in the true BPM industry (as opposed to the same-old same-old tools for technologists industry) are trying to do. This is a paradigm that is changing the guard in enterprise computing and will define how companies compute for the next 30-40 years. We need to move beyond simple 1990's XML, and into something more extensible, more powerful. This will inevitably upend the power inside end-user companies, and upset traditional buying/selling relationships.

The struggle for BPDM is in some part struggle for account control.

I choose power over simplicity. I don't trust those who have entrenched, vested interests to watch out for me. In fact, what would truly be a shame is if the powerful interests trying to hobble BPMN succeed by inserting a more XPDL-like rendering of the model, which they would like to do because this would not have the power of other OMG modeling standards, like UML. Hmm....

Phil