In Tribune expert

Si je vous dis : « Je suis un nouveau paradigme qui conceptualise les aspects méthodologiques, techniques et organisationnelles des plateformes de gestion des données à grande échelle. »

Alors vous me répondez ?  

  • « Data Maiche » … non,
  • « Data Mèche » … ça chauffe,
  • « Data Mesheuuuh » … presque,
  • « Data Mesh » … Bingo !

Ce paradigme a été popularisé par les travaux de Zhamak Dehghani dont vous pouvez retrouver une synthèse vidéo sur https://www.thoughtworks.com/data-mesh-paradigm-shift

Sur le web vous trouverez un grand nombre d’articles et de ressources pour vous présenter le sujet de façon détaillée, ce que nous ne ferons donc pas ici. Whaaat ?

En effet, nous allons plutôt aborder les problématiques, ou les limites, impliquées par le fonctionnement des plateformes actuelles. Problématiques qui ont conduit à l’approche « Data Mesh ».

Principes d’organisation des plateformes data existantes

La majorité des plateformes actuelles fonctionnent avec des équipes centralisées. Si on résume à l’extrême les parties prenantes qui sont mobilisées au quotidien dans la gestion des datas nous avons :

  • Les équipes de « production » (ou responsable de « domaine ») qui gèrent les outils à la source et vont générer la donnée brute,
  • Les équipes « IT / Data » qui vont intégrer, gérer, préparer ces données brutes afin de pouvoir les exposer aux équipes « consommatrices »
  • Les équipes « consommatrices » qui vont s’appuyer sur la donnée exposée pour prendre des décisions.

Partant de ce postulat, voyons à présent quels sont les points qui peuvent poser problème ? 

Le “Ownership” des données

De fait de l’organisation, il y a un effet de dé responsabilisation des équipes à chaque niveau.

  • Les équipes de production assurent le bon fonctionnement des outils de front office et la donnée qui en découle n’est pas une priorité,
  • Les équipes  IT / Data assurent la bonne intégration et mise à disposition mais ne peuvent maîtriser la complexité de chaque application et donc en prendre la responsabilité,
  • Les équipes consommatrices souhaitent principalement exploiter cette donnée de façon opérationnelle sans avoir à gérer les phases amont ou en être responsable.

Le “Ownership” des données n’est donc pas naturel et nécessite la mise en place de décisions d’entreprise pour affecter cet “Ownership” à des individus ou équipes. Avec une complexité à gérer dans l’adhésion et la mise à disposition de moyens adaptés à la bonne gestion. 

La gestion de la qualité des données

Un effet domino de la complexité de gérer l’ownership touche la gestion de la qualité des données pour les mêmes raisons.

Chaque équipe n’ayant qu’une vue partielle de la connaissance de la données :

  • La maîtrise des process de création pour les équipes de production,
  • La maîtrise des process de transformation pour les équipes IT / Data,
  • La maîtrise des process d’exploitation pour les équipes de consommation.

Il est donc très complexe pour ces équipes d’assurer et maintenir la gestion de la qualité des données dans le temps.

Les liens entre les acteurs de ces plateformes

Ce fonctionnement entraîne un effet de goulot d’étranglement sur les équipes “IT / Data” car elles doivent à la fois :

  • comprendre les mécaniques de créations des données pour les intégrer et préparer de la meilleure façon pour l’exposition,
  • comprendre les problématiques business de consommation afin de répondre aux interrogations des entités consommatrices.

Et dans un contexte de croissance des données disponibles et développement de la maturité et du volume d’utilisateurs … il est impossible de suivre et d’assurer une scalabilité de l’organisation.

L’essence du paradigme “Data Mesh”

Les fondamentaux

C’est donc avec la volonté d’apporter une solution à ces différents problèmes que se trouve la source de ce paradigme.

Voici pourquoi, dans tout ce que vous pourrez lire sur le sujet, vous retrouverez les grands principes suivants :

  • Considérer la “data” comme un produit. Ce qui implique qu’il faut définir un “marché” pour votre produit, identifier vos “clients”, faire le marketing de votre produit, définir le  prix, et suivre la satisfaction de vos clients.
  • Décomposer vos produits en domaine de données. Ce qui implique que chaque produit va apporter de la connaissance sur un thème défini, et qu’on peut regrouper / agréger plusieurs domaines entre eux pour en former des nouveaux.
  • Opérer ces produits » data » au sein d’une infrastructure Self Service. Ce qui implique que quiconque souhaitant utiliser un produit doit pouvoir le faire de façon autonome.

C’est ce qui explique les grands principes qui sont définit et que chaque domaine doit respecter : Discoverable, Adressable, Self-describing, Secure, Trustworthy & Interoperable

L’ambition

En proposant une vision méthodologique, technique et organisationnelle, le data mesh ambitionne donc de permettre une scalabilité dans l’exploitation des données.

Ainsi son application offre la possibilité de s’adapter :

  • à l’intégration de plus de données en entrée (Production)
  • à des modèles de données qui sont en constante évolution (IT / Data),
  • à des expositions plus variées et une nombre croissant d’utilisateurs (Consommation)

What Next ?

Souvent réduit à un principe de modélisation de la donnée, quand on creuse la réflexion sur le sujet en projetant une application concrète, on s’aperçoit qu’il s’agit plutôt d’une philosophie. La philosophie du “produit data”.

Et quand on regarde aussi l’engouement pour les sujets data, le volume d’initiatives de consommation des données qui sont lancées chaque années, et les ambitions des acteurs à être en capacité de traiter des projets d’IA … on peut raisonnablement se dire que cette philosophie trouvera rapidement echos et sera mise à l’épreuve du feu. 

Besoin d’être accompagné sur ce type de sujet ? N’hesitez pas à échanger avec l’un de nos experts qui vous partagera nos retours d’expériences et sa vision pour votre contexte. Alors vous savez ce qu’il vous reste à faire :

Recent Posts
AVISIA