The gears of a modern bank revolve in accordance with financial business processes. They are more complicated than usual - this rule works for everything to which you add the definition of “financial”. On the one hand, everything is complicated by regulators, an innumerable number of approvals and involved parties. On the other - slow-moving monolithic BPMS (Business Process Management System). In this post we will describe how successfully we abandoned one such system and went into a flexible and functional open source.
Programmers display business processes using different notations. Now the standard is BPMN (Business Process Model and Notation) - these are XML files with images attached to them. To work with this notation, BPMS products are created — monolithic proprietary systems that try to accommodate a maximum of BPM development tools: from the user interface editor to the version control system.
Only developers who have been working with these systems for a long time can extend them. REST API is provided in the enterprise BPMS, that is, systems can be accessed and the data received in response. But modification and deep tuning of the BPMS itself is almost impossible. Working with such BPMS is possible only through a manufacturer-limited set of tools — a proprietary version control system, a compiler, a depiler — usually a whole set is developed for each large BPMS. These tools are developing slowly, from release to release the same problems can persist, since not so many people are involved in the work, as is the case with open source. In general, the capabilities of enterprise BMPS and the needs of their users very rarely coincide.
In advertising such systems they talk about the end-to-end workflow, they say that the business itself can change BPM processes on the fly. But in fact, even analysts cannot do this - only developed ones can handle it.
The business process consists of user and service tasks, the sequence of which leads to the final stop. In BPMS, through such schemes, you can track the run-time of business processes, as well as various business indicators - for example, KPI.Changes of different scale in business processes we have to make often. We used to have a BPM process for client managers sitting in additional offices. In 2015, we closed part of the offices, and managers were transferred to field work. This required large changes in BPM processes, it was necessary to introduce other roles, actions. Or, for example, the regulations of the economic security service have changed, and instead of two matching ones, there are now three.
We first made changes through the IBM Lombardi BPMS. Having collected typical drawbacks of systems of its class, it was also distinguished by the absence of orderly documentation. It seemed that after the purchase of Lombardi Software, the software giant looked at the amorphous cloud of accompanying articles and decided not to touch anything. And even after re-reading all the documentation, it was impossible to do many things. For example, invoke a REST request with HTTPS authentication using a user certificate. Fortunately, the search for alternatives was crowned with success.
Camunda solves problems
After working with IBM BPM, we came to the conclusion that different groups of users should be able to change business processes. Regular employees of business units can contribute something insignificant online. System analysts change the sequence of tasks in business processes. New integration, changes in the UI and program code remain on the side of developers. And in order to maintain this flexibility, the entire BPMS must be deployed on microservices.
We can provide this approach using open-source BPMS Camunda. It is a fork of the Activity project, which the development team decided to make more salable. They put the documentation in order and began to develop Camunda separately, earning on selling support.
BPMS Camunda allows you to edit business processes using standard Java and supports the division into microservices. The transition of BPMS to microservices provides several advantages at once:
- Disposal of the monolith. We can divide business processes into segments, linking them to each other using Rabbit MQ or Kafka through queues. Business processes can be changed in isolation from each other, rolling changes without waiting for the full release.
- Getting rid of the server business processes.
- Scaling. If a server starts to fall under load, then it can be cloned. At peak loads, you can easily increase productivity by running multiple instances of business processes in different services.
- Versioned. If, for example, you need to update your Java version, you can raise several microservices with different Java versions and run the new version in parallel. In each microservice there can be not only different versions of software, but also different languages.
In the future, we plan to transfer one of our largest business processes to Camunda - corporate lending. Here everything is much more complicated than that of physical persons and even than that of small / medium business. Not a grocery, but a limit crediting scheme is used, the limits are limited in time, borrowers usually enter into larger organizations such as holdings, and holdings into something else. The limits are determined separately for each of these structures, and each structure has its own matching, the composition of which is constantly changing. We get a business process from hundreds of stages. We were able to change it with Camunda and decided to stay on it. Even if the developers decide to close the project now, the current capabilities of the system will be enough for another three years.
Our first version of Camunda was on Websphere and in fact differed little from IBM Lombardi. We decided to write the applications to which the service was addressed in Spring Boot. They deployed on Tomcat and did not work on their own. Then it turned out that Camunda can work on Tomcat, a version for Spring Boot was developed. The full microservice architecture has already become available there. All applications with which the business process worked were implemented on the microservice architecture based on Spring Cloud.
Then it turned out that you can quickly change the functionality not only in the services that serve the business process. The BPM engine itself can be connected to any springboot application as a library.
Camunda as microserviceThere was a question: how many microservices to raise? It was possible to make one server for each process, and to place all microservices there, or for each task to make its own microservice and in it a separate business process. The second would be more convenient, but would have to organize the interaction of processes scattered across individual microservices. We tried several options and settled on a solution when several microservices are responsible for a certain topic and several processes are grouped there. Communication takes place either through REST or through Rabbit MQ. Now they have also launched a pilot on Kafka.
BPMS Perspectives
Business processes not only display business flow, but react to events occurring in other systems. We have these events accumulates a separate division of Big Data. Based on the analysis of these events, new business processes are created or existing ones change - this happens after the fact, at intervals, for example, once a day.
Ideally, business processes should move on to changing online — for example, as demand for certain services increases, they automatically prioritize their execution and reallocate resources. This can be achieved through automation, interaction, for example, Kafka and Camunda, but this is a question for at least several years. Perhaps the most fully online English Monzo Bank has now moved towards changes in online mode. And we are also working on it.