In a recent posting Get Your BPMN Schema Today, Ismael Ghalimi shows how close he has come to loosing the plot. He has certainly moved well away from the reality of standards since he formed BPMI.org with Howard Smith.
Everything has become an element of spin – even down to misrepresenting the article of Bruce Silver. He suggests that Bruce thought “BPDM is essentially useless, and that the BPM industry badly needs an XML schema for BPMN.” While Bruce did talk to the need for robust interchange formats, I didn’t see him say it was essentially useless (although Bruce did demonstrate that he doesn’t really understand software, schemas or the semantics of process … but that is another subject).
Ismael went on …
BPDM, currently developed by the OMG, is presented by its promoters as a universal interchange format for business processes. In reality, it’s an utterly confusing metamodel that brings very little to the table, and is used by legacy workflow vendors as a way to fight against the upcoming dominance of the BPMN+BPEL standard combo. Workflow vendors like nothing more than to protect their respective little niches, and have done a phenomenal job over the past fifteen years of ensuring that no useful standard would ever be developed in the space.
Normally, I wouldn’t bother to comment on such clearly biased diatribe. But as many people never get to read the comments, I thought I should post the carefully worded rebuke that came from Cory Casenove (on of the main authors of BPDM):
We were active in the BPDM specification and feel that some of the views presented here are not well founded and others are out of perspective.
The comments from the author about “legacy workflow vendors as a way to fight against the upcoming dominance of the BPMN+BPEL” is, frankly nonsense both politically and technically. The dominant forces in producing BPDM were BPMN vendors, business and process modeling practitioners, business/process modeling vendors and government representatives – not “legacy workflow vendors” at all. There is no plot and no fight, BPDM fully embraces and supports BPMN and provides added value as we will discuss below. Technically BPDM is a superset of BPMN with added support for SOA – far from the centrally managed style of the old workflow systems. Perhaps we can keep our debate at a higher level.
The observation that BPDM is complex to understand has more merit – but lets look at the context and why;
Process semantics: Some other approaches to process “exchange formats” are little more than pictures in XML. While this provides interchange of the diagram it fails to exchange a process specification. One of the reasons that BPDM took so long is that nailing down what is really being said in process models is harder than it may appear, the team had the advantage of being able to work with the BPMN team directly, to iron out the real semantics – and there were a lot of arguments and disagreement about what they really meant. BPDM captures the result of this and provides a way to exchange the process semantics, not fuzzy pictures or partial thoughts. Semantics like this does take more time to grasp – but the result is REAL sharing of process, not lock-in to different vendor’s interpretations and extensions.
Integrating process and SOA: Process orchestration is a valuable tool in the enterprise toolbox, but not the only one. Process is part of the business model that includes services, organizations and resources. The SOA perspective in particular has been fully integrated so that the process for doing and the services offered and used are well integrated into a coherent enterprise perspective. BPMN can’t fight SOA, it needs to join it. Orchestration and SOA are just different ways to look at process. BPDM provides a bridge between those views. That bridge can be ignored by those who only want to understand orchestration, but we don’t think it will be ignored by the users who need both.
So this additional “complexity” of actually understanding what processes mean and how they relate to services and other processes has an impact, but that impact is primarily the responsibility of the builders of process tools, frameworks and infrastructures – perhaps having them take the time to understand the semantics behind their diagrams and runtimes is a good thing, I’m sure they are more than capable of grasping it.
There will be an open source Eclipse based implementation of BPDM on ModelDriven.org/bpdm as well as a schema for interchange – those who just want to know how to exchange BPMN models can use this, without the complexity. Perhaps we can also use this forum for an informed debate on the best way to represent process and provide the best approach to our communities and organizations.
Model Driven Solutions (www.modeldriven.com )