[Posted 29 Oct 2007 on BPMInstitute.org]
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.
Multiple Start
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. Notes added after original column:
1. BPMN 1.1 does provide a solution for Multiple Start. It uses the event gateway to represent the various starting triggers. An event gateway may be used at the beginning of a process either with no incoming sequence flow (i.e. as implied start node for the process), or directly following a None start event. In the latter case, the spec says the event gateway "bootstraps" the process start, i.e. the event gateway is really the thing that kicks it off. It's not really consistent with the rest of the notation, but no matter. This does the trick. The spec is ambiguous about the kind of events allowed: Message for sure, Timer is explicitly disallowed, but what about Error, or Signal? Not clear.
2. There is a way to create non-aborting intermediate events in BPMN today. The problem is cumbersome notation and unfamiliarity to business users. Well, you can try to teach it, anyway. Here's how it works. Any activity A with attached intermediate event E can be redrawn to exhibit equivalent triggered exception flow behavior without aborting A, as follows: Create subprocess A' with a start event going in parallel to activity A followed by Terminate, and to event E followed by a normal End event.
Here E aborts A.
Here E triggers the exception task but does not abort A. Exception task (it could be a subprocess) immediately after E. However, if not complete it will be aborted when A completes, which is the problem with non-aborting events done this way. So Exception task should be something very short, like sending a notification. Any exception activities that should not be aborted when A completes go into Next exception task, which cannot start until A completes.
3. Looking back at my Semi Structured diagram above, I can't figure out why I used a Complex (discriminator) gateway. Since the conditional event and the normal flow out of A are always exclusive alternatives, an exclusive merge - equivalent to no gateway at all! - seems to be all you need going into B. Am I missing something?