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.