One of BPMN’s most important elements is unfortunately also the most misunderstood. It’s called a pool, a rectangular shape that serves as a container for a process. So in that sense a pool is synonymous with a process, and that’s as basic as you can get. The confusion sets in when you understand that a business process diagram (BPD) – the top-level object in BPMN, describing a single end-to-end business process – frequently contains multiple pools. Usually only one of the pools describes your process, what BPMN calls a private process; the others typically stand for external participants: requesters of your process, service providers to your process, or possibly sources of unsolicited events that affect your process.
Often such external pools are represented as abstract processes, defined only by their interfaces, i.e. their communications with your pool in the form of messages. A private process defines the process orchestration, meaning the sequential flow of steps within it. An abstract process does not. It is drawn with no activities inside, just opaque rectangles or “black box” pools, but connected to your private process by message flows, i.e. requests, responses, and unsolicited events, called choreography.
This is sometimes quite baffling to business users learning BPMN. But you must remember that BPMN originated as a graphical design notation for BPML, a web service orchestration language quite similar to BPEL. In BPEL/BPML, a process is also a service, and in SOA the service requester and service provider are distinct and separate parties. In other words, the requester is not part of the process, but external to it. You might say this is about executable implementation and has nothing to do with process modeling. And I couldn’t really argue with that, except to say that such SOA concepts are deeply baked into BPMN, and if you ignore them you will wind up unable to avoid validation errors in your diagrams. So in my BPMN training, I try to teach this mindset to business users, even if they have no intention of moving to process implementation. Those with no prior experience in process modeling have no trouble with it, but to some experienced practitioners it is a struggle.
One of the first exercises we do in class is a simple time off request process. The diagram above is how a lot of business analysts with prior modeling experience would draw it. The pool is labeled Time Off Request, the name of the process. Lanes representing participants in the process subdivide the pool.
This is not technically incorrect, but I try to teach it a different way, like the diagram below:
Now employee, the requester, is external to the process, not part of it. In a sense this redefines the process as the servicing of a request, and excludes the preparation of the request, which is admittedly an ITish, SOA-conditioned view. The process starts upon receipt of the time off request. If the employee begins to fill out the request, has second thoughts, and never sends it off, no instance of this process is created. To me that makes sense. To some people it does not.
The employee’s own process is opaque, so we show it as a black box pool. As the service provider, we don’t really care what it is. We just want to show how we interact with it, in the form of a request message (time off request) and a choice of response messages.
One of the confusing things to business analysts who find the time to read the BPMN spec is that the spec says pools are used to distinguish process “participants.” But the spec means participants in the SOA sense, i.e. requester or provider, not in the sense of roles within the orchestration, like Manager and HR. Those are depicted as lanes within the internal process pool.
Many experienced practitioners who use process modeling for analysis and process improvement with no thought of automated implementation find my approach annoying, perhaps counter-productive, and would claim that their clients could never understand it. However, I find that business people can understand it easily; it’s the practitioners who may have to adapt their methodology.
Why would they? The answer is that BPMN is an industry standard, supported by a wide variety of inexpensive tools, and provides a common visual language that can be shared by business and IT. Those factors are creating the demand, by business, to adopt that standard, whether it fits their consultant’s pre-existing methodology or not. BPMN offers business the possibility of playing a more active role in defining the to-be process, using a common model shared with IT. But that new role and new common model demands thinking about the process in a new way – when it starts, when it ends, who’s in it and who’s external to it.
When I posted these thoughts on my BPMS Watch blog, I got an unexpected response from some IT architects. Instead of complaining about splitting off Employee into its own pool, more than one wrote to ask why HR and Manager in my diagram are not in their own separate pools:
We could then think of these participants as having control of their own processes subject only to the contracts implied by the messages between them.
In fact, one was insistent that a pool represents a participant, not a process:
Pools are somewhat synonymous with resources possibly taking part in a number of processes (even within a single business process diagram). In fact, the number of distinct processes in a diagram is not determined by simply counting the number of pools.
But that is simply incorrect. In BPMN, a pool is a container for a process, an orchestration. It does not represent an actor, nor is it a container for multiple processes. (A black box pool, with no orchestration defined within it, is sometimes labeled as if it were an actor, but only as a participant external to your private process, or orchestration.)
As BPMN gains acceptance as the key process description standard, it is inevitable that some will try to twist it to fit their pre-existing terminology and conceptual framework, assuming incorrectly that BPMN has none of its own. However, the BPMN 1.1 spec does not do a very good job of defining its fundamental terms. This making BPMN’s core concepts and metamodel crystal clear to everyone has to be a critical goal of BPMN 2.0, now under development by OMG. And that all starts with pools.
