Conversation vs. Collaboration vs. Choreography
Blog: Good e-Learning Blog
This short article will present the last three types of BPMN diagrams (collaboration diagrams, choreography diagrams and conversation diagrams) and the possibilities for their common use
BPMN diagrams are commonly treated as synonyms for process diagrams. However, this is just partially true, since BPMN 2.0 supports three other types of diagrams: collaboration diagrams, choreography diagrams and conversation diagrams. This short article will present the last three types of BPMN diagrams and the possibilities for their common use.
Collaboration diagrams represent interactions between two or more processes, where each individual process represents a person, role or a system. A collaboration diagram is quite commonly used and is easily recognized because it consists of more than one Pool. A Pool may be empty, a black box, or may show a process within.
The following diagrams represent a Help-desk diagram, which consist of three participants (i.e. Pools).
The above diagram consists of a white-box pool (i.e. help-desk center) with defined help-desk center process and two black-box processes (i.e. customer and expert). Most common BPMN elements in a collaboration diagram are process flow elements (i.e. activities, gateways, events), and message flows which are used to exchange data and coordinate work between collaborating participants.
All combinations of Pools, Processes, and a Choreography are allowed in a Collaboration.
Conversation diagrams have been introduced in BPMN 2.0 and represents a particular usage of and an informal description of a Collaboration diagram. In general, a conversation diagram is a simplified version of a Collaboration diagram. A conversation diagram provides an overview of which partners of a certain domain co-operate on which tasks.
The conversation diagram ‘view’ of a collaboration diagram includes two additional graphical elements that do not exist in other BPMN views: Conversation Node elements (hexagon) and a Conversation Link (double line).
The following conversation diagram presents “main players” in a help-desk environment and their common conversations (e.g. tasks, topics).
On a more detailed level, conversation diagrams can be modeled in a choreography diagram or a collaboration diagram.
As an example, the message flow of the conversation “Problem solving” is described by the collaboration diagram in figure 1 as a series of two message flows between customer and help-desk center. However, it is not required for a collaboration or choreography diagram to specify exactly one conversation.
It is also possible to combine the message flows from two or more conversations in one diagram. Collaboration and conversation diagrams can also be combined on a single diagram as presented below.
Choreography diagrams are new in BPMN 2.0 and focus on between-processes interactions and message flows. Another way to look at Choreography is to view it as a type of business ‘contract’ between two or more organizations.
Choreography is a type of process, but differs in purpose and behavior from a standard BPMN Process. A standard (orchestration) process defines the flow of activities of a specific participant or organization. In contrast, choreography formalizes the way participants coordinate their interactions. Thus the focus is not on orchestrations of the work performed within these participants, but rather on the exchange of information (messages) between these participants.
A choreography diagram can be used to analyze how participants exchange information to coordinate their interactions. The next figure represents help-desk process, modeled as a choreography.
A key to understanding Choreography and how they are used in BPMN is their relationship to Pools. Choreography exist outside of or in between Pools. A Process, within a Pool, represents the work of a specific Entity or Role. A Choreography, on the other hand, is a different kind of a process.
A Choreography defines the sequence of interactions between Participants. Thus, a Choreography does not exist in a single Pool—it is not the purview of a single Participant. Each step in the Choreography involves two or more Participants. These steps are called Choreography Activities.
Choreography can be included in a Collaboration diagram. A Collaboration specifies how the Participants and Message Flows in the Choreography are matched up with the Participants and Message Flows in the Collaboration.
This article presented three types of diagrams (i.e. models) which are, beside process diagrams, supported in BPMN 2.0 – collaboration diagrams, conversation diagrams and choreography diagrams. Most commonly used are collaboration diagrams, which represent message-based interactions between different participants (i.e. BPMN Pools).
Thus, a collaboration diagram always consist of several Pools (processes). A specific, top-level, view of a collaboration diagram is conversation diagram, which consists of process participants (pools) and common conversations between them (defined as conversation nodes). Most commonly, conversation diagram pools are black-box. A conversation diagram is easily recognized, since it includes two specific elements: conversations (hexagons) and conversation links (double lines).
A conversation diagram can be combined with collaboration diagrams in a common diagram. Choreography diagrams also represent a specific view of a collaboration, focused on between-process activities. Since Choreography represents between-process interactions they ‘exist’ outside pools, where the choreography diagrams are populated with specific choreography tasks. Choreography can also be included in a Collaboration diagram, meaning that all three types of presented diagrams can be used in a common diagram.