BPMN diagrams are commonly treated as synonymous with process diagrams. However, this is only 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 describe the possibilities for their common use.
Collaboration diagrams represent interactions between two or more processes, where each individual process represents a person, role, or 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 consists of three participants (i.e., Pools).
The above diagram consists of a white-box pool (i.e., help-desk center) with a defined help-desk center process and two black-box processes (i.e., customer and expert). The 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 choreography are allowed in a collaboration.
Conversation diagrams were introduced in BPMN 2.0 and represent 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 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 were introduced 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 the help-desk process, modeled as a choreography.
A key to understanding choreography diagrams and how they are used in BPMN is their relationship to pools. Choreography diagrams exist outside of, or in between, pools. A process, within a pool, represents the work of a specific entity or role. A choreography process, on the other hand, is a different kind of process.
A choreography process defines the sequence of interactions between participants. Thus, a choreography process does not exist in a single pool, and it is not the purview of a single participant. Each step in the choreography process 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 a choreography process are matched up with the participants, and message flows in the collaboration.
This article presented three types of diagrams (i.e., models) which are, besides process diagrams, supported in BPMN 2.0: collaboration diagrams, conversation diagrams, and choreography diagrams. The most commonly used are collaboration diagrams, which represent message-based interactions between different participants (i.e., BPMN pools).
Thus, a collaboration diagram always consists of several pools (processes). A specific, top-level view of a collaboration diagram is a 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 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.