Thursday, 12 June 2008

BPMN Pools and Lanes

Bruce Silver introduces one of the misunderstood areas of BPMN in his recent post . He notes that a Pool is a container for a process.
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.
Of course one person may view a process as end-to-end and another will view it simply as an activity their grand plan. It is a matter of perspective. So it is as well to determine what the scope of a BPM exercise is.
Bruce recommends the practice of treating the 'requester' or initiator of a process as an external element communicating with the orchestration. In BPMN terms the requester is a black-box process in its own pool. Here is his view of a simple absence request.
This provides a clear definition of the relationship between the Employee and the orchestrated business process. The message-passing constitutes the shared information between the Employee and the Time Off Request process. The Time Off Request process has a division of responsibilities between HR and the Manager of the employee represented by the BPMN Lane construct. A Lane is a graphical sub-division of the Pool and does not impose limitations on the business process. A pool however does constrain the process design in that sequence flows cannot cross pool boundaries. The problem that I have with this is that it is equally possible to view the HR activities as a service to the Manager and the nature of that service may change over time independently of the Manager or Employee expectations in the end-to-end process. I commented to Bruce
... 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.
Implicit in the division of the Time Off Request Pool by Lane is that all the information of the process is available to both Manager and HR. This is fine until outsourcing comes along and you have to work out what info that you need to pass across in the message. Alternatively it obscures important details about the scope of the participants involvement (as far as the process analyst viewed it). Bruce responded to my question of the value of the Lane...
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.
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.


Bruno Barrios said...

Hello Dave!

I saw this thread and the Bruce thread.

I'd like to ask 2 things for you one about this article and another about my problem:

1) I really thought about your idea of separating the lanes in pools, but, if you think this way, when would you use lanes again? Cuz almost everything could be transformated into pools.

2)Just explaining, in my case a customer starts the process(with phone call to manager) and the first SUBprocess the manager Inserts him in the website, then send back to him the login and password… on the second SUBprocess, the user must login and insert a lot of data in the system.. Is this step the user is executing part of the process and I know all activities that he has to execute.

Is it correct on my top level process I have 2 pools like enterprise and customer sending messages up and down. Think about all SUBprocees sending and receiving messages with the black-box poll named customer. (THIS IS OK)

Then, in the second SUBprocess, looking in child-level now, i have the customer as a lane inside the enterprise process? is it correct? os I’m obligated to keep him as an black-box in the second SUBprocess? But i know all the steps the customer will do, should I model him as a lane(part of process), or as a black-box, or as another pool with his activities sending and receiving messages from the enterprise process?

Thanks a lot!

David French said...

A few years have passed but I do not think anything has changed with LANES. As the book ( BPMN 2.0 by Example, Version 1.0) says "It is totally up to the purpose of the model and therefore a decision the modeler has to make, whether a collaboration diagram with different pools is useful, or whether one should stick to one pool with different lanes". I would only use Lanes for amplification in a similar manner to using a highlight colour.

Samuel Diniz Casimiro said...

Hi Dave,

I'm with you, and I'm sure Bruce is wrong. In fact, Bruce is responsible to spread this lie about pools all over the world. The BPMN specs are very clear: Pools are meant to represent Participants. That's it! I've also an article about this (in Portuguese).

See you,