The IBM Business Process Manager migration in FINA

Financial agency (FINA) uses the IBM Business Process Manager (BPM) tools as a platform for the implementation of business processes management from several business areas. The pioneer of the usage is pre-bankruptcy settlements process.

The writing office, archive center, coordinators and the settlement council work together on one case of settlement. The business process is designed and in performance led through IBPM. With the change of the legal framework, a new version, called pre-bankruptcy agreement, was made. The platform is also used to support the business process of enforcement over real estates and movable properties (PONIP).

Picture 1. Pre-bankruptcy settlements process

*From a business perspective, IBPM is used as a supporting tool in performing the business process. From a technical viewpoint, IBPM is a Business Process Model and Notation (BPMN), an executive server that integrates business process and the user interface. The integration is what’s the most appealing, in other words, the factor which accelerates the applications for support of business processes. We can see the development cycle in picture 2, in which it is apparent that programmers, apart from the business process, are also developing the users interface. The technology used for the production of the user interface has drastically changed over time and is now one of the main reasons for switching to a newer version of IBM BPM.

Picture 2. Development cycle through IBPM platform

The consolidation of IBM BPM on z/Linux

Regarding BPM, the main reasons are savings in licences costs and switching to a new topology. Because of the ways in which z/Linux is licenced it is possible to support more than one server in a cluster with the same licences, which results in higher availability. In Intel environment there were two BPM process servers: one for the pre-bankruptcy settlement project, and the other one for PONIP. Due to the fact that the principle new application – new server is not scalable, it was decided to, when consolidating, substitute those two servers with a mutual one, which will be used in a new pre-bankruptcy settlement project. Also, to increase the scalability (vertical and horizontal), a new environment was created, with a so called golden topology of the IBM BPM servers. As shown in the picture 3, that topology includes three clusters. In that way, it is enabled to separately tune each cluster, and by that, to use the available resources optimally.

Picture 3. The consolidation of IBM BPM on z/Linux

Why to migrate to a newer version?

Using the state-of-the-art technology is definitely one of the reasons for replacing the software with a newer version. The other reason, as equally important, is the fact that upgrading in the due time eliminates the danger of using the old software version, for which the manufacturer no longer offers support. The typical IBM BPM life cycle, from the presentation of the new version to the end of the support, lasts about five years. The right time to migrate to a newer version is around the half of its life cycle. FINA decided to replace its installation, because of the combination of both reasons, after approximately two years. Because last year a new project started developing, it was decided that the same project should develop on a new IBM BPM version. That exactly was what started the migration actions of IBM BPM to a newer version.

Migration methodology

The purpose of migration is almost always the same: to get a functional environment of the chosen IBM BPM version. Path leading to that goal can greatly differ, depending on whether we have to migrate the instances of the existing running processes, or not. That mainly affects the selection of the migration path, because if the processes are not migrated, it is enough just to install applications on the new environment, and then we are talking about the artifacts migration. If that is not enough and the processes have to be migrated, then the instance’s schemes of database are migrated, which is a much more challenging type of migration so it is almost never used when migrating the IBPM Process Center.

IBPM migration from V7.5.1 to V8.5.5

In FINA we did the migration in both ways. The Process Center was migrated by migrating the artifacts. Migration is rarely performed through the database – exceptionally, in cases where it is necessary to preserve the complete history of the developed applications’ versions. Since that was not the case here, the migration was made through exporting versions in the old, and importing applications in the new environment. Even though it was a migration with skipping two major versions (8.0 and 8.5), when importing applications there was no problem.

The Process Server’s migration

When migrating the Process Server, only migrating applications (artifacts) is not an option. IBM BPM is a stateful system formed of installation and configuration of the product and the condition of the processes in the database. If the goal is to continue with the process from where it stopped in the existing environment, it is necessary to migrate the database into the new environment. That action, as trivial as it may sound, can be really delicate and time consuming. The simplest example, for instance, when the base and IBM BPM version stay the same, and we are doing a migration from, let’s say, Windows to Linux, the migration is done by database backup and restore procedures. In our case it was all much more complicated, so we had to migrate bases from the BPM v7.5.1 version to BPM v8.5.5, as we were also changing the operating system and IBM DB2 version’s base. Since the database versions are different, it was necessary to create an offline backup of the base, which is made in two steps: first time at the so-called dry run, and the second time at the cut over.

Dry run and cut over

The most important and challenging task when migrating IBM BPM solution is planning. The migration almost always includes coordinated work of a larger group of people. Necessary roles can be seen in charts, with that sometimes one person takes on a few roles. When planning a migration, for each of the environments two actions are planned. In the first action, a so-called dry run of the migration is done, in isolation from the existing environment so that the migration and testing would not have any influence on the regular work. The aim of the dry run procedure is to check the migration plan and the migration procedure accuracy. When the accuracy of the procedure is confirmed through the dry run, the next phase is planned, the cut over phase. In the cut over procedure it is necessary to plan a certain time when the system won’t be available. The ideal time for a cut over is during the holidays or a longer period of time in which we can allow the unavailability of the system. It is also important to leave enough time in between the environments, when the system behavior is tracked, before the migration of the most critical environment, the production one, starts.

Linux justified the expectations

By migrating to z/Linux the user got a more reliable and stable system. The scalability of the system is also better, which is partly a result of a new topology. By migrating to z/Linux the user got a more reliable and stable system. z/Linux also allows flexibility in creating IBPM environments that fit the needs of FINA’s development process.