Les rouages ​​d'une banque moderne tournent conformément aux processus commerciaux financiers. Ils sont plus compliqués que d'habitude - cette règle fonctionne pour tout, à laquelle vous ajoutez la définition de «financière». D'une part, tout est compliqué par les régulateurs, les innombrables approbations et les parties impliquées. De l'autre - BPMS monolithique maladroit (Business Process Management System). Dans cet article, nous vous expliquerons comment vous avez réussi à abandonner un tel système et à opter pour un open source flexible et fonctionnel.
Les programmeurs affichent les processus métier en utilisant différentes notations. Maintenant, la norme est BPMN (Business Process Model and Notation) - ce sont des fichiers XML avec des images qui leur sont attachées. Pour travailler avec cette notation, des produits BPMS sont créés - des systèmes propriétaires monolithiques qui tentent de prendre en charge le maximum d'outils pour développer le BPM: de l'éditeur d'interface utilisateur au système de contrôle de version.
Seuls les développeurs qui utilisent ces systèmes depuis longtemps peuvent les étendre. Dans BPMS d'entreprise, une API REST est fournie, c'est-à -dire que les systèmes sont accessibles et reçus en réponse. Mais la modification et le réglage en profondeur de BPMS lui-même est presque impossible. Il est possible de travailler avec un tel BPMS uniquement à travers un ensemble limité d'outils par le fabricant - un système de contrôle de version propriétaire, un compilateur, un déployeur - généralement pour chaque grand BPMS, un ensemble complet est développé. Ces outils se développent lentement, les mêmes problèmes peuvent persister de version en version, car peu de personnes sont impliquées dans le travail, comme c'est le cas avec l'open source. En général, les capacités de BMPS d'entreprise et les besoins de leurs utilisateurs coïncident très rarement.
Dans la publicité de tels systèmes, ils parlent de workflow de bout en bout, ils disent que l'entreprise elle-même peut changer les processus BPM à la volée. Mais en fait, même les analystes ne peuvent pas le faire - seuls les développés peuvent le gérer.
Un processus métier se compose de tâches d'utilisateur et de service dont les séquences mènent à l'arrêt final. Dans BPMS, grâce à de tels schémas, vous pouvez suivre le temps d'exécution des processus métier, ainsi que divers indicateurs métier - par exemple, KPI.Nous devons souvent apporter des modifications de différentes tailles aux processus métier. Auparavant, nous avions un processus BPM pour les gestionnaires de clients qui occupent des bureaux supplémentaires. En 2015, nous avons fermé certains bureaux et transféré des managers sur le terrain. Cela a nécessité de grands changements dans les processus BPM, il a fallu introduire d'autres rôles, actions. Ou, par exemple, la réglementation du service de sécurité économique a changé, et au lieu de deux coordinateurs, il y en a maintenant trois.
Tout d'abord, nous avons apporté des modifications via le BPMS IBM Lombardi. Ayant recueilli les défauts typiques des systèmes de sa classe, il se distinguait également par le manque de documentation ordonnée. Il semblait qu'après l'achat de Lombardi Software, le géant du logiciel a regardé le nuage amorphe des articles qui l'accompagnaient et a décidé de ne rien toucher. Et même après avoir lu toute la documentation, il était impossible de faire beaucoup de choses. Par exemple, appelez une demande REST avec authentification HTTPS à l'aide d'un certificat utilisateur. Heureusement, la recherche d'une alternative a été un succès.
Camunda résout les problèmes
Après avoir travaillé avec IBM BPM, nous sommes arrivés à la conclusion que différents groupes d'utilisateurs devraient pouvoir modifier les processus métier. Quelque chose d'insignifiant dans le mode en ligne peut être apporté par les employés ordinaires des unités commerciales. Les analystes système modifient la séquence des tâches dans les processus métier. Les nouvelles intégrations, les changements dans l'interface utilisateur et le code du programme restent du côté des développeurs. Et afin de maintenir cette flexibilité, tous les BPMS doivent être déployés sur des microservices.
Nous pouvons fournir cette approche avec BPMS Camunda open source. C'est une fourchette du projet Activity, que l'équipe de développement a décidé de faire plus de vente. Ils ont mis en ordre la documentation et ont commencé à développer Camunda séparément, ils gagnent sur la vente de support.
BPMS Camunda vous permet de modifier les processus métier à l'aide de Java standard et prend en charge le partage de microservices. Le passage de BPMS aux microservices offre plusieurs avantages à la fois:
- Se débarrasser du monolithe. Nous pouvons diviser les processus métier par segments, en les reliant à l'aide de Rabbit MQ ou Kafka via la file d'attente. Les processus métier peuvent être modifiés isolément les uns des autres, effectuer des modifications sans attendre une version complète.
- Se débarrasser d'un serveur de processus métier.
- Mise à l'échelle. Si un serveur commence à tomber en charge, il peut être cloné. Aux pics de charge, vous pouvez facilement augmenter la productivité en exécutant plusieurs instances de processus métier dans différents services.
- Versioning Si, par exemple, vous devez mettre à jour la version Java, vous pouvez récupérer plusieurs microservices avec différentes versions de Java et exécuter la nouvelle version en parallèle. Chaque microservice peut avoir non seulement différentes versions de logiciels, mais également différentes langues.
À l'avenir, nous prévoyons de transférer l'un de nos plus grands processus commerciaux à Camunda - les prêts aux entreprises. Ici, tout est beaucoup plus compliqué que celui des particuliers et même celui des petites et moyennes entreprises. Ce n'est pas un produit mais un système de crédit limité qui est appliqué, les limites sont limitées dans le temps, les emprunteurs font généralement partie d'organisations plus importantes telles que les exploitations et les exploitations ont autre chose à faire. Les limites sont déterminées séparément pour chacune de ces structures, et chaque structure a ses propres correspondances, dont la composition est en constante évolution. Nous obtenons un processus commercial à partir de centaines d'étapes. Nous avons pu le changer avec Camunda et avons décidé de rester dessus. Même si les développeurs décident maintenant de fermer le projet, les capacités actuelles du système dureront encore trois ans.
Notre première version de Camunda était basée sur Websphere et, en fait, n'était pas très différente d'IBM Lombardi. Nous avons décidé d'écrire les applications auxquelles le service a accédé sur Spring Boot. Ils se sont déployés sur Tomcat et n'ont pas travaillé seuls. Ensuite, il s'est avéré que Camunda pouvait fonctionner sur Tomcat, une version pour Spring Boot a été développée. Une architecture de microservice complète y est déjà disponible. Toutes les applications avec lesquelles le processus métier fonctionnait ont été implémentées sur une architecture de microservices basée sur Spring Cloud.
Il s'est ensuite avéré que vous pouvez modifier rapidement les fonctionnalités non seulement dans les services qui servent le processus métier. Le moteur BPM lui-même peut être connecté à n'importe quelle application Springboot en tant que bibliothèque.
Camunda comme microserviceLa question s'est posée: combien de microservices à lever? Il était possible de créer un serveur pour chaque processus et d'y placer tous les microservices, ou de créer chaque microservice et un processus métier distinct pour chaque tâche. La seconde serait plus pratique, mais il faudrait organiser l'interaction des processus dispersés à travers les microservices individuels. Nous avons essayé plusieurs options et trouvé une solution lorsque plusieurs microservices sont responsables d'un certain sujet et que plusieurs processus y sont regroupés. La communication s'effectue via REST ou via Rabbit MQ. Maintenant, ils ont lancé un pilote sur Kafka.
Perspectives pour BPMS
Les processus métier affichent non seulement le flux de travail métier, mais répondent également aux événements qui se produisent dans d'autres systèmes. Nous avons ces événements accumulés par une division distincte du Big Data. Sur la base de l'analyse de ces événements, de nouveaux processus commerciaux sont créés ou des processus existants sont modifiés - cela se produit après coup, avec une fréquence, par exemple, une fois par jour.
Idéalement, les processus métier devraient évoluer en ligne - par exemple, lorsque la demande pour certains services augmente, ils hiérarchiseront automatiquement leur mise en œuvre et réaffecteront les ressources. Cela peut être réalisé grâce à l'automatisation, l'interaction, par exemple, Kafka et Camunda, mais c'est une question d'au moins plusieurs années. Peut-être que maintenant dans le sens des changements dans le mode en ligne, la plus avancée est la banque Monzo anglaise entièrement en ligne. Et nous y travaillons également.