Articles

Model Strategy: Preserving vs. Transforming

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.