The Business Process Modeling Notation (BPMN) standard from OMG has a lot to recommend it, but it’s not perfect. Since late February of this year, I’ve been doing BPMN training, and through that I have come to appreciate the subtle power of the notation and how it maps – or sometimes not – to the way real business analysts and architects want to model their processes. Some of BPMN’s problems, such as the lack of a standard XML storage and interchange format or a specification for minimal compliance, are so basic they make you wonder how it has succeeded in becoming the one important standard in BPM.
These issues are well known, and addressing them should be BPMN’s top priority, but they are undoubtedly hard and mired in vendor politics. While OMG dithers on such big picture issues, there are also a few of improvements in the notation that would fill important semantic gaps in the meantime. Here is my wish list.
You often see diagrams that contain something like the following:
The idea is the process can be started in either of two ways, either manually from a user’s desktop, or automatically, such as through a web service. The initial activity may differ based on the manner of starting, but downstream the process is the same either way. Now, is this diagram legal in BPMN? The spec is vague on this point. Technically, a None start (the one without an icon, labeled “manual”) means the trigger is unspecified, while the Message start refers to a particular triggering signal. If you label the diagram as I have here, most modelers would understand the intent, but simulation engines or executable designs based on the model would not.
This is a very common pattern, and BPMN should have a way to model it less ambiguously. One possibility would be to adapt the event gateway to start events. In a BPMN event gateway, a process pauses to wait for one of N specified events, and the first one to occur triggers resumption of processing and determines the path taken out of the gateway. If another of the N events occurs subsequently, it is ignored. In BPEL, the Pick construct lets you do exactly that, either waiting in the middle of a process or triggering the start of a new process, but the BPMN event gateway can’t start a process. BPMN would benefit by adding similar triggered start behavior. You might argue that the diagram above already does this, but it’s ambiguous, and there is nothing that explicitly ignores the second event to occur.
Non-Aborting Intermediate Events
One of the most useful constructs in BPMN is the attached intermediate event. If a timer, message (signal from outside the process), error (signal from inside the process), or signal (from either inside or outside) event is drawn attached to the boundary of a process task or subprocess, the task or subprocess immediately aborts, and processing continues on the exception flow out of the event. Attached intermediate events can be used to handle timeouts, errors, or signals from an external party, such as a customer canceling an order. If the event occurs either before the activity it is attached to begins, or after it ends, it is ignored. Thus modelers can add subprocesses to define precisely the scope of any possible interrupting event. This is amazingly helpful in describing exception handling from a business perspective.
The only problem is sometimes you want to trigger some parallel processing without aborting the activity the event is attached to. For example, maybe after a timeout or external event you want to send a notification but not interrupt the waiting activity. Some tool vendors (e.g., TIBCO) allow this, but it is not allowed by the BPMN spec and the non-interrupting behavior is not visible in the diagram. BPMN should provide a variant of the intermediate event to indicate non-interruption of the activity if the event occurs.
A second variant is especially important in insurance, where you may want to be able to suspend (“pend”) the instance, allowing it to be resumed later from the point of suspension. As BPMN is now, you would technically restart the activity rather than resuming it.
Semi-Structured Behavior
In BPMN, any sequence flow (solid arrow connector) leading from activity A to activity B means, by definition, start (or enable) activity B when activity A ends. But it’s amazing how often users want to give the user performing activity A the power to start activity B, if he or she so chooses, from the middle of activity A, not after it ends. So B is concurrent with A, within the same process. Let’s say that both A and B are part of subprocess X, so that X is not done until both A and B are complete.
BPMN has a construct called an ad hoc subprocess. You could use it, for instance, with lots of annotations, to describe the above behavior, but it is not as useful as it might be. A BPMN ad hoc subprocess, shown with a tilde icon, is a container for activities that can be completed in any order, and do not all need to be completed. It cannot be simulated or used to generate an executable design, so it really violates the spirit of BPMN as a business view of process behavior that can be analyzed and implemented from the model.
One way this might be implemented is with the non-aborting intermediate event suggested earlier. Such an event attached to A could start B while A continues on. Modelers want to do this, but today BPMN does not allow it. In the diagram here, assume the event attached to A (shown here as the conditional, formerly called rule, event) is of the proposed non-aborting variety. In BPMN 1.1, the complex merge gateway (asterisk inside) means select the first path to arrive and ignore any others – the discriminator pattern. So B will be enabled either from the middle of A (via the conditional event) or when A is done, but not both times. Modeling semi-structured behavior in this way works with simulation engines (that support event probabilities) and can generate implementation, which is what we want.
Standard Merge
My last wish list item isn’t filling a gap in BPMN, but simply making it more usable. Multiple paths in a flow are combined into one using a merge gateway. The symbol inside the gateway – none or X for an exclusive merge, + for a parallel merge, and O for an inclusive merge – all actually denote the same behavior, but the spec requires that the correct symbol be used depending on whether the inputs are known to be exclusive alternatives, known to be enabled parallel paths, or parallel paths not all of which may be enabled.
In other words, the modeler has to be smart because the BPMN merge symbol is stupid – stupider, in fact, than real process engines, which can generally figure out which inputs to the merge are enabled and knows to wait for all of them before completing the merge. Only exotic patterns, such as the discriminator mentioned earlier, differ from what I would call standard merge behavior. So I propose that a merge gateway with no symbol inside be redefined from its current meaning of exclusive merge to standard merge, which would then replace exclusive merge, inclusive merge, and parallel join gateways. My students would thank OMG as well.
