Cutter Consortium
29 April 2008

Improving BPM with Object Solutions

Business process management (BPM), also called business process modeling, is a hot topic these days: as a standalone solution; as the impetus for the customer relationship management (CRM) and supply chain management (SCM) categories; and perhaps most importantly, as a critical enabling technology for the orchestration function in service-oriented architecture (SOA).

There is a great deal of wisdom in building applications around end-to-end business processes. Making it easier for businesspeople and technical people to communicate is, in itself, a great step forward.

Unfortunately, the kinds of BPM solutions being put forward perpetuate an approach that for years kept workflow systems -- BPM''s core technology -- from being as successful as they could have been. This is an approach that deals with the routing of work processes on a track almost completely separate from the rest of the application. While isolating one application aspect is useful for modeling and optimizing, it creates real implementation problems.

First, workflow is so isolated from the data it is moving around that it can "consult" this data only through hardwired connections at preset points. This makes workflow-enabled systems notoriously Byzantine, inflexible, and hard to maintain. Additionally, workflow systems do not grasp, or at least fail to assume responsibility for, a number of tasks that are critical for safely managing a long-running process. This puts a significant burden on the rest of the application and at times makes incorporating workflow more trouble than it is worth.

When reviewing the protections that have evolved to ensure data integrity in short-running processes, we find that long-running processes have to provide the same protections without the help of classical, two-phase commit transaction processing machinery -- the ACID properties (atomicity, consistency, isolation, and durability).

A substitute for atomicity must be found, keeping all interrelated components of a transaction in sync. A substitute for data consistency must also be found, so that no incorrect values get into the database. A substitute for isolation must be provided, so that when a piece of work encounters data that has been interfered with, it will take appropriate measures. And finally, a substitute for durability must be provided, to ensure that intermediate states of the long-running process are captured and persisted in a safe place. This is a demanding constellation of tasks, and the workflow approach embedded in BPM and SOA orchestration fails to execute them.

Object Approaches

There is a far more promising approach to handling long-running processes. This involves seeing process management not as a standalone application aspect, but rather as one of a constellation of functions to be performed in a customized way on a particular set of data values. This is, in other words, an object approach. A piece of work in progress is modeled as a tightly integrated bundle of data-plus-function, where all function has direct access to all data values and can interact with all other functions as well. It makes for more flexible, easy-to-understand systems and is more respectful of data integrity than classical workflow. An object approach to process management is being pursued in several quarters, most of them being universities or research centers. Initiatives include agent approaches, case-handling systems, and a variety of inventions called "proclets," "worklets," and "WIPs." All implement some form of an object that represents a long-running process. Cutter's Executive Report "BPM in Peril -- Objects to the Rescue" (Vol. 6, No. 6) looks in detail at the WIP (work-in-progress) concept and implementation.

Organizations not in a position to experiment with WIPs or one of the other early stage object approaches should try to understand the fundamental insights so that they will recognize a solution when one comes into their acceptability range. In the meantime, they should try to ameliorate some of the vulnerabilities inherent in current BPM/SOA solutions by keeping workflows short, using tighter rather than looser coupling, and considering whether old-style transactions aren't, in many cases, more useful than newer process automation.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at jtibbetts@cutter.com.

-- John Tibbetts, Senior Consultant, Cutter Consortium

Improving BPM with Object Solutions