The team of IBM, SAP, and Oracle (augmented with a long list of new co-sponsors) submitted a revised version of their BPMN 2.0 proposal last week, and it is beginning to look almost real. I am going through the document and this post is the first of what I expect to be several on the topic.
The revised BPMN 2.0 submission is a significant improvement over BPMN 1.x and offers hope of eventual rapprochement with the BPDM proposal. However, it could go significantly further to resolve ambiguities over the most basic concepts and terminology that have persisted since the beginning of BPMN 1.0, terms like "process", "diagram", "participant", and "pool". I expect that BPMN will become the universal standard in BPM, and it is vital the spec do a better job of defining its most important concepts and terms.
The term business process diagram (BPD or simply diagram) is the top-level object in BPMN, but its scope is not precisely defined. The Overview says:
The structural elements of BPMN allow the viewer to be able to easily differentiate between sections of a BPMN Diagram. There are three basic types of sub-models within an end-to-end BPMN model: Processes... Choreographies... [and] Collaborations...This says a single "diagram" can contain "sections" each defining one (or more?) model types ("sub-models"), those types being Process models, Choreography models, and Collaboration models. Is this true? Normally a single diagram contains only one of those model types. The spec needs to clarify the scope of a single BPD.
The term process is defined a bit more clearly than in BPMN 1.x. It is aligned with process model, and it is equivalent to an orchestration of activities, i.e. a network of control flows (sequence flows) from start event (instantiation) to one or more end events. Well, sort of... The spec distinguishes two types of processes, private and abstract. A private process shows the orchestration in detail, and sequence flow there does represent the flow of control. An abstract process provides a more opaque view of the process, since its main purpose is to serve as source and target of message flow interactions between the private process and external entities. The Overview suggests that abstract processes contain only activities and events that send and receive messages, but later on the spec acknowledges the more common representation in which no activities and events are drawn, just message flows to the process boundary.
The notational representation of a process, either private or abstract, is a rectangular box called a pool. But for some reason, the spec does not clearly state that a pool represents a process. I wish that it would, because this is something that has led modelers astray since the dawn of BPMN 1.0. Instead it says a pool represents a participant. Other than to say it means a "role or business entity," the term participant is not defined. It is not the same as the term performer, which means the resource (which also could be described as a role or business entity) that performs a process activity. A participant role is meant in the SOA sense of "requester" vs "provider" of the process.
The distinction between participant and performer is important, because some modelers incorrectly represent activity performers as separate pools, rather than as lanes within a single pool. This negates the idea of a process, i.e. an orchestration, in which some centralized control or knowledge of the end-to-end process flow resides. There is an alternative style of process definition, called choreography, in which no such centralized control or knowledge exists, where each activity independently controls what happens next. In BPMN 1.x, the term choreography was used to indicate the pattern of message flows between pools, but in the new proposal, choreography signifies a new type of model in which nodes represent message exchanges between participants. I don't understand the notation yet, because it also includes what look like sequence flows, representing... well I don't exactly know.
The pattern of message exchanges between pools is now called a collaboration process, or global process. Another quibble: the spec equates an abstract process to a public process. In its more common usage, like ebXML or RosettaNet, a public process would be a collaboration or global process linking two or more abstract processes.
The notation for a pool does not distinguish between private and abstract processes. An empty ("black box") pool is obviously abstract, but a non-empty one could represent either a private or abstract process ("gray box pool"), unless all of the nodes are clearly identified as send/receive tasks and message events. This is a problem because in a private process ("white box pool") sequence flow represents control flow, but in a gray box it does not; it just represents ordering in time. My preference would be to get rid of gray box pools entirely and require abstract processes to be represented as empty black box pools, but I doubt this will happen. Failing that, the pool notation should distinguish between private and gray box pools, so it is unambiguous whether sequence flow means control flow or not.
Also, the pool notation needs to be clearly differentiated from lane, which it currently is not. Because a default main pool is implied even without drawing the pool shape, you can have diagrams with lanes but no pool. It is important that these are identifiable from the diagram as lanes and not pools.
When the draft spec mentions a diagram containing multiple pools communicating via message flows, it is usually framed in the context of B2B. While BPMN may someday be used to describe B2B processes, multi-pool diagrams are commonly used today for internal processes, in which both the process requester and service providers (sometimes including business systems) are represented as external black box pools. This is far and away the most frequent use of message flow in BPMN, but it is not even acknowledged by the spec.
Real-world BPMN diagrams also may contain multiple white box pools. Here the notion of participant breaks down completely: Both pools represent the same business entity, and the role (e.g., requester or provider) may be ambiguous, or change depending on the state of the process. The reason the pools are separate is that they represent distinct orchestrations, with independent lifetimes, not distinct participants. This reinforces the fact that pools represent processes, not participants, and the BPMN has to explain this better.
What gets this all mixed up is the fact that a black box pool is often rightfully labeled with the name of a business entity rather than the name of a process, since there is no "process" specified. That should not be the case with white box pools. My preference would be for BPMN to make a bigger distinction between private and abstract processes, giving them different notations (e.g. box outline), labeling conventions (process name vs business entity name), message flow attachment rules (to flow object vs to pool boundary)... and let's get rid of gray box pools entirely, except in true public processes.
One more important concept needs clearer explanation: subprocess. A subprocess in BPMN is simultaneously an activity and a process, and that gives the notation an inherently hierarchical structure. The spec describes two alternative ways to represent the same subprocess: collapsed and expanded inline. Inline expansion encloses the subprocess flow in an enlarged activity shape in the parent-level flow. But there is actually a third way, common in many tools, that takes advantage of BPMN's inherent hierarchy, which is to represent the expansion on a separate child-level page of the same BPD, typically hyperlinked to the parent level.
Such a hierarchy of process levels is, I find, the best way to represent complex real-world processes. In fact, inline expansion has much more limited value. But BPMN does not acknowledge this and provides no view attribute for distinguishing these two expanded subprocess representations (as does XPDL 2.1, for example).
The distinction between view representations is most definitely NOT the same as the distinction between reusable subprocess (renamed Call Activity in the new spec) and embedded subprocess. That distinction was vague in BPMN 1.x, but the new proposal adds little value here, and continues BPMN 1.x's distinction between the way process variables are passed to the subprocess at runtime. (In embedded, the subprocess has access implicitly via the process instance; in reusable/call, the data must be explicitly passed.) But such implementation details should not be foremost in a process modeling standard. A better distinction should be based on where the subprocess flow model is defined: embedded should mean defined in the same BPD, and reusable/call should mean defined in a different BPD.
That brings us full circle - what is the scope of a single diagram? This needs to be cleaned up, because it is the key to whether a subprocess is embedded or call activity.