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.
Bruce, good post – I share your concern about things getting too complex. Though admittedly, I was under the impression that the IBM camp wanted something that was even MORE complex, ie, a layer in the middle that will map bpmn to other formats like bpdm… oye! 🙂 (admittedly i may be mistaken as it is hard to track this process over such a long period of time)
re: attached events that do NOT abort an unfinished activity. I’ve worked in one BPMS that supports this feature and it is incredibly useful and allows for some really interesting escalation patterns that are, quite frankly, difficult to implement without it. Or without creating the false impression that this task has been visited many times.
I’d rather see BPMN 2.0 focused on refining the semantics of the notation, or adding additional notational elements, rather than focusing just on storage. And I’d rather BPDM be just a great portable storage mechanism for BPMN rather than boiling the ocean of context models… it seems like such a hard problem as to render itself inert. But no doubt the people tackling these things can render this complexity into a spec… i just wonder if a lighter weight, more useful spec could be rendered more quickly by having tighter goals. then after coming up with storage that makes sense for each of the individual specs, it might be interesting to come up with the metamodel that can describe them all (and easier).
I’ve seen the explosion in the webservices specs, which is a little disheartening. the complexity is so in excess of the additional value… and it puts a great cost burden on stack vendors to provide these new webservices stack implementations (and with many more lines of code, one wonders if the quality can be maintained). I don’t know enough about the current BPDM effort but I hope that it doesn’t get as complex as the webservices side of the house. the S in SOAP is long gone 🙂 Let’s hope the B in BPMN doesn’t disappear either!
Scott,
Thanks for the comment. I just discovered your blog and I like it (added to my blogroll), esp the recent one about heroes and unicorns. Keep it up.
–Bruce
Great summary of the high level issues and some of the current issues being worked through the industry. To me it just seems people are missing the top need that BPDM should be filling, which is providing a light weight data exchange model that can be useful and usable.
It just seems the goals of BPDM have grown and with this scope growth we now have very real interpretations of what BPDM should be when it grows up. It is hard to understand how BPDM can be BPMN 2.0 when it is different beast entirely.
BPMN provides a useful and usable standard which is why it has become so popular. If BPDM could first address the need for OMG to provide a simple and useful data exchange that would be great. In the absence of something like this from OMG vendors have either created their own proprietary data exchange or used complimentary standards like XPDL. If BPDM stays too complex then it risks being another over-architected standard that is rarely implemented.
Shane,
I’m sure OMG has never heard that charge before… 😉 I agree with you, except the part about scope growth of BPDM. I think it is what it always was – an ambitious abstract metamodel for processes, independent of any “language” such as BPMN. The “new” part was rebranding it BPMN 2.0, when all that the people actually using BPMN wanted was 1) an XML interchange format and 2) a bit cleaner description of the semantics and rules. Well maybe also a smoother fit with BPEL, too.
–Bruce
Bruce,
Fair enough, but scope creep is in the eye of the beholder. Maybe the issue is more communication and what different people perceived the scope of BPDM. It always has seemed at the top level people agree, but things then get complicated. As BPDM has been in process since 2003 it is not like these are new issues first being brought up.
Bruce –
thanks for the compliment, and just to keep the blog-lovefest going, your blog has been a great read for a long time. Hoping I can draw some of my colleages at BP3 into posting more often! we’ll see 🙂
ok, back to the debate at hand… you know, its almost tempting to just post an opensource xml format that comprehensively covers the BPMN 1.1 spec and post it on sourceforge. Additionally, we could post adaptors to/from that normalized format to any additional formats that are published (or others could contribute such… hm. its a thought… it would only take one person a short amount of time to do, I’m guessing. and an expert from each vendor ecosystem could probably write an adapter that slurps up the opensource format.
(or produces it)
Scott,
An xml serialization of BPMN is not hard – every tool has one, it’s just that they are all different. With BPMN 1.1, there are already multiple attempts at standardizing – BPDM, XPDL, and Intalio’s open source one. You need more than a schema. You need to specify how to serialize various diagram patterns, because even with the same schema, tools do them all differently, as I’ve learned from working with Robert Shapiro and Tom Laverty on portable BPMN in XPDL 2.1.
Bruce,
Glad you and Fred are having this discussion. Pardon me if I kibbitz.
> 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.
The calls for a BPMN metamodel started two or three years ago, including OMG reopening the BPDM submitter list to the new BPMI members, and invitations from the BPDM submitters at the time. Only one new vendor chose to participate, not among the major ones. IBM and SAP were in attendance at those meetings, and perhaps Oracle also. It’s unclear why they did not to participate, but there was nothing preventing them, certainly not an “insider” group.
> 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.
BPDM was conceived to cover common process languages including BPMN, rather than something unrelated or different from BPMN. BPMN and its precursors were widely known in the process modeling world during BPDM development. The calls mentioned above requested the BPDM submitters to include BPMN as a special case, which they did. BPDM includes a notation mapping to BPMN.
> ?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.
Adoption of process modeling tools would increase significantly if they worked with other tools, such as process analytics, monitoring and management, as well as processes defined textually rather than graphically. Simply capturing notation will not achieve this, because these tools are most often concerned with semantics, rather than notation. For example, process monitoring tools are concerned with how the process is expected to be performed or executed, rather than whether it was specified with a particular notation. Process modeling tools needs much more integration with other tools to achieve wider adoption than the occasional use they receive now (see the BPTrends 2008 survey), This is not possible with a purely notational metamodel.
> 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,
> 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.
BPDM includes a mapping to BPMN notation. A number of aspects of the metamodel were designed specifically to facilitate this mapping, for example, the model for gateways.
> 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.
BPMN can only be changed when there is agreement on which changes to make, and they are adopted through the Object Mangement Group process. This is facilitated by extensions developed outside the standard that are shown to be useful in practice. BPDM enables semantic extensions, and with the diagramming capabilities in the upcoming BPMN 2 submission, extensions to notation also. Users and vendors can develop their own additions to BPMN and suggest them to the OMG for adoption. This makes it easier for OMG to respond to user requests for new features.
Looking forward to more discussion between you and Fred.
Conrad
[…] Bock of NIST picks up the defense of BPDM where Fred Cummins left off. Since I don’t see much other discussion on the web about this […]