Often I see process models that represent the same basic business concept but are modeled with completely different styles. Technically the BPMN lane and pool shapes are both a swimlane. But which one do I use, when, and more importantly – why?
Swimlane: a way to group activities performed by the same actor on an activity diagram or to group activities in a single thread.
The term swimlane appears for the first time in formal process modeling in the UML specification. First there was the activity diagram. Then there was a need to separate the activities of individual actors. The swimlane was born. So why are we using BPMN these days instead of UML? Well the answer is quite complicated. The UML specificaiton is full of other types of diagrams including class diagrams, state diagrams, interaction diagrams, and more. Most of the UML specification is very technical, therefore making it less than idea for most business uses.
Many people today believe that the term swimlane is part of BPMN. In a way, this is partially true because the BPMN specification says that both a pool and a lane are techinically a swimlane.
BPMN Specification :
UML was created in 1996. Remember 1996? Internet… What’s that? 1998 – Internet is pretty cool, and by 1999 my mother sent her first email. I recall in 2001 I heard someone say the word “blog” for the first time. In 2002 BPMN was born. And now what we have the history lesson out of the way…
- Pool: Defines activities designated for a single participant. Pay special attention to the words single participant.
- Lane: “A further subdivision of a pool”. Quoting from the BPMN 1.2 specification: “Lanes are used to organize and categorize activities”.
The BPMN specification says specifically that both pools and lanes are considered to be a swimlane. So this is where some of the confusion comes from. Technically it’s correct to call a BPMN pool or lane a swimlane, but the swimlane is not defined as part of the BPMN specification.
Here is an example of a UML style diagram using swimlanes:
This is a small process where a manager wants to hire someone. The manager submits a job requisition to human resources. HR returns a list of candidates and the manager interviews them. This cycle continues until a suitable candidate has been found. After a candidate has been found, accounting is notified to set up the payroll for the new employee. On the first day of work the manager conducts the initial briefing and gives the new employee a tour of the facilities.
The example diagram used the BPMN shapes but is actually a UML style diagram in terms of swimlanes. Often I see this style of diagram in BPM tools (not calling out any vendor specifically here). This diagram is actually incorrect according to both the UML and BPMN specifications. In UML the shapes and usage is slightly different than they are in BPMN. In BPMN you cannot have a lane without it being inside of a pool. I suppose one could argue that the entire diagram is the pool, in which case the only thing that is missing is the label for the pool. So we would have to assume that the pool has something to do with people.
Now let’s take a look at the corrected version of the diagram with a BPMN pool correctly displaying the lanes.
In this example the pool is called People because that is the only logical assumption we can make regarding who the participants are. In fact, if you take the specification literally, there is only one person performing all of the activities. Remember that a pool is a container for activities associated to a single participant. In this respect it is not possible to transition from one person to another within a pool. Each additional participant requires another pool. The lane could be used to indicate that the activities are associated with a particular category of work. For example, the subprocess for finding candidates is actually a performed by the same person that creates the job requisition, but the category of activity is human resources. So I suppose we could say this participant role wears a lot of hats in their organization.
Often I see this style of diagram and I realize that the intent was to show that multiple people are involved in the process. However, this is incorrect in BPMN. If the intent is to show the multiple participants’ activities, you must draw them in multiple pools. But this creates another problem; I cannot draw a transition line (solid line) between pools. I must use a message. Why? First we have to understand what transition means.
- Transition: One activity from a participant has completed and another has begun. Transitions are notated with a single solid line with an arrow head pointing in the direction of the flow (sequence flow line). Sequence flow only occurs within the scope of a single participant.
- Interaction: A process participant wishes to involve other participants through messaging. Interaction is a form of communication that involves the sending of a message. Interactions are shown in BPMN with a single dashed line with an open arrow head indicating the direction of message flow.
- Message: A means to communication between process participants. A message has a well defined recipient and can have a message body containing process data or other data artifacts such as document attachments.
You can see from the definition that a transition is not allowed between participants. This is because it’s simply not possible. In any process, no matter if it’s human centric or system centric, any interaction between participants requires some sort of communication. Messaging is the the means in BPMN to have direct communication between participants. It is also possible to coordinate activities with things like signaling, but this is not actually an interaction. Signals (see my other post for details on signals) are used to coordinate events, but are not used to communicate.
So if you wanted to create a diagram that showed correct BPMN formatting, it would look like this:
The pools for the Accounting and Human Resources participants are collapsed for simplicity. This is a common practice when you wish to show in your diagram the focus on one single participant, but you still wish to show the points in which this participant interacts with others. Most likely I don’t care to show the details of the accounting department because it’s outside my juristiction, and I have no visibility on what they actually do. Also, it’s better to let accounting manage their own processes.
The other concept of style that I’m including in this example is the looping subprocess instead of the “upstream flow” lines. Upstream flow is when you sequence an activity that has already occurred. This is almost like going back in time. The problem with going back in time is that I’m not actually going back in time here. Something is different. I have a new iteration of an activity, but I’m not redoing the exact same instance. In this example I am interviewing a new job candidate. I’m not interviewing the same job candidate again. So in some cases the upstream flow is acceptable, but only if you want to redo something. Otherwise the proper BPMN notation is to use a looping subprocess, which shows that a new iteration is required, and probably a new set of data input is also required. With this in mind you can see that it is impossible to have upstream flow between participants. Any time messaging is involved I highly recommend using a looping subprocess instead of upstream flow. Otherwise your process participants could be out of sync and you might never know it. This is especially important if you intend to make this process automated and executable.
Another important concept to note from this example is that I actually created a parallel flow without actually using a parallel gateway. This done through messaging. The first interaction with the Human Resources participant creates a blocking asynchronous message. This means that until I receive a response from HR I cannot do anything else in respect to this process. A message must be recieve before I can continue at the step “Receive HR Response”. However the second point of interaction is quite different. When I interact with the Accounting participant I don’t wait for a response. I am not showing in this diagram how long it takes for accounting to set up a payroll account. In fact, it might take longer than what it does for the new hire to start working. In the first two examples above the process showed that I actually cannot have the person start work until payroll is set up. This behavior occurs when two processes intersect.
Process intersection is a concept that is hard to understand so it deserves some attention here. In this small process example we have encountered a problem in just a few small activities. Imagine how complicated this would get if we actually draw the entire set of activies for the other participants. There is a way to avoid this overhead and still accurately depict your process diagram. But you must understand process intersection to determine where to stop drawing one diagram and start on another.
The answer to this problem is that we have two different processes. One is the process of hiring someone. Another process is the payroll setup, in which the hiring manager is the requestor, but the hirning manager is in no way in control of this process. Therefore when it comes to syncrhonizing activity between the manager and accounting it gets very difficult to draw from the manager perspective. It’s better to attack this problem from the accounting participant’s perspective, and show the manager as a secondary participant. You can additionally show escalations and notifications from the accounting perspective back to the manager, which resolves the problem of accountability for getting the job done. But what does this have to do with hiring someone? This is why I say it’s a process intersection, not an explicit interaction within the same process. Attempting to mix the two very different business objectives in the same diagram will lead to a very complicated flow that takes a BPMN expert to understand.
Now back to the 3rd diagram example. Because I’ve seperated out what accounting does by simply showing my interaction point, I can easily go forth with the current process and not have to worry about whether or not accounting has done their job or not. We are trying to show the steps a manager takes to hire someone. If accounting doesn’t do their job, the other diagram from the accounting perspective should notifiy the submitter (the manager) that the work has not been done by the due date. But this is out of scope here. Let’s assume it’s been done. Next all we have to do is wait until the day the new hire is supposed to be at work and conduct the first day activities. Plain, simple, understandable, and and from the perspective of the primary participant – the hiring manager.