Les API sont très souvent mis en avant dans le domaine de l’intégration et du middleware. Pourtant, seuls, ils ne peuvent pas représenter toute la diversité des patterns d’intégration. En effet, il faut combiner plusieurs technologies d’intégration pour couvrir tous les cas d’usage. Par exemple, nous pouvons rapprocher les deux grands patterns du marché de l’intégration (logique modulaire portée par l’API Management et logique de masse portée par l’intégration Data) afin de former une approche commune de l’intégration : une plateforme d’intégration hybride de deuxième génération.
Ainsi, l’approche Service / API et l’approche Data peuvent être fédérées par l’ingestion, la sécurité, et surtout les scénarios d’intégration. Nous allons préciser ces différents niveaux d’intégration dans cet article.
Nous avons conclu la première partie de cet article en introduisant le sujet des scénarios d’intégration, qui accompagnent la structuration du middleware.
Pendant des années, les entreprises ont empilé des capacités d’intégration, plusieurs générations de technologies, parfois redondantes. Nous sommes intervenus fin 2019 dans une entreprise du secteur de la distribution bâtiment : elle cumulait douze solutions de middleware, sans aucune gouvernance.
Dans le cadre de cette mission, nous avons émis des préconisations, regroupées dans un schéma directeur middleware et intégration, qui définissait la stratégie d’intégration de l’entreprise.
Elle préconisait de fusionner au sein d’une même plate-forme :
● Les capacités de Digital Integration, centrées sur les API, basées sur le temps réel et les messages,
● Les capacités de Data Integration, centrées sur la donnée, basées sur le volume, le push, le streaming.
L’objectif est de pouvoir :
● Mixer la capacité à faire de l’unitaire et du volume, du transactionnel et de l’analytique, en fonction des cas d’usage.
● Rationnaliser un existant middleware et réduire la dette technique issue des générations précédentes, au moyen d’une plate-forme adaptée.
Cette convergence s’observe aussi en Asie, où la forte croissance, le rôle primordial de l’e-commerce et les écosystèmes de partenaires, poussent à ce type de construction, en parallèle de l’affirmation d’une discipline bien connue, l’architecture.
Ce type de plate-forme repose sur un assemblage de choix, fédérés par un modèle DevOps. Notre travail consiste généralement à construire et déployer cette vue unifiée, quelles que soient les technologies retenues. En effet, il n’existe pas aujourd’hui de vendeur capable de fournir une solution de bout en bout.
De plus, ainsi que nous l’observons sur les Data Platforms, les entreprises sont de toute façon réticentes à s’engager avec un seul vendeur sur des constructions aussi stratégiques.
C’est là qu’intervient la notion de scénario d’intégration. Ce sont des cas d’usage pré-identifiés et précâblés, que l’on est certain de retrouver d’une entreprise à l’autre, des modèles qui vont s’appliquer techniquement à la plate-forme.
Dans le schéma ci-dessus, nous en avons listé neuf, mais il en existe bien d’autres :
● Event-triggered IoT : l’objectif est de capter les messages-événements provenant d’objets connectés et de les corréler pour en accroître la lecture. Cette corrélation s’opère naturellement via l’application d’algorithme de Data Science / Machine Learning, qui déclenchent eux-mêmes d’autres événements à pousser vers des abonnés,
● Data Virtualisation : la Data Virtualisation est un pattern d’intégration qui s’appuie généralement elle-même sur un ensemble de technologies dominées par l’utilisation de SQL. Ces patterns peuvent être couverts par une plate-forme de ce type. L’intérêt est de ne pas avoir à disposer d’une Data Virtualisation séparée de la stratégie d’intégration, ou venant se poser comme une technologie supplémentaire.
● Batch Data Flow : il s’agit de constituer des agrégats de données, enrichis par des orchestrations, et mis à disposition par lots aux consommateurs,
● Processus transverses : ce sont des processus qui décrivent le cycle de vie d’une information dans le système de l’information, et pour lesquels il existe des métriques de performance métier que la plate-forme est la seule à pouvoir déterminer du fait de sa transversalité,
● Digital Twin Experience : se construit autour du scénario Event-Triggered IoT, car les événements reçus vont remonter vers le jumeau digital pour une interprétation en temps réel de son fonctionnement. Ce scénario s’enrichit alors de méta-données, pour faire converger les événements vers une vue unique du jumeau, qui justifient la connexion à un référentiel d’architecture d’entreprise ou à un Data Catalog.
● RPA Intégration : l’utilisation d’une solution de RPA demande parfois l’accès à des API exposées par la plate-forme, pour éviter l’automatisation de surface qui peut causer des problèmes de synchronisation d’information. Ce scénario est ainsi également un moyen de contrôler la qualité de la donnée dans les différentes sources en les comparant et en remontant les écarts.
● File 2 API 2 File : les fichiers n’ont pas disparu, et il est parfois nécessaire de transformer un fichier en autant de messages, ou d’agréger des messages dans un fichier, voire parfois les deux dans un traitement de bout en bout. Cela permet aussi de faire la jonction entre le patrimoine historique et les nouveaux moyens d’échange.
● AI & ML support : ce scénario vise à approvisionner les algorithmes portant sur les bases de données locales à la plate-forme, en informations nécessaires et suffisantes pour permettre l’apprentissage. Ces scénarios apparaissent lorsque la plate-forme d’intégration joue le rôle d’une Data Platform à part entière.
● MDM Workflows : la constitution et la consommation de la donnée de référence peuvent être prises en charge par la plate-forme.
Ces scénarios permettent de qualifier la stratégie d’intégration d’une entreprise, le profil d’une plate-forme d’intégration fédérée, et de sélectionner les meilleurs composants pour les usages.
Dans bien des cas, un audit de l’existant s’imposera pour connaître le poids de la dette technique, et déterminer comment la résoudre via des scénarios de correction et de migration indissociables de la construction de ce nouvel actif.
