BPDM Defender Speaks Out

Having long held the inside track, the BPDM camp has felt little need to advocate publicly for its vision for BPMN 2.0. However, with united opposition from IBM, SAP, and Oracle, EDS's Fred Cummins, co-chair of the BMI task force in OMG (responsible for BPMN and other BPM standards), has begun something of a public defense. His first post addresses the concern that BPDM is "too complex." He begins by acknowledging that BPMN and BPDM sprang from different goals:

BPMN focused on defining a graphical notation that was consistent with the way business people think about business processes. BPDM was intended to provide a common modeling representation to resolve differences between existing standards and proprietary languages, independent of the implementation technology.
The admission that BPDM was never conceived as BPMN but a way to map BPMN to other things is something all sides can apparently agree on.

While the success of BPMN's adoption by such a wide variety of tool vendors has been greatly aided by its light weight - it doesn't try to do too much - Fred notes that BPDM is not intended to stand alone, but to serve as the process component of a "suite of business modeling languages being developed by OMG," including SBVR (business rules) and BMM (strategic motivation model). Moreover, the reason for BPDM's complexity - what Fred calls "robust abstract metamodel" - is that it has to define...

...basic concepts, many of which will occur in other business models, but in different contexts [in order to] establish consistency of concepts between the different modeling languages. Within BPDM these concepts provide a consistent foundation so that the meanings of the concrete elements that occur in different graphical expressions of BPMN will be consistent with each other and will be interpreted in the same way when used in different modeling tools.
I personally doubt this is a winning argument, if adoption by process modeling tools is the measure.

But I have to say that complexity of the metamodel would not rank at the top of my list of complaints about BPDM. More serious is the view that the notation is secondary to the metamodel, and that user-defined semantics are OK as long as the underlying metamodel can describe them. This is the essence, for example, of Antoine Lonjon's contention that an attached event in BPMN does not necessarily abort an unfinished activity. Non-aborting attached events would be a great idea, I agree, but step one is to define a notation for it and put it into the BPMN spec.

I have no problem with BPDM as an abstract metamodel, but simply renaming it BPMN 2.0 puts at risk the success BPMN has enjoyed to this point (even without an interchange format). But I'm glad Fred is engaging in the public debate.