Processes in BPMN 2.

0
Process Management Whitepaper

Dipl.-Ing. Walter Abel

Managing Director
Dipl.-Ing. Walter Abel Management Consulting

Karl Czerny - Gasse 2/2/32

A - 1200 Vienna
Phone: (+43 1) 92912 65
Fax.: (+43 1) 92912 66
office@walter-abel.at
www.walter-abel.at
www.itsmprocesses.com

 Dipl.-Ing. Walter Abel Management Consulting

1.1
Processes in BPMN 2.0

Content

Content................................................................................................................................................... 2
1. Introduction .................................................................................................................................... 3
2. Processes ...................................................................................................................................... 4
2.1 Basics of Process Architecture ................................................................................................... 4
2.2 Basics of Process Modelling ....................................................................................................... 4
2.3 Process Components ................................................................................................................. 5
2.4 Modelling Guidelines .................................................................................................................. 7
2.5 Executable Processes ................................................................................................................ 9
2.6 Private Processes .....................................................................................................................10
2.7 Public Processes.......................................................................................................................10
2.8 Selection of Process Type .........................................................................................................11
3. Collaborations ...............................................................................................................................12
3.1 Black Box - Pools .........................................................................................................................13
4. Choreographies .............................................................................................................................15
4.1 Usage of Choreographies and Collaborations ...............................................................................16
5. Conversations ...............................................................................................................................17
6. Summary.......................................................................................................................................18
7. Sources.........................................................................................................................................19

 Dipl.-Ing. Walter Abel Management Consulting Page 2 of 19

1.1
Processes in BPMN 2.0

1. Introduction

Since the beginning of 2011 BPMN (Business Process Model and Notation) 2.0 is released by the Object
Management Group (OGC). The most obvious novelty from the modeller’ s perspective is the enhanced
set of possibilities to represent the interaction of different enterprises by comprehensive processes.

Even the previous releases of BPMN differentiated from other process modelling notations by the
possibility to model the information exchange between independent partners besides the description of
the sequence flow. The constructs for modelling of comprehensive processes over the borders of the
partner organizations have been remarkably enhanced within BPMN 2.0. Two new diagram types have
been introduced: choreography and conversion.

It is rather complex to get an overview of this variety of new ways to model comprehensive processes. In
practice all these possibilities rarely will be used all together. To select the appropriate diagram types and
modelling constructs a deeper understanding of their correlation is necessary.

The specification of BPMN 2.0 contains besides others the following definitions:

• Process
• Orchestration
• Private Process
• Executable Process
• Public Process
• Collaboration
• Choreography
• Conversation
• Communication

For the modelling of these concepts four diagram types are defined:

1. Process Diagram
2. Collaboration Diagram
3. Choreography Diagram
4. Conversation Diagram

 Dipl.-Ing. Walter Abel Management Consulting Page 3 of 19

1.1
Processes in BPMN 2.0

2. Processes
Within BPMN a process is defined as a sequence of activities (tasks) within an organization. In case
processes are automated by the usage of web services the term “orchestration”is used. Orchestration
describes the triggering sequence of these web services when a process is executed. The BPMN
specification uses the terms “process”and “orchestration”more or less synonymously.

BPMN 2.0 focuses on a detail level of process modelling that allows the direct execution of a process by
a process engine of a workflow system or a business process management system. For the necessary
tasks a lot of setailed constructs and attributes is available. Furthermore the exact meaning of modelable
facts for execution was defined, the execution semantics.

In case a process is modelled in a level of detail and attributes that allows automated execution by a
workflow engine it is called an executable process. In case these details are missing the process is not
executable. Exactly spoken the executability is not a feature of the process but of the process model.
Within the specification we read simplifying about executable respective non executable processes.

2.1 Basics of Process Architecture

For easy reading of company wide process models a hierarchical structure with constant level of detail
per modelling level makes the utmost sense:

2.2 Basics of Process Modelling

For the modelling of processes some basic rules are valid to ensure completeness and readability of the
process pictures:

• Processes are modelled in chronological manner along the timeline.

• They always have a defined trigger and they always produce a defined business relevant output.
• All activities within a process have roles responsible for them located within the organizational
structure and can be mapped with real persons.

 Dipl.-Ing. Walter Abel Management Consulting Page 4 of 19

1.1
Processes in BPMN 2.0

• A completely modelled process describes the way information is accompanying the flow of tasks.
• Variants of the process flow are described by branching of the process via gateways with defined
criteria for the separate branches.

2.3 Process Components

Common understandable process modelling requires standardization of used building blocks and terms of
modelling. The main process components are:

• Process
• Task
• Process Owner
• Role
• Participant
• Gateway
• Event
• Connector

Process

A process is a recurring flow of activities (tasks - see there) with defined trigger and defined output. Each
process has a person in charge of it (process owner - see there) and defined targets.

Task

A task is completed accomplishment within a process, which is not more detailed in the process level
where it is performed.

Process Owner

The process owner is responsible for the correct operation of a defined process. He/she may, but not in
every case, perform tasks within the process. Main issues are that:

• he/she is responsible for the outputs of the process from business perspective
• he/she has the organizational authority to gear into the process in a corrective or constitutive manner
in case the process output does not meet the given targets

Role

A role carries a defined responsibility within the process organization. It has a specified assignment within
the process:

• process owner
• responsible for defined tasks
• additional participant (see there)

Roles can be mapped with the organizational structure and be there either unique (role “sales manager”)
or may exist multiple (role “machine operator”).

 Dipl.-Ing. Walter Abel Management Consulting Page 5 of 19

1.1
Processes in BPMN 2.0

They are held by physical persons. Physical persons may carry one or more roles. Within a correct
organizational documentation the mapping of roles and physical persons are described within the job
descriptions:

• jobs contain at least one role (link to the process organization)

• jobs are located within the hierarchy of the enterprise organization (link to the organizational
structure)
• jobs are taken by physical persons

Thus the connection between organizational structure and process organization is documented precisely.

Participant

A (additional) participant is normally connected to separate tasks. Possible duties are:

• processing a task (contribution to)

• approval of the result of a task
• information provision (the participant is consulted during execution of the task)
• information receiving (the participant is informed about the execution of the task respective the
result of the task)

Gateway

A gateway serves for branching a process into either separate (alternative) flows or parallel
(simultaneous) flows according to defined criteria and rules. Important is the precise definition of the
branching criteria.

Event

An event (occurrence of a defined state) may:

• trigger a process (starting event)

• mark the result of a process (end event)
• interrupt a process (catching intermediate event)
• mark a defined state of the process (throwing intermediate event)

Connector

A connector describes the logic of the process flow. The main connectors are:

• sequence flow (describes the sequential arrangement of the tasks)

• information flow (describes the transport of information between activities, events and
organizational units or roles)
• control flow (describes the controlling logic of the process, hence it is important for the execution
by workflow engines)

 Dipl.-Ing. Walter Abel Management Consulting Page 6 of 19

1.1
Processes in BPMN 2.0

2.4 Modelling Guidelines

Each notation contains a huge amount of symbols to define the elements and the logic of a process. The
same is with BPMN. A company specific standardization is mission critical and the wise restriction within
the great variety of descriptional possibilities for process models as well.

Important Symbole der BPMN 2.0 in Prozessmodellen

Symbol Process Element Function

Start Event Trigger for a process

Start Message Event Message as trigger for a process

Start Timer Event Point in time as trigger for a process

Start Conditional Event Changed conditions as trigger for a process

Start Signal Event Signal over process borders as trigger for a process

Catching Intermediate
Process waits for a message
Message Event
Catching Intermediate Timer
Process waits for a defined time to continue
Event
Catching Intermediate
Process waits for changed conditions to continue
Conditional Event
Throwing Intermediate
Process sends a message and continues afterwards
Message Event
Throwing Intermediate Signal
Process places a signal and continues afterwards
Event

End Event End of the process

End Message Event Process ends with a message

End Signal Event Process ends with a signal

End Terminate Event Process stops all open (partial) activities

• at branching the process follows a defined
condition
Data Based Exclusive
Gateway • at junction each branch triggers the
continuation of the process

• at branching all partial flows of the process

are triggered
Parallel Gateway • at junction the process waits for all incoming
partial flows

 Dipl.-Ing. Walter Abel Management Consulting Page 7 of 19

1.1
Processes in BPMN 2.0

• at branching one or more brancjhing flows are

triggered according to defined conditions
Inclusive Gateway • at junction the process waits for all incoming
partial flows

One or more branching flows are triggered based on a

verbal description (only to be used when branching
Complex Gateway
with high complexity if not to be described by using
other gateway types)

Task Activity based upon an organizational responsibility

Parallel Multiple Task Activity is performed more than once in parallel

Activity is performed more than once one instance

Sequential Multiple Task
after the other

Subprocess Embedded independent and solitary flow of taks

External and internal organizational units respective

Organizational Unit,
the main role of a partial process (if no lanes are
Main Role (Pool)
defined)
Leading role of the partial process within an
Role (Lane)
organizational unit

Additional role with defined operation and duty within

Additional Participant
the process
Concatenation of tasks according to the flow logic of
Sequence Flow the process

Concatenation of tasks by information transport

Message Flow

 Dipl.-Ing. Walter Abel Management Consulting Page 8 of 19

1.1
Processes in BPMN 2.0

2.5 Executable Processes

An example of a simple executable process in a process diagram is shown in Picture 1. This picture
correlates with the BPMN versions 1.1, 1.2 and 2.0 as well.The basic objects for the modelling of a
process have not changed with the new version, but some new ones have been added (but they are not
used in this example).

Picture 1: Process for creation of a centralized buying - shown is the executable process which is the view onto the workflow of the
centralized buying process

Trigger of the process is a demand documented by the provision of a purchase requisition. This is handed
over to the business manager for approval via email (End Message Event). After approval, triggered by
the incoming purchase requisition (Start Message Event), a transmission to the purchasing agent is
performed (End Message Event). With the storage of the purchase requisitions, triggered by the incoming
purchase requisition (Start Message Event) the process finishes in a defined status (End Event “approved
purchase requisition stored”).

With the first working day of the month (Start Time Event) now the purchase requisitions are bundled and
the check of delivery capability with the possible suppliers is performed. This is a multi instance activity
performed for each item of a list (depicted by three parallel lines in the task symbol). In our case the
enterprise works with a lot of suppliers. Each of them now is asked for delivery capability. Hence the
activity is performed as often as suppliers are available. The inquiries are processed in parallel. As soon
as all suppliers are asked the selected supplier is given from the incoming answers. Thus in our example
there is no separation between a parallel activity for inquiry and a second activity for final selection.

The further flow follows the above picture.

 Dipl.-Ing. Walter Abel Management Consulting Page 9 of 19

1.1
Processes in BPMN 2.0

2.6 Private Processes

This reduced view to the processes often is the basis for a process documentation following a process
analysis. The graph only shows the internal logic of the task flow and the triggering, continuative and
ending events.

Picture 2: Process for the creation of a centralized buying - shown is the private process, which means the internal view of the enterprise to
the centralized buying

Trigger of the process is a demand documented by the creation of a purchase requisition. This is handed
over for approval by email (Catching Intermediate Message Event, which means that the following steps
are triggered immediately by the incoming purchase requisition). After der approval a second hand over
for storing of the purchase requisitions is performed (again a Catching Intermediate Message Event as
after intake of the purchase requisition immediately the storing is done). At the first working day (Start
Timer Event) the bundling and the check for delivery capability with the possible suppliers is performed.
This is again a multi instance activity performed for each item of a list (depicted by three parallel lines in
the task symbol). In our case the enterprise works with a lot of suppliers. Each of them now is asked for
delivery capability. Hence the activity is performed as often as suppliers are available. The inquiries are
processed in parallel. As soon as all suppliers are asked the selected supplier is given from the incoming
answers. Thus in our example there is no separation between a parallel activity for inquiry and a second
activity for final selection.

The process in Picture 2 shows the internal view of the enterprise at its own process. In BPMN such a
representation of a process with all the internals is called a “private process”. In contrast to this the “public
process”shows only the activities and events needed for the message exchange with partners. Parts of
the process not relevant for the partners are skipped in that case.

2.7 Public Processes

The public process shows the simplified external view to the process. Thus it needs to contain only the
events and activities relevant for the information flow between the partners. Activities without information
flow are skipped. In this example of a public process the purely internal activities like “Create Purchase
Requisition”, “Approve Purchase Requisition” and “Forward approved Purchase Requisition” can be
skipped. By that the gateway of approval decision is no more needed. With events it is to decide whether
the partner needs them for understanding of the process respective the control of interaction.

 Dipl.-Ing. Walter Abel Management Consulting Page 10 of 19

1.1
Processes in BPMN 2.0

Picture 3 demonstrates the process diagram documenting the public process for the processing of
centralized buying:

Picture 3: Process for the creation of a centralized buying - shown is the public process, which means the external view of the partners to the
centralized buying

2.8 Selection of Process Type

From the former explanation follows, that the purpose of the process picture is the most important
selection criterion for the type of process representation:

• Executable processes are used for the clarification of control and information flows (either in case of
detailed organizational documentations or for preparation of workflow automation)
• Private processes are used for the internal management view to the logic of the processes
• Public processes are used to clarify the logic of interaction with external partners

 Dipl.-Ing. Walter Abel Management Consulting Page 11 of 19

1.1
Processes in BPMN 2.0

3. Collaborations

Collaborations also have been part of previous versions of BPMN. A collaboration illustrates the
interaction between different partners via information exchange. Thus a collaboration diagram contains
participants shown as pools and information flows between these pools. In this case each partner
representing pool holds the process the partner performs during the interaction.

In our process of centralized buying the enterprise interacts with several suppliers. Within this interaction
each partner performs his process. Information is sent to and received from the partner. The
corresponding collaboration is shown in Picture 4:

Picture 4: Process for the creation of a centralized buying - shown is the collaboration of partial processes

The pool “Supplier”is characterized as multi instance participant by the three parallel lines at the bottom.
This means that the information exchange is not only done with one supplier but with several of them.
Each supplier is perfoming the modelled process and the enterprise exchanges information with each of
them as shown. Multi instance participants are new with BPMN 2.0.

The processes contained in the pools above are the same as in Picture 1. To improve clarity the symbols
of the information events are skipped. Their meaning can be read from the depicted information flows.

The complete collaboration starts with the requestor whose process starts with an undefined start event
(“Demand”). This event has no cause within the process. It ocurres in case the requestor invokes the
process. In contrary the processes of the other partners are starting with information flow receiving start
events. Such an event ocurres when the respective message arrives to the partner.

 Dipl.-Ing. Walter Abel Management Consulting Page 12 of 19

1.1
Processes in BPMN 2.0

Within BPMN information flows may be sent from tasks but also from events. Just as well tasks and
events may be targets of information flows. In BPMN both is possible. An information flow receiving event
defined that the process waits for the information. Sending a message requires active action by the
participant, thus it is more or less connected with a task and only seldom with an event. Only the going
out of a message without any activity may be modelled via a information sending event. This was used in
the process of centralized buying, for instance the sending of the “List of Requirements per email”
because the usage of a separate Task “Send Request for Delivery Capability”would have been less
compact.

BPMN provides two special types of tasks (no more detailed activities) for sending messages (type
“send”) and receiving messages (type “receive”). These tasks may be used instead of the respective
information events. At the other hand the information receiving event represents the waiting for the
message very well, hence it is used in the presented model.

3.1 Black Box - Pools

Within a collaboration diagram it is possible to skip the processes in one or more pools and just look to
the information flows between the pools. These pools are represented as “black boxes”. The information
flows start and end at the border of the respective pool. Picture 5 shows a combination where requestor
and supplier are represented by black box pools, at the other hand the business manager and the
purchasing agent are shown as white boxes with the formerly described public processes:

Picture 5: Process for the creation of a centralized buying - shown is the collaboration of partial processes with black boxes

 Dipl.-Ing. Walter Abel Management Consulting Page 13 of 19

1.1
Processes in BPMN 2.0

It is easy to recognize that here the focus is lying on the information exchange between the partial
processes. This can go as far as that a complete black box construct is used and only the information
flows are documented. An example is the distributed process development where the process owners of
the partial processes model their flows within the framework of predefined information flows.

Picture 6: Process for the creation of a centralized buying - shown is the collaboration of partial processes completely with black boxes

 Dipl.-Ing. Walter Abel Management Consulting Page 14 of 19

1.1
Processes in BPMN 2.0

4. Choreographies

The presentation of processes and collaborations was possible in former BPMN versions also. They only
have been extended by some additional constructs in BPMN 2.0. The explicit modelling of
choreographies via related diagrams ic completely new. A choreography is the sequence of message
exchanges between different partners typically in business - to - business scenarios. The difference to the
collaboration is that within a collaboration the sequence of information flows is important while in a
collaboration this sequence is described independent from the processes.

From a black box description like in picture 5 and 6 one can read which messages are exchanged by the
partners, but not the exact sequence or conditional information flows respective loops of the information
flow. So for instance in our example it is not shown that after arrival of the purchase requisition at the
business manager’ s exactly one of two possible messages is sent. Furthermore it is not shown that after
denial of the purchase requisition the complete flow is finished.

To document the logic of the sequence flow there are two possibilities existing. At one hand side it is
feasible to document al least the public process of one of the partners involved in the information
exchange like in picture 5. At the other hand side it is possible to use a choreography diagram:

Picture 7: Process for the creation of a centralized buying - choreography to document the logic of sequence

Each activity within the choreography is triggered by one partner by sending the first message. This
partner is documented in the light stripe (usually at the top) of the activity symbol. The other partners are
documented in the dark stripe (usually at the bottom) of the activity symbol. Whether the light stripe is on
top and the dark stripe is at the bottom of the activity symbol or vice versa is just convention but should
be consistent within a model. In addition if a collaboration is modelled it makes sense to take the vertical
order of the pools as basis for the convention.

Choreography activities with more than one partner are not part of our example. For this purpose it is
possible to define multiple partner fields in the activity symbol. Only one is light as only one partner can
trigger the sequence. The choreography activity “Check Delivery Capability”carries a multiple symbol as
it is executed multiple. As the related partner is also shown as multiple the message exchange is done
with each supplier separately.

A sequence flow is defined for the choreography activities within choreography diagrams. Its modelling
follows the same rules like for the sequence flow within normal processes but some elements of process
modelling do not make sense in choreography modelling. Hence they are not allowed. As an example
there are no message events in the normal sequence flow as message exchange is part of the
choreography activities per definition. Thus an event based gateway is followed by a choreography
activity and not by an event. In this case the path is selected which choreography activity is started by the
triggering message at first.

 Dipl.-Ing. Walter Abel Management Consulting Page 15 of 19

1.1
Processes in BPMN 2.0

If one wnts to know what messages are exchanged in the choreography activities they can be
represented by the letter symbols and connected with the respective partner field:

Picture 8: Process for the creation of a centralized buying - choreography to document the logic of sequence including messages

4.1 Usage of Choreographies and Collaborations

As presented above it is possible to document the content of choreographies by usage og collaborations

also. There are some reasons to use choreographies despite:

• Choreographies document the information exchange independent from the partner processes. Hence
they are a better basis for agreements and contracts between partners. The required process
interfaces are to be defined in an easy way. Thus they are the basis for creation and adaption of the
processes for the partners to correctly fulfil the agreed interaction.
• The sequence of the information exchange including branching is more obvious. Within a
collaboration this information has to be retrieved from the involved partner processes.
• Especially in complex environments the choreography is much clearer as a collaboration with at least
one public process (compare e.g. picture 7 to picture 4).
• Choreographies can be documented by the usage of choreography subprocesses supporting a more
compact documentation of complex flows.

Especially within complex business - to - business scenarios choreography diagrams are useful e.g. in
the context of electronic marketplaces or with the development of industry specific standards and rules for
defined transactions between partners. If an enterprise documents its internal processes and wants to
describe the message exchange with its partners a collaboration diagram is used.

 Dipl.-Ing. Walter Abel Management Consulting Page 16 of 19

1.1
Processes in BPMN 2.0

5. Conversations

Also the conversation diagram is new in BPMN 2.0. Simply spoken the conversation describes which
message exchanges belong to gether.

A problem with the exchange of messages is to assign the incoming message to the right process
instance. In our example of centralized buying if the supplier receives an inquiry for delivery capability this
has to know to which instance of the centralized buying process it refers.

In most cases the supplier will have created more than one statement of delivery capability for different
centralized buying orders. Normally within the order there is a reference to the inquiry so that it can be
allocated to the correct purchasing case.

In electronically supported processes it is important to define exactly how the information systems of the
involved partners allocate the incoming messages to the correct process instance. This is known as
correlation of messages belonging together. These messages belonging together need to carry a
correlation key. Messages combined within the communication carry the same correlation key.

Within the presented information the smallest amount of messages belonging together are called
“communication”. A conversation consists of multiple communications:

Picture 9: Process for the creation of a centralized buying - conversation for the presentation of message exchanges

Besides communications also information flows are possible in conversation diagrams, processes and
choreographies are not allowed.

Conversations may be hierarchical. For instance the “+”symbol in the hexagon “Order”within picture 9
represents a sub conversation to be described by a separate conversation diagram (not shown here).

As communications combine information flows a relation is existing between communications and

information flows. This is not evident immediately within a BPMN diagram. It is task of the modeller to
make this relation apparent in graphical representation. For instance it is possible to mark the information
flows belonging to separate communications by means of grouping within collaboration and choreograpy
diagrams.

The exact definition of correlations and thus the modelling of conversations normally is not the focus of
most of the BPMN modellers. In case of SOA platforms and process engines in the framework of cross
company processes with complex partner interaction the documentation of conversations provides an
useful overview about the total scenario.

Even in cases where detailed documented correlation mechanisms are not the primary focus a
conversation diagram provides a first overview of the overall context of the partner network. The
communication of the partners related to defined cases is clearly represented. The following details can
be modelled in choreography and collaboration diagrams.

 Dipl.-Ing. Walter Abel Management Consulting Page 17 of 19

1.1
Processes in BPMN 2.0

6. Summary

The possibilities of modelling of cross partner processes have been especially enhanced in BPMN 2.0 by
the introduction of the choreography and conversation diagram. At one hand this is an enrichment, at the
other hand it makes BPMN even more voluminous and complex. Additionally one situation can be
modelled in different ways. Collaborations, choreographies and conversations are different views of the
same topic - the exchange of messages between partners. It is not so easy to have an overview about
the relation of these representations. Some criticism by the modellers is focused on that asking for a
simple and clear notation.

For the practical use this means that the fitting diagram type has to be selected for the respective
modelling purpose. Besides this it is necessary to define which circumstances should be modelled how
within the diagrams. For instance, if an enterprise wants to document and maintain their internal
processes it makes sense to use normal process diagrams.

For processes with dominant partner interaction collaboration diagrams are useful, representing the
partners by black boxes.

Two or more enterprises which want to build up a business - to - business integration should use
choreography diagrams to specify the interaction to be supported by all partners. In case the partners
afterwards develop their own processes to support this choreography they may embed this choreography
into a collaboration diagram to ensure that their own processes support the agreed choreography
correctly.

 Dipl.-Ing. Walter Abel Management Consulting Page 18 of 19

1.1
Processes in BPMN 2.0

7. Sources

Parts of this whitepapers are taken from the document:

Kollaborationen, Choreographien und Konversationen in BPMN 2.0 - Erweiterte Konzepte zur

Modellierung übergreifender Geschäftsprozesse

by

Prof. Dr. Thomas Allweyer

Fachhochschule Kaiserslautern - University of Applied Sciences
Fachbereich Informatik und Mikrosystemtechnik
Amerikastraße 1
D - 66482 Zweibrücken

with friendly permission of the author.

Karl Czerny - Gasse 2/2/32

A - 1200 Vienna
Phone: +43 (1) 92912 65
Fax: +43 (1) 92912 66
office@walter-abel.at
www.walter-abel.at
www.itsmprocesses.com

 Dipl.-Ing. Walter Abel Management Consulting Page 19 of 19

1.1