Visualizing Responsive Processes
Blog: BPMS Watch - Bruce Silver
Merging BPMN and CMMN standards in OMG is, for the moment at least, a dead issue. The question remains how best to visually represent logic formerly known as case management, which I will henceforth refer to as responsive processes. Responsive processes are driven forward by events (including ad-hoc user action) and conditions, rather than by sequence flow. In a responsive process, an activity is enabled to start when its preconditions are satisfied.
I believe that a BPMN 2.0 process engine that can execute event subprocesses, including those with Escalation and Conditional triggers, can implement many if not most features of a responsive process, as IBM’s BPM 8.5.5 amply demonstrates. To be more precise, it should be able to implement a responsive process in which all activities, including those that CMMN calls discretionary, are specified at design time. CMMN goes beyond this, however, in allowing the design, or “plan,” to be modified arbitrarily at runtime on an instance by instance basis. We cannot assume that a BPMN 2.0 engine can handle this, but at this point I am not sure how critical this feature is. It may turn out to be critical, but for now let’s call it responsive-plus.
Whether or not you agree with me that BPMN as a “language” can handle responsive processes, you probably agree that as a notation it fails to visually communicate the responsive process logic. IBM’s Case Designer is a little better at that, and CMMN is a little better still. But I think all of these fall well short of the mark. So I have been thinking about what kind of notation would achieve that goal.
As I have said previously, responsive process/case logic is inherently much more difficult to represent in a printed diagram than flowchart-based logic. Scoped event logic tends toward some kind of state diagram, but I think it’s safe to say that business users (and most business analysts) would have a hard time with state diagrams and find them unacceptable. There is one form of diagram that could possibly fit the bill if sufficiently enhanced, and that is a Gantt chart, such as you might find in Microsoft Project. In a Gantt chart, activities are enabled by preconditions called dependencies. A Gantt’s chart has a very primitive notion of dependency, which is limited to completion (or possibly start) of another activity. It has no notion of end state, for example – an activity completing successfully versus unsuccessfully.
A Gantt chart takes the form of a table – an indented list of activities, each row specifying the activity’s start and end (both anticipated and actual). The indents (usually reinforced by a hierarchical numbering scheme) provide aggregation of activities for summary reporting, but if we give these summary activities their own entry and exit conditions they become subprocesses, or what CMMN calls stages. Anticipated start – actually, enablement – is based on the dependency logic, and actual start is based on when work actually starts. (CMMN has this distinction in the runtime state model, but BPMN unfortunately does not.) Each row in the Gantt chart also contributes a bar in a calendar view of the table. A vertical line slicing through the calendar view separates past from future. Things to the left of the line are actuals, things to the right are anticipated.
Gantt charts provide something that most BPM users instinctively desire – an estimate of when the process will complete, based on its current state. (BPM Suites are happy to provide this in the runtime if you purchase the predictive analytics module, but Gantt makes it part of the model itself.) BPMN has no standard property to record the mean activity duration, although many modeling tools provide this to support simulation. Gantt charts require that property.
Gantt charts also have the responsive-plus feature of being modifiable at runtime, including addition of new activities and dependencies. That sounds great! But they cheat, because a normal Gantt chart describes only a single instance of the process. It does not pretend to describe the general case, including alternative paths to the end state. In fact, the whole idea of exception end states – for the process as a whole or for individual activities – is absent.
Economy and expressiveness are key to visually communicating responsive process logic. We want to pack the most semantic value into the simplest diagram possible. The fewer distinct shapes and icons the better. Connectors are extremely valuable in communicating the dependency logic. Not all Gantt charts have them, but MS Project uses them quite effectively. An arrow into the left end of a bar indicates a precondition; an arrow into the right end of a bar indicates a completion condition. In MS Project, the precondition is always either completion (arrow out of the right end) or actual start (arrow out of the left end) of an activity. We’d like to extend this to event triggers and data conditions as well. CMMN supports 4 basic event types: state change in an activity (such as completion), state change in an information item, timer (relative to some other selected trigger), and ad-hoc user action. I think that’s about right, but we probably need to add BPMN Message, Error, and possibly Signal, and maybe distinguish interrupting and non-interrupting. As with sequence flows in BPMN, the label of a connector can be used to suggest the data condition. (The full data condition could be stuffed into the spreadsheet part of the Gantt, to the left of the chart.) For example, we should use line styles on the connectors and border styles on events to denote different triggering semantics. If done right, we could eliminate CMMN’s diamond sentry shapes, which add graphical complexity but little incremental semantic value.
Like CMMN, our responsive process model needs an information model that can be referenced in both data conditions and in state change events. BPMN 2.0 doesn’t really have this, and without it, Conditional events are kind of useless because the only data visible to them are process variables and properties. The information model should include both data and documents, so changes in content value, metadata, and lifecycle state can all be recognized as events. CMMN already has this, but it does not reveal the logic clearly in the printed diagram.
In a followup post, I will put up some examples of what this could look like.