BPM Process Migration

BPM Process Migration

Having worked in several BPM projects for quite some time, I usually enjoy the help of the BPM server. In particular, BPMN etc. are excellent for conversations with the customers. Of course, you still need to translate the customers desires into your own technical picture (which might differ considerably), but in the end you'll likely to get something that gives the customer a "I know this" feeling, which is worth a lot. Of course, there are still gaps, problems, and all that stuff. However, what really sucks, are upgrades of the project version.

Disclaimer: I am no BPM expert, much less skilled in the theory, just an experienced user. This is just the result of my thinkings. In particular, don't mismatch this post with a statement of my employer, Software AG, or Fujitsu. It reflects my impression of how to work with the webMethods BPM Server, or the Fujitsu Interstage Server. I have no idea how these ideas can be transferred to other BPM tools like, for example, Apache ServiceMix, or whatever.

Terminology

A BPM Process Model in the sense of this posting is a set of Process Nodes and a set of transitions between these nodes. In what follows, let PM be a process model, PN be the set of PM's nodes and TPN the set of transitions. PN consists two special subsets, the start nodes (SPN), and the end nodes (EPN). A process model typically reflects some kind of workflow can be graphically visualized (see, for example, this picture:





The possibility of graphical visualization is what's so attractive about BPM for non-technical folk.)
A BPM Process State is an element from a universe U, typically an unstructured set of named objects. In the case of Interstage BPM, these named objects are strings, in the case of webMethods BPM these objects can be complex (maps, arrays, etc.: the webMethods Pipeline):

A BPM Process Instance is an element of the set PN x U: A combination of a process node and a process state. This definition is too geeneral, of course. For example, the node PN must be reachable from a start node via a series of transitions out of TPN. However, for now we can ignore this.
A BPM Process Model can have multiple versions. These versions are usually related, for example, the sets of process nodes and transitions are frequently subsets. In general, however, they can be completely unrelated.
A BPM Process Migration involves

1. the creation of one or more new process models, or model versions.
2. Possibly the removal of existing process models and process instances.
3. Possibly a migration of process instances from one, or more process models to a new process model, typically a new version of their current model.

This last part is the one that sucks, because it is completely unsupported. The developers are completely left alone. (All you can do is to ensure some kind of compatibilty, which usually implies leaving old software versions, or at least parts thereof, in place and hoping, that old and new versions are working fine together.)

But, how could such tools look like? This is what my post is about:

• It should be possible to replace process models with new versions by migrating the process instances.
• This means that a developer ought  to be able to specify a mapping from the set PN1 x U to PN2 x U. (The mapping would usually be a Java class implementing a special interface.)

Example: A process state usually contains entries like these:
ID (Database or any other internal ID, for example an incoming order; the process specific details are stored elsewhere and not as part of the pipeline, which would otherwise grow too big. However, the details are easily accessible.)
State (A human readably process state, like "unconfirmed", "available", or "acknowledge".)
Names (for example, name of the orderer, etc. These are frequently not really required, but redundant and just copied from the details for the sake of convenience.)

A new process version might introduce a new ID (for example, from another external system, which is now connected to the processs), a new state, or something like that. In order to get the existing process instances working with the new model, we can either
- modify the process so that it does support null values, even if they are mandatory from a business perspective
- enhance the process state by adding these new values as part of the migration.
Guess, which I'd prefer? And, guess which we are left with now?