Processes in BPMN 2 Processes in... · Processes in BPMN 2.0 Dipl.-Ing. Walter Abel Management...

Karl Czerny - Gasse 2/2/32A - 1200 Vienna

Phone: (+43 1) 92912 65Fax.: (+43 1) 92912 66

Email: [email protected]: www.walter-abel.at

Dipl.-Ing. Walter Abel Management Consulting1.1

Processes in BPMN 2.0

Process Management Whitepaper

by Dipl.-Ing. Walter Abel

Managing DirectorDipl.-Ing. Walter Abel Management Consulting

mailto:[email protected]

http://www.walter-abel.at


Dipl.-Ing. Walter Abel Management Consulting of 191.1

Content

Content................................................................................................................................................... 21. Introduction .................................................................................................................................... 32. Processes ...................................................................................................................................... 4

2.1 Basics of Process Architecture ................................................................................................... 42.2 Basics of Process Modelling....................................................................................................... 42.3 Process Components ................................................................................................................. 52.4 Modelling Guidelines .................................................................................................................. 72.5 Executable Processes ................................................................................................................ 92.6 Private Processes .....................................................................................................................102.7 Public Processes.......................................................................................................................102.8 Selection of Process Type .........................................................................................................11

3. Collaborations ...............................................................................................................................123.1 Black Box - Pools .........................................................................................................................13

4. Choreographies.............................................................................................................................154.1 Usage of Choreographies and Collaborations ...............................................................................16

5. Conversations ...............................................................................................................................176. Summary.......................................................................................................................................187. Sources.........................................................................................................................................19



1. Introduction

Since the beginning of 2011 BPMN (Business Process Model and Notation) 2.0 is released by the ObjectManagement Group (OGC). The most obvious novelty from the modeller’s perspective is the enhancedset 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 thepossibility to model the information exchange between independent partners besides the description ofthe sequence flow. The constructs for modelling of comprehensive processes over the borders of thepartner organizations have been remarkably enhanced within BPMN 2.0. Two new diagram types havebeen introduced: choreography and conversion.

It is rather complex to get an overview of this variety of new ways to model comprehensive processes. Inpractice all these possibilities rarely will be used all together. To select the appropriate diagram types andmodelling 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 Diagram2. Collaboration Diagram3. Choreography Diagram4. Conversation Diagram



2. Processes

Within BPMN a process is defined as a sequence of activities (tasks) within an organization. In caseprocesses are automated by the usage of web services the term “orchestration” is used. Orchestrationdescribes the triggering sequence of these web services when a process is executed. The BPMNspecification 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 bya process engine of a workflow system or a business process management system. For the necessarytasks a lot of setailed constructs and attributes is available. Furthermore the exact meaning of modelablefacts 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 aworkflow engine it is called an executable process. In case these details are missing the process is notexecutable. 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 detailper 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 theprocess 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.



• 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 ofmodelling. 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. Eachprocess 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 levelwhere it is performed.

Process Owner

The process owner is responsible for the correct operation of a defined process. He/she may, but not inevery 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 withinthe 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”).



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

• 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 thebranching 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)



2.4 Modelling Guidelines

Each notation contains a huge amount of symbols to define the elements and the logic of a process. Thesame is with BPMN. A company specific standardization is mission critical and the wise restriction withinthe 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 IntermediateMessage Event Process waits for a message

Catching Intermediate TimerEvent Process waits for a defined time to continue

Catching IntermediateConditional Event Process waits for changed conditions to continue

Throwing IntermediateMessage Event Process sends a message and continues afterwards

Throwing Intermediate SignalEvent Process places a signal and continues afterwards

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

Data Based ExclusiveGateway

• at branching the process follows a definedcondition

• at junction each branch triggers thecontinuation of the process

Parallel Gateway

• at branching all partial flows of the processare triggered

• at junction the process waits for all incomingpartial flows



Inclusive Gateway

• at branching one or more brancjhing flows aretriggered according to defined conditions

• at junction the process waits for all incomingpartial flows

Complex Gateway

One or more branching flows are triggered based on averbal description (only to be used when branchingwith high complexity if not to be described by usingother gateway types)

Task Activity based upon an organizational responsibility

Parallel Multiple Task Activity is performed more than once in parallel

Sequential Multiple Task Activity is performed more than once one instanceafter the other

Subprocess Embedded independent and solitary flow of taks

Organizational Unit,Main Role (Pool)

External and internal organizational units respectivethe main role of a partial process (if no lanes aredefined)

Role (Lane) Leading role of the partial process within anorganizational unit

Additional Participant Additional role with defined operation and duty withinthe process

Sequence FlowConcatenation of tasks according to the flow logic ofthe process

Message Flow Concatenation of tasks by information transport



2.5 Executable Processes

An example of a simple executable process in a process diagram is shown in Picture 1. This picturecorrelates with the BPMN versions 1.1, 1.2 and 2.0 as well.The basic objects for the modelling of aprocess have not changed with the new version, but some new ones have been added (but they are notused 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 thecentralized buying process

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

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

The further flow follows the above picture.



2.6 Private Processes

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

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

Trigger of the process is a demand documented by the creation of a purchase requisition. This is handedover for approval by email (Catching Intermediate Message Event, which means that the following stepsare triggered immediately by the incoming purchase requisition). After der approval a second hand overfor storing of the purchase requisitions is performed (again a Catching Intermediate Message Event asafter intake of the purchase requisition immediately the storing is done). At the first working day (StartTimer 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 inthe task symbol). In our case the enterprise works with a lot of suppliers. Each of them now is asked fordelivery capability. Hence the activity is performed as often as suppliers are available. The inquiries areprocessed in parallel. As soon as all suppliers are asked the selected supplier is given from the incominganswers. Thus in our example there is no separation between a parallel activity for inquiry and a secondactivity for final selection.

The process in Picture 2 shows the internal view of the enterprise at its own process. In BPMN such arepresentation of a process with all the internals is called a “private process”. In contrast to this the “publicprocess” shows only the activities and events needed for the message exchange with partners. Parts ofthe 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 theevents and activities relevant for the information flow between the partners. Activities without informationflow are skipped. In this example of a public process the purely internal activities like “Create PurchaseRequisition”, “Approve Purchase Requisition” and “Forward approved Purchase Requisition” can beskipped. By that the gateway of approval decision is no more needed. With events it is to decide whetherthe partner needs them for understanding of the process respective the control of interaction.



Picture 3 demonstrates the process diagram documenting the public process for the processing ofcentralized 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 thecentralized buying

2.8 Selection of Process Type

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

• Executable processes are used for the clarification of control and information flows (either in case ofdetailed 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



3. Collaborations

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

In our process of centralized buying the enterprise interacts with several suppliers. Within this interactioneach partner performs his process. Information is sent to and received from the partner. Thecorresponding 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 ofthem 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 symbolsof 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 theprocess. In contrary the processes of the other partners are starting with information flow receiving startevents. Such an event ocurres when the respective message arrives to the partner.



Within BPMN information flows may be sent from tasks but also from events. Just as well tasks andevents may be targets of information flows. In BPMN both is possible. An information flow receiving eventdefined that the process waits for the information. Sending a message requires active action by theparticipant, thus it is more or less connected with a task and only seldom with an event. Only the goingout of a message without any activity may be modelled via a information sending event. This was used inthe 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 lesscompact.

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 respectiveinformation events. At the other hand the information receiving event represents the waiting for themessage 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 tothe information flows between the pools. These pools are represented as “black boxes”. The informationflows start and end at the border of the respective pool. Picture 5 shows a combination where requestorand supplier are represented by black box pools, at the other hand the business manager and thepurchasing 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



It is easy to recognize that here the focus is lying on the information exchange between the partialprocesses. This can go as far as that a complete black box construct is used and only the informationflows are documented. An example is the distributed process development where the process owners ofthe 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



4. Choreographies

The presentation of processes and collaborations was possible in former BPMN versions also. They onlyhave been extended by some additional constructs in BPMN 2.0. The explicit modelling ofchoreographies via related diagrams ic completely new. A choreography is the sequence of messageexchanges between different partners typically in business - to - business scenarios. The difference to thecollaboration is that within a collaboration the sequence of information flows is important while in acollaboration 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 thepartners, but not the exact sequence or conditional information flows respective loops of the informationflow. So for instance in our example it is not shown that after arrival of the purchase requisition at thebusiness manager’s exactly one of two possible messages is sent. Furthermore it is not shown that afterdenial 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 isfeasible to document al least the public process of one of the partners involved in the informationexchange 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. Thispartner is documented in the light stripe (usually at the top) of the activity symbol. The other partners aredocumented in the dark stripe (usually at the bottom) of the activity symbol. Whether the light stripe is ontop and the dark stripe is at the bottom of the activity symbol or vice versa is just convention but shouldbe consistent within a model. In addition if a collaboration is modelled it makes sense to take the verticalorder 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 ispossible to define multiple partner fields in the activity symbol. Only one is light as only one partner cantrigger the sequence. The choreography activity “Check Delivery Capability” carries a multiple symbol asit is executed multiple. As the related partner is also shown as multiple the message exchange is donewith each supplier separately.

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



If one wnts to know what messages are exchanged in the choreography activities they can berepresented 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 collaborationsalso. There are some reasons to use choreographies despite:

• Choreographies document the information exchange independent from the partner processes. Hencethey are a better basis for agreements and contracts between partners. The required processinterfaces are to be defined in an easy way. Thus they are the basis for creation and adaption of theprocesses for the partners to correctly fulfil the agreed interaction.

• The sequence of the information exchange including branching is more obvious. Within acollaboration 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 leastone public process (compare e.g. picture 7 to picture 4).

• Choreographies can be documented by the usage of choreography subprocesses supporting a morecompact documentation of complex flows.

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



5. Conversations

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

A problem with the exchange of messages is to assign the incoming message to the right processinstance. In our example of centralized buying if the supplier receives an inquiry for delivery capability thishas 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 differentcentralized buying orders. Normally within the order there is a reference to the inquiry so that it can beallocated to the correct purchasing case.

In electronically supported processes it is important to define exactly how the information systems of theinvolved partners allocate the incoming messages to the correct process instance. This is known ascorrelation of messages belonging together. These messages belonging together need to carry acorrelation 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 andchoreographies are not allowed.

Conversations may be hierarchical. For instance the “+” symbol in the hexagon “Order” within picture 9represents 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 andinformation flows. This is not evident immediately within a BPMN diagram. It is task of the modeller tomake this relation apparent in graphical representation. For instance it is possible to mark the informationflows belonging to separate communications by means of grouping within collaboration and choreograpydiagrams.

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

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



6. Summary

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

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

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

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


Karl Czerny - Gasse 2/2/32A - 1200 Vienna

Phone: +43 (1) 92912 65Fax: +43 (1) 92912 66

Email: [email protected]: www.walter-abel.at


7. Sources

Parts of this whitepapers are taken from the document:

Kollaborationen, Choreographien und Konversationen in BPMN 2.0 - Erweiterte Konzepte zurModellierung übergreifender Geschäftsprozesse

by

Prof. Dr. Thomas AllweyerFachhochschule Kaiserslautern - University of Applied SciencesFachbereich Informatik und MikrosystemtechnikAmerikastraße 1D - 66482 Zweibrücken

with friendly permission of the author.

mailto:[email protected]

http://www.walter-abel.at

Processes in BPMN 2 Processes in... · Processes in BPMN 2.0 Dipl.-Ing. Walter Abel Management...

Documents

Transcript of Processes in BPMN 2 Processes in... · Processes in BPMN 2.0 Dipl.-Ing. Walter Abel Management...