On The Future of BPMN (Too)...

The future of BPMN (once Business Process Modeling Notation, now Business Process Model and Notation) is finally here. Or is it? After much politicking, design by committee, and intellectual debate, the OMG (Object Management Group) finally adopted the long-anticipated BPMN 2.0 specification last June (I know, old news). For those that are unfamiliar with the OMG Technology Adoption Process, when a specification is "adopted", it enters a finalization phase, during which vendors are expected to implement the specification and work together to iron out any of its kinks. Having gone through that process with the UML2 project at Eclipse, I have first-hand experience with the challenges of balancing specification finalization against the realities of shipping a product ... But suffice it to say that the age of tooling support for BPMN 2.0 is at hand.

Eclipse has actually had a decent BPMN editor for a few years now, courtesy of the SOA Tools Platform project. It's good enough that I know of at least two vendors that considered scrapping their internal efforts in favor of adopting the open source tooling. However, the BPMN Modeler was never based on a standard metamodel, for various reasons, among them being the fact that, well, the OMG didn't really have one (unless you count BPDM, but that's a whole other ball of wax) - until now. When I proposed the BPMN2 subproject of MDT back in late 2007, I was pleased to receive interest from the BPMN Modeler team in adopting the metamodel implementation, once available. Fast forward two years beyond project creation and six months beyond specification adoption and, unfortunately, as a result of changing priorities among the project's original participating companies (what else is new?) - none of which is participating in the project any more - we still don't have a metamodel implementation. In fact, I was on the verge of contemplating a termination review for the project when, unprompted, Intalio stepped forward with a willingness and ability to contribute the metamodel implementation themselves! So, I'm pleased to say that, in the not too distant future, we'll have an open source implementation of the BPMN 2.0 metamodel at Eclipse!

So, is that the end of the story? Well, not quite. To their credit, the OMG has started looking at the long standing issue of overlap between UML and BPMN (not to mention its other metamodels) and general lack of architectural cohension between its various modeling specifications (often referred to unaffectionately as the "metamuddle"). In fact, the OMG Architecture Board recently charted the “Architecture Ecosystem AB SIG” (or “AE SIG” for short), which is being chaired by Cory Casanave (Model Driven Solutions) and Jim Amsden (IBM). The mission of the AE SIG is to work with OMG domain and platform task forces, other relevant OMG SIGs (special interest groups), external entities, and related industry groups to facilitate the creation of a common architectural ecosystem (sound familiar?). This ecosystem will support the creation, analysis, integration, and exchange of information between modeling languages across different domains and viewpoints, from differing authorities. In particular, the need for business and enterprise level architectural viewpoints must be better integrated with the technical viewpoints that define systems to address enterprise needs. The AE SIG will focus on the capability to define and integrate languages and models in various viewpoints and support other groups that will focus on the specific viewpoints required for their specific domains. A set of viewpoints, supporting models, and supporting technologies will comprise the ecosystem.

Recently, Cory issued a poll to prospective members of the AE SIG on the topic of integrating BPMN and UML. Details of the poll, reproduced here with permission from Cory (thanks!), are below.

The Question

There has been substantial discussion on the needs and issues with integrating UML and BPMN. Using this as a "test case" we would like to take a poll on what would be the best way for this integration to happen, strategically. In other words, if you could design this from the ground up, what would you do?

The Options

[1] They remain separate standards. There is a BPMN standard with metamodel and a UML standard with metamodel. These standards are separate, intended for separate communities and tools. There is no relationship between these standards. This is, essentially, the current condition.

[2] BPMN is a UML profile with notation. The separate metamodel for BPMN is deprecated and the formal specification of the BPMN notation is as a profile of UML, using the BPMN notation. The result looks and feels like BPMN as it is defined today, but it is defined “on top of” UML. This option would include any adjustments in the UML metamodel required to make such a profile well-formed. Another interpretation of this option could be that the BPMN metamodel is retained and there is also a UML profile for BPMN, presumably with a mapping between the two. However, the profile of BPMN should look the same in either case. (The latter may be the interpretation most people who voted for the option intended, so one should interpret this option to be silent on the question of retaining the separate BPMN metamodel or deprecating it.)

[3] Create a unified model encompassing both. A MOF or MOF-like metamodel is created that is the superset of the capabilities of UML and BPMN as unified conceptual system. This model would have the semantics of process layered in such a way that redundant concepts have identical metaclasses (perhaps with different notations) and similar concepts have like capabilities factored into common superclasses. The nature of this unified model would be much like the UML and BPMN models today, but including the concepts and specifications of both notations.

[4] Semantic models with UML and BPMN viewpoints. This option pre-supposes more advanced meta modeling capabilities where an underlying semantic model (or set of models) is defined and then various “viewpoints” on the semantic model provides the specialization of those semantics for the needs of a particular kind of stakeholder. In this option both UML notations and BPMN notations share the same or related underlying semantic model and have an additional specification that specifies the specific structures required for BPMN and UML viewpoints. The difference between this and the prior option is that the viewpoints and semantic models are more loosely coupled. The models are constructed with the expectation that multiple languages and viewpoints will be constructed out of the semantic building blocks. The semantic building blocks are, likewise, loosely coupled.

[5] BPMN replaces UML activity diagrams. Activity diagrams as currently defined in UML are deprecated and replaced with BPMN notations and semantics. BPMN essentially replaces a portion of UML behaviors.

[6] BPMN grows to make UML not required. BPMN grows to encompass all the capabilities required for business-focused modeling and architecture, thus making any integration with UML redundant. BPMN may, some day, replace UML.

[7] BPMN and UML are separate models, mapped with QVT. BPMN and UML are separate metamodels as they are now. A QVT mapping is specified between them such that a portion of a model in BPMN can be used to create a UML model and a portion of a UML model can be used to create a BPMN model. Since the notations are not the same, notations would not be mapped.

[8] There are ways to make links between them. Both the BPMN and UML metamodels exist in parallel, much as they do now, but there are ways to “link” elements between them. This may require some additions to the OMG's metamodeling capability. The links would, for example, allow a behavior specified in the BPMN model to be the implementation of an operation on the UML side. There are, of course, questions and issues about how this is done and how the context and types on each side reference the other with some precision. This may require changes to both specifications to be less assertive about the types of elements used in associations.

[9] Other. Any option not reflected above.

The Results

From the results, it's clear that (for those that responded, anyway) the most popular option is to create yet another metamodel that encompasses both BPMN and UML (maybe UUML, the Ultra Unified Modeling Language?). How would you have voted? It's perhaps worth noting that the integration options (2, 3, 4, 5), when combined, are by far in the majority, so it seems that anything would be preferable to the status quo. Time will tell, I suppose. In the meantime, the MDT project will focus on providing another de facto reference implementation of an OMG specification. As always, if you're interested in helping, we'd love to hear from you.