The two BPMN 2.0 proposals are out and already spurred quite some discussion in the BPMN blogging community. One of the changes that seem to remain mysterious about BPMN 2.0 are choreographies. Bruce Silver mentions the “brand new choreography model that nobody understands (or cares about)” in one of his posts. So it’s high time to shed some light on this topic.

First observation: Choreographies are already part of BPMN 1.x.

Really? What is a choreography anyway? I often use the following definition: “a choreography lists all possible interactions between a set of business partners, together with the behavioral constraints between them.” So the focus is on INTERACTIONS. Choreographies are business protocols, interaction contracts between business partners that want to engage in a collaborative business process. Choreographies only prescribe the observable behavior of partners, not their internal behavior.


To illustrate my point I brought an example of a typical choreography model designed in BPMN 1.x. Two partners are involved – a seller and an auctioning service. The choreography describes the interactions needed for creating an auction. You see message send tasks and intermediate message events that are properly connected through message flow. Two pools are used. Control flow constructs are available to show the causal dependencies between the different communication actions. All fine. Everybody happy.

Second observation: Choreography modeling in BPMN 1.x is possible – but painful.

At first sight, the sample model looks all fine. But wait! If you take a closer look at the model you will see a whole lot of problems.

  • Incompatible branching structures. Both processes contain a data-based XOR gateway. The semantics is that both partners can decide on their own. While it makes sense that the auctioning service decides whether a registration is already present, the seller must not make this decision – an event-based gateway would be more appropriate showing that the seller depends on the decision of the auctioning service.
  • Incompatible sequence flow. The seller waits for a creation confirmation before issuing payment. The auctioning service on the other hand waits for the payment first. This is a classical deadlock situation.
  • Issues with process instantiation. The trigger for process instantiation on the auctioning service side is not specified. Instantiation happens “magically”.
  • Redundancy. The modeler has to duplicate a lot of information in the diagram. The sequence flows, the activities, the control flow constructs, etc. Everything has to be drawn twice.

Well, now you argue that the modeler was simply too dumb to come up with a correct model. Sure, he could have modeled everything properly. It’s not a matter of expressiveness of the language.

But let me tell you this: The number of modeling errors people introduce in their BPMN 1.x choreographies I observe every day cannot stem from a collective dumbness. There must be something fundamentally wrong with the modeling language.

Third observation: Interaction modeling (like in BPMN 2.0) makes sense.

So what can we do to help out those poor modelers designing choreographies? Let’s start with the redundancy issue. In an optimal modeling language you reflect a design decision only once in the model. If interaction A happens before interaction B, why draw this relationship twice in the model? If there is a branching point, a loop, parallelism – why draw it twice in the model?

The new choreography model in BPMN 2.0 does exactly this. It avoids redundancy. Interactions are not split up into send and receive activities. Control flow is defined between interactions, not needing to split it up and distribute it to the partners. I often call this modeling style “interaction modeling” as opposed to “interconnection modeling”.

Avoiding redundancy also helps with other issues. You avoid the incompatible sequence flows. You avoid incompatible branching structures. And also the process instantiation issue is cured. Not by avoiding redundancy but by simply not specifying the instantiation condition for the individual partners.

The proposed notation for the new choreography model might look a bit unfamiliar at the beginning but it does make sense. It speeds up choreography modeling and leads to less modeling errors at the same time. It even enables composability and reusability of choreographies – but let me talk about this another time…

Fourth observation: Interaction modeling creates new problems.

So everything perfect now? Unfortunately, not. The advantages gained by interaction modeling brings a new problem: All dependencies are now defined globally. This means that sequence flows are not assigned to a particular partner. Why is this problematic? Well, you might design choreographies that are not “enforceable”.

Imagine an interaction between partner P1 and P2 that must happen before another interaction between P3 and P4 can happen. How should P3 know when the interaction between P1 and P2 happened? To cover this situation, the BPMN 2.0 comes with quite some structural constraints on what you are allowed to model.

Being a researcher in the field of choreographies, I am of course very happy to see that our work (e.g. our “iBPMN” proposals and enforceability work) actually contributed to exactly these discussions in the BPMN 2.0 spec. On the other hand, the spec still does not completely hit the nail in all the details.

There are also a number of other issues that are related to the questions around synchronous vs. asynchronous communication models that have a heavy impact on what should be allowed in a choreography.

Many things still need further sharpening – but enough for this article. Let’s dive into the details in the next posts.