Systèmes d'information : bouger les cathédrales

Les systèmes d'information "historiques", ceux des grandes entreprises et organisations, sont d'immuables cathédrales.

Cathédrale de Reims

D'immuables cathédrales

Certes, ils n'en ont pas l'esthétique, ils relèvent plus de la pesanteur du Roman, que de l'équilibre structurel du Gothique... Mais ils imposent le respect, ne serait que par leur résistance aux changements : nous avons vu ici à maintes fois que l'effroyable complexité, l'imbrication fatale, l'empilement applicatif opportuniste, ont créé une rigidité qui placent ces créations de l'esprit hors du temps.

Et pourtant, tous les jours, de toutes parts, apparaissent d'impérieuses nécessités de mettre ces cathédrales en mouvement.

Comment faire pour ne pas effondrer ces architectures, lourds et rigides héritages du passé, précieux garants des fonctionnements, et du respect des multiples règles et prescriptions ?

Deux voies d'évolution

Longtemps on a pensé, et beaucoup pensent encore, qu'il suffisait de se doter de Méthodes d'Architecture et d'Architectes, pompeusement baptisés Architectes d'Entreprise, pour réformer le SI...

Congrès spécialisés, gourous, cursus, ... canalisent énergies et compétences. Mais est-on sur la bonne voie ? Est-on sur un chemin adapté aux défis actuels, qui ne sont plus ceux de la maturité de l'informatisation, atteinte il y a une à 2 décennies. N'y a-t-il pas, sur ce sujet, aveuglement collectif, à vouloir projeter l'avenir avec les recettes du passé ?

D'ailleurs, à l'opposé des chantres de l'Architecture d'Entreprise et de leurs ambitions méthodologiques qui visent à tout décrire, tout maîtriser, les aficionados de l'agilité, du développement agile, préconisent des approches incrémentales, de petits pas de développement, qui se moquent des approches en cascade et des projets mastodontes du passé.

Qui croire ? Faire table rase et s'engager dans le tout agile, voire le tout web, le tout connecté ? Ou se rassurer à force de certifications d'Architectes, labellisés à la méthode la plus reconnue ? et à laquelle confier son avenir ?

Ce sont 2 voies respectables. Mais il n'est plus temps, ni de créer des cathédrales, ni en tout point de leur substituer des créations agiles : l'impératif est de bouger les cathédrales, et de leur adjoindre des absidioles d'agilité. Si les Architectes d'Entreprise existent, voilà bien le cœur de leur ingénierie.

Une troisième voie inexplorée

Existe-t-il une baguette magique qui transformerait les colosses du passé en champions de l'age numérique ? Existe-t-il un levier de mise en mouvement ?

Entre ces 2 idéologies, et leurs pratiques, il faut reconnaître qu'on n'a pas trouvé cet artifice. Je vous propose pourtant ici d'explorer une troisième voie dans ce sens.

En premier lieu, pour provoquer la réflexion, et les remises en cause, changeons de paradigme.

• abandonnons l'hypothèse que l'on peut maîtriser le SI dans sa globalité : cette voie, nous l'avons vu, aboutit à de la méthode, à des malentendus, et parfois à de magnifiques tunneliers qui ne peuvent mourir qu'au fond du tunnel. En effet, sans maîtriser le global, il reste encore des milliards de milliards de solutions.
• prenons comme impératif de préserver l'existant et de le mixer, le coupler avec les compléments agiles qui répondent aux attentes actuelles. En effet, dans cet état d'esprit, l'existant est infiniment complexe, donc relativement immuable. Interdisons-nous de faire table rase, tous les efforts doivent porter sur le mariage de l'ancien et du moderne.

Un global non maîtrisable, et un existant irremplaçable, voilà le paradigme.

Le salut est alors dans le local, le domaine réduit, et la capitalisation sur l'existant.

On avancerait ainsi par petits mouvements, qui se propagent par l'exemple plus que par la théorie. La mise en mouvement de la cathédrale est ainsi engagée et sécurisée.

Un levier disponible : les données

A ce point du raisonnement, le voile se lève : nous avons à portée de main le levier tant cherché ! Ce sont les données !

Car les données étaient déjà là au premier temps de l'informatique, et seront toujours là, pour les anciens comme pour le modernes ! Elles peuvent réconcilier toutes les chapelles, quelles que soit les différentes formes qu'on donne à ces matérialisations des informations. Et les diverses syntaxes et avatars technologiques ne sont que contingences dont on peut, et dont il faut, s'abstraire.

Données d'un puits (Source R. Mandel)

J'ai proposé ici une des approches possibles : les puits de données. Cela suppose un effort conceptuel pour clarifier quelques notions, bien dissocier les cycles de vies, modéliser les 3 dates (date de fait, date de vision,date technique) comme expliqué sur ce site (le trouble des dates), et faire le tour des fonctions nécessaires (voir une présentation des principes de puits de données). Voilà un levier dont le coût est dérisoire (un prototype sur cas réel a coûté de l'ordre du 20 000 ième du budget informatique).

La bonne nouvelle

Réorganiser le SI autour des données est possible. Au delà des puits de données, d'autres chemins de migration restent à imaginer, en s'appuyant en particulier sur les nombreuses offres émergentes au sein de l'écosystème des données :

Ecosystème des données d'après EMA-9sight Consulting

La bonne nouvelle est que les diverses routines de lecture, virtualisation, conversion, manipulation, sont largement disponibles. Au catalogue de grands éditeurs, comme dans l'offre de start-up, et dans la déferlante de l'Open Source (voir par exemple la liste des connecteurs disponibles chez un intégrateur de données). L'hybridation de données, de toutes sortes et à tout propos, est possible, au sein d'un écosystème des données, comme le montre l'image ci dessus extraite d'un livre blanc sur les Big Data.

Un marketing décalé

Alors comment expliquer que ce levier disponible, stratégique pour la migration, soit largement sous-utilisé... Certes, ces offres sont récentes, il faut du temps pour se les approprier. Les services informatiques résistent et sont sceptiques, avec une naturelle inertie pour s'engager dans cette révolution du patrimoine SI.

Mais la raison est aussi, à mon sens, liée au marketing de ces offres, qui les positionne sur la marge de l'empire du SI et non en son cœur lui-même : un marketing décalé, polarisé sur le Big data et l'Analytic.

Bref, il est clair que nous avons à portée de main la technologie qui va bien. La troisième voie est ouverte, facile à initier, rapidement praticable, sans grand projet. Elle cible le cœur du SI.

C'est une impérieuse nécessité.

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 ?