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.

Principles and the Police

Stephen Franks, a prospective member of parliament later this year, raises the issue of basing the police role on the public support by reference to the founding fathers of London's Metropolitan police. He does so with typically inflammatory language imputing cowardice and other shameful behaviour to police and ambulance staff. Although his politics and attitudes may be an anathema, it is worth considering what society expects of its police service. Interestingly Stephen Franks drops a few of Richard Mayne's principles from his extract:
4. To recognise always that the extent to which the co-operation of the public can be secured diminishes proportionately the necessity of the use of physical force and compulsion for achieving police objectives.

6. To use physical force only when the exercise of persuasion, advice and warning is found to be insufficient to obtain public co-operation to an extent necessary to secure observance of law or to restore order, and to use only the minimum degree of physical force which is necessary on any particular occasion for achieving a police objective.
8. To recognise always the need for strict adherence to police-executive functions, and to refrain from even seeming to usurp the powers of the judiciary of avenging individuals or the State, and of authoritatively judging guilt and punishing the guilty.
9. To recognise always that the test of police efficiency is the absence of crime and disorder, and not the visible evidence of police action in dealing with them.

These are, of course, as relevant as the others.
Unfortunately the time has long gone when the 'Met' has widespread public support and it certainly avoids such detailed principles in current operations but a challenge to the New Zealand Police Commissioner Howard Broad is to identify what he thinks the police should be doing and how well he thinks it is doing it. Unlike most other large organisations, the police do not publish a 'vision statement' or even its operating principles against which the day to day operational success may be measured.
Our politicians and representatives will serve us best by working out what the principles for the Police should be and encouraging support for the front-line staff.

Intalio - Becoming a Good Fit for Enterprise

Although I really like the approach that Intalio has taken to BPMS with its use, support and provisioning of Open Source components and adoption of standards, I have been frustrated by the user interface and lack of reporting mechanisms for the BPMS itself (broadly BAM). The user interface was developed to support the Tempo workflow component without much consideration that people engaged in workflow may need to have some integration with systems that are not to be provided by the Intalio solutions. There may even be a corporate way of presenting the user interface for tasks/to-do lists (Microsoft's Outlook has a fairly wide usage in this respect). It is intuitively clear that given the use of standards like SOAP in Intalio, replacement of the UI at run-time is fairly simple as all the interfaces are defined in WSDL. Not so easy, is incorporating a replacement UI into the Intalio Designer (eclipse-based). However, there has apparently been some work going on in dark corners to resolve these and the up-coming user conference will have some show and tell on replacing the user interface using, as an example, Ruby-on-Rails. My particular interest will be to see if a full-function XFORMS user-interface can be developed combining the benefits of the visual form design already in Intalio with the ability to use standard message schemas and have full control of the submissions from the form. There has been some smart work on BAM which looks to be following the common Intalio thread of open source by using the Eclipse BIRT reporting project . Again this is featured at the user conference. Unfortunately, I am not able to make the conference but will be following the output with interest.