👌🏽 👩🏿‍🎓 👨🏾‍🏭 How to migrate a large process from IBM BPM to Camunda and not stop feature development 👉🏻 🥃 👨‍🎓

Hi, my name is Denis, I work at Tinkoff and do BPM systems. In this article I will tell you how to migrate from the legacy of systems a la IBM BPM to the open source Camunda process engine using the example of a large process. And in the end I will invite you to the fourth meeting on Camunda, which will be held on February 27 in Tinkoff, in Moscow (metro Vodny Stadion) in the evening.

BPMS systems and BPMN as a way to program them

The idea that through programming can be programmed is well-sold , the market is growing from year to year. Some businesses get really cool results.
To make good projects and sell successfully, BPMS systems, in addition to “eating” BPMN files, must also be able to:

Identify specific performers in processes
Provide interfaces for users, implementers, and administrators
Call external services, send and listen to events, etc. In general, be able to "fall through" into the code
Provide data modeling and storage
Follow business rules
Test everything created

We used IBM BPM BPMS in Tinkoff, which helped us develop due to its complexity and acceptable coverage of these features. But we decided to refuse it.

Reasons for abandoning IBM BPM

We realized that from the great functionality of the BPMS system we use only:

Interpretation of bpmn files
Falling into code

Other things were transferred to other systems, for example:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
Data storage somewhere moved to Siebel - in situations where many consumers need CRUD operations on data, and somewhere - in separate applications. IBM BPM allows you to simulate data in a relational style, he creates the plates for the model. But it stores it all in one database for all processes, which creates additional connectivity and load on the database.
For business rules, we traditionally use IBM ODM, and now we are starting to use our Kotlin framework.
Normally, in the development style, we did not learn how to test applications on IBM BPM.

There were general questions that we did not like:

We switched to Kotlin and Spring, which is difficult in IBM BPM.
Very few specialists or those wishing to work with this product.
Difficulties of joint development of schemes \ code, essentially a monopoly mode of development.
4 3 ( ~40 ), .

Separately, it is worth mentioning the problem of noisy neighbors - licensing restrictions forced us to shove many products into one cluster. We tried to reuse the common code within different business processes, which created difficulties with its modification.

For example, there was a SMS sending code that was used by 2 products - cash settlement services and outsourced accounting. Previously, the text was hardcoded at the component level, but now the process of “outsourcing accounting” wanted to transfer the text of the SMS from the process. But the CSC process did not want this, but changes must be made everywhere.

Or banal bugs could put the entire base so that many products did not work, although they are not to blame.

Why did they choose Camunda, my colleague Nikolai wrote in a previous post.

What is a big process

We decided to transfer the large process from IBM (at first, however, we trained on a small one):

More than 100k instances per month.
More than 70 squares
Over 30 integrations with other systems
Fast growing backlog

This is the process of opening a current account in Tinkoff Business. It was not possible to transfer such a process in one approach, a pause of 3-4 months in development would be required, which is not very suitable for the pace of business development.
We decided to move to pieces and refactor everything that comes to hand. And to solve the problem of noisy neighbors, we made a separate application, which was responsible only for applications for cash settlement services.

At the top level, the process looks like this:

Transition Rules

No. 1: Stopped digging

We decided to stop making new features in the old application. When the task appeared in the backlog, we tried to identify the box \ component \ service to which it relates and rewrote this thing from scratch in Camunda. Sometimes at a cost it was 1.2x (x - if they were doing at IBM), sometimes - 3x or 5x.

# 2: Camunda doesn't know anything about IBM

After refactoring, we just wanted to turn off the old application, so we decided to make new features in Camunda so that it knew nothing about IBM at all. Two things helped us:

Business data stored in Siebel
Ready-made APIs from Camuda that help you fully understand how and how the process ended.

As a result, we made a process at IBM that starts and receives the result from Camunda:

No. 3: Long “manual tasks” and gluing processes

First, we moved simple, one-step synchronous calls to Camunda and everything worked well. After that, we began to glue these things into normal “business processes”, where expectations from users began to appear.
Users can do their tasks for years, so we started to have a bunch of tasks to manually fix processes from the trashhold. We won this way - we just started to take into account the type of a specific task in Camunda and not take into account the trashhold on tasks where a long wait is possible.

No. 4: Feature toggling at the fork

Some pieces of code were so confused that it was easier to write from scratch and see if it worked fine. To do this, introduced into IBM feature toggling with gateways. We sent a small stream of applications to Camuda and looked at the pens, everything is ok.

Migrating instances from IBM to Camunda

Ultimately, the process at IBM consisted only of calls to Camunda, and 3 levels of processes were collected at Camunda. The business processes themselves have not changed much, so we managed to transfer the old instances from IBM to Camunda to the same waiting points. And shut down IBM.

What to do if you have a similar situation

If you want to move to Camunda with the BPMS legacy, then:

Move the context to a separate database.
Move user interfaces to a separate application.
Stop coding new functionality in the old application.
Use one-way calls so that Camunda does not know about the old system.
Start with small boxes, but don't forget about long custom tasks.

This approach helped us to reduce the number of incidents by 14 times, the regression time by 4 times, made it possible to release day-to-day and reduced the cost of manual testing by 4 times. Now 5 people are working on the project and doing the same amount of work as 9 people with IBM. I hope your results will be no worse.

Invitation to mitap No. 4 by Camunda

February 27, 2020 (Thursday) at 19:30 at Moscow, Golovinskoye Shosse 5A, Vodny Business Center, we will hold another meeting on Camunda. You can register and read about the speakers at the link . Come!

How to migrate a large process from IBM BPM to Camunda and not stop feature development