It started out as a casual conversation over drinks at the Oct 2008 BPM Tech Show in DC, late in the afternoon, after the tutorials and presentations had finished. We wanted to know: “why is there such a variation in different BPM systems?” This expanded into a breakfast meeting the following morning on the topic of “What are advantages/ disadvantages of either preserving or transforming a BPM model?” We found that most existing systems tend to follow one of two possible strategies. Existing BPM Systems (and their associated methodologies) can be categorized as supporting either a “Model Transforming Strategy” or a “Model Preserving Strategy”.

It was remarkable how passionate people were about their position. Some insisted that preserving the model through the process development lifecycle was the critical ingredient that makes agility possible. Other argued strongly that transforming the model into other forms is the correct and most effective way to implement processes. After the event we held a number of conference calls in the attempt to fully understand the distinction, and most importantly, when each of these strategies is best used. This is the first of a number of posts that will explain the result of our discussions comparing and contrasting these two strategies.

Common Ground

Both strategies make some similar assumptions about the process of creating a process. Let’s call the workflow that creates a workflow the “business process lifecycle”. In the world of BPM, nothing is static. We need to understand that there are at least three different kinds of dynamics, and these terms will help us distinguish them:

• business process enactment: the business process itself has a dynamic component as it moves from the beginning to the end of handling a single case. The process definition does not normally change here, only the process instance or context that records the state of a particular case changes.
• business process lifecycle: these are the changes that a business process goes through from initial concept, to modeling, to integration, and finally to deployment into an enactment environment.
• business process improvement: this is the change to a business process that occurs over time through repeated use of the business process lifecycle followed by analysis of how well that version of the business process worked. This is the TQM or continual improvement aspect of BPM.

There is broad agreement that a process definition passes through a business process lifecycle that will involve different people with different specializations along the way. The original concept for a business process will probably start with a “pure” business owner. There may be a “business process analyst” who has insight into the business itself, and also has skills being able to model that process. There may be a “systems engineer” who performs the work of integrating the process with the other systems in the organization. Finally in the enactment environment there are administrators and users who interact with the running processes. Some people report more elaborate lifecycles that pass through four or more different specializations, and those certainly exist, but for discussion we should stick primarily to these three which are readily observed today.

The distinction between model preserving and model transforming is only a distinction within the process development lifecycle. Both approaches support process enactment and process improvement, but they handle the process lifecycle very differently.

Model Transforming Strategy – Definition

Proponents of the Model Transforming Strategy hold that the model should be transformed into different forms as it steps through the stages of the process lifecycle. Each form of the model is designed to be most appropriate for the specialized domain at that stage in the lifecycle.

The business process analyst designs a high level model in the business domain. This business person / process analyst is not expected to be a programmer as well. The high level model is transformed into something suitable for a programmer. This is done by translating the “business domain” model to a “system domain” model, either by adding in extra nodes which handle integration activities, or by transforming the diagram into a completely new diagram that represent the system level interactions that have to go on in order to cause the business level interactions to take place. The systems engineer then works with this form of the model to integrate the process with the other systems. Later this is transformed again for the enactment environment.

The model transforming strategy comes from a long tradition of programming and system development. In the software engineering field, the high level model is often expressed in a visual language known as Unified Modeling Language (UML). This might then be translated into a programming language, such as C++. The intended program is there, but the form is entirely changed and bears no resemblance to the original UML. Some would say that the UML is “destroyed” and replaced by the other form. Meaningful aspects of the original are expressed in the new form, but in an entirely different way. Often the transformation is “lossy”, which is to say that there are some aspects of the original which are simply not included in the transformed version. Perhaps the transformed version does not need those aspects of the former model. For example when C++ is transformed to machine code, the variable names are lost, because the the machine code has no need for the variable names. These kinds of transformations are routine in the software development world.

Coming back to a BPM example: the business analyst might put an activity describing a document review in the business view. This would be transformed to: a activity which sends email informing the person; an activity to check the document out of a repository; an activity to send a reminder message if the response is getting late, and an activity to wait for the response to come back. The programmer might extend this to include notation to handle exceptions and other timeouts that the business person did not include. Later this might be transformed again in order to get the executable code.

Accustomed to this approach, it is easy to imagine how software engineering experts viewed BPM as just another case of translation of a high level model into executable code. Conventional wisdom says we should stay with the successful approach from the past, and this is especially strongly encouraged by vendors that have tools designed to support the Model Transforming Strategy.

Model Preserving Strategy – Definition

An alternate strategy exists which retains the same form of the model through the process lifecycle. This strategy is actually quite common among the Human BPM products.

The lifecycle is essentially the same: first the business person draws up a high-level model of the process that represents the business view of what has to happen in the process. It has all of the major activities in a way that is meaningful to the people in the organization.

Second, the process model is given to a programmer, who implements the integration of this process with other information system. The difference is that this is done without changing the form of the original model. Instead of transforming the model, replacing human level nodes with system level node, the original visual nodes are left in place, but additional settings are made on those existing nodes to make them capable to do the integration tasks. This embellishes the nodes in the model, but it does not change the form of the model.

Third, the model is installed into the process execution engine, again without any transformation. The number of activities nodes in the engine is exactly the same number of activity nodes that the business person drew. The connections between them are exactly the same as the business person drew. This is the principle of “What You Draw is What You Execute” (WYDIWYE)

This model travels through the entire system without any change of form. At least there is no change required by the lifecycle. It is possible that the developer will see a way to improve the original model, but such a change is done in collaboration with a business analyst because both are working on the same model and both are seeing the same form.

Analysis

Different BPMS products can be categorized as either supporting a “Model Preserving Strategy” or a “Model Transforming Strategy”. Which is better? Well, those who have been diligently reading my blog posts already know that the answer depends upon what you want to do. It depends upon the kind of business process you are implementing.

What we can do is compare and contrast the two strategies in their ability to support the following seven dimensions:

1. Support for Round-Trip
2. Ability to handle runtime problem situations
3. Usefulness of Analytic Data
4. Ability to simulate and optimize the process
5. Ease of Use for the Programmer
6. Agile and Iterative Development
7. Visibility of Runtime Status

From this, we then figure out what situations one strategy would be good for, and what situations the other strategy would be good for. I will be comparing and contrasting these strategies in future posts.