Notes – Linkedin live Cathédrales data IT vs Chapelles data métiers

Ce mercredi, avec Eric Mattern – https://www.linkedin.com/in/ericmattern/ , nous avons animé un Linkedin live dont le titre était le suivant : « Cathédrale data IT et chapelles data métier : adversaires ou partenaires ».

L’enregistrement de ce Linkedin live est disponible sur la chaîne Youtube de l’éditeur Orkestra Data – https://www.youtube.com/channel/UCTMIhpylDRjTwVsO7eEyTtg

Le plan de l’intervention était le suivant :

Cathédrale IT c’est puissant et attirant

Les ambitions d’une cathédrale IT
La cathédrale IT : son architecture
Le projet de construction de la cathédrale
L’épreuve du temps

Chapelles métiers c’est l’indépendance et la discrétion

La chapelle dans le quotidien métier
La chapelle métier : son architecture
Le projet de chapelle métier
L’épreuve du temps

Mise en regard cathédrale IT / chapelle métier

Pour partage, mes notes sur les parties de mon intervention.

Un peu d’histoire

L’histoire des data platforms IT est connue.

Pour exploiter en 2^ème intention les données des processus opérationnels, des solutions de regroupement des données sont apparues au fil du temps : infocentres, DW/DM, big data, data lake, modern data stack – avec des approches hybrides de type data lake house et déclinées dans des cloud data (AWS, GCP, Azure).

Du côté métier, en parallèle des systèmes mis en place par l’IT, les données ont vite circulé dans les environnements bureautiques (fichiers, mails, excel). Jusqu’à la mise en place de bases de données locales (mysql), de procédures d’extraction et de diffusion à la main des données (par bricolage, mais aussi au travers de système complet hors IT), avec des acteurs data plus ou moins officiels (IT human middleware, cellules données hors IT). Le shadow data se développe. Les éditeurs BI vendent, vantent la self BI. Les données devenant de plus en plus prépondérantes, l’IT ne peut pas, ne doit pas répondre à tous les besoins data, des data platforms orientées métier apparaissent.

Est-ce que ces deux mondes que l’on a caricaturé par d’un côté des cathédrales IT et de l’autres côtés des chapelles métier, vont être adversaires ou partenaires ?

Ambitions des cathédrales IT

Si on parle de cathédrale c’est pour deux raisons :

– La construction d’une infrastructure centralisée des données d’entreprise, « toutes » les données accessibles et opérées en un même endroit. Ce qui veut dire la capacité d’accueillir d’importants volumes de données.

– Et être en mesure de répondre à des besoins qui vont solliciter de la puissance de traitement, ce sont de formidables usines à calculs (data science, statistiques – calculs d’indicateurs, consolidation de données – vues 360°, IA classique – reconnaissance de patterns et maintenant l’IA générative).

Sous-jacent il y a également une ambition de pouvoir, en réunissant toutes les données au même endroit, cela permettrait :

de faciliter et de maîtriser l’accès aux données en construisant un couche de connaissance (recensement des données, labélisation, vue sémantique, catalogage, marketplace avec les autorisations associées) -> pouvoir normatif,
de développer le patrimoine data et d’y appliquer des règles de gouvernance (mise en qualité, normalisation, enrichissement, réutilisation, valorisation, compliance, sécurité) -> pouvoir de maîtrise d’un actif,
de mieux contrôler la vie des données, traitements et usages par des moyens d’observation (data observability) – (monitoring, lineage, SLA, contrôles des politiques de données) -> pouvoir de contrôle.

Elle s’adresse principalement aux acteurs qui exercent au sein de data fabric et de data office.

Les métiers sont plus spectateurs qu’acteurs (Surtout éloignez les métiers des réunions d’implémentation Databricks ! Attention cela évolue à l’exemple de la bascule opérée par Microsoft au travers de son catalogue de données Purview en ce début d’année – passage d’une vue technique vers une vue beaucoup plus fonctionnelle / métier).

A quoi ressemble une cathédrale data IT ?

La cathédrale IT : son architecture

On connait tous ce type de schéma ou de plan d’architecture qui donne une vue d’ensemble des différentes fonctions à couvrir et des briques technologiques candidates. Schémas souvent photographiés dans les retours d’expérience … vu comme un graal d’ingénierie et la fin de tous les problèmes data !

On est dans l’esprit des cathédrales dans le sens de la grande dimension technologique, de la richesse fonctionnelle, de la sophistication d’assemblage, l’architecture est clé, l’ingénierie de construction est un challenge (quand tout s’assemble et se met à fonctionner il y a l’effet waouh recherché des data ingénieurs).

Comment se construit une cathédrale data IT ?

Le projet de construction de la cathédrale

C’est une longue liste de choix, choix de l’emplacement (infrastructure cloud, on premise), choix du niveau d’intégration (entre le best of breed ou le pré intégré), choix des briques technologiques (ETL, pile de stockage, moteurs de calculs, outil de gouvernance, orchestrateur, IDE dont librairies utiles), et des technologies (par exemple de stockage), choix des modes d’intégration entre ces briques (traduits dans les scripts d’intégration), définition des conteneurs, choix des standards à prendre en compte, que faire en cas de recouvrement fonctionnel entre briques, quelle stratégie vis-à-vis-à-vis des métadonnées souvent oubliées.

S’il y a un message à retenir : l’INTEGRATION est le sujet le plus difficile qui existe en architecture logicielle. Et ici on est face à une sophistication élevée (NB : certains éditeurs l’ont compris est proposent des frameworks qui prennent en charge cette intégration – voir le guide Panorama des data platforms et l’éditeur 5X – guide à télécharger ici https://orkestra-data.com/ ).

Exemple de crash test, comment mettre en place dans la cathédrale une gestion unifiée des accès, de bout en bout, supportée et alignée entre les différentes briques ?

Le recrutement de compétences est clé, les bâtisseurs de cathédrale sont des ressources rares et précieuses : data ingénieur, data intégrateur, des spécialistes techniques des différentes briques en double – continuité de service … (NB un data scientist n’est pas un data ingénieur – erreur des projets big data historiques).

C’est un projet unique à risque.

C’est un projet coûteux.

Ne pas reproduire les erreurs précédentes (échecs des data lake, échecs des projets big data) … les causes sont connues.

Si vous réussissez, le résultat est alors d’une efficacité redoutable. J’ai en tête dans la monétique, une montée en puissance de reconnaissance d’anomalies transactionnelles, contextualisées, en temps réel, impossible à réaliser sans une cathédrale.

La cathédrale à l’épreuve du temps

Mais construire la cathédrale prend du temps.

Remplir la cathédrale prend du temps (avec des données et métadonnées qualifiées).

Mettre en place les 1^er cas d’usage (industriels versus POC) prend du temps.

Comment meubler ce temps, le « slow time to delivery » ? Avec le risque du shadow data, de la dette technique qui s’accroit.

Charger les données en aveugle (des cas d’usage) n’est pas forcément une bonne approche.

La promesse est forte, mais comment changer le moteur de l’avion tout en continuant de voler ?!

Au vu de l’investissement, la pression de la rentabilité arrive vite.

Son cout de revient est porté par les consommations en données qu’elle opère, plus il y a d’utilisation plus la cathédrale devient rentable.

La cathédrale va courir à aspirer un maximum de données (étendre sa portée) et à attirer les cas d’usage.

Au risque de se précipiter (sauter sur tous les cas d’usage) et accumuler une dette technique (vite fait mal fait … avec les principes de base du génie logiciel oubliés).

Heureusement, des ROI très élevés inatteignables sans la capacité de traiter des masse de données peuvent être rapidement obtenus (détection de churn, de fraude, d’optimisation cachée, de production d’insights / signaux).

Une fois la construction atteinte, la cathédrale est malheureusement un édifice qui subit les assaut du temps.

En étant un point central pour les données, il y a une suite de risques bien connus :

Le phénomène de goulet d’étranglement : des files d’attente des demandes métier qui s’allonge (mobiliser la cathédrale prend du temps),
Pour y répondre on fait grossir les équipes en charge de la cathédrale,
En parallèle, qui dit centralisation, dit risque de déresponsabilisation des métiers qui se déchargent sur les gardiens de la cathédrale (les données métier deviennent leur problème), qui doivent alors se renforcer.
Le tout conduit au phénomène d’obésité de ces équipes, jusqu’à un effondrement de la responsabilité vis-à-vis des données. Plus personne n’est alors pleinement responsable des données (déresponsabilisation des métiers, impossible aux gardiens de la cathédrale de maîtriser tous les contextes métier – ils manipulent les données sans les comprendre).

Un autre risque connu est le phénomène de marécage (data swamp) : avec l’ingestion de données sans maîtrise de leur contexte (métadonnées), dupliquées, mélangées parce que provenant de plusieurs sources, des traitements des données sans cohérence entre eux (plat de spaghettis de pipelines), avec des règles métier embarquées, dupliquées et non forcément tracées.

Un autre phénomène est le risque d’obsolescence technique : le cycle de renouvellement / obsolescence des briques techniques data et très rapide (sans oublier les batailles techniques qui mettent à mal des choix – cf. Batailles Snowflake, Databricks autour des tables Iceberg, sur le catalogage, sur l’intégration d’offres tiers vs fonction intégrée, rachetées…). La façon dont sera géré le cycle d’évolution technique est critique.

Le métier de data ingénieur (engineer) est difficile entre des nouvelles briques qui apparaissent quasiment toutes les semaines, des nouveaux standards de fait, des briques abandonnées, des briques non matures mais lancées par les éditeurs pour prendre position (j’ai deux souvenirs récent, avec une solution de data catalogage ne permettant pas de charger des métadonnées d’une certaine taille … à la grande frustration des développeurs et une fonctions d’observabilité soi-disant compatible à condition … de dupliquer les données !).

Le plus dur est que cela intervient dès le temps de la construction et bien entendu dans le temps d’entretien, avec des couts important de montée de version des briques et de maintien en condition opérationnelle de l’intégration d’ensemble. Je n’ai jamais vu les cycles de publication des nouvelles releases des différentes briques s’aligner et sans remettre en cause une partie des scripts d’intégration développés (attention aux cathédrales instables).

Pour rajouter un peu de tension dans le métier de data ingénieur, un rappel, les big data d’il y a 12 ans ne sont plus des big data (un serveur moyen actuel avec les dernières briques de stockage sont capable de supporter les volumes de données qui nécessitaient une infrastructure conséquente il y a 12 ans).

Et pour terminer, l’évolution des couts est à surveiller comme le lait sur le feu : couts cloud, couts de licence, avec les montées en volume, en performance (pour un POC le CAPEX peut être négligeable … voire trompeur, pour un projet industriel il peut être conséquent et surtout, au fil de sa montée en puissance – nombre de traitements exécutés-volumes de données traités, les charges peuvent exploser).

En conclusion de cette partie, une cathédrale cela se mérite, c’est attirant, cela coute cher mais c’est puissant… et il faut être en mesure de la faire vivre dans le temps.

Partie chapelles métiers

Partie sur les chapelles data métiers – pour les éléments de discours voir les ressources proposées par Orkestra data sur son site – https://orkestra-data.com/ mais aussi en vidéo sur la chaîne Youtube.

Mise en regard cathédrale IT et chapelles métiers

La mise en regard des deux approches, amène à plusieurs constats :

Des complémentarités évidentes – avec deux exemples :
- 1) sur la qualité des données, en alliant préventif et curatif. Les chapelles jouent un rôle préventif en étant à la racine de la production des données (ou des data products) – on parle de root cause analysis en démarche qualité. De leur côté les cathédrale par leur capacité de masse et de calcul sont des forces de frappes sur le traitement curatif des stocks de données. Sans oublier que le tout, la qualité induite est indispensable aux cathédrales pour leurs moteurs de calculs (data science, IA)
- 2) sur le retour opérationnel des résultats produits par les cathédrales IT dans les processus opérationnels et data (avec la BI temps réel, le scoring, la reconnaissance de comportements intégrés dans les processus). Mais aussi la capacité de découverte et d’accès plus étendu des données, cela permet d’innover et d’enrichir les processus data. Dans les briques fonctionnels d’un data stack la brique de data sharing est incontournable (DaaS, ETL inversé, exposition de data products par exemple).
Des contraintes communes : gouvernance des données (vue d’ensemble : accès, sécurité, compliance, standardisation) … hélas souvent limitée au contenu des cathédrales … on ne résout pas le problème des données en dehors.
Des projets de construction qui vont ensemble. Le projet de cathédrale a besoin d’une stratégie d’alimentation en données. Stratégie où les chapelles métier ont leur mot à dire. Et pour revenir au problème du « slow time to delivery », dans le temps de construction de la cathédrale, il existe des solutions tactiques qui permettent de continuer à voler, avec des chapelles et des ressources temporaires.

Une illustration de la complémentarité sur l’exemple de la supply chain (avec les problématiques de logistique, de gestion de stocks, de flux tendus, de traçabilité…et d’éviter toute rupture).

La masse de données que l’on peut collecter tout au long d’une supply chain, permet énormément de choses, dont prioritairement : l’anticipation, la prévention et la réactivité face aux risques fournisseurs, risques transporteurs, risques de production (résilience attendue, ne pas mettre en arrêt la chaîne de production, lever les risques de congestion, répondre aux exigences de livraison) avec la mobilisation d’algorithmes de BI, data science, recherche opérationnelle et IA. Autre exemple optimiser le cout climatique de la chaine. Une cathédrale data supply chain est mobilisée. Mais cette cathédrale a besoin d’une multitude de chapelles data : reflet de la digitalisation de processus (collecte de données suivi – géolocalisation – traçabilité, de risques géopolitiques, météo, financiers) qui peuvent mobiliser des milliers d’acteurs (des fournisseurs aux conducteurs de camion en passant par des analystes financiers par exemple).

Sans cette myriade de chapelles, la cathédrale est inopérante.

Et certaines cathédrale l’ont bien compris avec des tentatives d’assimilation des chapelles, mais qui fait fuir les métiers (ou du moins les rend frileux, avec le danger connu de la déresponsabilisation).

La coopération entre les deux types d’édifices est vitale, elle mobilise des normes – un langage commun, des capacités d’interaction fluide (sur la base de data products, de data contracts par exemple qui vont embarquer des règles communes d’interopérabilité, de compliance).

Une dernier point provocateur vouloir tout mettre (ou voir) ses données dans une vue unique (l’ambition de la cathédrale) est riche en mythes, en retour d’expérience biaisés, en buzz du marché – « mettez toutes vos données dans la cathédrale et oubliez vos problèmes data » (voir par exemple les batailles en cours autour des fonctions de catalogage des données – cf. les dernières annonces au cours des conférences Databricks, Snowflake), avec des limites connues. Seul le duo cathédrale / chapelles métier peut répondre à cette ambition. Le développement de ce dernier point pourrait faire l’objet d’une suite à ce webinaire : vue unique des données mythes, limites, réalités !

La conclusion, vous l’avez compris, il y a une nécessaire complémentarité : pas de cathédrale sans chapelle. Pas de maîtrise d’ensemble des données sans à la fois des cathédrales et des chapelles.

Il y a des outils disponibles (exemple Orkestra data pour couvrir les fonctions de chapelles métiers) et au-delà, des cadres de vie des données comme le data mesh, conjuguent et montrent que l’on a besoin des deux orientations.

S’il y a une chose à retenir, si chez vous il y a un projet de cathédrale data IT assurez vous qu’il y a bien aussi des chapelles data métier …