Very recently, I was in discussions with a long-term client of Dunstan Thomas in preparation for an upcoming training session on the use of BPMN 2.0 with Sparx Systems Enterprise Architect.
Over the course of those discussions, we got onto the subject of modelling preferences and how some people may model a process one way, and yet another person may model the exact same business process in a completely different manner.
A prime example of this (and the focus of this article) was on our preferences for modelling Pools in BPMN, Whitebox Pools to be exact.
So what is a Pool & why do I need it?
If we look at BPMN in layers, as shown below, then a Pool is not an element of BPMN that you will be using until you get into layer 2 and above:
At this level, you would have moved beyond the realms of Business Modelling (the Conversation diagram) and Descriptive Modelling (the Choreography diagram) and will have started what is known as Analytical Modelling.
Analytical modelling is used to precisely describe the flow of a process, including any exception paths and compensations, and it is here that you would use Pools whilst building Collaboration and Process Diagrams.
A Pool is a container for a process, or a representation of an external participant. It allows the modelling of external participants triggering a business process and the modelling of message flows between the participants represented by the Pools.
We will now take a look at a simple process model that has been modelled using Pools in different ways.
In this example, a whitebox Pool has been used to represent each participant in the process. The term whitebox, refers to the fact that we know and understand the actions undertaken within that container as part of the process and so it is modelled in this open fashion where we can see and consume the different actions undertaken by the participant (and the surrounding decision logic).
In this example the same process has been modelled, but with one major difference. Rather than using multiple Pools, each representing a participant within the business process, this version has used a single whitebox Pool* (representing the overall process itself) that has been subdivided using Lanes** to represent the participants within the process.
* This is my personal preferred method of modelling, using Blackbox Pools to represent external participants and only using message flows to show those interactions with external parties.
** A Lane is a subdivision of a Pool and is often used to model performer roles or organisational units (such as departments). You can even further subdivide a Lane by nesting other Lanes within. This element can be used on both Collaboration & Process diagrams.
What’s the difference?
The difference between these two models is not just visual, it boils down to a very important rule of the notation, and that is:
Sequence flow connectors are not allowed to cross Pool boundaries!
This means that in our multiple Pool example we cannot just tie everything up neatly in a sequence flow and be done with it, we will need to demonstrate the flow of information from one participant to another. This is done using the message flow connection and intermediate events to trigger the receiving party into action for their part in the process.
In the single Pool example, you will have noticed that there aren’t any message flows present. This is because you cannot use a message flow within a Pool, only from one Pool to another. It means that we have had to be cleaver about how we model the flow of information as we only have the sequence flow at our disposal. In this instance User tasks have been assigned to each participant using a Send X, Receive Y naming convention and this is my preferred method for showing communication within a single Pool.
I have purposefully avoided the use of the Send & Receive tasks for the participants as in terms of the notation, they are identical to the Throwing and Catching Message events and so a message flow should be attached to them…which of course we cannot do.
Which is the right way to use Pools?
Both of the examples show here are correct BPMN, and the choice will come down to your preference in terms of modelling.
My advice is this…be consistent. If your colleagues and stakeholders are used to consuming process models that are done in a particular fashion, it is probably better to model that way. The reasoning behind this is that it is better that your intended audience can read and understand the process instead of modelling it another way, simply because you can.
How can we help you?
Dunstan Thomas offer training and consulting services on the use of various modelling notations and Sparx Systems Enterprise Architect.
If you have a requirement and would like to discuss your options, please get in touch.