Press "Enter" to skip to content

Data mesh et référentiels de données d’entreprise : est-ce compatible ?

Publié le 30 mars 2023 par Joël Bizingre

Dernière modification le 8 décembre 2023

Cet article décrit comment l’approche Data mesh est compatible avec la définition de référentiels de données d’entreprise.

Plan :

  • Mise en avant de l’importance de la notion de responsabilité des domaines métier dans l’approche Data mesh au travers de retours d’expérience d’échecs d’approches centralisées (data lake, central data team),
  • Jusqu’à la remise en cause de la logique de référentiels de données d’entreprise parce que relevant d’une perspective centralisatrice,
  • Remise en cause qui serait une erreur. Retour sur la notion de responsabilité des domaines métier pour montrer que Data mesh et référentiels de données d’entreprise sont compatibles et forment même un couple primordial.

Négligence du principe de domaine du Data mesh et échecs du passé

L’approche Data mesh est tendance, elle gagne en popularité et en écoute dans les entreprises … elle fait le buzz (voir l’actualité de ce sujet dans les différentes revues data du mois : exemple https://www.datassence.fr/2023/02/10/revue-data-du-mois-janvier-2023/#_ftn2 ).

Elle vient au bon moment face aux échecs de projets centraux Data Lake, Big Data (elle veut y répondre, mais attention on ne se situe pas au même niveau et de plus, l’approche data mesh ne résout en rien un part de la raison de ces échecs – exemple l’erreur d’alignement avec la nature des données traitées).

Un des piliers de l’approche ou du paradigme Data mesh est la logique domain driven (en cohérence avec les autres piliers : data as a product – data product, infrastructure – plate-forme data de fabrique et self service des data products, gouvernance fédérée des données).

Cette mise en avant est clé, elle permet de placer l’engagement des données au plus près de leur connaissance, de leur gestion, de leurs usages. Autrement dit le domaine formalise l’idée d’être au plus proche des responsabilités métier par opposition à une vision centralisée de gestion des données. Et effectivement une part des échecs des approches centralisées (type data lake) est due à une mauvaise prise en compte de cette responsabilité.

Un petit vécu sur deux retours d’expérience d’échecs de data lake :

1) Dans le 1er cas un data lake central a été initié avec l’appui pilote d’un domaine métier porteur. Le projet data lake n’est jamais arrivé à attirer d’autres domaines métier. Ces derniers ayant pris peur d’être dépossédés de leurs données, de par l’effet central et de par la prééminence (voir une crainte d’hégémonie) du domaine métier pilote et porteur.

2) Dans le 2ème cas, un data lake central est mis en place. Avec l’intégration des données de plusieurs domaines métier. Le data lake joue son rôle, de la valeur ajoutée est dégagée par des nouvelles capacités d’analyse, d’exploitation des données. Mais au bout de deux ans, le data lake « s’effondre » sur lui-même. La course à l’intégration de plus en plus de données, la course aux delivry de projets métier data de toutes natures, les contraintes d’intégrer de plus en plus de règles métier autour des données a conduit à un effet ciseau et de tensions (central/local) :

  • du côté du data lake, l’équipe en charge est passée de moins de 10 personnes à plus de 70 personnes pour « assurer » les responsabilités vis-à-vis des données embarquées et des projets délivrés, avec hélas les défauts de la centralisation et l’éloignement du terrain métier (« on ne comprend pas trop ce qu’on manipule et pourquoi ! »),
  • et du côté des domaines métier, on a progressivement délégué, transféré puis abandonné à l’équipe data lake les responsabilités autour des données (« ce n’est plus notre problème, elles sont chez eux ! »).

Dans les deux cas la perte ou la peur de perte de responsabilité sur les données ont conduit à l’échec.

L’approche data mesh à la vertu de se réconcilier avec l’idée d’une gestion des données « au plus proche des domaines de responsabilité ».

Remise en cause de la logique de référentiels de données d’entreprise parce que relevant d’une perspective centralisatrice

Mais attention, l’effet tendance data mesh pousse certain à porter aux nues l’approche par domaine métier et leur autonomie associée, avec le mirage : de la non nécessité de la gestion de données de référence d’entreprise. Dans le paradigme data mesh, les données sont distribuées dans les domaines. La gestion traditionnelle centralisatrice et redescendante des données de référence ne fonctionnera tout simplement pas.

Forcément le sujet ne peut que m’interpeller.

Les référentiels de données jouent fondamentalement un rôle clé (voir https://www.datassence.fr/referentiels-de-donnees/ et https://www.dunod.com/sciences-techniques/referentiels-du-systeme-d-information-donnees-reference-et-architectures-d ).

L’origine de ce mirage part de l’opposition local (domaine) / central.

Les référentiels de données seraient de l’obédience centrale et donc hors de la logique data mesh.

Que l’on se rassure le rôle des référentiels n’est absolument pas remis en cause par le data mesh. Leur rôle est et reste fondamental : indispensable au data mesh.

La question est alors comment s’y intègrent-t-ils ?

Data mesh et référentiels de données sont compatibles et la notion de domaine joue un rôle clé.

Plusieurs axes sont à prendre en compte :

  • 1) Un référentiel de données peut avoir une source légitime au sein d’un domaine métier qui comme pour toutes ses données applique les bonnes pratiques data mesh : responsabilité, mise à disposition, contrôle des usages… (par exemple un domaine métier en charge des collectivités pour son organisation, peut être légitime pour être le responsable des données de référence territoriales – communes, regroupements de communes, zones géographiques et collectivités, et utiles à d’autres domaines),

  • 2) Le terme référentiel d’entreprise, n’est pas neutre. L’approche par domaine, n’exclut pas un domaine métier de portée entreprise. Et il est même recommandé. C’est enfoncer une porte ouverte de dire que les domaines métier font partie d’une organisation avec toutes les conséquences qui vont avec. Les référentiels de données d’entreprise ont alors toute leur place légitime dans ce domaine métier entreprise. Ils relèvent d’une responsabilité de niveau entreprise. Il est indispensable de les exposer aux autres domaines… Cependant il faut trouver l’équilibre de leur portée en termes de données gérées. Il faut éviter de reproduire le syndrome d’une base référentielle obèse avec des centaines d’attributs… non forcément de la responsabilité du domaine entreprise et naturellement issus des autres domaines métier (exemple classique d’un référentiel des personnes morales ou clients, dont les attributs relèvent des domaines métier : du marketing, du commercial, des processus support…). L’équilibre est simple : le domaine métier entreprise est responsable de la partie socle du référentiel (voir dans l’ouvrage en référence https://www.dunod.com/sciences-techniques/referentiels-du-systeme-d-information-donnees-reference-et-architectures-d, l’explication détaillée de la notion de référentiel socle). Cette partie socle a besoin de quelques traits d’identité (une dizaine de données) et expose quelques services limités mais stratégiques (cycle de vie – immatriculation, identifier, rechercher, vérifier). Le domaine métier entreprise est responsable de la légitimité des occurrences embarquées et cela au travers du pouvoir d’identification / immatriculation (on parle d’autorité référentielle voire d’autorité de régulation dans des référentiels conditionnés par des aspects juridiques – avec le cas emblématique du référentiel SIRENE de l’Insee). Pour le reste des données (complémentaires aux traits d’identités), plusieurs styles d’architecture autour des référentiels peuvent s’appliquer. Par exemple le domaine entreprise va s’abonner aux données relevant du référentiel auprès des autres domaines, pour les consolider, dédoublonner, ou alors juste se limiter à fournir un id de référence permettant d’assurer une transcodification avec un id local (il n’y a pas un principe unique, le choix d’architecture est à faire au cas par cas – en particulier par rapport au besoin du time to market des données – un domaine peut ne pas avoir le temps d’attendre la propagation des données de référence).
  • NB : dans l’approche data mesh, certains parlent de « core data as a product » pour distinguer les référentiels de données d’entreprise. Personnellement j’aime bien aussi parler de « core data product » comme produit de plates-formes data (les deux termes / logiques se complètent : le 1er voit la donnée de référence comme un produit, le 2ème voit un produit basé sur les données de référence).
Un référentiel de données est un data product (principe 2 du data mesh), qui doit être utilisable en self service autant par les acteurs IT que par les acteurs métier (principe 3), et qui édifie une capacité d’interopérabilité, de cohérence entre les données par une gouvernance et une architecture fédérées (principe 4).
  • 3) Un domaine métier ce n’est pas uniquement une responsabilité liée à des droits mais aussi liées à des devoirs. Vis-à-vis des données de référence, ses devoirs sont : ne pas les réinventer, assurer la bonne circulation des Id de référence dans son périmètre, alimenter le cas échéant le référentiel avec les données de sa responsabilité (si mapping ou ½ interface d’intégration, c’est de sa responsabilité, c’est lui qui connait le mieux ses données et donc comment les traduire dans une vision partagée – référentielle). En faisant cela, il permet aux autres domaines métier et via le domaine entreprise, de créer à leur besoin une vue de référence des données concernées (par exemple créer sa vue client en se basant sur l’id maître du domaine entreprise et en interrogeant les autres domaines).

  • 4) Enfin une dernière réflexion, il ne faut pas confondre infrastructure de master data management (MDM) et instanciation logique de référentiels de données dans une infrastructure MDM. Une des sources de l’idée que les référentiels de données n’ont pas leur place dans le data mesh, vient de l’idée qu’une plate-forme MDM centrale va à l’encontre des principes du data mesh. C’est se tromper de niveau de réflexion et confondre une commodité d’infrastructure et son usage instancié par domaine métier. Rien n’interdit d’avoir une unique plate-forme MDM en infrastructure avec des instanciations déclinées par domaine métier.

NB : toute cette discussion s’applique bien entendu aussi aux nomenclatures et à leur gestion, distributions. Avec aussi en tête, le célèbre distributeur de nomenclature souvent absent, ou difficile à positionner.

NB bis : la notion de responsabilité est clé, à rapprocher du rôle de data owner dans le pilier gouvernance de l’approche data mesh.

Références associées à cet article :

Tous droits réservés – datassence.fr. Cet article a été publié originellement sur www.datassence.fr.

L’attribut alt de cette image est vide, son nom de fichier est Datassence_Logo1_1.png.

Lire plus d'articles à propos de Data mesh, Domaine métier ou Référentiels de données

Les commentaires sont fermés.