Lanes (known as swimlanes in BPMN 1.x) represent process performers in BPMN.
Rules for the lanes:
- Lanes are optional.
- Lanes may be nested (hierarchical).
- Lanes semantics is fully at the discretion of the diagram’s author - it may be a function, role, position…
- Embedded subprocesses do not have pools and therefore can’t have lanes.
- Lanes are meaningful only to the user tasks - service tasks, script tasks, subprocesses, gateways, events are irrelevant to which lane you put them in.
- Even for the user tasks the lane is essentially a comment - actual performer is defined by the model attributes of the given task.
Novice BPMN users love lanes and use them at first excercises with enthusiasm:
Figure 1. BPMN diagram with lanes.
However using lanes won’t allow showing the process “happy path” which arguably is more valuable from ease of perception standpoint:
Figure 2. BPMN diagram with a happy path.
Moreover, when dealing with large processes there is no room for lanes at all.
There is a general rule applicable to any notation including BPMN: the number of activities at any diagram level should not exceed 7-9. Otherwise the scheme becomes too difficult to perceive:
Figure 3. “Flat” diagram with a large number of activities is hard to understand.
Accordingly, if the process comprises a large number of tasks, it should be decomposed into subprocesses:
Figure 4. Subprocesses help creating a simple diagram from a complex process.
But this style of modeling leaves no room for lanes:
- At the top level there are only subprocesses while lanes apply only to the user tasks (rule 5).
- Subprocess diagram doesn’t allow pools nor lanes (rule 4).
More precisely, rule 4 applies only to the embedded processes; reusable subprocesses may have lanes. I’ve seen diagrams where reusable subprocesses where used instead of embedded solely to be able to depict lanes. This is definitely bad practice - embedded subprocesses shall be used for the decomposition. Reusable subprocesses introduce additional complexity because unlike embedded they are executed in a separate data context.
If you can’t live without diagramming performers then use BPMN artifact “group”:
Figure 5. BPMN groups shows performers within the embedded subprocess.
Great article, Anatoly!
Here you touched on one issue that I meet almost every day. The fact that lanes cannot be included in sub-process (unless they are global) frustrates many process analysts that don’t fully understand the logic behind BPMN rules. And that becomes especially hot when they move from a drawing tool to a real modelling tool that does not allow and/or alerts on semantic errors. But probably lanes come as frustration number two or three. Number one in my experience is the inability to have message flows reaching nodes inside sub-processes. Or at least that’s the thing I spent most time explaining. The absolute dependency (data- and control-wise) of the sub-process on its parent seems very difficult for many people to understand. Should we ask them to try harder or maybe it’s time BPMN got friendlier to their needs without losing its execution capabilities.
Kind regards,
Ivo
Interesting thought, Ivo. I don’t see any particular logic in forbidding swimlanes in subprocesses, too. OK, there is one reason but it’s pure technical: no pool therefore no swimlanes. Guess they could find a workaround.
Вы говорите, что семантика дорожек может быть любой, таким образом, описывайте некий шаблон (полноценный стандарт), как нужно строить диаграммы бизнес-процессов.
Как Вы считаете, возможно, ли создание стандартов выполнения бизнес-процессов в организации, не с точки зрения конкретики (например, заказ должен быть оплачен в течение трех дней), а с точки зрения выполнения бизнес-процесса как такового на концептуальном уровне (например, на схеме событий типа «сообщение» должно быть в количестве 5)? Это своего рода перерастает в некий стандарт, на который можно в последствии накладывать на конкретные данные (бизнес-процессы в организации). Спасибо
Ирина
Эффективное применение BPMN в организации требует выработки внутреннего стандарта по моделированию. Это необходимо из-за того, что BPMN позволяет моделировать одно и то же несколькими разными способами. В частности, в таком стандарте может быть сказано, что дорожками мы моделируем подразделения.
Anatoly -
would you say you’re arguing more for limiting the use of swim lanes, or limiting the use of re-usable subprocesses (if just for the purpose of getting swim lanes)?
The way I read it (could be wrong) you’re not arguing one shouldn’t use swim lanes, just that the spec and the use of proper model decomposition make it hard to use swim lanes properly without using re-usable subprocesses… but I may be misreading.
The issue with swimlanes is that they are a useful analytical device for identifying process improvement, but as this great article shows they make end user adoption very difficult. Why - the ability to lay out a swimlane makes the diagram too large to be easily displayed on a browser, iPad or smartphone. Printed and stuck on an office wall is no longer good enough with a mobile workforce.
Scott
Well I didn’t mean to give recommendations, just to explain what can and what can’t be done with swimlanes. BPMN was intentionally desinged as methodology-neutral so there is no single truth there. But there are rules that confine modeler’s freedom and I just wanted to clarify them for novice BPMN users.
My personal position is this: one can’t bring secondary aspects to the diagram without compromising primary things, i.e. making them less clear. For me, the control flow is primary and participants are secondary.
So for really complex processes swimlanes are luxury we can’t afford; happy path style diagram are 1) more informative, 2) more compact as Ian noted and 3) are scalable in BPMN because unlike swimlane style diagrams they don’t suffer from process decomposition into subprocesses.
BTW, I apply the same principles to data flows: there are data objects in BPMN but they are secondary with respect to control flow. Data objects/stores become primary issue only in interprocess communications, see http://mainthing.ru/item/434/
Anatoly,
While I disagree with some of your “rules” about lanes (#4 is incorrect, for example), I agree with the general points you make. I have noticed that people who really care about lanes, such as process improvement consultants, prefer the flat modeling style, as opposed to architects, who favor hierarchical modeling. If you care about handoffs between lanes in your process improvement methodology, flat models work better. I have had a difficult time using lanes effectively in my Method and Style approach, which favors the hierarchical style.
–Bruce
Bruce
Thank you for the valuable input.
Regarding #4 “Embedded subprocesses do not have pools and therefore can’t have lanes” - which part of it is incorrect?
- Is it possible to draw a pool on embedded subprocess diagram (apart from external entities and processes others than the one the subprocess belong to)? I’t be very confusing: we already used the pool for the top-level process.
- Is it possible to draw lanes without pools on embedded subprocess diagram? The spec (p.282) says “A Lane is a sub-partition within a Pool or a Process”. It’s hard to imagine lanes without a pool.
Lanes are sub-partitions within a Pool or a Process. However, you are allowed to remove the boundary of at most one Pool (participant) in Collaboration. So, for me that impies that I can use lanes without a pool. So I can use it within a subprocess as well. Anyway I am not sure is that a real problem. I need lanes only when I need to stress that there is a “more” complicated “structure” of an organisation involved in process.
Szymon
You are probably right but it raises a question about the quality of BPMN spec: better have it explicit rather than guessing of what’s implied. At the end of the day each vendor would follow its own judgement.
It’s not a real problem for you neither for me but it is for many people as comments above witness.