> 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

> 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 http://www.brsilver.com/wordpress/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

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

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