The Limits of BPMN

A couple weeks ago I had the pleasure of presenting at the Social BPM Summer School program in Como, Italy, hosted by Marco Brambilla and colleagues from the Politecnico di Milano. My topic was extending BPMN to accommodate Social BPM. It was motivated by recent papers by Marco and others on this subject that, to my thinking, were inconsistent with features of BPMN that must be respected in any extension. And on my return last week I found this post by Keith Swenson on why BPMN is incompatible with adaptive case management - a sentiment I partly agree with, although not for the reasons Keith cites. BPMN is a very flexible language - totally manual processes and fully automated straight-through processes share it comfortably - but it does have limits, e.g., behaviors that it cannot express. Still, it is surprising to me how little has been written about what those limits are, what "BPMN-ness" really means. Extending BPMN (as Marco and others in the social BPM community propose) requires fitting new behaviors into the BPMN framework, while abandoning it (as Keith and others in the ACM community propose) has no such constraints.

The most fundamental concepts in BPMN are activity and process. An activity is an action, a bit of "work performed". We label activities verb-object, to focus on the action. But it is not just any action. It is an action performed repeatedly in the course of business. Each instance of the activity has a well-defined start and end. It is specifically NOT an action performed continuously, without a clear notion of an instance. BPM architecture frequently cites "activities" that fail this test. They use verbs like Manage, Monitor, or Maintain, and are not what BPMN means by activities.

A process is a sequence of activities in pursuit of some goal. Like activity, a BPMN process is also performed repeatedly on separate instances, not continuously. A basic principle of BPMN is that the instance of each activity in a process must correspond one-to-one with the process instance. For example, a process in which the instance is an order cannot directly contain a billing activity performed once a month. The instances do not align. This is one reason why a value chain is NOT a BPMN process.

A process definition, also called a process model, is a map of all possible activity sequences leading from some common initial state of the instance to some defined end state, along with flow control nodes called gateways and events that control the branching. Every instance is constrained to follow some path described by the process model. New ad-hoc activities may not be added to the model once the instance has started, and the instance may not magically jump from one activity to another if the model does not describe that flow path. Moreover, at the conclusion of any activity in a running instance, if provided with all of the information either received or developed in the instance up to that point, the process model "knows" with absolute certainty the next activity. In a BPMS, this centralized knowledge is physically realized in a process engine that not only knows the next step but actually directs the instance there. BPMN's term for this explicit and centralized process logic is orchestration. A BPMN process is, by definition, an orchestration. This the main reason why BPMN, by itself, is unsuited for ACM.

Given this more precise definition of a BPMN process, it should not be surprising that a number of actions and actors that affect a process lie outside of it. BPMN's term for each of these entities, including the process itself, is participant (often confused with performer, the actor that performs an activity inside the process, but not the same thing at all). The pool shape, the graphical representation of a participant, serves as a container for a BPMN process; empty ("black-box") pools represent the external entities that interact with the process. As an orchestration, a process implies a domain of control. Certainly, actors external to that domain of control lie outside the process. But also activities that do not align 1:1 with the process instance lie outside, as well.

BPMN describes two primary ways an external entity communicates with the process: messaging and shared data.

A message is information pushed by the external entity to a specific process or to a specific instance of that process. A message flow connector in the diagram links the sender and receiver of the message, which may only be either an activity, a Message event, or a black-box pool. When a message is received by a user task, the model does not reveal the actions that will be or might be taken in response. In contrast, a Message event in the process represents a specific handler for the message, i.e. how the process responds upon receiving it. Actually, the event shape really just indicates initiation of the handler, which is defined by the flow of actions out of the event. BPMN provides a limited number of ways to respond to a message: start a new process instance, resume a paused instance, interrupt a running activity and run the handler flow, or don't interrupt anything but initiate the handler flow in parallel. That covers a lot of possibilities, but triggering of the handler flow is always assumed to be unconditional and immediate. In other words, the process can't decide to ignore certain messages or take its sweet time in initiating the handler flow.

A data store represents persisted information, meaning stored in a file, database, or application system, accessible to both a process activity and to external entities. External entities can pass information to the process by updating a data store, which the process activity queries when it needs to. In the diagram this is represented by a data association connector from the external pool to the data store and another one from the data store to the activity. With shared data, a process activity pulls the information when it is ready to do so.

While rarely used, BPMN provides two additional information-passing mechanisms. Neither provides a graphical connector like message flow or data association, and thus the interaction is less clearly revealed in the diagram.

A signal, together with its corresponding Signal event, actually combines two distinct behaviors in one element (a bug, I would say, in the spec). The main one is the publish-subscribe analogue of a message. Unlike a message, which is addressed to a particular process or process instance, a signal is broadcast to any listener. It represents loose coupling, since the sender of a signal need not be aware of who (what processes or events) might be listening for it. The other signal behavior is, like message, addressed to a particular process instance, but removes message's constraint that the sender and receiver may not be in the same process.

A Conditional event represents something like a database trigger inside the process. The event continuously monitors some data condition, and when that condition becomes true triggers the handler. It is analogous to a data store and incoming data association, except that instead of a discrete active query it represents a passive continuous listener.

An important thing to note is that except for a data store query or message received by a user task, all of these mechanisms rely on BPMN events. Event-triggered behaviors are limited to those described previously for a message: start a new process instance, resume a paused instance, abort an activity and redirect to the handler, or initiate the handler on a parallel thread without aborting the running activity. That's it. The particular behavior is indicated in the diagram by the event border style and its placement in the diagram. In all of these cases, triggering the handler is definitive and immediate upon activation of the trigger. A user may not get in the middle of it, maybe decide not to execute the handler. This is a limitation of BPMN that affects social BPM and ACM.

To those of you who know BPMN already, the preceding recitation of its features might seem a strange way to talk about it, but it serves as a springboard for discussing how and why it might be extended to meet the needs of social BPM and - dare I even imagine it? - ACM. Stay tuned for that.