Data Mesh : Révolution ou Concept Marketing ? 1/2

Le concept de « Data Mesh », apparu pour la 1ère fois en 2019 dans l’article de Zhamak Dehghani, principal technology consultant chez ThoughtWorks, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh , constitue un point focal d’espoir et de débats passionnés au sein de la communauté Data. Il est vu par certains comme une petite révolution dans la manière de gérer la donnée, et par d’autres comme un nouveau concept marketing se contentant de « réchauffer » des idées vieilles comme le monde. Face à la multitude et la divergence de points de vue, nous pensions intéressant de revenir sur les fondamentaux du concept et d’apporter un regard éclairé et circonstancié dessus.

Data Mesh : les raisons qui poussent à un changement radical

Les données existent depuis de nombreuses décennies dans les organisations, mais elles n’ont jamais fait l’objet d’une telle attention que sur les dix dernières années. L’avènement des possibilités analytiques, notamment prédictives ou prescriptives, a fait accélérer les investissements massifs sur les compétences, les technologies, et autres projets ou chantiers orientés « data ». Dans le même temps, peut-être de manière légèrement décalée, nous avons aussi vu un regain d’intérêt sur les fondamentaux du Data Management autour de la qualité, des métadonnées, ou encore des données maîtres et de référence. Cette accélération des investissements va bien entendu de pair avec la pression des hautes instances dirigeantes des entreprises, qui attendent des bénéfices à la hauteur des moyens engagés. Et c’est souvent là où le bât blesse. En effet, dans la majorité des cas, on observe un décalage grandissant entre les espoirs et la réalité. Ce décalage a de plus en plus tendance à s’accentuer dans le temps au fur et à mesure que nous collectons plus de données provenant de plus de sources, pour plus d’usages qui sont en constante prolifération.

Alors face à cette situation, le bon vieux réflexe commun est de se dire, comme notre cher ami Barney dans « How I met your mother » que « New is always better », ce qui en d’autres termes signifie qu’il faut quelque chose de nouveau pour faire face à la situation actuelle et franchir un point d’inflexion.

Habituellement, la fameuse nouveauté est une nouveauté technologique, et c’est ce que l’on a pu observer avec les « datalake », « data hub », et autres plateformes data qui, si elles permettent de résoudre beaucoup de problèmes et de faciliter la vie de nombreux acteurs de la donnée, n’en résolvent cependant pas les fondamentaux : pour de nombreuses organisations il reste encore très difficile, malgré de nombreux efforts, d’avoir facilement accès aux bonnes données, avec un niveau de confort et de confiance à la hauteur de l’usage que tout un chacun veut en faire.

Ce constat général est partagé par Zhamak Dehghani, qui explique dans son article, et futur ouvrage « Data Mesh » à paraître chez O’Reilly que l’approche monolithique et centralisée de type « datalake », qui consiste à regrouper physiquement les données opérationnelles venant de sources diverses dans un lieu commun, conduit habituellement aux écueils suivants :

• Une difficulté à faire face à la prolifération accélérée des sources de données— accélérée notamment par les architectures de micro-services — et des points de consommation — accélérée par le déploiement des algorithmes apprenants dans nos opérations quotidiennes : l’approche centralisée se traduit en effet généralement par un ownership unifié entre la plate-forme elle-même, les opérations que cette plate-forme effectue sur les données, et les données qu’elle traite, avec pour conséquence une friction organisationnelle entre la capacité de l’équipe centrale qui détient cet ownership, et les nombreux consommateurs de la donnée à des fins analytiques ;
• Des défauts d’intégration entre les données opérationnelles(qui sont issues des systèmes transactionnels ou de diverses sources de données externes) et les données analytiques, avec des « pipelines » complexes à maintenir entre les deux, des zones de couplage importantes, et des goulots d’étranglement au niveau des équipes impliquées ;
• Déconnexion et silotage fonctionnel des équipes : l’approche monolithique et centralisée de type « datalake » conduit à hyperspécialiser fonctionnellement les équipes entre là où sont créées les données brutes, là où sont opérés le stockage et la transformation des données, et là où sont exploitées les données à des fins analytiques. En conséquence, il peut y avoir potentiellement des mécompréhensions et de la frustration chez ces trois populations qui ne travaillent pas de manière intégrée.

On remarquera dans ces derniers propos que le prisme est très centré sur les données analytiques, avec les concepts d’architecture, d’organisation et de gestion associée. En effet, le « Data Mesh » est bien un concept qui s’applique aux données analytiques et non à l’ensemble des données de l’entreprise. Il propose une approche pour réduire l’espace entre les données opérationnelles et les données analytiques, mais n’exprime cependant pas réellement une solution d’organisation et d’architecture englobant l’ensemble des données de l’entreprise : il s’agit d’un point important sur lequel nous reviendrons dans la suite de l’article.

Data Mesh : une approche socio-technologique, et non juste une approche architecturale

Le « Data Mesh » est une approche socio-technologique pour partager, accéder et gérer les données analytiques dans des environnements complexes et à grande échelle. Ce n’est donc pas uniquement une approche architecturale, mais bien une approche englobant différents vecteurs de changement que sont : l’organisation, l’architecture, la technique, le modèle opérationnel et les principes sus-jacents.

Quatre grands principes encadrent le concept de « Data Mesh » :

• Un ownership orienté domaine (domain-oriented ownership)
• La donnée comme un produit (data as a product)
• Une plateforme data self-service (self-serve data platform)
• Une gouvernance fédérée (federated computational governance)

a. Un ownership orienté domaine

Ce principe énonce une organisation décentralisée pour le partage, la mise à disposition et la gestion des données analytiques selon des domaines métier au plus proche de la donnée. Le « Data Mesh » regroupe ainsi de manière systématique dans des domaines métiers les différents composants qui vont permettre de gérer les données analytiques en autonomie, à savoir les données analytiques elles-mêmes, les métadonnées associées, le code pour assurer la maintenance de ces données et leur intégrité, et l’infrastructure nécessaire à la création et à l’exposition de ces données analytiques. L’organisation du travail ne suit donc pas un style d’architecture particulier qui partitionnerait le travail de manière fonctionnelle — comme c’est le cas avec les datalakes actuels.

La question qui émerge souvent est de savoir comment déterminer les domaines métier énoncés. Trois grands archétypes de domaines, qui sont interconnectés et vont cohabiter ensemble, sont proposés autour de ce principe :

• Les domaines de données alignés aux sources de données: les données analytiques reflètent des faits métiers générés par les systèmes opérationnels ;
• Les domaines de données agrégés: les données analytiques constituent un agrégat de données venant de multiples domaines « amont », en particulier des domaines alignés aux sources de données ;
• Les domaines de données alignés aux consommateurs de données: les données analytiques reflètent des besoins spécifiques de consommation. Ces domaines, qui sont généralement des domaines en « bout de chaîne », sont également appelés domaines « fit-for-purpose » .

Ainsi, pour une entreprise qui vendrait des livres en ligne, nous pourrions avoir les domaines suivants :

• Domaines alignés aux sources de données : articles, client, évènements web (click, etc.)
• Domaines agrégés : préférences client
• Domaines alignés aux consommateurs de données : performance article, recommandations client.

Il est à noter que ce principe peut être vu comme perturbant pour beaucoup d’entreprises car les domaines évolueront de manière organique par nature, avec une approche quasi ou non planifiée de la « bonne » partition des domaines de données. Un domaine n’existe que s’il est pertinent au vu de l’usage des données analytiques qui en est fait. Un autre élément perturbant est que le « Data Mesh », en corollaire, ne fait donc pas la promotion des sources uniques de vérité (SSOT : Single Source of Truth) avec des modèles canoniques et unifiés de données, qu’elle considère davantage comme une « idéologie ».

Dans tous les cas, et nous ne pouvons le nier, le principe répond à certains écueils des « datalake » car il permet d’éviter les goulots d’étranglement susmentionnés et d’internaliser l’implémentation des pipelines complexes de transformation au sein d’un Domaine, qui en détient sa responsabilité.

Ici se termine notre premier article sur ce concept passionnant qu’est le Data Mesh. Le deuxième volet sera publié très prochainement pour poursuivre la description des principes clés de ce paradigme : la nécessité de considérer la donnée comme un produit, l’importance d’une plateforme data self-service et d’une gouvernance fédérée. Stay tuned !