Les clients d’aujourd’hui recherchent des services agiles, rapides, flexibles et composables. Des services qui ne sont ni entravés ni encombrés. Des services faciles d’accès et encore plus faciles à expérimenter. Des services rapides et précis. Ces facteurs influencent le CSAT et le NPS collectifs d’une entreprise moderne. Les entreprises le reconnaissent et c’est pourquoi environ 85 % des entreprises de taille moyenne à grande utilisent déjà l’architecture de microservices. L’architecture distribuée des applications à microservices rend les composants des applications indépendants, décentralisés, résistants aux pannes, entretenus et mis à jour isolément; ce qui favorise ainsi l’autosuffisance, la scalabilité, la fiabilité du système et la simplification des offres de services.
Cependant, si l’architecture des microservices prépare l’application à des services agiles, la véritable expérience client ne provient pas uniquement des composants découplés de l’application, mais de la manière dont chaque étape d’un parcours de réussite client déclenche automatiquement une étape logique suivante pour assurer la satisfaction du client. En effet, à mesure que le processus métier s’étend et que d’autres composants sont ajoutés, le « chaos de cohésion » peut devenir réalité. L’absence d’une orchestration adéquate des étapes du processus dans un flux logique, en gardant l’objectif final du client à l’esprit, peut rapidement rendre les avantages supposés du paysage des microservices inutiles.
Ainsi, les applications à microservices peuvent être regroupées et la séquence des étapes dans chaque flux de processus peut être orchestrée via une plateforme de diffusion d’événements comme Kafka tout en étant gérées et gouvernées par un moteur BPM ou d’intégration, tel que RHPAM, Camunda, ou même MuleSoft, qui promet la coexistence fluide d’une architecture menée par les API et d’une architecture basée sur les événements. Une telle architecture encapsulera divers microservices dans un flux d’événements, chaque service étant attentif à l’action entreprise par un utilisateur à travers le sujet publié dans le flux d’événements et, en fonction de cette action, déclenchant un service correspondant selon le flux de processus logique défini. Par conséquent, chaque service est autonome et agit ou réagit en fonction de son point de déclenchement, dans l’esprit même de l’orchestration pilotée par les événements.
Dans mes conversations avec des entreprises à travers différentes régions et secteurs, les clients testent généralement ce modèle de service via une plateforme de diffusion d’événements comme Kafka, ou orchestrent le service de manière centralisée via un moteur BPMN comme RHPAM. Cependant, chacune de ces options a ses avantages et ses inconvénients. Le modèle hybride qui considère à la fois un moteur BPMN pour l’orchestration centralisée des processus et la coordination avec les services de travail via un flux d’événements connaît un très bon engouement et l’essor de géants de l’intégration d’entreprise tels que MuleSoft — qui prétendent prendre en charge l’architecture pilotée par les événements en plus de l’intégration menée par les API plus familière — rend les options de solutions très intéressantes pour les clients.
Analysons ces scénarios un par un en prenant l’exemple de Bob, qui veut réserver un Ridola d’Amsterdam à Den Haag, et voyons quels services doivent interagir pour que l’expérience soit agréable pour Bob et comment certains de ces outils peuvent rendre cette expérience fluide.
Le mécanisme en jeu lors de la commande d’un Ridola par Bob :
Lors de la commande d’un Ridola, en supposant qu’il s’inscrit pour la toute première fois, Bob ouvre l’application et va parcourir le trajet suivant à travers les microservices suivants : Service Profil Client – Service de géolocalisation, gestion des taxis et conducteurs, gestion de trajet et paiements.
La chaîne de valeur, en termes simples, commence lorsque Bob ouvre l’application, s’inscrit en fournissant ses informations de profil, puis choisit les lieux de départ et d’arrivée de son trajet, après quoi Ridola recherche et recommande les taxis et conducteurs disponibles à proximité avec le tarif associé. Dès que Bob choisit son taxi, le service de gestion de trajet organise le voyage en guidant le conducteur et en amenant à Bob le taxi choisi, lance le trajet d’Amsterdam à Den Haag, et une fois le trajet terminé, Bob est invité à payer et, après paiement, une facture est envoyée à son adresse courriel.
Options disponibles pour Ridola pour offrir un service bien orchestré à Bob :
Orchestration centralisée pilotée par BPMN : Dans cette approche, Ridola intègre le flux de travail métier dans le moteur BPM centralisé (par exemple RHPAM, Camunda, etc.) Ces technologies BPM suivent la Business Process Modeling Notation (BPMN), qui est une norme pour la modélisation des processus métier. L’intégration entre l’interface utilisateur passager et l’application se fait via REST. Dès que Bob se connecte à l’application, le moteur centralisé (cerveau du flux de travail métier) envoie des commandes aux services de travail et attend leur réponse. De telles commandes sont émises par le délégué Java ou un outil comme AWS Lambda. L’ensemble du « service de commande de taxi » est construit comme un microservice Springboot.
Cela signifie que la première commande du moteur centralisé, après la connexion de Bob, sera envoyée au service de profil client qui s’ouvrira et invitera Bob à se connecter. À la fin de cette étape, le moteur centralisé ordonnera au service de localisation de s’activer pour demander à Bob sa localisation actuelle ainsi que ses gares de départ et d’arrivée. Ensuite, le service de gestion des taxis et des conducteurs est déclenché de façon centralisée, et ainsi de suite.
Figure : Architecture d’orchestration basée sur BPMN
Le point essentiel à retenir dans cette approche est le moteur d’orchestration centralisé qui déclenche les actions sur les services de travail. Les services de travail ne se transmettent pas mutuellement la commande. Tout est géré centralement selon les standards BPMN, facilitant ainsi la maintenance, le soutien et la mise à niveau. Le moteur BPM peut aussi devenir le référentiel unique fournissant les mises à jour transactionnelles, l’état du service, etc., et donc une source pour piloter l’observabilité.
Cependant, à l’inverse, une telle intégration un-à-un entre le moteur d’orchestration centralisé et chacun des services de travail peut rendre le paysage « étroitement couplé », avec une « intégration point à point », précisément ce qu’une entreprise souhaite éviter en adoptant une architecture à microservices. Ainsi, même si cette approche est appropriée quand le nombre de transactions est faible, pour une grande entreprise comme Ridola, avec un nombre massif de transactions, cette approche peut rapidement surchauffer le moteur d’orchestration et dégrader l’expérience que Ridola souhaite offrir au client final.
Orchestration pilotée par les événements : Contrairement à l’approche centralisée explorée dans la section précédente, de nombreux clients semblent opter pour une orchestration menée par une plateforme de diffusion d’événements. Cela peut impliquer l’utilisation de technologies comme Apache Kafka, IBM Data Streams, Amazon Kinesis, Confluent, etc. Il s’agit d’une approche décentralisée où la logique métier est répartie dans tous les microservices que Bob utilisera pour son service de taxi Ridola. Chacun de ces services – que ce soit le service de profil client, le service de localisation, le service de gestion des taxis et conducteurs, la gestion des trajets ou le service de paiement – est intégré avec un flux d’événements central (par exemple, Kafka ou Confluent) et écoute le sujet qui correspond à son service. Ce sujet publié dans le flux d’événements résulte de l’action effectuée par Bob (en se connectant à l’application) ou de l’action effectuée par le service précédent (par exemple, le service de profil client). Ce sujet sert également de déclencheur pour le service suivant (par exemple, le service de localisation) afin qu’il interroge Bob à propos de sa localisation et de ses gares de départ et d’arrivée. De même, chaque service connaît son tour et sa responsabilité grâce au sujet publié sur le flux d’événements, et le processus de commande de taxi s’enchaîne de service en service selon une véritable logique d’événement.
Figure : Orchestration basée sur la diffusion d’événements
Alors que cette approche introduit le « couplage lâche » qui faisait défaut à la première, la maintenance et l’entretien des services deviennent fastidieux lorsque le processus métier global change, ce qui affecte les sous-services de la chaîne de valeur. De plus, il n’y a pas d’observabilité centralisée de la performance, et il faut consulter chaque service pour les journaux et traces. Cela signifie qu’en cas d’erreur ou de dépannage, il faudra vérifier chaque service un à un, ce qui prendra du temps.
Cependant, si une chaîne de valeur de processus est assez bien définie et que les services qui la composent sont bien établis, cette approche peut fonctionner. Le responsable métier doit évaluer les scénarios et prendre la décision adéquate.
Approche hybride – orchestration d’événements menée par BPMN : De nombreux clients comprennent la puissante combinaison des deux approches précédentes et choisissent de réaliser une preuve de valeur puis une mise en œuvre complète de cette solution hybride. Ici, le moteur BPM centralisé (RHPAM ou Camunda) héberge la logique métier, mais la communication avec les services de travail en aval ne se fait pas de manière point à point. Cette communication est établie via le courtier d’événements. Ainsi, le couplage lâche est assuré entre les services.
Figure : Orchestration d’événements menée par BPMN
Comme illustré ci-dessus, dès que Bob se connecte à l’application, le moteur centralisé envoie les commandes aux services de travail via les flux d’événements et attend leurs réponses. Ces commandes sont émises par le délégué Java ou un outil comme AWS Lambda.
Grâce à cette approche, l’entreprise bénéficie d’une gouvernance centralisée et d’avantages en matière d’observabilité sans rendre l’écosystème étroitement couplé et difficile à maintenir. Il s’agit d’un très bon modèle pour les grandes entreprises et il connaît une large adoption.
MuleSoft + Orchestration pilotée par les événements : L’intégration d’entreprise est incontournable dans toute grande entreprise et la plupart des entreprises aujourd’hui, y compris Ridola, misent sur l’intégration menée par les API. Cependant, même dans une architecture menée par les API (de nature synchrone), il existe des scénarios où la communication asynchrone devient essentielle pour l’entreprise. C’est là que l’architecture pilotée par les événements vient compléter l’architecture API, les deux pouvant coexister harmonieusement afin de garantir qu’un client comme Bob ne soit pas pénalisé en raison des limites architecturales internes.
Voici quelques scénarios dans lesquels cette association du synchrone (mené par API) et de l’asynchrone (mené par événement) s’avère possible :
Mises à jour asynchrones des bases de données : MuleSoft suit une architecture à trois couches avec des API d’expérience au sommet servant les clients sur plusieurs canaux, des API de processus qui servent de pipelines pour traiter la tâche réelle et transmettent le résultat aux API d’expérience, et les API système à la base qui sont la source des données d’entreprise exploitées par les API de processus pour rendre la solution contextuelle et sur mesure.
Il se peut que survienne une avalanche de demandes client et que les API de processus soient submergées par la nécessité répétée d’aller chercher les données auprès des API système. Ces allers-retours peuvent ajouter de la latence dans la satisfaction des besoins des API d’expérience.
Figure : Une couche de diffusion d’événements entre les API système et processus accélère le traitement
C’est dans ce scénario (comme illustré ci-dessus) qu’un courtier d’événements peut servir de réserve pour les informations les plus demandées (par exemple les informations client) et agir comme « guichet unique » pour ces informations destinées aux API de processus, mettre à jour de façon asynchrone les systèmes appropriés, évitant ainsi tout appel inutile et répété au système CRM pour chaque requête d’API de processus.
MuleSoft dispose de connecteurs vers divers systèmes permettant de capter le changement de données et de le publier sous forme d’événements simples auprès du courtier d’événements. Les applications en amont peuvent alors agir en tant que consommatrices d’événements et s’abonner à ces événements pour mettre à jour les systèmes finaux.
Traitement différé dû à une surcharge du système et accusé de réception des demandes client : Parfois, lorsque la couche système tombe après avoir atteint sa capacité maximale, les échanges entre les API d’expérience, de processus et système continuent inutilement, surchargeant encore plus le système. Il se peut aussi que le système soit en maintenance durant le week-end, mais que des demandes soient reçues pendant cette période.
Dans ce cas, les applications pilotées par MuleSoft peuvent générer des événements simples pour chaque demande au niveau des couches d’expérience ou de processus, ces événements étant stockés dans un courtier d’événements jusqu’à ce que le système final soit prêt à traiter la demande. Le système demandeur accusera réception de la demande client, celles pouvant être traitées à l’aide des API de processus ou système disponibles le seront en temps opportun. Pour celles pour lesquelles les informations ne sont pas suffisantes, une notification signalant un délai possible pourra être envoyée pour éviter toute déception client.
Ce sont là les thèmes majeurs qui émergent chez les clients modernes désireux de tirer parti du meilleur des architectures menées par API et par les événements pour assurer un service client fluide, tout en évitant une surcharge inutile sur les systèmes.
Conclusion :
Les entreprises naviguent dans « l’économie de l’expérience » et la seule façon de gagner des parts de marché est de gagner la confiance des clients. C’est là que l’orchestration d’événements menée par BPMN et un équilibre stratégiquement trouvé entre API et architecture pilotée par événement assurent la résilience du système, le pragmatisme des processus et une expérience client remarquable, le tout dans la continuité. C’est le bon moment pour que les entreprises examinent des cas d’usage propres à leur domaine, puis évaluent comment une combinaison des approches ci-dessus peut les aider dans leur démarche d’affaires. Toutes ces approches ont leurs avantages et inconvénients et dépendent de plusieurs facteurs comme la maturité de la chaîne de valeur du processus d’une entreprise, la fréquence et l’intensité des changements, l’ampleur de ces changements, le nombre de transactions, la taille de la clientèle, etc.
Prendre la bonne décision et choisir l’option adaptée au bon cas d’usage peut s’avérer un processus difficile qui nécessite une diligence raisonnable. Ainsi, de nombreuses entreprises à travers le monde s’associent aux principaux intégrateurs de systèmes de l’écosystème. Par conséquent, si vous envisagez de vous lancer dans l’orchestration d’événements, de nombreux partenaires sont prêts à vous guider et à vous accompagner dans votre parcours. Lancez-vous dès maintenant !!
