Migratory Movements

11th of March 2016

Every time we deploy a new version of an automated process, we are faced with the need for process migration. Birds perform migrations every year with great risk to their lives out of necessity. And just as those bird migrations, business process migrations are not without difficulties and risks.

There are several possible scenarios when introducing process automation:

  • The process is completely new, such as the introduction of a new value chain.
  • The process only exists as a combination of manual actions without a strict enforcement of the sequence.
  • The process was already automated in the past, and is receiving a new version. This scenario has different flavors:
    • The process versions can coexist within the Business Process Management Solution (BPMS), either indefinitely or during a transition period.
    • The process versions cannot coexist within the BPMS.
  • A non-automated or manual process is replaced by a newer version, which is also non-automated.

The first scenario is the most straightforward of the lot. Introducing a new business process does come with a heavy load of change management to organize around this new way of working, but since no legacy process exists, no migration is needed. Unfortunately, this scenario is also the least likely to occur.

The second scenario introduces a first automated version of an existing manual process. One might think that no migration is needed in this scenario either, since no process data would exist in the BPMS. However, this would be shortsighted, because of the implicit process data existing in the organization, usually existing in the form of states of data within the systems participating in the process. Suppose a process would sequentially update data within three legacy systems. It could very well be that at the moment of deployment, for several process instances, the first two steps are already performed. For the newly deployed process, several instances could already be in a state which is not the start state.

The third scenario has two flavors. Either the versions can coexist or they cannot. The impossibility to coexist usually comes from legacy systems that cannot cope with both process version demands at the same time. For instance, when services or the underlying data model of a legacy system change so drastically that the old process service calls no longer have a meaning within the legacy system.

The fourth scenario is not really a problem for process migration, but rather a change management and training issue.

To tackle process migration in these scenarios, several approaches can be taken:

  • The automated process will coexist with the manual or earlier automated process. This comes down to not migrating the manual process instances, but rather letting them finish in the process version in which they were started.
  • We create an automated process version for the open scenarios. This would boil down to providing a version where at different points in the process we introduce a conditional start, so that certain instances would step into the new version of the process at the proper place within the sequence.
  • We close off all instances of the old process version, and redo them in an instance of the new version, so that they can continue where they left off. Some BPMS technologies allow you to migrate instances to the newer process version if a suitable process state can be determined.
  • Applying some of the underlying principles of Micro Services, we can draw up atomic processes, which we then string together using signal and message events, making it possible to start the implicit process at any point in its execution. I am not a huge fan of this approach, as it makes the maintenance of processes considerably harder and more costly.

None of these approaches stand above the other. In each process migration, a risk versus cost assessment, combined with the principles and best practices of the enterprise, should help determine the course of action to take, and might even differ from process instance to process instance. However, it is a step not to be overlooked in any initiative of BPM.

Thought BPM