BPMN Vs

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

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).BPMN Collaboration

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

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).

Free BPMN Downloads!

The following conversation diagram presents “main players” in a help-desk environment and their common conversations (e.g. tasks, topics).BPMN Collaboration

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.BPMN Collaboration

Choreography diagram

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.BPMN Collaboration

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.

Conclusion

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.

Free BPMN Resources

SHARE
Gregor received his PhD in 2008 in the fields of software engineering and information systems and has nearly a decade of experience in BPMN, starting to investigate and actively use BPMN since its introduction in 2004. In addition, he has participated in the development of one of the first BPMN modeling utilities - a package of plugins for Visio, which were introduced early in 2005 and is the main author of the first BPMN poster (bpmn.itposter.net), which has been translated into several languages and already exceeded 50.000 downloads.
  • Putcha V. Narasimham

    Good explanation. I have discovered the need for “Conversation” or “Dialog” while studying UML UseCase modeling. The exact nature of “UseCase” is NOT defined in UML and many professionals mistake it to be a sub-system or part or a process etc. Now it should be simple and easy for UML to recognize UseCase to be a Dialog or Conversation.

    In the definition of “conversation” it is stated to be what is exchanged between two or more participants but any specific conversation can only occur between two and only two participants. There is one more constraint that only one participant can send messages at any time and the other must be in “receive mode”. putchavn@yahoo.com

  • Putcha V. Narasimham

    Gregor:

    I am revisiting to know the precise definitions of Collaborations, Choreography and Conversation and their relation to Processes. I am unable to find them in this article. I will check with the BPMN Specification.

    I see “conversation or dialog” as a sequence of messages between two and only two entities each executing different but related sets of Activities or Process Steps or Tasks within their control without external dependencies. If any of the two entities have external dependencies, then the conversation has to end or pause. The conversation may resume but that would be a different conversation with respect to the paused conversation. I have observed that a messages from one entity goes to another entity which creates a new and specific task for the message received. A predefined task has to be freshly executed on the message received otherwise the conversation breaks. Every task may examine the incoming message and declare that the message was already responded to to avoid unnecessary repetition without knowing it is repetition.

    I look forward to your response

    23 OCT 17

  • Putcha V. Narasimham

    Gregor:

    I am revisiting to know the precise definitions of Collaborations, Choreography and Conversation and their relation to Processes. I am unable to find them in this article. I will check with the BPMN Specification.

    I see “conversation or dialog” as a sequence of messages between two and only two entities each executing different but related sets of Activities or Process Steps or Tasks within their control without external dependencies. If any of the two entities have external dependencies, then the conversation has to end or pause. The conversation may resume but that would be a different conversation with respect to the paused conversation. I have observed that a messages from one entity goes to another entity which creates a new and specific task for the message received. A predefined task has to be freshly executed on the message received otherwise the conversation breaks. Every task may examine the incoming message and declare that the message was already responded to to avoid unnecessary repetition without knowing it is repetition.

    I look forward to your response

    23 OCT 17

  • Putcha V. Narasimham

    Gregor:

    I am revisiting to know the precise definitions of Collaborations, Choreography and Conversation and their relation to Processes. I am unable to find them in this article. I will check with the BPMN Specification.

    I see “conversation or dialog” as a sequence of messages between two and only two entities each executing different but related sets of Activities or Process Steps or Tasks within their control without external dependencies. If any of the two entities have external dependencies, then the conversation has to end or pause. The conversation may resume but that would be a different conversation with respect to the paused conversation. I have observed that a messages from one entity goes to another entity which creates a new and specific task for the message received. A predefined task has to be freshly executed on the message received otherwise the conversation breaks. Every task may examine the incoming message and declare that the message was already responded to to avoid unnecessary repetition without knowing it is repetition.

    I look forward to your response

    23 OCT 17