Top 5 des modèles d'intégration des données

Les données constituent un asset métier précieux, mais il est parfois difficile d'y accéder, de les orchestrer et de les interpréter.

Lorsque les données transitent par plusieurs systèmes, elles ne le font pas toujours dans un format standard. Leur intégration les transforme en données indépendantes pour un accès et une manipulation plus faciles.

Pour rendre les données encore plus rapidement exploitables, les développeurs peuvent avoir recours à des modèles d'intégration des données visant à standardiser le processus d'intégration.

C'est à l'usage que les modèles apparaissent et se pérennisent, un peu à la manière d'un sentier de randonnée. Les modèles ne sont pas tous de même qualité. Toutefois, ils peuvent être optimisés ou adoptés en fonction des besoins de l'entreprise en attente d'une solution. Le cas d'utilisation métier est en quelque sorte l'instanciation du modèle, soit une utilisation pour le processus générique de déplacement et de gestion des données.

Il existe cinq modèles d'intégration des données basés sur les cas d'utilisation métiers et les modèles d'intégration cloud.

La migration consiste à déplacer des données d'un système vers un autre. Une migration se compose d'un système source sur lequel résident les données avant leur exécution, un critère qui détermine l'ampleur du volume de données à migrer, une transformation à laquelle devra se plier l'ensemble de données, un système de destination sur lequel les données seront insérées et, enfin, une possibilité de capture des résultats de la migration pour comparer l'état final à l'état souhaité.

Aucun système de données ne peut se passer de la migration. La création et la gestion des données prennent un temps précieux, et la migration permet à celles-ci de conserver leur indépendance par rapport aux outils utilisés pour leur création, leur consultation et leur gestion. Sans migration, toutes les données collectées seraient perdues à chaque changement d'outil, ce qui aurait un effet désastreux sur la productivité de l'entreprise dans un contexte digital.

La migration a lieu lors du déplacement de données d'un système vers un autre, ou d'une instance vers une autre ou encore vers une nouvelle instance de ce système, de la préparation d'un nouveau système qui viendra étendre l'infrastructure actuelle, de la sauvegarde d'un ensemble de données, de l'ajout de nœuds à des clusters de base de données, du remplacement du matériel de base de données, de la consolidation des systèmes, etc.

La diffusion, parfois appelée « synchronisation unidirectionnelle d'un système vers plusieurs autres systèmes », fait référence au déplacement de données depuis un système source vers plusieurs systèmes de destination en flux continu et en temps réel, ou quasi réel.

Lorsqu'il est nécessaire de mettre à jour les données sur plusieurs systèmes dans le temps, il faut avoir recours à un modèle de corrélation, de synchronisation bidirectionnelle ou de diffusion. Le modèle de diffusion, tout comme le modèle de migration, ne déplace les données que dans un sens, de la source vers la destination. Le modèle de diffusion, à l'inverse du modèle de migration, est transactionnel.

Cela signifie qu'il n'exécute pas la logique des gestionnaires de messages pour tous les éléments concernés, mais seulement pour ceux qui ont récemment subi une modification. La diffusion peut être comparée à une fenêtre coulissante qui ne capture que les éléments dont les valeurs de champ ont changé depuis la dernière exécution de la diffusion.

Une autre différence majeure réside dans la manière dont l'implémentation du modèle est conçue. La migration sera ajustée pour prendre en charge d'importants volumes de données et traiter de nombreux enregistrements en parallèle, mais aussi pour fonctionner en mode dégradé. Les modèles de diffusion sont optimisés pour traiter les enregistrements rapidement et avec une grande fiabilité, et donc éviter de perdre des données stratégiques au cours du transit.

Le modèle de diffusion s'avère particulièrement utile lorsque le système B a besoin de connaître en temps réel des informations originaires ou résidant sur le système A. Imaginez que vous souhaitiez créer un tableau de bord de rapports en temps réel, soit une destination pour de nombreuses applications de diffusion qui reçoivent des notifications en temps réel sur ce qu'il se passe sur les différents systèmes.

Ou que vous souhaitiez lancer l'exécution des commandes dès qu'elles arrivent dans votre CRM, votre outil e-commerce ou votre outil interne où est centralisé votre système de traitement de l'exécution des commandes, indépendamment du canal d'origine de la commande. Ou que vous souhaitiez envoyer une notification concernant la température de votre turbine à vapeur à un système de surveillance toutes les 100 millisecondes. Ou que souhaitiez informer le système de gestion des patients d'un médecin généraliste de l'admission d'un de ses patients réguliers aux urgences. Les exemples de transfert de données d'un système d'origine vers un autre ne manquent pas.

Vous pouvez facilement savoir si le modèle de diffusion convient à votre situation, si celle-ci répond aux critères suivants :

• Le système B doit-il être informé de l'événement sitôt qu'il se produit : oui
• Les données doivent-elles être transmises automatiquement de A à B : oui
• Le système A doit-il être tenu informé du devenir de l'objet au sein du système B : non

La première question vous permet de décider si vous devez opter pour le modèle de migration ou pour le modèle de diffusion selon que les données doivent être en temps réel ou non. Toute fréquence inférieure à environ une heure correspond généralement au modèle de diffusion. Mais il existe tout de même des exceptions en fonction des volumes de données.

La deuxième question permet d'ordinaire d'écarter les applications « à la demande ». En règle générale, les modèles de diffusion sont initiés par une notification push ou une tâche programmée et ne reposent donc pas sur une intervention humaine.

La dernière question vous indique si vous devez ou non fusionner les deux ensembles de données afin de les synchroniser sur deux systèmes. C'est ce que l'on nomme synchronisation bidirectionnelle. Selon les besoins, il faut faire appel à différents modèles d'intégration des données. En raison de la flexibilité de couplage des applications du modèle de diffusion, nous recommandons l'utilisation de deux applications de diffusion plutôt que d'une seule application de synchronisation bidirectionnelle.

Ce modèle d'intégration des données nommé synchronisation bidirectionnelle consiste à combiner deux ensembles de données sur deux systèmes différents pour qu'ils se comportent comme une seule et même entité, tout en respectant leur existence en tant qu'ensembles de données distincts. Ce type de besoin d'intégration trouve son origine dans l'utilisation de différents outils ou systèmes qui accomplissent différentes fonctions sur un même ensemble de données.

Imaginez que vous disposez d'un système dédié à la prise et à la gestion de commandes et d'un autre système dédié au service client. Admettons que ces deux systèmes répondent bien mieux à vos besoins qu'une suite qui prendrait en charge les deux fonctions à l'aide d'une base de données commune. L'utilisation de la synchronisation bidirectionnelle pour le partage de l'ensemble de données vous permet de vous servir des deux systèmes tout en conservant une vue uniforme en temps réel des données de l'un et de l'autre.

La synchronisation bidirectionnelle peut vous rendre service, voire vous sauver la mise, selon les circonstances qui justifient son utilisation. Si vous disposez d'au moins deux représentations indépendantes et isolées de la même réalité, vous pouvez utiliser la synchronisation bidirectionnelle pour optimiser vos processus.

Mais vous pouvez aussi avoir recours à la synchronisation bidirectionnelle pour remplacer une suite de produits qui fonctionnent correctement ensemble, sans toutefois correspondre parfaitement de manière individuelle à la fonction qu'ils sont censés remplir. Vous pouvez opter à la place pour une suite dont vous aurez sélectionné tous les éléments avant de les intégrer les uns aux autres sur une plateforme d'intégration comme Anypoint Platform de MuleSoft.

Le besoin de synchronisation bidirectionnelle est motivé par le souhait de représentations d'objets réels complètes et cohérentes. Prenons un exemple. Si vous souhaitez obtenir une vue unique de votre client, vous pouvez l'obtenir manuellement en donnant à tous l'accès à tous les systèmes qui proposent une représentation de la notion d'un client. Plus efficace encore, vous pouvez répertorier les champs à afficher pour cet objet client dans les systèmes que vous souhaitez et afficher les systèmes propriétaires.

La plupart des systèmes d'entreprise sont capables d'étendre les objets de sorte que vous puissiez modifier la structure des données de l'objet client afin d'inclure ces champs. Vous pouvez ensuite créer des applications d'intégration, soit des applications point à point (à l'aide d'une plateforme d'intégration courante) s'il s'agit d'une solution simple, soit un système de routage plus sophistiqué, comme un modèle de routage pub/sub ou de files d'attente, si plusieurs systèmes sont concernés.

Par exemple, les vendeurs ont besoin de connaître l'état des livraisons, mais ils n'ont pas besoin de connaître l'adresse de l'entrepôt où se trouve le colis. De même, les livreurs doivent connaître le nom du client destinataire, mais il n'est pas nécessaire qu'ils soient au courant du prix de la commande. La synchronisation bidirectionnelle permet aux vendeurs comme aux livreurs de disposer d'une vue en temps réel adaptée à leurs besoins du même client.

La corrélation est un modèle d'intégration des données conçu pour identifier l'intersection de deux ensembles de données et pour effectuer la synchronisation bidirectionnelle de cet ensemble de données uniquement, seulement si cet élément se trouve naturellement sur les deux systèmes. La synchronisation de l'intersection par la corrélation ressemble beaucoup à la manière dont le modèle bidirectionnel synchronise l'union des ensembles de données sélectionnés.

Dans le cas du modèle de corrélation, il est possible que les éléments qui résident sur les deux systèmes aient été créés manuellement sur chacun des systèmes, comme cela arrive quand deux commerciaux saisissent le même contact dans deux systèmes CRM différents. Ou alors, ils ont pu y être déplacés au cours de diverses intégrations. Le modèle de corrélation n'accorde aucune importance à l'origine de ces objets et les synchronise indépendamment du moment qu'ils se trouvent sur chaque système.

La corrélation est un modèle d'intégration des données conçu pour identifier l'intersection de deux ensembles de données et pour effectuer la synchronisation bidirectionnelle de cet ensemble de données uniquement, seulement si cet élément se trouve naturellement sur les deux systèmes. La synchronisation de l'intersection par la corrélation ressemble beaucoup à la manière dont le modèle bidirectionnel synchronise l'union des ensembles de données sélectionnés.

Dans le cas du modèle de corrélation, il est possible que les éléments qui résident sur les deux systèmes aient été créés manuellement sur chacun des systèmes, comme cela arrive quand deux commerciaux saisissent le même contact dans deux systèmes CRM différents. Ou alors, ils ont pu y être déplacés au cours de diverses intégrations. Le modèle de corrélation n'accorde aucune importance à l'origine de ces objets et les synchronise indépendamment du moment qu'ils se trouvent sur chaque système.

La corrélation est un modèle d'intégration des données intéressant lorsque vous disposez de deux groupes ou systèmes devant partager leurs données, seulement s'ils disposent tous deux d'un enregistrement représentant le même élément ou la même personne dans la réalité. Prenons l'exemple d'un groupe hospitalier possédant deux hôpitaux dans la même ville. Il est intéressant que les deux hôpitaux partagent leurs données. Ainsi, lorsqu'un patient est admis dans l'un des deux, son dossier se met automatiquement à jour et indique le type de soins qu'il a reçus au sein de chaque établissement.

Pour réussir une telle intégration, il est possible de créer deux intégrations à l'aide du modèle de diffusion, une de l'hôpital A vers l'hôpital B et l'autre de l'hôpital B vers l'hôpital A. La synchronisation des données est assurée, mais il faut à présent gérer deux applications d'intégration.

Pour soulager la charge liée à la gestion de deux applications, il est possible d'utiliser le modèle de synchronisation bidirectionnelle entre l'hôpital A et l'hôpital B. Mais pour être vraiment efficace, il faut que la synchronisation ignore les dossiers des patients de l'hôpital B n'ayant jamais été traités à l'hôpital A et transférer en temps réel ceux des patients dont le dossier vient d'être créé. Le modèle de corrélation est particulièrement utile, car il synchronise uniquement de façon bidirectionnelle les objets lorsque c'est nécessaire plutôt que de transférer l'intégralité de l'ensemble de données dans les deux sens.

La corrélation est le modèle de données à préférer lorsque conserver des données superflues s'avère plus coûteux qu'utile, car ce modèle vous permet d'ignorer les données « inutiles ». Prenons l'exemple d'une faculté faisant partie d'un groupe universitaire qui souhaiterait générer des rapports relatifs à ses étudiants.

Les étudiants qui n'ont jamais fréquenté cette faculté ne doivent pas être pris en compte dans ces rapports. En revanche, il est intéressant d'inclure les unités validées par ces étudiants dans d'autres facultés dépendant du même groupe universitaire. Ici, le modèle de corrélation simplifierait bien des choses en matière d'intégration ou de génération des rapports, car il permettrait de synchroniser uniquement les informations des étudiants ayant fréquenté les deux facultés.

L'agrégation consiste à transformer des données issues de différentes sources en un seul et même élément. Imaginez que l'intégration des données client réside sur trois systèmes différents et qu'un analyste de données veuille générer un rapport utilisant les données de ces trois systèmes. Il est possible de créer une migration quotidienne depuis chacun des systèmes vers un référentiel de données, puis d'exécuter les requêtes sur cette base de données. Mais il faudrait alors assurer le suivi et la synchronisation d'une nouvelle base de données.

De plus, ce référentiel de données devrait être mis à jour dès qu'une modification serait apportée à l'un des systèmes. Autre désavantage, les données dateraient de la veille et donc, pour générer des rapports en temps réel, l'analyste devrait soit initier les migrations manuellement, soit attendre le lendemain. Afin d'assurer la mise à jour constante de la base de données utilisée pour les rapports afin qu'elle prenne en compte les modifications les plus récentes apportées à chaque système, il serait possible de configurer trois applications de diffusion. Mais il faudrait tout de même assurer la gestion de cette base de données accueillant uniquement des données répliquées pour y exécuter régulièrement des demandes. Cela entraînerait aussi un véritable gâchis d'appels d'API ayant pour but de contrôler la disponibilité de la base de données à x minutes de la réalité.

C'est là que le modèle d'agrégation entre en jeu. Si vous construisez une application ou utilisez un de nos patrons qui reposent sur ce modèle, vous constaterez qu'il est possible d'exécuter sur demande des requêtes sur plusieurs systèmes, de fusionner l'ensemble de données et d'en faire ce que vous voulez.

Par exemple, vous pouvez construire une application d'intégration qui exécute des requêtes sur plusieurs systèmes, fusionne les données, puis génère un rapport. Ainsi, vous n'avez plus besoin d'une base de données séparée, et le rapport vous est fourni au format de votre choix, notamment .csv. Vous pouvez déposer le rapport à l'endroit où sont directement stockés les rapports.

La valeur du modèle d'agrégation réside dans sa capacité d'extraction et de traitement des données provenant de plusieurs systèmes dans une seule et même application. Ainsi les données sont actualisées quand vous le souhaitez, sans doublons, et peuvent être traitées ou fusionnées pour produire l'ensemble de données que vous voulez.

Le modèle d'agrégation s'avère particulièrement utile si vous souhaitez créer des API d'orchestration destinées à « moderniser » les systèmes legacy, particulièrement lorsque vous créez une API qui utilise les données de plusieurs systèmes, puis les traite pour en tirer une seule réponse. Autre cas d'utilisation : la création de rapports ou de tableaux de bord qui extraient les données de plusieurs systèmes et s'en servent pour créer une expérience.

Enfin, si vous utilisez certains de vos systèmes à des fins de conformité ou d'audit, ceux-ci ont peut-être aussi besoin d'accéder à des données connexes issues de plusieurs systèmes. Le modèle d'agrégation permet de garantir que vos données de conformité résident sur un seul système. Toutefois, celles-ci peuvent être composées de données pertinentes issues de différents systèmes. Vous pouvez ainsi réduire la quantité d'apprentissage nécessaire sur l'ensemble des systèmes afin de conserver de la visibilité sur les événements en cours.