Another reply to Bruce on this whole BPDM/BPMN debate. Yes, Bruce, I think this issue has very little to do with XML, BPDM or BPMN. I think this issue strikes to the heart of the matter: BPM is disruptive. Powerful, entrenched, legacy vendors don't like disruption. BPDM and the concepts inside BPDM are the most transformative of anything the BPM technology industry has seen so far. This is a chess game that's being played, not checkers...

Bruce,

No matter how you spin it, IBM/SAP/Oracle interests are offering up a new XML representation limited to, basically, what BPMN did four years ago. Why is that, Bruce? Why are we debating "how best to stand still" instead of "how can we get all this brainpower from IBM, SAP, Oracle, Lombardi, Mega, etc." together to extend BPMN to cover all the great business power in BPDM? Instead, IBM/SAP/Oracle are spending their time making sure the BPMN spec stands still, so that we're all, as Tom Waits put it, "waiting until yesterday is here."

I've come to the conclusion that this shift in power of process application development inside end-user companies is such a major change that the vested interests of IBM/SAP/Oracle will fight it. This is a change on par with what happened in the '80's as we moved to desktop computing. It's not some big conspiracy theory I'm advocating... it's just business. BPM is about changing the way business runs, using model-driven technology as the prime enabler of this change, and integrating real business people into a radically different software development life-cycle. Vendors who have billions of dollars invested and at stake have no interest in disruptive changes to the SDLC. They have an interest in the status quo.

Most of the elements of BPDM that are so "hard" are, in fact, elements that have always been planned for notation in future BPMN versions, like choreography. These have been discussed for BPMN since the BPMI.org days! So why is there so much push-back? Why aren't we having a very different debate? For example, it would be more interesting to me if the question was "how can we accelerate the choreography concepts of BPDM into the BPMN notation?"

But we're not having that debate. We're not using these 18 months (that's how long BPMN 2.0 will take, start to finish) to push the notation radically forward. We've got a lot of smart people arguing over a metamodel - again! We're wasting time - again! Why not leverage work that's been done (BPDM) instead of wasting time proposing yet another metamodel?

Those of us "on the BPDM side" want to change how businesses are modeled. We want to move business modeling forward. Why would we spend 18 months doing what can be done today perfectly well with BPMN and XPDL. If IBM/SAP/Oracle are really serious about easy-to-use serialization, then why don't they simply do this: release your BPMN tools today and have them serialize using XPDL. You can do that today. It's easy. I'll put this link in so their developers can easily find it. If IBM/SAP/Oracle adopted this serialization mechanism, it would be the standard, no question.

Instead they're stealing time... trying to get us to wait until yesterday gets here.

The power move is to embrace the concepts in the BPDM specification, and design a more powerful notation for them, while also embracing all the existing elements of BPMN. That's a notation worthy of our best efforts.

Whether we bite off the complexity of BPDM today, or in the future, we will have to bite it off. It's not the mechanics of BPDM that are scaring IBM/SAP/Oracle, it's the concepts. And those concepts - powerful business concepts - will prevail, it's just a matter of time. I'd prefer to accelerate the change, they'd prefer to slow time down, to wait until yesterday comes.

But don't be fooled as to the issue: this isn't about XML, it's about strategy. It's about BPM.

Phil

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