Data mesh : principes, conditions de succès et critiques
Le data meshdata meshLe Data Mesh est une approche décentralisée de l'architecture et de l'organisation des données, où les équipes métier possèdent et exposent leurs données comme des produits, encadrées par des standards partagés.Voir la définition complète → est le paradigme architectural le plus discuté de ces cinq dernières années. Il a des défenseurs passionnés et des détracteurs tout aussi passionnés. Le comprendre clairement, ce qu'il est vraiment, quel problème il résout et quand il est pertinent, est indispensable pour tout responsable data senior.
Le problème que résout le data mesh
Le data mesh est né d'un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → d'échec précis, observé dans de grandes organisations à forte intensité de données.
Le schéma : l'équipe data centrale devient le goulot d'étranglement. Chaque domaine (produit, marketing, finance, opérations) a besoin de données. Tous les demandent à l'équipe centrale de la plateforme data. L'équipe centrale est submergée. La livraison des données prend des semaines. Les métiers sont frustrés. La qualité des données est irrirrLe taux de rendement interne est le taux d'actualisation qui annule la valeur actuelle nette d'un projet. Il exprime le rendement annualisé attendu d'un investissement.Voir la définition complète →égulière parce que l'équipe centrale ne comprend pas les subtilités propres à chaque domaine.
Zhamak Dehghani (alors chez Thoughtworks) a diagnostiqué là un problème organisationnel et architectural, pas technique. Sa solution : distribuer la propriété des données aux domaines qui les comprennent le mieux.
Data Mesh Explained
Vérification des acquis
1. D'après la leçon, quelle est la nature fondamentale du problème que le data mesh a été conçu pour résoudre ?
2. Dans le cadre du principe de « plateforme data en self-serve », comment évolue le rôle de l'équipe data centrale ?
3. Qu'est-ce qui traduit le mieux le sens de « la donnée comme produit » dans un data mesh ?
4. Sélectionnez TOUS les énoncés qui décrivent correctement les quatre principes du data mesh.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUS les symptômes du schéma d'échec qui a motivé la création du data mesh.
Sélectionnez toutes les réponses correctes.
Les quatre principes du data mesh
1. Propriété des données décentralisée et orientée domaine
Les données sont détenues et servies par le domaine qui les produit. Le domaine checkout détient les données de checkout. Le domaine client détient les données client. Chaque équipe domaine est responsable de la qualité, de la fiabilité et de l'accès aux données.
2. La donnée comme produit
Chaque domaine ne produit pas seulement de la donnée, il produit un data productdata productUn actif de données géré comme un produit : un owner, des utilisateurs identifiés, une qualité garantie et une valeur business mesurable.Voir la définition complète →. Un data product a un owner, un SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète →, de la documentation, un schéma, une découvrabilité. Il est traité avec la même discipline de product management qu'un produit logiciel.
3. Plateforme data en self-serve
L'équipe data centrale passe de producteur de données à fournisseur de plateforme. Elle construit l'infrastructure que les équipes domaines utilisent pour produire et consommer des data products : l'outillage, les standards et l'infrastructure, pas la donnée elle-même.
4. Gouvernance computationnelle fédérée
Les politiques globales (conformité RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →, standards de sécurité, seuils de qualité des données) sont définies au niveau central et appliquées par la plateforme. Les équipes domaines opèrent dans ces garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → mais restent autonomes sur la façon de les implémenter.
Quand le data mesh a du sens
Le data mesh résout un problème d'échelle et d'autonomie. Sa mise en œuvre exige une maturité organisationnelle importante. Posez-vous ces questions :
- Avez-vous plusieurs domaines produit avec des domaines de données distincts ? (< 3 domaines → le mesh est disproportionné)
- L'équipe data centrale est-elle un goulot d'étranglement ? (Si non, le problème que résout le mesh n'existe pas)
- Vos équipes domaines ont-elles une capacité de data engineering suffisante ? (Le mesh exige que chaque domaine prenne en charge son data engineering, c'est une exigence de compétences considérable)
- Avez-vous l'alignement du management pour restructurer la propriété des données ? (Le mesh est un changement organisationnel, pas seulement technique)
Airbnb, Netflix et Intuit ont mis en place des architectures de type mesh. Mais ils disposaient de centaines de data engineers et d'organisations multi-domaines complexes. Pour une entreprise de 500 personnes avec un seul domaine produit, une architecture centralisée avec de bons process vaut probablement mieux.
Les critiques
Le data mesh ne fait pas l'unanimité. Les critiques récurrentes :
- Risque de duplication : sans gouvernance solide, les domaines crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éent des versions redondantes et incohérentes des entités partagées (client, produit).
- Exigence de compétences : la plupart des équipes domaines n'ont pas les compétences de data engineering nécessaires pour produire des data products de qualité. Vous déplacez le problème, vous ne le résolvez pas.
- Complexité : la gouvernance fédérée est difficile. Les jointures inter-domaines deviennent des problèmes de systèmes distribués.
La réponse honnête : le data mesh est une solution à un problème spécifique, à grande échelle. Appliqué prématurément ou sans maturité organisationnelle, il crée plus de problèmes qu'il n'en résout.
Questions de quiz
- Quel problème organisationnel le data mesh cherche-t-il principalement à résoudre ?
A) Le coût du stockage de données
B) L'équipe data centrale qui devient un goulot d'étranglement, ralentissant la livraison de données aux domaines
C) La sécurité des données dans le cloud
D) La vitesse de traitement des requêtes SQL
Réponse: B
- Dans le data mesh, quel est le nouveau rôle de l'équipe data centrale ?
A) Propriétaire de toutes les données de l'organisation
B) Fournisseur de plateforme self-serve que les équipes domaines utilisent pour produire leurs data products
C) Équipe d'audit et de conformité
D) Équipe de reporting BI
Réponse: B
- Dans quel contexte le data mesh est-il le plus adapté ?
A) Une startup avec 50 employés et un seul produit
B) Une organisation multi-domaines mature avec de nombreuses équipes data et un bottleneck central avéré
C) Toute organisation souhaitant améliorer sa gouvernance des données
D) Une organisation avec peu de compétences en data engineering
Réponse: B
À faire, tiré de cette leçon
Ces actions sont compilées dans le plan d'action du rôle.
- N'adoptez le data mesh que dans les organisations multi-domaines matures, avec un goulot d'étranglement démontré
Articles liés
Les articles récents du blog qui s'appuient sur cette leçon.
- DataComment JPMorgan Chase a structuré ses contrats de données pour maîtriser la gouvernance inter-domainesJPMorgan Chase a déployé une architecture de contrats de données à grande échelle pour résoudre un problème récurrent dans les grandes organisations : qui possède quoi, et selon quelles règles. Voici ce que cette expérience enseigne aux CDO qui gèrent des domaines multiples et des parties prenantes aux intérêts divergents.
- DataLe modèle hub-and-spoke data : pourquoi il déçoit presque toujoursLe modèle hub-and-spoke s'est imposé comme la réponse élégante au débat entre centralisation et décentralisation des équipes data. Mais derrière cette architecture séduisante sur papier, les CDO découvrent en pratique une série de dysfonctionnements que le consensus ne veut pas admettre.
- DataComment JPMorgan Chase a structuré ses contrats de données pour gouverner 50 domaines métiersJPMorgan Chase a déployé un cadre de contrats de données inter-domaines pour résoudre des conflits de propriété qui paralysaient ses équipes analytiques. Ce que la banque a construit, ce que ça a produit, et ce qu'un CDO peut en tirer concrètement.