Surprisingly little information has reached public view concerning BPMN 2.0, now under consideration in OMG. Unlike most standards approval processes, the outcome of this one is not preordained. There are two submissions, quite different, and it could go either way.
Oracle’s Vishal Saxena notes that one reason BPMN 1.x has been so successful is that it “keeps simple things simple” by focusing on abstract business-level modeling, allowing developers flexibility in how to implement the technical details, and argues that BPMN 2.0 “should maintain this flexibility.” In response, IDS Scheer’s Sebastian Stein points out that a problem with BPMN 1.x is that it “only has implicitly defined execution semantics,” and BPMN 2.0 needs to make them explicit. He goes on to neatly summarize the competing proposals:
At the current point there are two different approaches discussed within OMG, how to do that:
- BPMN 1.1 already contains an implicit definition of the execution semantics, so just make them explicit by writing them down.
- Use a more abstract meta model with well defined execution semantics like BPDM and map BPMN elements to it.
Approach 1 is a simple solution, because in the end it does not change much for the BPMN user. The implicit execution semantics are just made explicit, but they are not modified. Approach 2 is more complicated, because a second language is added to the stack and new concepts are introduced. Having more and new concepts might contradict BPMN?s current strength – simplicity. This will increase the learning curve for BPMN modelling and might hinder a further adoption.
I think this is a fair characterization, but it’s not the whole story. Approach 1 is a joint submission by the large platform/middleware vendors, companies used to having their way in W3C and OASIS. Approach 2 is BPDM, which has been incubating in OMG for a long time, and wedded to OMG fundamentals like MOF and xmi. More significantly, Approach 1 reflects (to me, at least) a BPMS approach to BPM solution development, emphasizing unification of the business-oriented process model with the executable design, while Approach 2 is more aligned to OMG’s programmer-oriented MDA vision, in which models are just a more efficient way to generate code.
It’s a subtle distinction, and not everyone would agree with my characterization. A key element is that in Approach 1, the execution semantics of shapes in the diagram are specified by the standard, while in Approach 2 they can be redefined by the user. That’s what the BPMN Wish List controversy back in March was all about.
As a non-voting guest member of OMG, I am not a party to the contest, but I am not neutral, either. I think a win by Approach 1 would greatly assist BPMS become mainstream and better define the relationship of BPM to SOA. Formal action by OMG on this is not scheduled until August-September.
Yeah, you are right that approach 2 is more the OMG way. I’m not really sure if I agree that in the second approach the user can redefine the execution semantics, because they are defined by the mapping to BPDM. Or what do you mean exactly by redefining?
Refer back to the Wish List post in March, regarding Antoine’s statement that BPMN inherently supported nonaborting attached events because it is based on a metamodel that lets you add that custom behavior. This is the BPDM approach… as long as you can specify the semantics at the MOF level, anything is OK.
Bruce, Sebastian,
Thanks for this discussion. Just wanted to give some
information about BPMN and BPDM that might be helpful.
> Approach 1. BPMN 1.1 already contains an implicit
> definition of the execution semantics, so just make them
> explicit by writing them down.
BPMN 1.x semantics is written down in the existing
specification. For example, see the second paragraph of
Section 9.5.2 (Exclusive Gateways) in
http://doc.omg.org/formal/08-01-17. The goal for BPMN 2 is
to capture the semantics in a metamodel, rather than just
text.
> Approach 2 is more complicated, because a second language
> is added to the stack and new concepts are
> introduced. Having more and new concepts might contradict
> BPMN?s current strength – simplicity. This will increase
> the learning curve for BPMN modelling and might hinder a
> further adoption. Having more and new concepts might
> contradict BPMN?s current strength – simplicity. This
> will increase the learning curve for BPMN modelling and
> might hinder a further adoption.
The additional concepts are for vendors to create integrated
applications. The end user does not see them in diagrams or
XSD. Users will see improved interoperability between
applications and tools because the abstractions capture
commonalities in the metamodel that are normally written
multiple times in different ways across the specification.
> Approach 2 is BPDM, which has been incubating in OMG for
> a long time, and wedded to OMG fundamentals like MOF and
> xmi.
BPDM provides an XSD, as well as XMI. The OMG Board of
Directors voted to adopt BPDM last month. It is a formal
OMG specification.
> More significantly, Approach 1 reflects to me, at least)
> (a BPMS approach to BPM solution development, emphasizing
> unification of the business-oriented process model with
> the executable design, while Approach 2 is more aligned
> to OMG?s programmer-oriented MDA vision, in which models
> are just a more efficient way to generate code.
BPDM can model manual, semi-manual, and automated
processes. It uses the term “occurrence” rather than
“execution” to cover all these. For example, an occurrence
of a Commute process happens on a particular day with a
particular commuter, and involves many manual and automated
processes.
> A key element is that in Approach 1, the execution
> semantics of shapes in the diagram are specified by the
> standard, while in Approach 2 they can be redefined by
> the user. That?s what the BPMN Wish List controversy
> back in March was all about.
In both approaches, changes to BPMN must be approved through open process at the Object Management Group. In the
BPDM-based approach, the user has the option of defining
additional semantic constructs that are not part of standard
BPMN or BPDM. These can be used in communities that find
them useful, or proposed as additions to BPMN at OMG. This
capability also makes it easier for OMG to respond to user
requests for new features in BPMN.
Hope this is useful. More information about BPDM is
available at http://www.conradbock.org/#BPDM.
Conrad Bock
U.S. National Institute of Standards and Technology
Hi Conrad,
the question is whether BPMN 2 should use his own metamodel or if it should include another metamodel (BPDM), which was not directly defined for BPMN.
Sebastian
Sebastian,
> the question is whether BPMN 2 should use his own
> metamodel or if it should include another metamodel
> (BPDM), which was not directly defined for BPMN.
BPDM was defined with BPMN in mind and integrates quite alot of the terminology already (Process, Activity, Gateway, etc). The terminology can be further aligned in BPMN 2, and where it can’t, BPMN is a specialization of BPDM. Having two similar metamodels adopted at OMG is a significant burden for everyone. Also see the comments at https://www.methodandstyle.com/2008/05/06/an-insiders-view-of-bpmn-20.
The BPMN metamodel needs abstractions because business modeling, and even process modeling, goes well beyond BPMN as a notation. A diagram-specific interchange format cannot meet the realities of a marketplace where BP, EA, and SOA methodologies are used together and will evolve over time. There are and will be other notations and other interchange formats. It is the job of the notation to be user friendly and provide a specific view that is comfortable for its intended users. It is the job of the metamodel behind the view to capture the semantics of the many views required for realistic architecture efforts.
For perspective, let’s remember the market’s most immediate concern is diagrams and serialized interchange, not metamodels. We have a fully standardized metamodel that supports user-friendly XML documents via XSD, has a mapping to BPMN 1.x notation, and in the next BPMN 2 submission will capture purely graphical information such as activity positions. We can get to an interchange format much more quickly with a BPDM-based approach than waiting for an entirely new metamodel to be developed, mapped to XML and notation, integrated with graphical information, and worked through the standardization process.
Conrad, Cory, Fred
Conrad (et al),
This is a question, not a comment: With BPDM, does the BPMN serialization describe the semantic or the notation? E.g., Would the XML for an implicit parallel split (2 unconditional sequence flows out of an activity) be the same or different from the case of AND-split gateway? In your understanding would that apply also to the IBM-SAP-Oracle one or not?
–Bruce
Bruce,
> This is a question, not a comment: With BPDM, does the
> BPMN serialization describe the semantic or the notation?
Serialization would be the XML documents, is that what you mean? Serializations are inherently notational, because they capture the diagrams being interchanged. They use the most concrete concepts only, rather than abstractions.
Metamodels contain at least concrete concepts, because serializations conform to XSD or XMI generated from metamodels. Semantic metamodels, like BPDM, also include abstract concepts for semantic elements that are defined once and reused many times across the metamodel and in other metamodels. This facilitates uniform implementation and understanding of the specification, as well as integration with other tools in industrial, enterprise-wide architectures. This is critical for BPMN tools, since they need to work in a larger context of enterprise applications. The abstractions are not visible in the user’s XML documents, of course, because these are purely notational.
> E.g., Would the XML for an implicit parallel split (2
> unconditional sequence flows out of an activity) be the
> same or different from the case of AND-split gateway? In
> your understanding would that apply also to the
> IBM-SAP-Oracle one or not?
Both BPMN-S and IOS would capture the above cases differently, because metamodels must represent concrete concepts to support serialization. BPDM has the added benefit of providing abstractions of these concrete concepts, as described above. For example, BPDM has a single abstraction for the semantics that process definitions can occur (be performed/executed) many times. In the above cases, BPDM explicitly models that occurrences of the process (the individual performances/executions at certain times) will be linked to occurrences of other processes corresponding the activities connected by the gateways and sequence flows, and that the temporal order of these other occurrences will be as required by the gateways and sequence flows. Purely notational metamodels, such as IOS’, only represent that activities appear in the diagram, and have sequence flows and gateways between them. The meaning of this for actual occurrences left completely to textual description.
Conrad