BPMN to Requester: Get Outta My Pool
June 11th, 2008
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; 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 (called message flows in BPMN). They are drawn with no activities inside, just opaque rectangles or “black box” pools.
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. And that all starts with pools.
Entry Filed under: BPM
8 Comments Add your own
1. frenchdk | June 11th, 2008 at 2:45 pm
Would you please clarify the value of the “Lane” here. I suggest that there is something to be gained by treating the departmental manager and HR as actors at the same level by putting them in different 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. This also recognises that organisational change (including mergers and acquisitions) does not necessarily alter the business process.
My view is a bit biased toward the SOA / IT viewpoint, I know, but what is lost on the business side?
2. bruce | June 11th, 2008 at 2:58 pm
What is lost is the idea of orchestration, which is central to BPMN. A pool does not represent an actor but a process. (Well, a black box pool could be thought of as an actor, but not a pool with activities inside it.) If you do not have orchestration connecting the activities of multiple actors, you don’t really have a process. You just have independent services sending requests and responses to each other. There is no central “thing” that holds it together. Yes there is a viewpoint that says, “why do we need orchestration [e.g. BPEL] at all?” That’s more of a libertarian or anarchist view of BPM. Maybe a valid viewpoint, but I don’t think proper use of BPMN.
3. frenchdk | June 11th, 2008 at 7:40 pm
…I do not see myself as an anarchist but do see a potential in isolating standalone processes so that they can be included into other end-to-end processes, (re-used as the developers would term it). Drawing the HR and Manager Lanes as Pools within the end-to-end process does not lose the sense of orchestration. You just have a more precise definition of the relationship between very different actors in the process. There are definite gains in the implementation arena…
Expanded upon in my blog
David
4. torben | June 12th, 2008 at 11:44 am
To be honest, I find it a very problematic statement that a pool is somewhat of a synonym to a process. In fact, this is even wrong…
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 diagramm is not to be determined by simply counting the number of pools. (Would be simple, wouldn’t it? ;))
To give you a simple example: imagine a pool with two start events not even sharing a single diagram object in the subsequent flow. So, there are two completely independent definitions of two totally different business processes performed by the same actor. All of this in the same pool…
Therefore, the distinction of a pool and a process has to be made explicit. Especially if you think of a BPEL transformation as propagated in many of your posts. In fact you can only transform processes, but not pools…
Cheers,
Torben
5. bruce | June 12th, 2008 at 12:06 pm
Torben,
Well I guess we agree to disagree. In BPMN, a pool is a container for a process. It has an optional attribute ProcessRef that points to at most one process. Your example of two independent orchestrations (processes) in a single pool is not valid BPMN. A black box pool, with no orchestration defined within it, is sometimes used as a proxy for a participant. It would not have a ProcessRef, so I suppose you could say it contained multiple processes, all of which are unnamed and invisible.
Some of the confusion comes from the clumsy treatment of the term “process” in BPMN. Quoting from the spec…
I use process synonymously with orchestration, i.e. a BPMN process is an orchestration. This is what BPMN calls a “private process.” An “abstract process,” denoted by an empty (black box) pool, is often labeled with the name of the participant, not a process, as discussed above.
–Bruce
6. wout | June 17th, 2008 at 3:04 pm
I totally agree with the IT side of the discussion.
Process is a kind of Activity, so should have the same notation as Subprocess and Task (rounded rectangle). Maybe Process is a kind of Subprocess??? That way you can build a nice hierarchy of Processes. (Watch out for multiple raised Events!)
Lanes are kinds of Actors. Pools are also Actors, but they have a hierarchical relationship with Lanes. Maybe like an org chart or something?
7. allweyer | July 1st, 2008 at 10:58 am
None of the two diagrams is better or worse than the other - they just provide different views onto the process.
The first one provides an overall view on the entire flow, showing who is doing what in which order. This is what you need in order to gain an understanding of the company’s processes without going to much into detail. This also helps when you try to improve processes, e.g. by shifting activities from one role to another (such as shifting activities to the customer, creating cheaper and faster processes with a large amount of self service activities). Or you may find that several activities are carried out twice (e.g. partner 1 does a checks the quality of their products before moving them to partner 2, and partner 2 performs the quality check again - you can get rid of the second quality check, if you make sure that partner 1 does the quality check right). You cannot find such weaknesses if you model these partners as separate pools with their private processes. To the contrary: Such a modeling style actually reinforces existing interfaces. Process improvement aims towards reducing the number of interfaces. This purpose of is entirely neglected if you say that business people should always model the process as in your second diagram. It is not a matter whether business experts can learn that type of modelling, but it does not serve some important purposes.
The second diagram highlights the idea of an organization and/or a technical system (such as a BPMS) providing a service to someone, such as a customer or a partner. In order to do this you need to have already decided which partner should carry out which activities, so that the interfaces are defined. Therefore you should draw such a diagram only after you have optimized your overall processes. It provides a more detailed view which should be developed at a later stage in a Business Process Management Project.
Within a pool you have some kind of central control or governance of the process contained, the other participants with their own pools are outside the reach of this control. They have their own control - there is only an agreement on the choreography, i.e. the message exchange. Depending on how you view a process, the scope of control may be different. For example, the management of a company may define and control the company’s core processes. The scope of control would be the company, i.e. when modeling such a core process, the pool would represent the company, lanes could represent departments. After the company has defined and maybe re-engineered its processes, they may decide that is not enough just to draw a picture what has to be done by which department in which order, but they need to define services with specified services etc. So they would create more detailed models specifying theses services. Now the department that actually has to provide the service only controls their part of the overall process (within the broader control scope of the company management), so now it makes sense to model this department as a pool and the other departments as separate pools. So what is a lane in one view of the process may become a pool in another view.
And of course if you want to automize a process with a BPMS the second diagram also makes sense (you even may model the manager and the HR department as separate participants, and the actual process is running in one system pool, as you would model it in Intalio Designer).
BPMN will not be accepted by Business Analysts if IT people force them using workflow concepts where they do not support their purpose of modelling. Business process models are not only used for specifying executable workflows, but for a multitude of other puroposes, as well. I agree that many BPMN concepts can be useful for business people, as well. But they should be used only where they actually provide value.
8. bruce | July 1st, 2008 at 11:28 am
Thomas,
Thank you for a really thoughtful comment. After pondering it, I find I completely agree with you, and I plan to add that nuance to my BPMN training.
–Bruce
Leave a Comment
You must be logged in to post a comment.
Trackback this post | Subscribe to the comments via RSS Feed