🍞 👩🏽‍✈️ 👨🏻‍💼 Comment migrer un processus volumineux d'IBM BPM vers Camunda et ne pas arrêter le développement de fonctionnalités 🚎 🀄️ ⚱️

Bonjour, je m'appelle Denis, je travaille chez Tinkoff et je fais des systèmes BPM. Dans cet article, je vais vous expliquer comment migrer de l'héritage de systèmes à la IBM BPM vers le moteur de processus open source Camunda en utilisant l'exemple d'un grand processus. Et à la fin je vous inviterai à la quatrième réunion sur Camunda, qui se tiendra le 27 février à Tinkoff, à Moscou (métro Vodny Stadion) dans la soirée.

Les systèmes BPMS et BPMN comme moyen de les programmer

L'idée selon laquelle la programmation peut être programmée est bien vendue , le marché croît d'année en année. Certaines entreprises obtiennent des résultats vraiment sympas.
Pour réaliser de bons projets et vendre avec succès, les systèmes BPMS, en plus de «manger» des fichiers BPMN, doivent également pouvoir:

Identifier des acteurs spécifiques dans les processus
Fournir des interfaces pour les utilisateurs, les implémenteurs et les administrateurs
Appelez des services externes, envoyez et écoutez des événements, etc. En général, être capable de "tomber" dans le code
Fournir la modélisation et le stockage des données
Suivez les règles de l'entreprise
Testez tout ce qui a été créé

Nous avons utilisé IBM BPM BPMS à Tinkoff, ce qui nous a aidés à nous développer en raison de sa complexité et de la couverture acceptable de ces fonctionnalités. Mais nous avons décidé de le refuser.

Raisons d'abandonner IBM BPM

Nous avons réalisé que grâce à la grande fonctionnalité du système BPMS, nous n'utilisons que:

Interprétation des fichiers bpmn
Tomber dans le code

D'autres choses ont été transférées à d'autres systèmes, par exemple:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
Le stockage des données quelque part a été déplacé vers Siebel - dans des situations où de nombreux consommateurs ont besoin d'opérations CRUD sur les données, et quelque part - dans des applications distinctes. IBM BPM vous permet de simuler des données dans un style relationnel, il crée les plaques du modèle. Mais il stocke tout dans une base de données pour tous les processus, ce qui crée une connectivité et une charge supplémentaires sur la base de données.
Pour les règles métier, nous utilisons traditionnellement IBM ODM, et maintenant nous commençons à utiliser notre framework Kotlin.
Normalement, dans le style de développement, nous n'avons pas appris à tester des applications sur IBM BPM.

Il y avait des questions générales que nous n'avons pas aimées:

Nous sommes passés à Kotlin et Spring, ce qui est difficile dans IBM BPM.
Très peu de spécialistes ou ceux qui souhaitent travailler avec ce produit.
Difficultés de développement conjoint de schémas \ code, essentiellement un mode de développement monopolistique.
4 3 ( ~40 ), .

Par ailleurs, il convient de mentionner le problème des voisins bruyants - les restrictions de licence nous ont obligés à regrouper de nombreux produits dans un seul cluster. Nous avons essayé de réutiliser le code commun dans différents processus métier, ce qui a créé des difficultés avec sa modification.

Par exemple, il y avait un code d'envoi de SMS utilisé par 2 produits - les services de règlement en espèces et la comptabilité externalisée. Auparavant, le texte était codé en dur au niveau des composants, mais maintenant le processus de «sous-traitance comptable» voulait transférer le texte du SMS du processus. Mais le processus du SCC ne le voulait pas, mais des changements doivent être apportés partout.

Ou des bugs banals pourraient mettre toute la base de sorte que de nombreux produits ne fonctionnent pas, bien qu'ils ne soient pas à blâmer.

Pourquoi ont-ils choisi Camunda, avait écrit mon collègue Nikolai dans un précédent post.

Qu'est-ce qu'un gros processus

Nous avons décidé de transférer le grand processus d'IBM (au début, cependant, nous nous sommes formés sur un petit):

Plus de 100 000 instances par mois.
Plus de 70 carrés
Plus de 30 intégrations avec d'autres systèmes
Carnet de commandes à croissance rapide

Il s'agit du processus d'ouverture d'un compte courant dans Tinkoff Business. Il n'a pas été possible de transférer un tel processus dans une seule approche, une pause de 3 à 4 mois de développement serait nécessaire, ce qui n'est pas très adapté au rythme de développement des affaires.
Nous avons décidé de déménager et de refaçonner tout ce qui vient à portée de main. Et pour résoudre le problème des voisins bruyants, nous avons fait une demande distincte, qui n'était responsable que des demandes de services de règlement en espèces.

Au niveau supérieur, le processus ressemble à ceci:

Règles de transition

N ° 1: Arrêt des fouilles

Nous avons décidé d'arrêter de créer de nouvelles fonctionnalités dans l'ancienne application. Lorsque la tâche est apparue dans le backlog, nous avons essayé d'identifier la boîte \ composant \ service à laquelle elle se rapporte et réécrit cette chose à partir de zéro dans Camunda. Parfois à un coût, c'était 1,2x (x - si c'était le cas chez IBM), parfois - 3x ou 5x.

# 2: Camunda ne sait rien d'IBM

Après refactoring, nous voulions simplement désactiver l'ancienne application, nous avons donc décidé de créer de nouvelles fonctionnalités dans Camunda afin qu'il ne sache rien du tout d'IBM. Deux choses nous ont aidés:

Données commerciales stockées dans Siebel
API prêtes à l'emploi de Camuda qui vous aident à comprendre comment et comment le processus s'est terminé.

En conséquence, nous avons fait un processus chez IBM qui démarre et reçoit le résultat de Camunda:

N ° 3: longues «tâches manuelles» et processus de collage

Tout d'abord, nous avons transféré des appels synchrones simples et en une seule étape vers Camunda et tout a bien fonctionné. Après cela, nous avons commencé à coller ces choses dans des «processus commerciaux» normaux, où les attentes des utilisateurs ont commencé à apparaître.
Les utilisateurs peuvent effectuer leurs tâches pendant des années, nous avons donc commencé à avoir un tas de tâches pour réparer manuellement les processus à partir de la corbeille. Nous avons gagné de cette façon - nous avons juste commencé à prendre en compte le type de tâche spécifique dans Camunda et non à prendre en compte la corbeille sur les tâches où une longue attente est possible.

N ° 4: Fonction de basculement à la fourche

Certains morceaux de code étaient si confus qu'il était plus facile d'écrire à partir de zéro et de voir si cela fonctionnait bien. Pour ce faire, introduit dans la fonction IBM basculer avec les passerelles. Nous avons envoyé un petit flux d'applications à Camuda et regardé les stylos, tout va bien.

Migration d'instances d'IBM vers Camunda

En fin de compte, le processus chez IBM consistait uniquement en appels à Camunda, et 3 niveaux de processus ont été collectés chez Camunda. Les processus métier eux-mêmes n'ont pas beaucoup changé, nous avons donc réussi à transférer les anciennes instances d'IBM vers Camunda vers les mêmes points d'attente. Et arrêtez IBM.

Que faire si vous avez une situation similaire

Si vous souhaitez passer à Camunda avec l'héritage BPMS, alors:

Déplacez le contexte vers une base de données distincte.
Déplacez les interfaces utilisateur vers une application distincte.
Arrêtez de coder de nouvelles fonctionnalités dans l'ancienne application.
Utilisez les appels unidirectionnels pour que Camunda ne connaisse pas l'ancien système.
Commencez avec de petites boîtes, mais n'oubliez pas les longues tâches personnalisées.

Cette approche nous a permis de réduire le nombre d'incidents de 14 fois, le temps de régression de 4 fois, a permis de publier au jour le jour et a réduit le coût des tests manuels de 4 fois. Maintenant, 5 personnes travaillent sur le projet et font la même quantité de travail que 9 personnes avec IBM. J'espère que vos résultats ne seront pas pires.

Invitation à mitap n ° 4 par Camunda

Le 27 février 2020 (jeudi) à 19h30 à Moscou, Golovinskoye Shosse 5A, Vodny Business Center, nous tiendrons une autre réunion sur Camunda. Vous pouvez vous inscrire et lire sur les intervenants sur le lien . Viens!

Comment migrer un processus volumineux d'IBM BPM vers Camunda et ne pas arrêter le développement de fonctionnalités