Dans les modèles d’affaire des industries de service, savoir diversifier et distribuer les capacités à accueillir et à traiter les demandes des clients est essentielle pour être réactif et fournir une prise en charge personnalisée. C’est la justification principale de la mise en oeuvre des architectures de systèmes d’information dite distribuées qui permettent de coordonner l’utilisation de ressources éloignées les unes des autres, tout en préservant leur cohérence.
La plus connue des architectures de ce style est la SOA (Service Oriented Architecture), dont la version 1.0, standardisée par le forum OASIS fin 2012, a été reprise par l’Open Group. Il a porté de grandes promesses car il trouvait, dans les Web services normalisés par le Forum W3C, une technologie de mise en oeuvre naturelle.
Or, la plupart des entreprises qui se sont lancé dans cette voie ont essuyé des échecs cuisants, qu’ils soient dus à une complexité et des coûts de réalisation qui n’étaient pas à la mesure des gains attendus,qu’ils soient dus à une agilité espérée qui s’est traduite, en réalité, par une plus grande inertie du système d’information, qu’ils soient dus à un fonctionnement opérationnel non satisfaisant.
Pour rappel, la promesse initiale de la SOA était de résoudre la question de l’interopérabilité des progiciels, en les intégrant à une ou plusieurs plates-formes d’orchestration, chargées d’exécuter les interfaces des utilisateurs.
Pour cela, il fallait développer des services façades devant chaque application métier, et les exposer sur un bus d’échanges pour qu’ils puissent être orchestrés. Tous les éditeurs ont équipé leurs progiciels de ce type de services et ont, de ce fait, renchéri leur facturation pour, en réalité, des services qui se sont avérés complexes à utiliser.
Lorsque les entreprises ont voulu faire la même chose avec leurs applications historiques les difficultés ont été énormes : des surcoûts, des retards, des impasses.
Dès 2015, beaucoup de DSI ont remis en question la SOA, et ont préféré faire de l’intégration à la demande sur mesure, avec des standards simplifiés comme XML sur HTTP, eytsans déployer la totalité des couches de la SOA de référence. Le Gartner est allé dans le même sens, ne recommandant d’utiliser la SOA que pour les services externes qui nécessitaient de suivre les standards.
Dans ce contexte mitigé, l’architecture de type « Data Centric » est une nouvelle tentative de résoudre la question de la distribution des traitements, basée sur la centralisation des données. Tous les composants applicatifs ont accès à des données à jour, cohérentes et justes, c’est leur source de synchronisation.
Le diagramme ci-après ne nécessite pas de grands commentaires pour comprendre tous les avantages du concept. On y reconnait les macros fonctions d’une mutuelle santé ou d’une compagnie d’assurance de personnes.
La mise en oeuvre de cette architecture repose un ensemble de composants regroupés au sein d’un Data Hub qui concentre tous les services de collecte et de distribution des données de l’entreprise.
Chaque composant transmets ses données au Data Hub selon ses propres contraintes fonctionnelles et techniques. Ce peut être une collecte basée sur une fonction de « Change Data Capture » de la base de données ou bien un forward de message dans une file d’attente. Les services du Data Hub traitent ces données et les mettent à la disposition des composants utilisateurs dans le temps imparti requis par le business de l’entreprise.
Les transactions sont réalisées directement en activant les API exposées par les progiciels. Ces API bien plus simples à réaliser que les Web services, n’exposent que les transactions utiles. Elles n’ont pas besoin d’exposer les données qui sont déjà acheminée par le Data Hub. Cela simplifie grandement l’intégration.
Les traitements de données du Data Hub contiennent tout ce qui couvre les fonctions de mise en qualité des données, le catalogage, leur gouvernance opérationnelle, leur entreposage, via par exemple un Datalake. Celui-ci peut héberger les traitements de préparation et d’agrégation des données avant de les transmettre aux applications aval, comme la comptabilité ou les paiements, ou aux Datamarts pour le pilotage.
Le style d’architecture « Data Centric » est une architecture qui répond aux exigences de la distribution des traitements, elle est bien plus simple à mettre en oeuvre que la SOA. En outre, grâce à son tropisme vers les données, elle permet de les valoriser bien plus que ne le faisait la SOA.
C’est l’architecture du Système d’Information la plus adaptée pour mettre en oeuvre une stratégie Data Driven.