I want to share some thoughts about it.

First Prof. Börger looks at some of weaknesses of the BPMN 2.0 Standard.

He sais:

The crucial criterion is how well the practitioner is supported when walking through the different levels of detail (refinement levels).

The standard does not support process structure at the risk of producing incomprehensible spaghetti diagrams.

The standard document fails to provide a seamless systematic mechanism for refinement from conceptual to executable models, which is necessary to guarantee the reliability of the implementation.

I discussed the same topic some days ago. I agree that the standard does not prescribe a solution to the problem, but as I said keeping some basic rules the solution is easy. It is always a question of discretion how much should be prescribed by a standard and how much should be described in a guideline or methodology or best practice how to use a standard effectively. There are always many ways to do it wrong, but as long as it is easily possible to do it right, it should not be such of a headache. As I said I will discuss the way to do it right in the seminar BPMNexpress. In general also I teach it also in the mentoring.

He also sais:

Furthermore a statistical evaluation (of BPMN 1.1) shows that `the average BPMN model uses less than 20% of the available vocabulary’ and that, out of the more than 50 graphical elements in BPMN, `Only five elements (normal flow, task, end event, start event, and pool) were used in more than 50% of the models we analyzed.’

Yes, and this is why it is possible to learn what you really need to know about BPMN in half a day. Of course full mastery is only reached within a longer process of modeling, mentoring and quality assurance. But this is normal with any modeling method.

The he talks about difficult modeling concepts in BPMN 2.0:

The lifecycle concept is an example of an underspecified feature, particularly in relation to the equally underspecified interruption mechanisms like exceptions or cancellation or compensation for transactions.

I have the same opinion. I tried to convince the BPMN 2.0 standardization team that these concepts are too difficult and problematic. Now I recommend to my clients not to use them. However for all of these problems, there is an easier way to solve them.

A general notion of state is missing and, as a consequence, the specification of relevant data dependent conditions is only poorly supported.

In fact BPMN 2.0 has a notion of state for data objects. This already helps a lot! I do recommend to my clients the use of state for data objects and it makes many modeling problems much simpler.

And yes, the state model is not very elaborated – but it can be extended.

Communication and process interaction are poorly supported for concurrent execution, e.g. of independent (not embedded) subprocesses or of processes belonging to different parts of one organization or to different cooperating organizations.

An analogous problem results from the poor interweaving of different BPMN diagram types, in particular that no consistency criteria are imposed for them, for example collaboration vs choreography vs process diagrams.

I do not agree at all. This is one major part of what is new in BPMN 2.0 compared to BPMN 1.x. I will teach this in BPMNdelta.

Later Prof. Börger looks at difficulties with WPI Workflow Patterns

The workflow patterns, as presented by the WPI, come without pragmatic or rational foundation. In fact there is no statistical underpinning showing how frequently which patterns appear in real-life business processes.

My opinion is that some of these are of practical relevance and others are not. I am preparing a publication on the topic, but it is not finished. Also most of these patterns that are relevant in practice can be reduced back to very simple principles of modeling.

Prof. Börger has the same opinion as he sais:

In fact most patterns are not of fundamental character but are easily definable from a small set of more basic and rather simple patterns.

In the last section Prof. Börger discusses YAWL and coloured petri nets. Some of his statements:

In this section, we show that the purported semantic foundation of YAWL using coloured Petri nets is not `suitable’ for the practice of BPM.

… deal with patterns that Petri nets have difficulty expressing, in particular patterns dealing with cancellation, synchronization of active branches only, and multiple concurrently executing instances of the same task.’

… languages which `lack the concepts to be able to deal with the broad range of requirements one may encounter when trying to precisely capture business scenarios’ directly applies to Petri nets, work flow nets, reset nets and other extensions proposed for modeling business processes.

I already discussed some days ago, why I would not build a new standard for Adaptive Case Management based on BPMN and I argued it is because of the “token logic” – actually what is meant is the petri net logic of BPMN. So we – Prof. Börger and me – have the same opinion on this if we refer to advanced scenarios. These are some of the topics that I will discuss in BPMfuture.

As I said BPMN is good for some problems, but it is difficult with more flexibility as it is needed for Adaptive Case Management and in general for the work of knowledge workers. Instead of building more and more complex formal constructs to address all of these special cases it is easier to not use petri net at all for Adaptive Case Management.

However I am more optimistic than Prof. Börger when we refer to cancellation scenarios and BPMN. Yes – he is right it is very difficult with petri net – but BPMN also has other features of modeling. It is possible in BPMN to use data objects and state – and therefore it becomes easier to model cancellation scenarios. I do teach this in BPMNexpress.

Finally he proposes to use a concept of introducing Product Lines to BPM. I have to study this more, before I say something about it.

So – it is very useful to have this tool for the top-down design of process interaction now. Inversely it can be used for the validation of an already existing bottom-up modeling. In reality it will be a mixture between the two. It is of central importance to have the enforceability in mind, that is to define a process, that is actually executeable by the participants. For this the model levels serve as basis for validation.

If we go down to the technical modeling, it is now possible to model Conversations, which are groups of Message Flows, Correlations, which are assignments between a message and a process instance, Service Bindings, Data Flow, … Compared to BPMN 1.2 the DataFlow is more than an artifact now (i.e. more than just a pictogram). It has a datastructure and the Activities have DataInput and DataOutput. Also the DataObject can be used as Parameterspecification for reusable Subprocesses. The Events have been enhanced. There are complex Events, Events , that can interrupt an activity or not, it is possible to define Event-Subprocesses that run aside from the Sequence Flow.

Here some critical comments from my side may be allowed. I think the workflow type of modeling is too strong in this. First there are strong sequence flow relationships established, only to be loosened later by many Events. I think it would be better for the future to define the relationships more loosely from the beginning. For example they could be modeled as preconditions depending on the status. That is something for the future.

Personally I found the discussion around the relationship between public and private processes very fascinating. One time it seemed like we had so many problems with it, that we could not do it. And additionally to this there was the climax of the debate with the concurrent submission. We were blamed, that our model was too strict. A very good discussion! But we found a very simple and elegant solution to these problems. The sequence flow is now not so strict than it was before. It has been loosened, and the difficulties disappeared.

Furthermore one important area is to have in mind the asynchronity of messages. That can produce race conditions between messages. However this in my opinion is not mainly a technical problem, but is due to the asynchronous nature of business processes, that I hope to discuss in the Blog as well in the future. Most problems on the message technology side can be avoided on the business process design level – and that is good news.

There are more changes from 1.2 to 2.0, but in my view these were the most important.BPMN has become quite powerful. Sometimes it is not so clear as to how to solve a certain modeling problem. However the success will depend on elaborating best practices and good guidance.

My wishlist for BPMN in the future? Modeling of Interactions with and of Business Objects. Find simpler ways to model special cases. Model a Process specific  Status.

But now is the time that BPMN 2.0 has to be used and proven in practice. After that we can establish our common opinion about the wishlist for the future. It is a language. And the vocabluary is only the beginning of the process to learn to speak that language. Therefore a good coaching process is what I can recommend.

Elaborating more on what I said before about loosely coupled processes, I want to emphasize today, that the cut of the processes is of major importance – i.e. which parts are loosely coupled and which parts are tightly coupled. Furthermore if process parts are loosely coupled, it is of big importance which process parts are public and which are private. Public process parts constitute a contract, that the other participant can rely on (when to request, when to confirm), while private processes are only needed within the operations of one participant’s organization – for example an approval or a special form of approval that is irrelevant to the other partner. This has these benefits:

• Flexibility: It is possible for one participant to adapt the private process to changes as business requires it without the need to negotiate with the other partner, as long as the change still complies to the public process.
• Stability: The participant can rely on the behavior of the opposite participant, even when the opposite participant makes changes that comply to the public process.
• Visibility: In Process Monitoring internals are not visibible because they should not. It is a decision of discretion which parts of the process should be visible to other partners. However I believe that BPMN 2.0 might be amended for this purpose, because for this it might be necessary that also non-communication activities can be part of a public process.
• Decoupling: The number of private processes that comply to a public process needs not to be multiplied with the number of choreographies, that comply to a public process. Say you have 3 choreographies that you want to combine with 3 private processes. Then without decoupling you have 3*3=9 process models. With decoupling you have 3 + 1 + 3 = 7 process models.

It is important to understand, that the Choreography is an abstract process while the private process is a concrete process – i.e. can be executed by a process engine and has process instances. So the Choreography Model will never be executed by a process engine. It is the summary view of the participants. It never proceeds on it’s own. It proceeds, if one of the participants proceed (as far as the public process is concerned).

If you ever tried to build a central process with process instances that decide about the message flow, you might have tasted how difficult that is. For simple processes this might still be possible. However you always find these difficulties:

• Either the central process does not have enought information to decide – and that are business decisions in the end – or
• The central process needs to know nearly everything.
• As soon as information reaches the central process by means of messages, it is already outdated (because the sender might have evolved in the mean time).
• Also in many decisions it is necessary to involve humans, not just rules.
• If humans are involved, they might not only to decide left-right, but regroup – solve differently (e.g. create return instead of lowering delivery quantity).

This all leads to the conlusion, that I have made for myself: If there is a middle tier, it needs to be a full fledged business application in the end. With business objects, UIs and the like.

Then we have 3 partipants instead of 2 – which is fine. Then we have 2 Choreographies between them, which are still abstract.

I found the collaboration between the companies very productive. Often some have a hidden agenda or have prejudices. In this case I can testify, that I personally did not perceive such a thing.

Of yourse every company has it’s worldview. I found IBM had the strength in workflow technology and metamodeling. I found, that Oracle had an especially deep knowledge in message exchange. And SAP had extensibe experience in business processes and their modeling.

There were strong contrary positions, due to the fact, that there were two different consortiums that prepared a submission.

• Adaptive, Axway Software, Hewlett-Packard, Lombardi Software, MEGA International, Troux, Unisys.
• IBM, Oracle, SAP AG, and Unisys.

There was a collaboration of project management level and the assessment of a common submission. On the concept level there was the discussion of BPDM (Business Process Definition Metamodel) should be the unterlying meta model or not, a 2007 OMG standard for a general exchange format for processes.For IBM, Oracle, SAP a native BPMN metamodel with possible mapping to BPDM was the course we chose.

But there was a very productive part in this controversy. Because members of the other submission team joined also our discussion, our discussion was much enriched. Especially the contributions of the NIST (National Institute of Standards and Technology of the US) revealed many special cases that can happen during message exchange, that were not previously in the discussion. I found that especially inspiring, because I had encountered many of these special cases previously in my architecture projects. That was about the same time that I joined the discussion in more detail. However within the BPDM approach I found some pre-determinations that I definitely could not follow. For example I could not agree, that temporal relations (i.e. that message has to be earlier/later than that messate) should be the main way to describe relations, because in my opinion mere temporal relations do not sufficiently describe cause/effect relationship or constraints between exchanged messages. However there was a significant openness in the discussion that allowed us to find compromises that could achieve very good advances to adress use cases. I personally had significant objections to the choreography modeling. However they could also be resolved – not so elegantly as I had wished – but resolved.

However this was a very interesting discussion, that was not fully completed within the scope of BPMN 2.0 and that I hope I can follow up in the near future.

In the next blog post I will go into details of the my view on BPMN 2.0 and the new modeling possibilities that it offers.

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.

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.

This is a first Choreograpy model. It consists of two Choreography Tasks.

The first Choreography Task is  Request Booking as an interaction between two participants – the Runway Show Management and the Venue Provider. We know from the coloring that the Runway Show Management is the initiator of this interaction. We also know, that at least one message must be exchanged between the participants in the course of the interaction, maybe more.

The second Choreography Task is Confirm Booking. Here the same participants are interacting as before. So we see, that the participants are part of the Choreography model and can be referenced by different Choreography Tasks. However in the second Choreography Task the Venue provider is the initiator of the interation.

We know from the sequence flows between the Choreography Tasks, that the Confirm Booking Task follows after the Request Booking Task.

If you are interested to learn how to model choreographies, I invite you to my training classes.

As a general consideration the underlying problem discussed in the executable modeling debate is this: If Process Modeling is done, there are different purposes for it, as I already stated:
http://www.bpmnforum.net/blog/bpmn/bpmn-in-practice/process-modeling-purpose/
and
http://www.bpmnforum.net/blog/bpmn/bpmn-in-practice/more-on-modeling-purpose/
And yes – most BPMN models today are done for documentation purposes. But ImhO this is quite natural.
BPMN modeling is always done with a purpose. It is done or is most prudently done within a context of a BPM strategy that includes a BPM transformation. For a discussion about this see for example (1). One part of this BPM transformation is the as-is modeling of processes – for which a process documentation is needed. So in such a phase BPMN can serve as the as-is analysis modeling language – which it mostly does as of today. But that is not the whole purpose of the BPM transformation. It is a first step. The subsequent steps are shall-be process design and realization of the shall-be process. The realization is not necessarily done or always done with IT systems. But even for a process execution within a non-IT context consistency and completeness of a process model makes sense. Furthermore the more a process model goes into being the foundation of an IT realization, the more it must become executable – or at least be usable for development and ideally for model driven development. Therefore as the maturity of BPM transformations is progressing with time, the importance of the executable modeling aspect increase.

Bibliography

1. Snabe, Jim Hagemann, et al. Business Process Management – the SAP Roadmap. Bonn, Boston : Galileo Press Inc., 2009. ISBN 978-1-59229-231-8.

There have been complaints, that BPMN 2.0 is only designed with the goal of defining an executable process modeling language and that this impairs the usage of the modeling language for the purposes that it is currently most often used for: documentation.
http://www.brsilver.com/wordpress/2009/01/19/bpmn-20-update/
The complaint is that a model would not be counted as valid, if it is not executable. The demand is that it should also be valid, if it is not executable.
To shed some more light on the issue it is necessary to discuss several aspects. These come to my mind immediately:

1. Choreography Modeling and Execution
2. The concept of enforceability
3. Conformance
4. Abstract Processes

Ad 1) A new feature in BPMN 2.0 is the choreography model. Modeling a choreography model with BPMN 2.0 means modeling an abstract process representing the view of an independent observer on the exchange of the messages that are exchanged between participants. This process is by definition abstract, because it is “in the middle between” the participants. So by definition such a process can never be executed directly or be executable. It can only be realized by means of processes within the participants. But the realization is not necessary for a choreography model to be valid.
Ad 2) Enforceability of a choreography process is an attribute, that holds true, if a choreography model can be realized at all. Not all choreography models are able to be realized. This is completely independent of any technology. It is because of logic only. To make an example If we define this process between John, Mark and Jane, which are in different cities: First John calls Mark and tells him the weather. Then after this Jane calls Mark and they plan the weekend trip. This process is not enforceable. Because Jane cannot know when John has called Mark. So to make the process enforceable, John or Mark need to call Jane to tell her, that John and Mark have phoned. Which of both is better is another thing – but the first process is not enforceable – completely independent of the technology.
So yes, there are some rules in BPMN 2.0 Choreography model that must be kept with a choreography process so that the enforceability is not destroyed. But this has merely logical reasons.
Ad 3) There is a difference between Process Modeling Conformance and Process Execution Conformance. Process Modeling Conformance does explicitly not require that the Process Execution Semantics is kept. However the Process Execution Semantics is most clearly defined. But because this is optional, it is only for those who want to execute. And for those, an execution semantics is very helpful.
Ad 4) Abstract Processes are Processes that have the process type abstract. By definition they are not executed as is, but they are an abstraction of the process, that is really executed.
Good discussion though and I might continue to post on this.