Model Strategy: Preserving vs. Transforming

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.


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.


16 thoughts on “Model Strategy: Preserving vs. Transforming

  1. Keith,
    I like where you’re going with this, but don’t stack the deck with your graphics. I like the picture you have for model-transforming but I think it applies to both strategies. On the left is simple business-friendly view of the process. In the middle is a detailed business analyst/architect view of the process. It provides a complete but abstract view of the flow but without executable detail. On the right is the executable detail. It normally does not appear in the diagram so it is shown in text view. Of course you could have diagram and text views of all 3 panels. I think the difference between model-transforming and model-preserving is whether the 3 panels reflect a single model populated (and visualized) at different levels of detail, or 3 separate models. I think both Fujitsu and the executable BPMN 2.0 effort of OMG are model-preserving in that sense, although you might consider them at opposite ends. On the other hand, BPMN-to-BPEL (or BPMN-to-FileNet, for that matter) is model-transforming.

  2. Pingback: Model Strategy & Analytics « Go Flow

  3. Bruce: good points.

    The pictures are meant to try to convey what it means to “change the form” of the model, and what it means to “preserve the form” of the model, without trying to be specific about any particular model. As it is, I used a BPMN-like model in the business domain — don’t know if that was a good idea if I am trying to discuss the abstract concept around model strategy.

    For model transforming: I am trying to express the idea of simply that there is a complete lack of one-to-one, or even many-to-one relationships. I want to show that the form at the system domain, is not simply an elaboration of the business domain. I am picking pictures which are essentially completely different (but if you look carefully you will see they come from my Sept 2007 Human “Facilitator” Processes post).

    For model preservation: I want to stress that the form of the model really does remain the same. Actually, you are right, I should have some slight differences, such as additional embellishments in the system domain — changes that don’t change the form of the model and retains a one-to-one correlation at each level.

  4. Pingback: Process for the Enterprise » Blog Archive » Preserving the Model

  5. Pingback: Model Strategy, Round-Trip & Agile Development « Go Flow

  6. Pingback: Model Strategy & Simulation « Go Flow

  7. Pingback: Process for the Enterprise » Blog Archive » Keith Swenson on Model-Preservation vs. Model-Transformation

  8. Pingback: “BPM In Practice” in San Diego « Go Flow

  9. Just like to say that the business side of this conversation is Business Optimisation………….as in, whet you have explained very well is the real life execution of the strategic initiative that is a Business Optimisation Program in action.

    I am not educated enought to discuss this technically – but to educate a CxO, your images do the job 100% as they are.

  10. Pingback: Process Reification « Thoughts on Collaborative Planning

  11. Pingback: The Border Between EA and BPMS Tools - Process Is The Main Thing

  12. Pingback: Flipping the Process Life Cycle | Collaborative Planning & Social Business

  13. Pingback: Why BPMN Matters - Process Is The Main Thing

  14. Pingback: Почему BPMN имеет значение |

Leave a Reply

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

You are commenting using your 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