BPMN and Case Management

In a previous post I describe the basic differences between case management and conventional BPM.   This post concerns the limitations of BPMN 2.0 for modeling case management, and proposes some possible extensions.

It is important to distinguish the semi-structured behavior of case management from completely ad-hoc processing.  By semi-structured I mean there is a case model, a design-time artifact that defines normal or typical case logic, such as the activities and information “required” to complete a case (or a phase in the case).  Case management inherently allows ad-hoc behavior in that the behavior of a case instance (let’s just call that the case) can deviate at runtime from the case model.  For example, the collection of activities involved in completing the case may not agree with those described in the case model. 

The case model provides the structure necessary for documenting, understanding, and analyzing the processing and associated information objects involved.  It is possible to conceive of case management without such a case model, but that is not particularly interesting from a modeling perspective.  The issue is how to extend BPMN to serve as a useful design-time notation for the case model.  This should not imply that the user’s runtime view of the case should strictly adhere to such notation or even use it at all.

As with regular BPMN, I would like to see the case model express as much of the “flow” logic as possible in a diagram intelligible to business.  Hiding the logic in technical details invisible in the diagram should be minimized.  At the same time, economy in the notation is vital, as page real estate is always scarce.  I tend to favor a hierarchical modeling style, in which a top-level diagram provides a global view, with drilldown to detail in other hyperlinked views.

BPMN is lacking a number of concepts needed for modeling a case.

1.  A  case is a collection of independent activities – both tasks and processes – not a single process.  Attempting to define a case as a type of BPMN process is doomed to fail.  On the other hand, simply modeling a case as a collection of BPMN process models does not capture the case as a whole as a single entity, which is crucial.  BPMN has the notion of a collaboration as a collection of processes interacting via message flows.  A case is a similar collection, but linked by different means.
2. The case model describes a set of activities that must be performed and a set of activities that may be performed.  (I use the term activity in the BPMN sense, either a task or subprocess.)  The optional activities provide a menu of predefined tasks and processes that users can add to the case at runtime. In addition, ad-hoc activities (outside of the case model) may be defined at runtime and added to the case .  In contrast, BPMN describes only the activities that are performed at various points in the flow.
3. Process modeling in BPMN is based on orchestration, i.e., control flow described using sequence flows in the notation: When activity A completes, start activity B.  In contrast, case activities interact through events.  Extensions to BPMN’s event model could make it more useful for case management.
4. Adding an activity to a case is not the same as starting it.  BPMN sequence flow means start the activity.  BPMN lacks the ability to add an activity to a case (or delete or update it).
5. Documents (or more generally, information objects) are central to case management.  A document has a lifetime independent of a case and could be part of more than one case.  Thus documents should be stored and managed externally to the case instance and referenced by it.   In the case model, documents of a particular type may be either required or optional components of a case, just like activities.  The optional document types provide a menu of predefined types that can be added to the case at runtime.  (And you could have in addition pure ad-hoc documents, external to the case model, defined at runtime.) Document state changes (created, updated, approved, deleted, etc) are events that commonly trigger case processing logic.  BPMN data object is defined inside a process (or activity); it is like a variable.  BPMN data store is much closer to document in case management, but has no notion of required vs optional, state change events, etc.   

We should use to the extent possible existing BPMN 2.0 constructs.  Useful ones include:

1. Activity, either task or subprocess.
2. Global activity (task or reusable subprocess).  Defined once in the case model (or imported definition) and called in multiple places.
3. Boundary event, interrupting or non-interrupting, meaning if this event occurs while the activity is running, trigger the exception flow.
4. Escalation boundary event.  On a User task this means “user action,” i.e. decision by task performer, what we sometimes call ad-hoc.
5. Catching event in sequence flow, meaning wait for this event, then continue when it occurs; useful for synchronizing case activities (and external events).
6. Throwing event, to communicate and synchronize with other case activities (and external entities).
7. Ad-hoc subprocess.  Here is how BPMN 2.0 spec defines it:

An Ad-Hoc Sub-Process is a specialized type of Sub-Process that is a group of Activities that have no required sequence relationships. A set of activities can be defined for the Process, but the sequence and number of performances for the Activities is determined by the performers of the Activities… Activities within the Process are generally disconnected from each other. During execution of the Process,any one or more of the Activities may be active and they may be performed multiple times. The performers determine when Activities will start, what the next Activity will be, and so on…. [The completionCondition] Expression defines the conditions when the Process will end. When the Expression is evaluated to True, the Process will be terminated.

The case model needs to describe more logic than simply the completion condition, and provide a notation for it.

In conclusion, I think we need the following elements in the case modeling notation:

1. A container representing the case, holding activities and documents.
2. A child container for subcase, representing a phase or milestone within the case.  I’m not sure this is needed.  Here is a possible rationale.  Cases can be very long-lived.  Sometimes they never end, just suspended and archived, and could be reopened at some point in the future.  Each subcase may have a different set of required and optional activities and documents (but a single activity or document could be referenced by multiple subcases).
3. Activities contained in case or subcase, either task or subprocess.  Use solid boundary for required (in case model, can be overridden at runtime) and dashed boundary for optional.
4. Documents contained in case or subcase.  Use solid boundary for required (in case model, can be overridden at runtime) and dashed boundary for optional.
5. Implied events.  State changes on case activities and documents (or a standard enumerated list of them: onCreate, onUpdate, etc.) implicitly generate events, i.e. the “throw” does not need to be shown in the diagram.
6. Boundary events on case activities , consistent as much as possible with BPMN standard.
   • User action (Escalation event)
   • Exception (Error event)
   • Deadline (Timer event)
   • Case state change (Conditional event)
   • External event (Message or Signal event; Signal only if broadcast pub-sub type, otherwise use Mesage)
   • Document state change (new type).  Fuzzy line between this and case state event.  This is meant to mean state changes in the doc repository, including metadata.  If a document is approved, is that a document state change (in doc repository) or a case state change (i.e. “approved” for this case).
7. Exception flow action conventions.  Possibly shown as end events?
   • Activity actions (add, update) – relate to activities defined in the case model
     • Add ad-hoc activity (use tilde)
   • Document actions (add, update)
     • Add ad-hoc document (use tilde)
   • Complete this activity in [state]
   • Change case/subcase state to [state]
8. Activity start conventions.  I am struggling with this one a little.  Any case activity by default can be manually started at any time.  (Here “case activity” means top-level activity in a case or subcase container; activity inside a case subprocess activity is subject to normal BPMN rules about process activities.)  In addition, I would like to show automated start in a convenient way.  One possibility is something like BPMN event subprocess convention, i.e. use event type icon in upper left corner to indicate the triggering event, or multiple event if more than one possible trigger.  These events are one half of a throw-catch pair, with matching throw modeled as exception flow end event (see above) or implicit case state event (not drawn).  You would have to drill into the activity to see more detail.  I need to think more about this one.

Scenarios and example diagrams to follow.

Tags: case management, case management notation