Process Model Change Management

Jochen Küster of the IBM Research Zurich lab (where they do a lot of BPM research), was first after the morning break at our CASCON workshop on collaboration and consistency management in BPM, presenting on process model change management. This was more of a technical talk about the tools required. As motivation, process models are a key part of model-driven development, and become input to the IT process modeling efforts for SOA implementations. Multiple models of different types will be created at different points in the modeling lifecycle, but individual models will also go through multiple revisions that need to be compared and merged. This sort of version management – that allows models to be compared with differences highlighted, then selectively merged – doesn’t exist in most process modeling tools, and didn’t exist at all in the IBM process modeling tools when their research started. This is different from just keeping a copy of all revised process models, where any one can be selected and used.

In order to do this sort of comparison and selective merging, it’s necessary to generate a change log that can be used for this purpose, logging not only atomic activities, but have those rolled up to compound operations to denote an entire process fragment. Furthermore, the merged model generated by the selective application of the changes must still be valid, and must be checked for correctness: a resolution of the changes following a detection of the changes.

The solution starts with a tree-like decomposition of the process model into fragments, with correspondences being determined between model elements and fragments; this was the subject of research by the Zurich lab that I saw presented at BPM 2008 in Milan on parsing using a refined process structure tree (PST). A key part of this is to identify the compound operations that denote the insertion, movement or deletion of a process fragment. The current research is focused on computing a joint PST (J-PST) for the merged process, which is the combination of two PSTs determined by the earlier decomposition, based on the correspondences found between the two models. The dependencies are also computed, that is, which process fragments and activities need to be inserted, moved or deleted before others can be handled.

The results of this research has been integrated into WebSphere Business Modeler v7.0, although not clear if this is part of production code, or a prototype integration. In the future, they’re looking at improving usability particularly around model difference resolution, then integrate and extend these concepts of change management and consistency checking to other artifacts such as use cases and SCA component diagrams.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.