Learning BPMN 2 – Which models are available in BPMN?
BPMN is not one specific model type -like an Event-driven Process Chain- but is a collection of multiple model types that are connected to each other. This article will show the available model types in the BPMN 2.0 specification and how these are supported in ARIS (as of ARIS 7.1 SR9).
BPMN model types
The BPMN 2.0 specification contains some changes compared to the 1.x specification (shown in the graphic below):
- the BPMN process diagram was divided into two model types – the BPMN Process and the BPMN Collaboration Diagrams
- the new Choreography Diagram, and
- the new Conversation Diagram.
BPMN Process and Collaboration Diagrams
The split of the former BPMN Process into two model types removed the participants and the message exchange and added these object types to the collaboration diagram. The main result of this is that regular BPMN processes *always* happen within a pool and if you cannot create a subprocess to a process diagram that has pools in it. This is a major clarification and supports consistency in modeling on multiple levels.
BPMN Collaboration Diagrams contain all objects of the Process Diagram and add the message flow between pools (participants). Therefore they are used to show a high(er) level interaction between participants and the change of control flow between the pools (e.g. one participant is waiting until a response from the other participants arrives via a message flow). Typically it is best practice to show only one process in one pool in a collaboration diagram and treat the other pool as black box and assign a corresponding Collaboration Diagram to this pool object.
This also means that you cannot see the participant interaction in Process Diagrams anymore, but will have to use message events to show this.
A new model type in BPMN 2.0 is the Choreography Diagram. Its purpose is to show the interaction between participants in a different format and concentrate on the message flow instead of the individual detailed tasks of a process. Therefore new object types were introduced that include sender and receiver within the object (instead of connecting roles to a task or using swimlanes) and connect the sent/received messages to this object.
It also shows the process logic, by using sequence flows and gateways for routing the control flow, but the main purpose of this model type is to show the interaction between the different process steps and participants.
The second new BPMN 2.0 model type – the BPMN Conversation diagram – takes this concept on an even higher level. It shows the conversations between the participants in a 30,000 foot view and shows them as conversation objects (hexagons) without showing the individual message flow, which can go back and forth within a conversation / in one collaboration diagrams. It does not include process logic.
This setup of model types allows to show different aspects of a process for different audiences:
- the 30,000 foot view as an overview by using a Conversation Diagram for senior management or Enterprise Architects which have to understand the whole interaction,
- on a sublevel either the interaction in a Choreography between process steps for Integration Architects, who are not interested in the minutae of the individual process step implementation, or as a Collaboration Diagram, that uses black box pools for process owners,
- on the lowest level the Process Diagram shows the details of the process of one participant.
Available BPMN model types in ARIS
ARIS as of January 2011 supports four model types. They refer to the Beta version of the specification and are labeled (beta) in the model type name
Useful additional model types
As we saw in Lesson 1, the BPMN standard does not aim to be a “one-size-fits-all” approach to business process management (even though the BPMN hype creators wants to make you believe this), but has a well defined scope.
Unfortunately this creates the need for workarounds that will be described more detailed in later articles, but one example are lane objects which have no specfic meaning according to the spec. They can describe organizational units, roles, data or systems for example, which makes it hard to show create well defined relationships in ARIS.
To solve this problem I recommend to use two additional model types when modeling BPMN:
– the BPMN Allocation Diagram (beta), and
– the Function Allocation Diagram.
BPMN Allocation Diagram (beta)
The BPMN Allocation Diagram (beta) in the current state allows to map participants (pool objects) to organizational units. This covers the majority of organizational needs and is compliant to the specification which states that a pool represents a partner entity (e.g. company) or partner role (e.g. buyer). However, one popular use is to label the pools with the process name to show the message exchange between multiple processes, which in my personal opinion is a fair usage of these objects for non-executable processes, even though you will have to describe this exception in your project conventions.
The current state of the BPMN Allocation Diagram (beta) only allows you to map the partner entity and partner roles, but those objects allow you to assign organizational charts to add more detail. There were more mapping possibilities in the BPMN 1.x implementation and the “BPMN in ARIS” workgroup is currently thinking about additional mapping functionalities.
Function Allocation Diagrams
Functions Allocation Diagrams (FADs) are a “trusted old friend” from other ARIS use cases, like adding synchronization objects for SAP implementations or adding more details to an EPC to avoid a cluttered layout. The purpose of a FAD is to describe a task (function) in more detail by providing the possibility to connect “real” objects (application system types, risks or person types/roles to mention a few) to a task. This allows to overcome most of the shortcomings of BPMN diagrams and enables to assign additional model types to these objects. In addition to this all FAD-related reports that were created can be used in a BPMN scenario.
Cross-posted from ARIS Community: https://www.ariscommunity.com/users/roland-woldt/2011-01-28-learning-bpmn-2-which-models-are-available-bpmn
Roland Woldt is a well-rounded executive with 20+ years of Business / Digital Transformation consulting and software development/system implementation experience, in addition to leadership positions within the German Armed Forces (11 years).
He has worked as a Team Lead, Engagement/Program Manager, and Enterprise/Solution Architect for many projects. Within these projects, he was responsible for the full project life cycle from shaping a solution and selling it, to setting up a methodological approach through design, implementation, and test, up to the rollout of solutions.
In addition to this Roland has managed consulting offerings during their lifecycle from the definition, delivery to update, and had revenue responsibility for them. This also included the stand-up and development of consulting teams, and their day-to-day management.