BPMN 2.0 Issues: (1) Is BPDM too Complex for BPMN 2.0?
by
Fred Cummins
In "Which Way for BPMN 2.0?" Bruce Silver discusses some of the issues surrounding the next version of BPMN. The RFP for BPMN 2.0, issued by the Object Management Group, calls for a reconciliation of BPMN and BPDM to achieve a robust business process modeling and model exchange capability with a consistent graphical notation. There are currently two submissions, one that focuses on resolving differences between BPMN and BPDM, and one that abandons BPDM to create an independent computational model for BPMN.
I represent EDS in the development of BPDM and BPMN and the submission to merge them into a single language specification. In a series of blog entries, I will discuss some of the issues that divide these submissions. In this entry I will discuss the concern that the BPDM metamodel is too complex.
These two specifications, BPMN and BPDM, developed from two different perspectives. 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. It evolved from an analysis of process modeling requirements, including support for process integration in SOA.
In addition, BPDM is a member of a suite of business modeling languages being developed by OMG. For example, SBVR (Semantics of Business Vocabulary and Rules) supports modeling the semantics of business concepts and the expression of business rules incorporating those semantics. BMM (Business Motivation Model) provides a framework for capturing strategic planning models. A strategic objective of the Business Modeling and Integration task force of OMG is to develop a full complement of business modeling standards that work together to support more effective enterprise planning, analysis, design and improvement.
As a result, BPDM has a robust abstract metamodel supporting the BPMN modeling concepts. This abstract metamodel defines basic concepts, many of which will occur in other business models, but in different contexts. The use of these abstract concepts will help 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. For example, there are a number of variations of BPMN events (the elements represented by a circle with various icons). While these graphics have different meanings, there are shared concepts that make them all events and define how events are incorporated in a business process model.
To a BPMN user and even on first impression of tool builders, the BPDM metamodel looks complex. However, it should be understood that this complexity provides precision in the definition of the concrete elements. The abstract concepts do not appear as additional BPMN graphics and they do not appear as additional concepts expressed in the XML when a business process model is exchanged between modeling tools. Consequently, compliance with BPDM does not require implementation of the abstract metamodel, it only requires that the concrete elements that users see and that are exchanged via XML must be compliant with the specified format and semantics. In addition, a tool vendor should provide defaults and views of the model that allow the casual business user to ignore all the options and complexities of BPMN that could be incorporated in a robust solution.
In summary, the appearance of complexity of the BPDM metamodel makes the specification more precise and robust, and supports development of consistent, complementary business modeling capabilities in the future. The complexity does not make business process modeling more complex for users, and it does not unnecessarily constrain the implementations of tool vendors.
