One of the persistent criticisms of BPM is that the process definitions are too rigid to accommodate the realities of modern business. This can deter organizations from properly evaluating how BPM can help them. The reality is that most BPM tools offer a range of options for building highly flexible and adaptable processes. In this article, we will briefly explore some of these.
Researchers have proposed various approaches to this which can generally be grouped into two categories, Late Modeling and Late Binding. With Late Modeling, some portions of the process are not specified until runtime, allowing each instance to potentially be different. InConcert supported this from the mid 90’s but hasn’t been sold for several years. It was a powerful, but challenging capability that was widely used by their customers. We know of no current commercial product which supports this to the same extent. With Late Binding, sub-process calls are not statically defined, but are expressions of some sort. Several current products, including IBM Business Process Manager support this. This allows variability at a fixed number of points in the process. Perhaps one reason this is not more widely supported is that it is outside of the BPMN specification. However, there is another approach which is available in most current products and fully within the BPMN specification.
Before proposing a solution, let’s dig a little deeper into the reasons flexibility is desirable in business process models. Reichart and Weber in a recent book Enabling Flexibility in Process-Aware Information Systems, provide an extensive analysis of different forms of flexibility and business motivations for each. They define four categories of flexibility. We will look quickly at each.
Variability, where different process instances have relatively minor and predictable variations. In the simplest cases, variability is handled with gateways and including all variants in a single process. This becomes unmanageable as the number of variants increases. Late binding of sub-process specifications can support more variability by substituting alternate implementations of the variable portions of the process while maintain a simpler overall process structure.
Looseness where the goal is known, but the course of action to achieve it cannot be predicted. While the required sequence of steps cannot be known in advance, the set of possible actions probably is known. A library of sub-processes can be made available, with the selection of the next one either by a person or some rules logic. Potentially each process instance follows a unique path, but all are assembled from the same set of components.
Adaptation where active process instances need to respond to events occurring during their lifecycle. To handle variability, we used late binding of sub-processes at known locations. To support adaptation, we recommend event driven triggering of sub-processes combined with late binding. Each process instance responds to the actual events which affect it.
Evolution where the business process changes, and active processes must be updated to the new process. Support of evolution is most important in longer running processes. Since the new processes were not known when some instances started, they could not have planned for them specifically, but if the process definition consists of a sequence of deferred sub-processes, new versions can be substituted. As a practical matter, there will be limits on compatibility of new versions with the interfaces of old versions, but it is possible to deploy new process definitions into running process.
All of these scenarios can be implemented within the BPMN specification using capabilities found in nearly all current BPM products. Intermediate Send Message Events, followed by Intermediate Receive Message Events can replace Call Process activities. The message is received by a Start Message Event in a process with a corresponding send message end event. The behavior is similar to a sub-process call, but is more flexible. The invoked sub-process can be specified by the message content and new versions of the sub-process can be deployed and immediately invoked from any running instance of the main process. The future behavior of running processes can be changed without directly modifying those processes. This is equivalent to late binding of sub-process calls.
We have successfully used this approach to solve most of the scenarios described above. We will provide some simple examples to illustrate some of these.
This process fragment:
Combined with this process:
Behaves similarly to a BPMN Call Activity. Execution is transferred to the second process and returned to the original when it completes. However, it also offers options not available with a standard Call Activity. The most obvious and useful is that message correlation allows runtime selection from multiple versions of the “sub-process”. This potentially includes new versions which were defined while the top level process was running. This simple pattern satisfies most requirements for Variability and Evolution as described above.
To achieve Looseness, we can expand the pattern slightly by putting the invocation in a loop with a user or system step to determine the next action.
These two patterns, along with the Event Sub-Process can provide the flexibility required in many business situations. That doesn’t imply that we should always use these instead of the standard sub-process mechanisms. To achieve flexibility, we are using much looser coupling between process components. This can make monitoring, reporting and failure analysis significantly more complicated. You should always balance the benefits of flexibility against its costs. There are many situations where use of these modeling techniques allows solution of problems which statically defined processes cannot. Adding these to your set of modeling tools will significantly expand the range of business applications where you will be able to use BPM. We encourage you to experiment with these to evaluate how they can help you better accommodate your organization’s needs.
