A la découverte des "puits d'événements" pour simplifier les systèmes d'information

A l'instar de la société, les systèmes d'information des grandes entreprises et organisations se complexifient inexorablement.
Nous avons déjà maintes fois expliqué ce phénomène naturel, contre lequel l'Architecture d'Entreprise et l'Urbanisme des SI doivent lutter : l'accumulation de logiciels en liens inextricables tel un récif de corail.

Le champ couvert par les systèmes de plus en plus vaste, et les imbrications, empilements, redondances y créent une sur-complexité : à l'évidence, a posteriori, on voit clairement qu'on aurait pu faire plus simple. Seulement, il est trop tard, les liens sur-complexes ont rigidifié l'ensemble. Le patrimoine est devenu tel un conglomérat corallien aléatoire.

Il existe plusieurs réponses à cette problématique :

• mettre en place et imposer des référentiels de données partagés, les fameuses "master data", approche vertueuse, mais nécessitant des clarifications de gouvernance et des transferts de responsabilité sur les données,
• re-urbaniser une partie du patrimoine à l'occasion d'un grand projet, approche risquée, coûteuse, et de dernier recours,
• définir une cible d'urbanisme pour un domaine et converger vers la cible à l'occasion des projets, approche optimale, mais aux résultats immédiats peu visibles,
• gérer un catalogue services réutilisables, approche technique vertueuse et progressive.

Toutes ces réponses impliquent coûts, délais, risques, efforts d'administration et de gouvernance.

De plus, la rigidité du récif "applicatif" est confortée par la rigidité des habitudes et pratiques acquises. Le système technique formate en effet ses utilisateurs : même si les logiciels étaient totalement flexibles, les usagers, les clients ne comprendraient pas de perpétuels changements. Les viscosités métier, sociale, et sociétale, réduisent l'intérêt, et le retour sur investissement, d'une éventuelle agilité des développements logiciels.

Comment, dans ce contexte, assainir le système, en réduire la complexité, éviter qu'il ne se complexifie par empilement, alors qu'on n'a plus les moyens de financer les coûts et risques des "big-bang" applicatifs, des projets ERP, des refontes des processus et des migrations des utilisateurs ?

Comment faire avec cet état de fait ? Comment évoluer sans rupture et réformer doucement en profondeur ?

Un levier négligé

Pour l'Architecture d'Entreprise, il existe pourtant un levier, à mon sens clairement sous-utilisé voire ignoré, qui satisfait ces conditions. Levier qui permet de lutter contre l'accroissement de l'entropie en agissant au cœur même de son développement, par une approche à la fois curative et préventive attaquant le mal à sa source.

Ce levier agit exclusivement sur les données, sans perturber le patrimoine applicatif, si rigide, et les processus, si sensibles. Il se situe au centre du cyclone des données qui matérialise les échanges structurés entre applications, services et autres ERP, voire SaaS, DaaS,... car ce lieu stratégique de la maîtrise de l'entropie est le royaume des dialectes locaux, fondés sur des modélisations variées des mêmes informations, des modes d'échanges temporels (invocation de services, flux de messages, stocks à date, historiques,...), des modalités techniques datant des différentes époques, et sur un espace sémantique non maîtrisé. Une Tour de Babel des échanges aux multiples facettes, et qui traverse tous les niveaux du SI : sémantiques, fonctionnels, techniques.

Car les échanges cristallisent les dysfonctionnements : non cohérence entre divers processus, duplications, redondances, flous des concepts, absence de gestion des cycles de vie, de la profondeur historique, de la mise en cohérence, de la traçabilité,... et au final sur-investissement, sclérose, et non qualité coûteuse et visible.

L'assainissement des échanges repose certes sur la mise en place de référentiels de données, c'est une approche bien connue, et fondée maintenant sur une offre de produits de MDM. Approche nécessaire (voir : référentiels de données pilier du SI), mais qui ne peut suffire.

A mon sens il existe une autre figure de style, artefact tueur d'entropie, peu référencée sauf par une approche technique, mal connue, et non systématisée. Car cette figure de style repose avant tout sur un effort conceptuel.

Il s'agit de ce que l'on peut appeler un "puits d'événements" (initialement appelé "puits de données"). Limitons nous ici aux principes et aux vertus énoncés ci-dessous. Un développement plus fourni serait aisé, sur la base de travaux réalisés dans un contexte particulier, jusqu'à la maquette technique, travaux qui ont de toute évidence une portée générale.

Principes d'un puits d'événements

Un puits d'événements est, sur un champ sémantique ayant vocation à de nombreux partages et échanges (au sein de l'entreprise ou avec ses partenaires) un système d'information mis en forme normalisée :

• étant approvisionné par diverses sources non nécessairement coordonnées (le puits offre un service de mise en cohérence et de gestion de la mise en qualité, mais ne prend jamais la main sur les données),
• admettant toutes les formes d'alimentations (tous protocoles, modélisation variables, modes flux ou messages ou invocation de services),
• pouvant restituer les informations selon de multiples protocoles et services (dans une relation "commerciale" et contractuelle vis à vis des domaines "clients" individuels ou collectifs, internes voire externes),
•  disposant d'une supervision pour gérer les contrats, la sécurité, la confidentialité, la pérennité des données (sauvegarde-restauration),
• gérant de façon atomique, au niveau du "grain" le plus fin, la profondeur historique et les cycles de vie des données (cycle événementiel des faits, cycle des visions, cycle des mises en qualité) sur les 3 dimensions de la trilogie des dates (grain tri-daté : voir la question du trouble des dates dans le SI), grâce à une modélisation des données générique et conceptuelle de sa base interne au puits,
• implanté sur une architecture technique et logiciel fournissant le catalogue des services nécessaires aux interfonctionnements et aux conversions de protocole (fournis par les éditeurs d'intégration de données),
• permettant les reconfigurations de périmètre (éclatement en plusieurs puits, fusion de puits), par une gestion des versions, le référencement de chaque flux, et le modèle générique.

Ainsi un puits d'événements, contrairement au MDM qui se substitue à la gestion des référentiels anciennement incluse dans plusieurs applications, ne remet pas en cause le patrimoine et les processus existants. Un puits ne gère pas les données de structure, gestion confiée bien sûr à un MDM (identification des objets, nomenclatures, postes, ...), mais il historise, stocke en base de données, et rapproche les données dynamiques, classiquement échangées en flux, ou propulsées en mode message, voire virtuellement échangées par consommation de services.

Le puits d'évenements ne nécessite aucune adaptation du patrimoine existant, car il fait son affaire de toutes les conversions en entrée (alimentation du puits) et en sortie (service aux clients du puits).

Positionnement et composition d'un puits selon l'auteur

En s'insérant progressivement, sans big-bang, au sein du "plat de spaghetti" d'échanges de données d'un même champ sémantique, et dans leurs cycles de vie, le puits assainit ces échanges, réduit leurs variantes contingentes et opportunistes. Il s'interpose comme plateforme multi-protocoles et s'impose progressivement comme la référence incontournable. Il permet le passage en douceur d'échanges en mode fichier, ou en mode asynchrone, entre silos applicatifs, à des échanges plus tendus, unitaires et interactifs, en respect de contrats basés sur un catalogue de services et de contenus d'objets conceptuels. Il est à la fois le moyen pratique pour simplifier les migrations, et préfigure concrètement la cible dés-imbriquée. A noter qu'une approche de type "format pivot" ne résout que partiellement le sujet, en particulier parce qu'un stockage historique est nécessaire pour pouvoir accepter et restituer tous les tempos d'échange.

Vertus d'un puits d'événements

En synthèse, un puits d'événements permet de partager, au sujet des événements, les données :

• fraîches, car les domaines possesseurs de données peuvent y déposer leur données pour usage par d'autres, dès qu'elles sont disponibles. Le puits permet de gérer le cycle de vie et de mise en qualité, et respecte les contrats de dépôt.
• pures car le puits assure une mise en cohérence et remonte les anomalies vers les domaines gestionnaires, tout en traçant la mise en qualité.
• disponibles car le puits garantit :
• la complétude conceptuelle, en particulier par la gestion des 3 dates des grains, et la modélisation générique (par exemple : typage des périodes d'activité en RH)
• l'évolutivité des modalités d'échange, par le report des conversions confiées à des routines de services, la base centrale étant construite sur un modèle générique couvrant tous les contenus et tous les historiques : les clients et fournisseurs du puits n'ont pas à connaître cette complexité, et peuvent fonctionner à leur rythme, et selon leurs usages. Ils peuvent aussi migrer en douceur vers d'autres rythmes et protocoles, en s'appuyant sur le catalogue de contrats du puits.
• profondes car le puits explore et mémorise toutes visions datées et dans toute leur profondeur historique.

Une figure de style pour simplifier le SI, tuer les norias d'envois de données divers et variés, accélérer les échanges, donner de la visibilité, tout en préservant l'existant.

Une figure basée sur l'agilité que permettent les plateformes d'intégration de données, et leurs propres catalogues de routines, connecteurs et autres accès aux ESB. Sans pour autant imposer un passage généralisé à des échanges synchrones, mais employer les plateformes à bon escient, au rythme des besoins, sur une base conceptuelle durable garantie par la modélisation générique.

A voir : une présentation du sujet ici.

A quand la fin des délices du spaghetti ?