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.

 

 

We often talk about the process “round trip”. The process lifecycle is explicitly about moving the process through different people with different specializations. The business analyst draws a high-level model and the systems integrator includes details for connecting the systems. Another dynamic is the continual process improvement that occurs when you assess how effective the current process is, make a change at the high level, and take that change through the lifecycle again.

In an earlier post, I introduced the concept of a “Model Preserving Strategy” versus a “Model Transforming Strategy” and defined them as two approaches that a BPMS can take in the lifecycle of a business process.

You don’t want to have to force the programmer to start from scratch with the integration work because you made a small high-level change to the process. Round-trip is the idea that all the changes that the programmer does during integration are somehow brought back to the original model. If you do this, then the business analyst can make a small change, and the programmer only needs to make the associated small change.

Round-Trip with Model Transforming Strategy

The model transforming strategy presents a significant challenge for an effective round trip. When transforming from business domain to system domain, certain aspects of the model that are not needed for the integration or enactment are typically left behind. Then with the model in that state the systems engineer starts to modify the model. When done, it is not always clear how those changes should fit with the things in the original business domain model.

It is not always the case that information must be left behind. Some systems encode things needed only in the business domain into passive elements of the system domain model. This works if the two models are only slightly different, but transformation is often more significant. Without a one-to-one correlation between objects in the two domains, there is often no place to put this information.

A second approach to allowing round trip is to simply put identifying numbers into the elements generated that indicate from which parts of the business domain model they came. The business domain model is retained by the business analyst. Later the modified integration domain model can be re-imported into the retained business model. If any of the identifiers match at import time, then that integration information is associated in such a way that it can be re-exported again next time.

While it is a significant challenge, it is possible for a Model Transforming Strategy to support round trip capabilities even though they transform the model to other forms.

Round-Trip with Model Preserving Strategy

Preserving the same model through the steps of a lifecycle is clearly an advantage when it comes to completing a round trip. There is almost nothing to do. Since the model is preserved in the same form, it is simply a matter of making sure that the business analyst uses the latest copy with all the integration embellishments.

The business analyst and the system integrator can work simultaneously on the same model. By simultaneously I don’t mean keystroke-for-keystroke simultaneousness, but rather that one opens, changes, and saves; then, the other opens, changes, and saves. A normal resource management system can prevent accidental edit conflicts by allowing each person to check out with a lock while they edit. Being able to collaborate at the same time, means that you do not need specific time spans in which each person does their part of the work. This allows very fast cycle times between them.

Agile Development Depends Upon Round Trip

“Agile BPM Development” is not just about implementing quickly, but also implementing iteratively. The Agile method is to implement part of a solution, try that out, maybe measure how well that works, implement a bit more, try that out, and so on. There are many small changes, with each change being implemented and released in a very short time. In each cycle you want to start with the results of the last cycle. In this way, you avoid a significant amount of rework on every cycle.

The ability to support round trips is directly proportional to the ability to support Agile. Any limitation in carrying integration changes back to the business domain adds significant effort on every cycle because some parts of the integration work must be done again. The more work that is required to perform an iteration, the less net value you get from making a small change. In order to prevent waste, an organization in this situation will wait longer and save up more changes before executing the iteration.

The Model Preserving Strategy holds a clear advantage for those interested in Agile development. Because the form of the model remains the same, it is possible for different parts of the lifecycle to be working on the same copy of the model at (nearly) the same time. A business person can make a 5% change to a model. The programmer can make a 5% change to the same copy of the model. The modified process can be installed into the enactment engine without a significant reworking of things. A Model Transformation Strategy can get close to this, but the fast that the model is transformed prevents people from working simultaneously.

Summary

If you are concerned about retaining a strong round-trip capability and implementing using an Agile development approach, then the Model Preserving Strategy is a clear winner. Since there are no transformations between domains, there is no barrier to the business analyst and the systems integrator passing the process definition back and forth as much as they want. It is not impossible to provide round-trip capability with the Model Transforming Strategy, and some of the existing systems do a very good job of offering complete round trip, but it is something that must be checked very carefully. And even round trip is supported, the fact that you have to make an explicit transformation between the domains becomes a barrier to effective collaboration between the business analyst and the systems integrator.

 

 

In an earlier post, I introduced the concept of a “Model Preserving Strategy” versus a “Model Transforming Strategy” and defined them as two approaches that a BPMS can take in the lifecycle of a business process. I then posted a couple of situations where the Model Preserving Strategy is a better choice, but it is not always a better choice. This post is dedicated to those situations where the Model Transforming Strategy shines.

The main reason for transforming a model into another form, is to realize performance improvements.

Transforming for Execution

Processes and programs are written by people, but execute in a machine. Those machines (or execution environments) have certain capabilities, either limitations or affordances for doing specific things. Transforming the model can allow you to take advantage of those capabilities, or work around the limitations, to have a faster running program. This is like an optimizing compiler that will take a third generation language and convert it to machine code that uses specific capabilities of the target machine in order to run faster.

The alternative to compiling a program to machine code, is to interpret the program. Interpreted languages such as LISP, PERL, PHP, Ruby, and JavaScript come to mind. Sometimes a “just in time” compiler is used to compile the code just before it is run, but the environment does it transparently so that the transformed version is never seen by anyone. Java is a language which is compiled to an intermediate form that is then interpreted. The trade-off between using a compiled language and an interpreted language is much debated, and still depends upon how much performance you need. The core of a database server is a performance critical component clearly requiring a highly optimized language. Many web application development environments use an interpreted language, because CPU performance is not a critical aspect of these types of applications.

The model transforming strategy can do the same for business processes by taking in a diagram that is meaningful to a business analyst and producing an optimized output that runs faster in the execution environment.

Transforming for Developer

Another reason to transform the model is to put it in a form that is comfortable for the system integrator. If you have Java developers on staff, then transforming the BPMN model to Java would allow the developer to be more effective with less training than if they are forced to learn to work within the constraints of BPMN.

This will not necessarily be from BPMN to a programming language. My post on “Human Facilitator Processes” illustrates a transformation from BPMN to BPMN. The difference being that the business domain model was a BPMN diagram representing flow of responsibility, while the system domain model was a BPMN representation of the flow of data.

The point is that the transformation is from a form that is best for a business analyst to use, to a form that is best for the system integrator to use. If your business process requires a lot of system integration work, then optimizing the time of the developer might be significant.

Model Preserving Strategy

The entire reason for preserving the model across the lifecycle is to make end-to-end coordination easy at the expense of the intermediate steps. System engineer are not prevented from doing the system integration, but they simply must do the work directly in the same model that the business person used. The execution of the model is not prevented, it simply must execute from the same form that the business person used. This is the tradeoff.

How to Decide

If you have a BPM project that involves a lot of programming work to integrate systems, relatively less work from the business domain, and a low likelihood of a need to evolve the business model over time, then a Model Transforming Strategy will allow you to optimize the use of the systems engineers. They can work in a familiar way using tools and skills they already have.

If you anticipate a large rate of transaction processing, you may need to consider the Model Transformation Strategy for high performance. How large is large? You start by counting the cases per month, multiply by the number of activities per case on the average, then divide by the number of hours per month to find the approximate number of activity executions per hour. If this works out to be more than 1 million activity executions per hour, then you must consider carefully whether a compiled approach is required. If you anticipate 10,000 activity executions per hour or less, then there will be no problem using an interpreted approach, even on a very modest server. These are just ballpark figures, and between these two you will have to consider the specifics of the implementation and the type of transactions being invoked. It is worth noting that many important business critical processes involve less than 10,000 activity executions per hour, and performance is simply not an issue.

Those knowledgeable about performance know that programs spend most of their time in 5% of the code. If you can optimize that 5% of the code, you can often attain 99% of the performance of optimizing the entire code. This explains why interpreted BPM diagrams working at a high level by calling into function which are themselves optimized often perform just about as fast as compiled programs. Thus overall performance is less related to whether the code is compiled or not, and more related to whether the supporting functionality is a good fit for the need.

The rise in popularity of interpreted languages for web applications is an indication that CPU performance is no longer a limiting factor in many web applications. Experience shows that servers are more limited by IO bandwidth now, than they are by CPU usage, and so overall performance can often be enhanced by spending CPU time on interpreting a language if in return you can reduce the data transfer requirements.

Conclusion

If most of the project effort is going to be system integration, or you have an extremely high rate of activity execution, then the Model Transforming Strategy allows flexibility to be able to optimize for the programmer and for the specific requirements of the execution environment.

 

ABOUT THE AUTHOR:

Keith Swenson is Vice President of Research and Development at Fujitsu Computer Systems Corporation, as well as Chairman of the Technical Committee of Workflow Management Coalition (WfMC). He is known for having been a pioneer in web services, and has helped the development of standards such as WfMC Interface 2, OMG Workflow Interface, SWAP, Wf-XML, AWSP, WSCI, and is currently working on standards such as XPDL and ASAP. He has led efforts to develop software products to support work teams at MS2, Netscape, and Ashton Tate. He is currently the Chairman of the Technical Committee of the Workflow Management Coalition. In 2004 he was awarded the Marvin L. Manheim Award for outstanding contributions in the field of workflow.