Frank Michael Kraft's Blog

In my view, BPMN 2.0 is an important milestone in a greater journey with in a trend. The trend is the connecting of models from a business domain with those from system development.

First: What is the purpose of BPMN?

1. Description of as-is processes within a company and cross companies
2. Using the models for subsequent system development. The model is the high-level specification.
3. Execution of the model (for example in Appian Anywhere) – probably translation into another execution language like BPEL.
4. Model driven development of systems.

If we want to reach and achieve the fourth step, it is clear, that the execution semantics must be clearer as before – unambiguous.

On the one hand it is required to have “soft” models in the description of as-is models and also shall-be models. This will be so in all future. But especially the connecting of business domain models with system models within a holistic model cycle is a new level of effectiveness that we set our hope to.

In my opinion, this hope is not in vain.

Furthermore a complete meta model is needed for model exchange. This is – in my opinion – overdue anyway.

Why do we model at all? We want to utilize and connect flexibility with quality. This is reached by transparency. Only by transparency it is possible to execute the needed quality assurance on this level. If this is connected with model execution or model driven development, this is even better. We have laid the foundations.

This sounds quite enthusiastic. However I am a notorious BPMN critic. Even now more than enough critics comes to my mind. However I am exhilarated what we have reached within the scope of BPMN 2.0. We have made enormous progress in some key areas. I will elaborate on this in further blog posts.

At the Workflow Management Coalition BPMN Industry Day we also discussed about the implications, that BPMN 2.0 now has a meta model. In itself this is a very good thing. However some problems appear, when thinking about backward compatibility, especially with XPDL as de-facto standard for model exchange. If there are models, which are incomplete, but they still need to be exchanged, how can this be handled, if the BPMN 2.0 metamodel requires strict cardinality conformity, that was not required by XPDL? The same problem appears in tools in general, if the model is in an incomplete state and it is saved. Tools need to react gracefully to this situation, otherwise the usability of the tool is harmed.

So if in this example the incomplete model is validated against the meta model, then it fails, because the meta model requires at least two participants for the conversation node. However it makes completely sense to have the cardinality 2..* in the metamodel, because there is no meaningful Conversation without at least two participants. A possible solution would be to water down the metamodel. This is not discussed for BPMN 2.0, but may be for XPDL.

So in this watered down metamodel the participants cardinality is only *, allowing for 0 participants as well. The validadion succeeds, but the semantic suffers. Furthermore the check has to be done whatsoever at some stage. So watering down the metamodel is not a good idea in my view. Instead the solution should be a model lifecycle.

In this proposal the model itself has a lifecycle, which can be active or inactive. If the model is inactive, the validation reacts gracefully against the metamodel. Only if the model is active, the validation fails, but this is indeed intended. So it is unter the control of the modeler, if he wants the full strength of the validation or not.

Such a model lifecycle is not planned in BPMN 2.0 as far as I know, but I think it is a good idea and should be considered. There is a MOF 2.0 Facility and Object Lifecycle Specification that might be considered to be used in order not to invent something new that exists already.

On the BPMN & XPDL Industry Day of the WfMC Thought Leadership Summit one topic of discussion was the current status of BPMN Diagram Exchange.

In the BPMN 2.0 Spec there is a proposal, that builds on a generic OMG proposal, which is not finalized and which will be standardized independent of the BPMN 2.0 standardization.

In this proposal the idea is to have a Diagram Interchange Model independent from the Domain Model, which is in my opinion, a good idea. It is generic, so that other diagram types could be modeled. The diagram validation is done agains a so called Diagram Definition Model, which is also new. The Diagram Definition Model defines, which Attributes a Diagram Interchange node or connector can have, the allowed references and additional (OCL) constraints. Furthermore each Diagram Interchange node or connector is refers to a Domain Model class – in this case a BPMN Task or Gateway or Sequence Flow for example.

Advantages I see:

• Seperation of Model and View – Model maintenance
• Multiple Diagrams for the same underlying BPMN model are possible
• Generic format for different diagram types – tools can use synergies

Disadvantages I see:

• Tools vendors can not use XSD validation. They have to implement the validation against the Diagram Definition.
• The constraints of the Domain model (e.g. Sequence Flows can only be connected to …) must be repeated in the Diagram Definition Model.
• Grafical Attributes (e.g. line thickness) must be repeated as per modeling element.
• Attribute Format (name / value) too generic in my view.

The XPDL Format used to include the Graphics Info into the Elements of the Domain model.

This is simple and straight, and current tools support it, but has the disadvantage, that it is not possible to have one modeling element (e.g. one process) appear in different diagrams. Instead, the modeling elements must be repeated as per diagram, which has many disadvantages in model execution, analysis and model driven development. The Signavio modeler, which was discussed at the meeting, follows the same approach. However it is good as long as only diagrams are drawn for visualization purposes.

Because the BPMN Digram Exchange Proposal was too generic for some, Bruce Silver proposed an BpmnDI.XSD for a concrete XSD validation.

This approach repeats basically all or many BPMN domain modeling elements. This of course is the disadvantage, because it is but a redundant repetition of the already defined domain model. However it is no complete repetition, because the gateway type for example is not included. So a tool must look into the domain model anyway to render the gateway.

Within this discussion it came to my mind, how the GMF (Graphical Modeling Framework) solves this question. I think it is well worth to have a look at this approach, because I think it may be a good compromise.

The GMF defines a Grafical Definition Model, which only defines Shapes. This is simple to understand and straight. Then it defines a Mapping Model. Within the mapping models, nodes and connections are grouped as needed. For example it defines, that there is a node lane which can contain node Activity and Sequence Flow. As a followon the Acitivty node is connected to the Activity domain class and the Shape, that descibes how an activity should look like. The shape can be re-used, which is an advantage of the BPMN Diagram Exchange Approach. The Structures of the Diagram is already contained in the Mapping Model, so it can be serialized to XMI and XSD, which is also an advantage. However still the diagram logic is separated from the Domain Model, which is an advantage over XPDL. And it is a very generic model, which is an advantage over a mere BpmnDI.xsd.

I personally worked with the GMF, and found it quite practical. I am not proposing to use GMF per se, but maybe the approach should be further considered.