Flexible BPM: From Case Management to Active Project Execution

May 22, 2009

Earlier this year, Henk De Man of Cordys published two papers on case management at bptrends, one about different modeling approaches, and another about the approach taken by Cordys. This contribution has also been submitted to the OMG as an answer to their dynamic business activity modeling RFI. I recommend these papers to anyone interested in flexible BPMS, and applaud the company for making this information public. These descriptions represent the best I have seen from any vendor in this field.

Our active knowledge architecture approach is well aligned with this proposal from Cordys, though our emphasis is the complex creative and artistic human-interaction processes that are typically organized in projects. Projects are larger and more complex than cases, requiring multi-dimensional modeling and continuous elaboration of project plans as instance level process models. This post explores similarities between case management and process-oriented knowledge architectures, and proposes some additional use cases and solutions that we believe would make case management simpler and more useful for a wider range of dynamic business activities. Rather than defining new languages for different kinds of processes, we believe that a common process modeling core standard should support dialects (or profiles) for different modeling scenarios, such as “BPMN for standard BPMS”, “case management”, and “project planning and execution”.


Since 1997, I have designed and implemented two prototype process execution systems

  • Workware, a model-driven project portal, which combined workflow and groupware to support structured and emergent processes through interactive process execution,
  • Configurable Visual Workplaces (CVW), where model-driven product design was supported by interactive task pattern execution, combined with metamodeling for extensible data management, view configuration, and role-specific workplaces.

Both of these prototypes were applied by users in trial projects, and CVW was also used by method engineers to develop operational support for a range of collaborative design processes. CVW dealt with processes on a slightly lower level than Workware, but both systems followed the same modeling and execution principles. Prior to this research, my first industry position was as developer of a case file handling system for government institutions, an area that was subject to extensive standardization on the national level during the late 80s and early 90s. I even wrote my master’s thesis on performance analysis of case management, so this topic has been on my radar for some time.

Similarities between Case Management and Active Project Execution

Cordys case management is similar to our interactive process execution in a number of ways:

  • Processes are managed as instance models.
  • The process models evolve during execution, (though it is unclear to me to what extent Cordys models are designed for evolution, and e.g. whether completely unplanned, emergent activities may be added dynamically).
  • Execution of semi-structured processes is determined partially by users and partially by the process engine.
  • Execution rules utilize the hierarchical composition clusters of tasks, e.g. for termination.
  • Operational and declarative concepts are combined, e.g. “manual” and “automatic” follow-ups for operational execution, combined with “before” constraints and declarative rules.
  • State and activity-based semantics are combined, e.g. for scoping of rules.
  • Case data influences processes through business rules, driven by events.
  • Case data is primarily property values.
  • Case data access rules can be controlled by the process state.
  • User interfaces are dynamically enabled according to state and role.
  • Models are executed by an underlying state machine.
  • Continuous process improvement is facilitated by harvesting case instance histories.
  • During execution, tasks are grouped into applicable and not applicable. Some applicable tasks are released to be performed automatically, while others are available to be performed when the user chooses (planned), or can be instantiated into the case manually (unplanned).
  • Filters are used to add or remove tasks from the applicable set. This corresponds to cancellation inheritance, which is the preferred technique for active knowledge architectures. A similar approach based on filtering lenses was chosen for awareness mediation in Workware, and user-defined to-do-lists were controlled by a query, an add-list, and a remove-list.

Extensions Needed for Active Project Execution

Despite the many similarities between case management and our approach, we see a need for some adjustments and extensions. Projects are unique business processes, which contains both islands of automation and pockets of creativity. The definition of project processes, i.e. planning, occurs throughout project execution. There can be no separation of build time and runtime. Engineering projects can be large, complex, and long-lived. We believe they are best managed by a project knowledge architecture model, which integrates processes with models of organizational structures and roles, products and deliverables, and underlying system support. In order to support dynamic business activity modeling in general, we think the case modeling RFP should be extended with these use cases:

  • Process models as templates for project planning, as incomplete models, maybe even empty ones at the start, which are mostly being defined while they are being executed.
  • Populating a process model from a library of template activities, representing different methods and ways of working. Semi-automatic support for connecting the activity from the library into the local context is needed, e.g. connecting interfaces, roles, data parameters, and maybe even placeholders for subtasks in template patterns.
  • Immediate execution of case and process models of any kind, with any degree of completeness, should be supported for prototyping, simulation and end user comprehension.
  • Complex case or project data structures should be used to derive dependencies between activities that need to be coordinated. For instance, if oil pump X is to be connected to pipe Y, there will be dependencies between the activities for specifying, designing, 3D-modeling and testing X and Y, which need to be coordinated. Product dependencies are often more important than process dependencies for coordinating complex project cases. A multi-dimensional aspect-oriented approach should be taken to process execution, where e.g. the set of applicable activities in a given context is composed of some activities from the process context and others from the product or artifact context, filtered according to authority assigned in the organizational context. A one-eyed process-only approach will not suffice.
  • In general, some common usage patterns for the interplay of artifact and activity oriented models should be defined. We have for instance seen that the relationships in an object model for product artifacts, typically end up being represented as activities in the process models, while relationships in the process model often reflect artifact states. A thorough product&process modeling methodology should be able to move effortlessly between these perspectives.
  • Case file data structures can be complex and multi-facetted, to support e.g. different views for different roles and stakeholders. A single hierarchy of cases, folders and items will not suffice, when the business people organize data according to business cases, the systems engineering people according to functions and systems, the geometric layout modelers according to location, the project planners according to the time axis, the procurement responsible according to suppliers and lead time, the manufacturing people according to material take-off and plant machinery needed, etc. The case information should be conceptualized and modeled as knowledge – according to its use by the different people participating in the case, rather than simply as data – according to how it is stored and managed by software applications.
  • Organizational responsibility and authority should be modeled as part of the process. Although users should be allowed to control a significant part of the execution of a case process, the organization should also be able to restrict the rights to perform some operations. Similarly, the responsibility for performing activities and making decisions should be represented. Role-oriented process modeling languages excel at this, though they require a too rigid distribution of work to fully support dynamic business activities.
  • In projects, resource allocation is driven by unique competence, as opposed to the load balancing concerns of “mass cases”.
  • A default “standard” state machine for activities execution should be defined, similar to e.g. the one defined by WfMC, but more suitable for dynamic and evolving processes.

Proposals for a Refined and Simplified Dynamic Business Activity Modeling

Though we find Cordys case modeling approach superior to most available alternatives, there are still some issues where we’d prefer different designs for a dynamic activity modeling standard. We also believe that such a standard should be aligned with BPMN as much as possible

Simplified Typing of Sequences and other Relationships

According to their own description, Cordys applies an automatic and manual “follow-up” relationship to connect events to the activities they trigger, and activities to the next activity. The semantics are slightly different from BPMN sequence flows, but there is also substantial overlap between these constructs. Cordys also introduces a third relationship type, the “before” sequence constraint. Though there are clearly nuances in the meaning of these relationship types, it is our experience that these details confuse business users, making the language more difficult to use, and the models more error-prone.

The alternative would be to have a single sequence flow / follow-up relationship type, and apply properties to distinguish between nuanced interpretations. Visually, these properties could of course be displayed like in Cordys today. When defining a stable, standard modeling language, we prefer to define separate types only when there are essential features that differentiate two concepts, not for more temporary features that may be subject to change over the lifetime of an instance.

The difference between decision that some activity should be performed, and decision when it is performed, is central to the semantic nuances in this case. Seeing a flow as a constraint, there are a few different interpretations of the model fragment

A -> flow_to -> B

  • B should be started when A finishes
  • B should be started sometime after A finishes
  • B should start after A starts
  • B should finish after A finishes
  • Etc.

Along a different dimension, there are also a number of different strengths of enforcement of such rules:

  • Absolutely prohibited to violate the rule, the user interface will not make it possible in any way,
  • Absolutely prohibited to violate the rule, but authorized people may change or remove the rule for a given instance,
  • A supervisor or process owner must authorize any violation,
  • The user may proceed, but will be warned, and possibly asked to confirm that (s)he takes responsibility,
  • Etc.

Clearly we cannot define separate types for any relevant combination of these semantics, without creating a very complex modeling language. The same flexibility can however be achieved by a much smaller number of properties. When multiple dimensions are applied to categorize some elements, encoding these differences with typing would require the product of the number of alternatives within each dimension, while encoding the same information with properties only requires one property for each dimension.

We have found a combination of the different semantics proposed by Cordys to be most useful, by defining a single flow type, which has these default behavior properties:

  • Warn the user when a task is started although an input flow has not been triggered (a soft “before” constraint, which can be adjusted to a stricter enforcement),
  • Make the successor activity applicable when the predecessor is completed (automatic sequence flow, but activity start left up to the user)
  • Include in the user interface for the first activity the opportunity to manually trigger the flow to the second activity.

Our solution thus combines some aspects of the semantics of all the three types defined by Cordys, in a simpler language. Different semantics are applied in different circumstances or process stages.

This approach also supports the typical modeling scenario best. At the outstart, we often just define the main sequences of the processes, without caring too much about the detailed semantic. They can be added later. Our approach facilitates this evolution without having to change the type of any element, and a process model is executable from the start, by following the default interpretation of the sequence flows. This approach is best implemented by an instance-oriented modeling framework, where types are defined by their templates. In such a system, it is easy to locally extend or restrict the language, by defining new template types, with a different set of default property values. All potentially relevant local template types should however not be included in the core language, as it would become too complicated.

Fundamentally, this discussion illustrates why it is a bad idea to define a modeling language primarily or solely in terms of types or classes. A more property-oriented approach would also make it easier to define dialects based on a core language, for instance a dialect with BPMN semantics for conventional workflow, another for case management that applies Cordys’ relationship types, and maybe a third for engineering project management, applying yet another set of relationship types.

Modeling of Decisions

While Cordys’ RFP proposal to the OMG emphasizes the modeling of decisions, both for business rules and for capturing human decision making, their case modeling language does not seem to include decisions as a core type. Instead, the difference between their rules and BPMN gateways are highlighted. Again, we’d prefer a more unifying approach. Generalizing the BPMN gateway constructs seems preferable to introducing completely new constructs. Cordys is right that rules should be applied more flexibly and concurrently, at any time when they are relevant, not just when the flow of work arrives at a gateway. We believe the solution lies in aligning the semantics of decision gateways and events.

Process execution is about making decisions about the ordering and flow of work. Decisions are made

  • Manually by the participants, or
  • Automatically, by the process and rule engines.

In interactive execution, the automation boundary is not fixed. To handle exceptions, decisions that were modeled to be automated, may need to be taken manually. Manual decisions may become automatic when new rules are added during execution, or the system may need to take action when a user fails to react, e.g. when the starting of a released activity is delayed for a long time. Some decisions may be modeled as partially automated, with rules that handle the straightforward combinations of input data, leaving the users to handle more complex and special cases.

Further complicating the picture, process execution involves two kinds of decisions

  • Explicit decisions, modeled as e.g. gateways or rules, and
  • Implicit decisions, determining state transitions in the lifecycles of other process elements, such as starting and completing an activity, triggering a sequence flow, etc.

As discussed above, Cordys separates manual and automatic follow-ups in their language, in order to represent two different ways of making the (implicit) decision of triggering a flow. By including implicit decisions, decision-making becomes an aspect of the process and all process model elements, an aspect which is critical to process enactment and automation.

Also as discussed above, we need to take into account the difference between deciding that a certain alternative should be chosen, and deciding when the work should continue on that alternative. Sometimes one of these steps is automated, the other not.

In Workware, explicit representation of decisions was a cornerstone for interactive process execution. We even introduced two decisions for every activity, start and completion, and connected all flow relationships to these decisions rather than directly to the activities. This did of course complicate the models somewhat, by making explicit what was implicit in most other languages. We therefore also opened up for simplified process modeling views where these detailed decisions could be hidden (made implicit), and the flows connected directly to activities instead. As an added bonus, the explicit representation of decisions allowed us to tackle the problem of assigning authority and responsibility for manual decision making. This is illustrated in the two versions of the process fragment shown below

Modeling the reponsibility for decision making as part of the process

Modeling the reponsibility for decision making as part of the process

To the left, the question whether to accept or reject the proposal is placed inside the evaluation activity w1, meaning that decision can be made locally, by the user responsible for w1. In the revised model to the right, however, the decision is moved out of the local activity, implying that the person responsible for the surrounding activity should decide.

Composite or Complex Events, Decisions, and Rules

High level decisions, such as whether to approve or reject a loan application, or selection among different product concepts, are typically the primary outcome of a large processes or cases. Such decisions are however seldom explicitly represented as decisions. By allowing the decomposition of decisions and gateways into processes (or cases), a more comprehensive business activity model could be developed. It is not just the high level decisions that may require a detailed description of how the decision is made, who is involved etc. In general, a decision or gateway represents the “what” aspect, the effects of the decision, but not the “how” aspects of decision-making processes.

Visual Rules

In order to visualize and manage all the critical dependencies of a project or case, we think that rules should also be represented as visual model elements. The dependencies reflected by references to case data parameters in events and conditions, and as effect actions, should be visualized alongside the process sequences. For management and coordination it is more the context of the rule that needs to be visualized, the events and data parameters, and possibly organizational roles involved in manual decision making, rather than the internal logic of the rule itself.

Of course, some rules are today represented visually, e.g. as flows between an event and an activity in BPMN (or as automatic follow-ups in Cordys). In this case the visual model specifies the event that triggers the rule, and the resulting action (the activity), but for most event types, the condition is empty. BPMN though has a conditional event type, which completes the picture, to allow visual modeling of ECA (when Event if Condition then Action) rules. If we look at the if-then production rules defined in tables in Cordys, it is clear that the event part of the rule is implicit. I would guess that a rule is evaluated whenever the rule is applicable, and one of the input parameters are updated (the triggering event). The action part of the rule is also not explicitly modeled as an activity, but rather as an update of some data values or activity states.

A Unified Framework for Events, Activities, Rules and Decisions

The above discussion leads us to define the core behavioral constructs according to this class hierarchy:

Class hierarchy for behavioral constructs

Class hierarchy for behavioral constructs

A task is a complex event, involving a start event, which may trigger sub-activities, and a completion event, which may trigger succeeding activities. In order to align the execution semantics of tasks as events, it would however be correct to treat the completion event as the key, because it triggers outgoing flows, just like the occurrence of the event does. This makes the semantics of flow relationships the same, regardless of whether the source is an event or an activity. A decision is a kind of activity, so it can be decomposed into a process of sub-activities. A decision could however also be decomposed into a network of sub-decisions, e.g. to represent decision trees. Finally, rules are a (semi-)automatic kind of decision, which fire (the event semantics of the rule) when another event occurs, and the conditions are satisfied. The activity aspect of the rule is covered by the action clause, which may be specified in a low level action language, or modeled as an activity.

The main reason for aligning these constructs, is to provide a simple and principled core language. After all, the semantics of these constructs are similar, when it comes to e.g.

  • Event triggering
  • Control of which items are applicable in a given situation, according to clusters/hierarchies and sequence constraints
  • Resolution of input data parameters, and reaction to e.g. data update events
  • Links to the organizational model to determine authorization and responsibility
  • Composition
  • Instantiation during execution
  • Process history
  • Combination of manual, automatic, and interactive decision making

Note also that this solution removes the need for abstract supertypes, such as BPMN’s FlowElement, which complicates many standard language specifications.

Richer Execution Contexts

A final issue that we would like to see handled by a generic business activity modeling standard, is the modeling and runtime utilization of the execution context. While case management goes beyond conventional BPM notations in representing the content and effects of case data, the proposed solution still seems insufficient to deal with large projects. Like we discussed above, case data should be extended with

  • Relationships, hierarchies, inheritance and other data structures may influence process execution, because they capture important dependencies among activities. The effects of these dependencies on the process should be automatically derived from the data structures, to remove the burden of manually replicating them in the process models, which would quickly become too complex.
  • Support for metadata evolution, e.g. to support product design,
  • Seamless and uniform inclusion of metadata and instance data in process models,
  • Multiple views on case data adapted to the concerns of different roles and stakeholders, maybe even different value sets for the same parameters,
  • The organizational context should combine process hierarchies and organizational models to resolve responsibility and authority for different activities in different circumstances.

An upcoming post will describe the influence of product models on business processes in greater detail, using an example from field development projects in the offshore oil&gas industry. After all, products are far more prominent in the native language that business people use when they talk about their work, than processes.


One Response to “Flexible BPM: From Case Management to Active Project Execution”

  1. […] by BCM are probably the most relevant standards for our approach, alongside the recent work on dynamic business activity modeling in the OMG. Some of the standards mentioned above, like CPP, CPA and BPSS from ebXML, are […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: