The whole reason for BPMN’s existence is to provide a notation that is outwardly familiar to flowcharters but has precise semantics and rules as demanded by analysts, architects, and developers. Nevertheless, the BPMN 2.0 spec fails to offer a business-understandable definition of its most basic concepts… starting with “process”.
What does BPMN mean by a process, anyway? It doesn’t mean the same thing many long-time flowcharters think it means, as evidenced in a recent comment thread here. Blame for this lies mainly with the BPMN spec itself, which adds to its sins of omission by continual reference to both pools and lanes as “swimlanes,” when they mean entirely different things. (Microsoft is even worse by using the same shape for pool and lane in Visio Premium’s BPMN stencil!) For some unknown reason, the BPMN spec is reluctant to acknowledge that a pool is primarily a container for a process (in addition to its secondary value as a participant in a collaboration).
A BPMS Watch reader wrote to ask why a diagram like this
gives BPMN validation errors. The tool’s validation function is correct. BPMN (and any good BPMN tool) requires a sequence flow between task 1 and task 4. Otherwise the pool named “Process 1” contains two processes, one containing task 1 and another containing task 4, and a pool can only contain one process. Or, you could conceivably argue that there is one process but that task 1 and task 4 are on alternative paths within it… certainly not what the modeler intended.
In BPMN, a process model depicts all the possible paths from the initial state of any process instance to its final state, and the logic that causes the instance to take one path vs another. That routing logic is based on a combination of instance data (via gateways) and events that occur. Because the logic for all possible paths from start to end is known in advance, the process could in principle be automated in an engine… even though few modeled processes are in fact automated.
A sequence flow – the solid arrow – is BPMN’s symbol for flow of control within a process. When the node at the tail of the sequence flow is complete, the node at the arrowhead is enabled to start. All nodes in a process must be linked via a continuous chain of sequence flows from the process’s start to an end node. The shape that separates what is inside a process from what is outside is called a pool. Sequence flows are confined within a pool; they cannot cross its boundary. Other than its rectangular shape a pool has almost nothing to do with a lane, which is a graphical subdivision of a process used to categorize activities. Historically lanes have been widely used to indicate the role or department that performs or is responsible for the activity, but technically they can be used for any categorization (critical vs non-critical, etc.)
Usually the start node of a process is denoted by a start event and end node by an end event. But BPMN also allows implicit start and end nodes as well. Any flow object (activity, gateway, or event) with no incoming sequence flow (with a few special exceptions) is an implicit start, and any flow object with no outgoing sequence flows is similarly an implicit end. Until recently, BPMN had a rule that you could not have implicit start or end nodes in a process level if it contained any actual start or end events. That’s in fact the reason why the diagram above, in which task 4 is an implicit start node of Process 1, gives a validation error.
But Steve White reports that that rule was eliminated in the final BPMN 2.0 spec. The diagram above shows why that was a mistake. With the elimination of constraints on implicit start and end events, you could argue that the diagram above is “valid.” But it still makes no sense, and it certainly does not reflect the modeler’s intent. Here’s why.
It would mean that in Process 1, task 4 is a second start node of the process, along with the start event. What does it mean when a process has more than one start node? Here BPMN is a bit confusing. Multiple start events represent alternative start nodes, i.e., only one of them represents the start node for any given instance. That is certainly the case for triggered starts, denoted by a trigger icon inside the event. You could have an order that comes in through the call center and an order that comes in through the web. They would have separate Message start events, and the paths out of those events would merge downstream (if they are not, in fact, entirely independent processes). For None starts, I believe the same applies. I interpret None start events in a top-level process as manual start by a task performer, but the spec does not insist on that. The BPMN 2.0 spec says that an implicit start node acts as if it were preceded by a None start event.
If the diagram above is considered valid, the start event and task 4 become alternative start nodes of Process 1. But task 4 was certainly not intended to represent the initial state of Process 1. Also, an instance of Process 1 that contains task 4 would be independent of the instance that contained task 1, rather than a continuation of it, as the modeler obviously intended.
It’s actually very simple: if task 1 and task 4 are meant to represent actions on the same process instance, they need to both lie on the same chain of sequence flows from process start to end. That’s what a “process” in BPMN means.
(By the way, Process 2 should have a start and end event as well, and the message flow from task 1 should really go the Message start of Process 2. A Message start event means create a new instance of this process whenever this message arrives.)
The best solution of all is to make those pools lanes instead, and replace the message flows with sequence flows. That’s probably what the modeler intended… before the BPMN spec (and Visio) muddied the waters with the notion that pools and lanes are sort of the same thing.
[…] This post was mentioned on Twitter by BPM Chile Group and kenlacrosse, Ricardo Seguel. Ricardo Seguel said: Shared: What is a “Process”? http://bit.ly/bWYt7C […]
Bruce,
You’ve identified the heart of the issue: ” a pool is primarily a container for a process.” That is slightly different from my understanding from some Business Analyst training. Each activity is a process, sub-process, or task. The swim lanes are not processes themselves, but roles that perform the various processes. I think we are using a different interpretation of these artificats.
I am most certainly not disagreeing with you – just trying to understand where I’ve gone awry! So… reference your diagram, taken from my example: If I leave it as is and add a sequence flow from Activity 1 to 4, I get rid of the errors. But have I done the right thing?
Also, I can remove errors by adding end message tasks in the second pool with connections to the first.
As a team, we’ve agreed on clarity and communication over pure BPMN correctness. But I’m very much interested in satisfying both objectives.
Again and again, thanks for your patience and information.
Bruce,
One more item – this from BPMN.org:
An Lane is a sub-partition within a Pool and will extend the
entire length of the Pool, either vertically or horizontally.
Lanes are used to organize and categorize activities within
a Pool. The meaning of the Lanes is up to the modeler.
We don’t tend to make the Lane a Process. Is that contrary to BPM notation? We use the lane as a role or if we’re doing a system diagram, possible a system.
Still trying to get it right!
Connie
I think there are a few points of confusion here. Firstly, BPMN 2.0 does require that a Sequence Flow not cross a Pool boundary. This has the effect that a Process’ Sequence Flow will be entirely contained within a Pool. However, this does not mean that the container = the process. Typically, an enterprise (i.e. organisational entity of some description) is the “container” of a process, in that the Activities of Process will occur entirely within and under the control of the enterprise. Therefore, although the BPMN 2.0 spec seems a bit ambivalent about Pools and Lanes – the Pool can be usefully thought to represent the entity which controls a Sequence Flow. A corollary to this is that Lanes can be usefully thought of as representing business functions (i.e. a ‘logical’ capability or physical business unit – within an enterprise) – but that is another discussion. Also note that it is entirely ‘legal’ BPMN to not include a Pool at all.
Secondly, the definition of a process must surely also include the messaging received and sent to all involved parties. This is to say that there is more to the description/definition/specification of a Process than the Sequence Flow of Activities.
This is another point on BPMN 2.0 is vague – however it would seem that there is currently no graphical element within BPMN that defines the scope of a process (see the discussion on ‘Diagram Point of View’ on pgs 26 and 27 of the BPMN v2.0 spec). However, if we conceive of at least two levels of ‘process like’ description (i.e. abstraction) – such as the BPMN 2.0 spec implies with the inclusion of the ‘Collapsed Sub-Process’ then it seems that the Collapsed Sub-Process can be used to define the scope of Processes or Activities contained within it when expanded. Therefore, you could consider placing a single Collapsed Sub Process around all Pools that in turn contain Sequence Flows that might be considered to be included in the scope of a given Collaborative Process. Note the BPMN 2.0 spec seems to support the notion of a Collaborative Process – i.e. a Process that includes the Activities in more than one Pool (see Figure 7.3 on pg 25).
In BPMN, a process does not equate to a business process. It means an orchestration, that is, the control flow logic from some initial state of an instance (the start event) to some final state (an end event). In other words, the map of sequence flows does indeed define a process. That doesn’t mean there is not more detail of importance beyond the control flow. Data, messages, service definitions, human task assignment details are examples of data underneath each flow element shape, although only tools that support executable BPMN 2.0 (e.g. Oracle) even try to use them so far. There are many other important information elements, such as simulation parameters, KPIs, strategies and goals, and governance attributes, that are not part of the BPMN spec at all. None of that change the fact that a pool is a container for a single BPMN process, and that is a pool’s greatest impact on model semantics, regardless of what kind of “story” you want to wrap around its interpretation as the “owner” or “participant”.
I’m not quite sure what point is being made here. Is it simply that a sequence flow is required to stay within a Pool – therefore a Pool is a (BPMN) process container? If this is the point then it is probably worth noting that it is not the only such ‘container’ defined within the BPMN 2.0 spec (see Expanded sub-process pg 32 of spec – a Sequence Flow may not cross the boundary…). Therefore, while there are undoubtedly holes in the BPMN 2.0 spec in terms of missing or vague key definitions – I’m not sure it helps much to single out the Pool as any more a ‘container’ than the Expanded Sub-process or indeed the page on which the model is depicted. A final point on this issue is that it is entirely legal within the BPMN 2.0 spec to have multiple sequence flows – independent of each other (i.e. separate start and end events) contained within a single Pool. This is obviously not recommended practice – but does suggest that there is not necessarily a 1:1 mapping between sequence flow and Pool (which I think is what you are suggesting?).
On the semantic side of things, the BPMN 2.0 spec is also very clear that a Pool represents a participant in a collaboration (and can represent something similar under certain conditions in a choreography), and that it also acts to partition Activities from those in other Pools. It further defines a Participant as a business entity that controls a process (pg 518). So the notion that a Pool represents the entity that controls a process (and as a consequence – also contains the process) is at least a “story” that seems imbeded in the BPMN 2.0 spec itself.
Actually, I think this is becoming clearer. Our Analyst training did say the model describes a process. Each roundtangle can be the lowest level (activity or task) or a further decomposible process (a sub-process). We tend to use the pool as a high-level entity and the lanes as lower-level entities.
When we use one pool as an external user and another as our company, there are two methods to comply with standards. One is that a specific user activity may end with an end-message event that connects to the other pool with a start-message event. Nothing really happens in the first pool, until a message is sent from the company pool. That works.
It also works to tie the user events together with sequence flows and just show the interaction with the company pool as message flows. I am still unclear as to which approach is preferable. The user events are really dependent on the company response. And the company would not respond without the user message. In that sense the end and start messages work well and seem quite logical. But I’m not sure there is any more clarity than just showing the logical flow via the non-compliant message flows entering an activity in a different pool.
Yes, I know, a picture would be worth a whole bunch of words here.
I think Bruce’s point is captured well in the paragraph: “With the elimination of constraints on implicit start and end events, you could argue that the diagram above is “valid.” But it still makes no sense, and it certainly does not reflect the modeler’s intent.”
Bruce is not suggesting a 1:1 mapping between a process and a sequence flow, for we know that a process can have many branches of flow. What Bruce is saying is that the mapping must be explicit or else it’s ambiguous or even liable to be technically wrong.
In the above example, for instance, this is what actually happens: 1 and 4 start SIMULTANEOUSLY. At this point, both 1 and 4 hit end events (since 4 is not a formal Intermediate Event, it will not “wait” for message flow from 3). Technically, here process 1 is over. In the mean time, 1 triggered 2 and 2 triggered 3. At this point, 3 will trigger 4 AGAIN. We could see this more clearly, if explicit start/end events were enforced.
Bruce raises an important issue. Consider, for instance: do these two diagrams together not constitute a high-level “process”? If so, how do we decide to put Process 1 and Process 2 in separate pools as opposed to merging them into one pool (and using the Expanded or Collapsed Sub-Process notation)? At what conceptual level we should situate our definition of “process” in any given situation? What criteria do we use to determine the best choice for modeling (e.g., Are the processes sequential or possibly overlap? Do they treat the same kind of token? Do they use the same technology? etc). Once we determine what a “business process” is, do we represent it in one or multiple pools? The answer to these questions will drastically alter the process model, it’s meaning, real-world correctness, and readability. I believe that the multi-pool approach to modeling is underused by modelers and undersupported by tool vendors. I consider this one of the most powerful conceptual revolutions represented by BPMN.
On one application of Multi-pool processes, see Bruce’s article: http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90f6b04c-fb9b-2a10-ba80-a7924bc7b954
Best.
Thanks Vlad. I agree with what you say. Also, re Chris’s suggestion that a pool is not a container for a process, I would just add:
1. A subprocess is not the same as a process. A process can be “called” as a reusable subprocess using the Call Activity construct, but this is not the same as the subprocess element. A pool represents a process not a subprocess… so if you use a pool on a child level (subprocess) diagram, label it with the name of the top-level process not the subprocess.
2. In the BPMN 2.0 metamodel and schema, a “participant” — the semantic element represented by the pool shape — can reference only one process element… not more than one.
Ummm – I don’t believe that at any point in this exchange that I have claimed that a pool is not a container of a sequence flow??
The first point I was trying to make is that the logic that says “a pool is primarily a container for a process” is like saying that a laptop is a container of electronic componentry. While it is true that a laptop is container of electronic componentry – it is only true by virtue of its purpose. Similarly, the (semantic) meaning (i.e purpose) of the Pool in BPMN Spec 2.0 is to represent a participant which controls execution of a (collaboration) process (see defns pg 518 of BPMN 2.0 Spec) – and as a consequence of this it is the case that a Pool will entirely contain a sequence flow, and can be used to partition flows etc. However, this consequence is not sufficient rationale to then name a Pool after the process rather than the business entity or role the it represents. I’d suggest that Figure 10.125 on pg 315 illustrates the intended use of Pools and Lanes within the BPMN 2.0 Spec (as well as Figures 7.2, 7.3, 7.5 & 7.6 and numerous others contaied within the Spec).
The second point is that while a sub-process is not equivalent in every respect to a process – it nonetheless also has the characteristic by which the sequence flow it contains must be contained within its boundaries. Indeed FlowElementContainers class diagram indicates that process, sub-process and choreography are all types of FlowElementContainers.
The underlying problem here is that BPMN Spec 2.0 (surprisingly) does not have a symbol that (semantically) represents a process.
This touches on the third point I was trying to make which is that while it is true thata particiant can reference only one process – the spec seems to allow for a “process” which has two separate and independently triggered sequence flows that are contained within a single Pool (i.e. the process concept in the Spec is not equivalent to single sequence flow). I’m not advocating anyone adopting this practice – just noting that it seems to be legal BPMN 2.0 – see Process class diagram pg 150.
Chris,
I think we agree on a couple things: 1. BPMN 2.0 does not explicitly have a shape described as the container of a single process, and that was kind of dumb. (BPMN 1.2 did… it was called a “pool”.) 2. The spec does not clearly define the meaning of BPMN’s most basic concepts, such as a “process.” They thought a UML class diagram was sufficient. Also dumb. But where we part company is on the point that the “real” meaning of a pool is to describe an external entity. There are many examples of a business process that must be modeled as multiple interacting BPMN processes (often because there is no 1:1 correspondence of instances), even though the performers of the activities in each pool are the same resources. It is just like partnerLinks in BPEL. While the spec narrative may spin a story about how they represent B2B counterparties, more often they simply represent the interfaces of other internal processes.