In my last post I have already talked about why I find choreography modeling in BPMN 2.0 far better than in the previous versions. Currently, I am at a Conceptual Modeling conference in Barcelona and inspired to go a step further in making the case for choreography modeling.

I attended several presentations that focus on commercial transactions as starting point for designing business processes. Commercial transactions (e.g. I give you money and you give me that machine in return) are at the very center of doing business. Such transactions are typically related to other transactions with further partners (e.g. carrying out delivery through a shipper or redistributing risk through the introduction of a bank). A value net with different partners is created. High-level commercial transactions might then be refined into smaller transactions (e.g. I give you 20% of the price and you guarantee me to deliver that machine).

Let’s interact!

When having identified the basic commercial transactions, we can think about how they are realized through interactions between the partners. Most steps in a transaction (e.g. request, promise, state, accept) are made explicit through information exchanges (e.g. through sending an invoice or a delivery acknowledgement message). Especially in the presence of modern information technology, exchanging information has become very cheap and there will typically be a confirmation for each and every thing you do. Interestingly enough, steps are sometimes not made explicit but are rather assumed by the involved partners. Take the leave request process in my university as an example: After submitting a leave request form you will never get a notice about whether the leave is accepted or not. Obviously, there was never the need to reject leave requests in the past and so this information exchange step was optimized away (or simply forgotten back in the days).

Other parts of commercial transactions might simply not be realized through interactions as well (e.g. granting access to a power grid). Therefore, we might observe that the actual information exchanges look quite different to what was initially identified as commercial transactions.

As a second step, modeling information exchange again requires different levels of abstraction in order to cope with the complexity. Imagine placing a purchase order, which in turn is realized through a number of interactions. Therefore, the possibility to refine complex interactions into more detailed ones is also something that requires proper representation in models.

BPMN 2.0 enters the game

Supporting different levels of abstraction in business processes is at the very heart of BPMN. Subprocesses are an essential means to create a hierarchy of activities. Also pools and their division into lanes and again dividing them into sublanes clearly shows that BPMN does care about managing complexity.

But why stop in the context of interactions? We have seen that an external view on organizations is important to understand their actual value creation through business transactions. However, when it comes to supporting refinement of complex interactions, the capabilities of BPMN 1.x were rather limited. Message-level interactions can be represented, but complex interactions were simply not on the agenda.

BPMN 2.0 fills this gap by allowing decomposition of high-level commercial transactions into lower-level ones, refinement of transactions into complex interactions and in turn decomposition of complex interactions into interactions on a message exchange level. At the heart of this are the new “Choreography Sub-Processes”, alluding to the classical subprocesses within pools.

While there are concrete examples in the BPMN 2.0 proposal that show how interactions on the message level should be visualized, it is still somehow unclear how collapsed Choreography Sub-Processes should look like. So you should interpret the illustration I included in this post as my own suggestion for that.