Fire and Ice. Part 3. BPMN Collaboration

Collaboration

Prologue. In the previous installment of my blog, the conversation diagram for ACME was introduced. Such a diagram provides the highest level view of a company and its communications with the business environment. One conversation is a zoomed-out view of a collaboration on a particular topic. In this installment, I will explore one of ACME’s conversations by means of Collaboration Diagrams. To refresh the mind, the ACME conversation diagram is reproduced, slightly revisedⁱ. The elements not relevant for Retailer Order scenario are deactivated.

To enlarge the picture just click on it

Let us work together. A Collaboration Diagram portrays synchronized interactions between two or more Participants in a peer-to-peer fashion. Participants exchange messages to execute their internal processes, without a central control or one entity responsible for those message exchanges. This happens in line with predefined and agreed upon rules. On the other hand, each Participant defines, controls and is responsible for its own internal processes.

To enlarge the picture just click on it

The screenshot above portrays the external collaboration taking place during Retailer Order conversation. The pools representing ACME’s business partners are our good friends, as they were also present on the conversation diagram. This time however, conversation links are decomposed into their constituent message flows, presented as dotted arrows between pools. Messages associated with flows are shown too, as small envelopes. But what happened to ACME? It was replaced by the end-to-end Order-To-Cash Retailer Order process, as I want to illustrate ideas for a BPMN top-down process architecture.  

Technically, the pool symbol represents a collaboration participant and use of a black-box pool for a process may seem a bit unorthodox. But here the notion of a graphical process container comes to the rescue. BPMN specifications state each pool contains a separate process, fully contained within its boundaries. Therefore, experts either claim a black-box pool does not need to represent a company or use it to depict a process in such a way. As Deng Xiaoping said once, it does not matter if the cat is black or white, what matters is it catches the mice.

Let us not dance now. The sole purpose of a collaboration diagram with black-box pools is to present the message flows between the participants, with the mother company - or end-to-end process as a surrogate – in the center. While in the example above some conclusions on message sequencing can be easily reached, collaboration diagram may not always fully convey an accurate picture in this respect. Message exchanges between participants are governed by choreography, therefore the latest BPMN specifications prescribe a dedicated model and notation for such a purpose, i.e. to depict collaboration in a very precise way. Choreography encompasses activities, each of which represents the exchange of one or more messages between two or more participants. Thus, it is treated in BPMN specifications as a process of some sort.

Pure choreography can be depicted on a stand-alone diagram. To make things a bit more complicated however, it can be also inserted into a collaboration diagram, similar to the one presented before. In such a case, messages would flow in and out of choreography activities, positioned between the end-to-end process at the center and the external participants positioned around. Choreography modeling is certainly useful in complex B2B situations. Actually, BPMN specifications explicitly define choreography as “…an ordered sequence of B2B message exchanges between two or more Participants.”

However, we can and have to put choreography modeling considerations aside for the time being. When the focus is on internal process modeling, pure collaboration diagrams are sufficient. Besides, no matter what, it is not possible to model choreography activities using ARIS now, as it is outside the scope of its existing BPMN implementation.       

To enlarge the picture just click on it

Internal Collaboration. The final screenshot illustrates collaboration diagram depicting OTC - Retailer Order process in more detail. We see here five processes, grouped together and sending messages to each otherⁱⁱ. But why the OTC Retail Order process was not presented now using one white-box pool? Indeed, the best practice in this respect recommends modeling an end-to-end process within a single pool. However, two laws of proper pool symbol use have to be observed to do it. The first states the contained process should be controlled entirely within its boundaries, either by BPMS and/or by an Executive/Manager with sufficient authority. The OTC Retailer Order process as a whole is compliant in this respect. However, the second law states the process within pool boundary should run as a single instance from its beginning to endⁱⁱⁱ. This is not the case here.

The Fulfill Retailer Order process is initiated when the order arrives and ends when it is paid. It is performed for one order and repeated for another; therefore each execution is treated as one instance. Other processes behave differently. As the annotations indicate, the production strategy at ACME is Make-To-Stock. The Produce Goods process is driven by production plans, adjusted during scheduling to accommodate ad-hoc Production Orders. In other words, it runs largely independently of order fulfillment and ad-hoc Production Orders are exceptions, not a norm. Likewise, the Purchase Materials process also sings to the tune of a Make-To-Stock strategy. A particular ad-hoc Purchase Requisition is combined with planned purchases of materials to satisfy urgent production requirements^iv.

The Despatch Courier Shipments process in turn is not really invoked by Shipment Ready message. Instead, it is performed daily at a fixed hour for many order shipments, i.e. many instances of Fulfill Retailer Order process. In other words, the courier truck arrives every day once, to collect many order shipments. Finally, while the Register Payments process is initiated by arrival of a daily Account Statement, it is performed for all payments received on a particular day. The Fulfill Retailer Order process has to wait days, probably weeks, until the payment for a particular order arrives and is correlated with the proper order and corresponding invoice.

So where do those five components of OTC - Retailer Order process come from? Actually, within BPMN they come from nowhere, as modeling of hierarchical breakdown of activities is not inside specification’s scope. Moreover, those processes are not derived from decomposition of the OTC – Retailer Order process at all. Instead, they are assembled from processes and activities which should be defined elsewhere. I will deal with this topic extensively few future installments away.

Epilogue. When modeling the OTC Retailer Order process, I sailed into uncharted waters, so I invented few tricks to go ahead. Please note the layout of processes, similar to Gantt chart, which hopefully conveys their logical sequence and timing. To indicate optional, i.e. conditional processes, I used annotations encouraged by BPMN standard. Some conclusions on logical sequence and timing of message flows can be also drawn from their alignment and location. Finally, please note some of the message flow arrows are not accompanied by the envelope symbols. I used this convention to indicate flows which do not transport real data content, but inform about status change of something. For example, Goods Produced message flow from Produce Goods to Fulfill Retailer Order process indicates simply that the instance of the latter for a particular order can resume its processing. This can be implemented in several ways, but for a non-executable process modeling such indication is sufficient^v.

I guess it is quite a lot for this installment, I will continue soon, so please stay tuned.
 

See also my other posts:

• Fire and Ice. Part 1. BPMN 2.0 Today
• Fire and Ice. Part 2. BPMN Conversations
• Fire and Ice. Part 4. BPMN Process Models

References

• i - Conversations nodes were renamed, the new diagram version indicates also Carriers are involved only in Retailer Order conversations. As I learned in the meantime, ACME uses its own trucks to transport products to wholesale Customers.
• ii - Pools can communicate also by means of signals. However, this form of inter-pool communication is discouraged on business-oriented diagrams, as it makes such communication implicit.
• iii - See Bruce Silver, BPMN Method and Style: A Levels-based Methodology for BPM Process Modeling and Improvement Using BPMN 2.0, Cody-Cassidy Press, 2009, p. 173. See also Thomas Allweyer, BPMN 2.0: Introduction to the Standard for Business Process Modeling, Books on Demand GmbH, 2010, pp. 55-56.
• iv - One could combine the Fulfill Retailer Order, Produce Goods and Purchase Materials processes in one pool only if all activities were truly performed for one order, i.e. within one process instance. That in turn would be maybe possible only in case of pure Make-To-Order strategy.
• v - For example, in an automated process, order status can be updated via a batch run or in real time during payment registration operations. A message can be also sent and received using a publish/subscribe mechanism.