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

Suite et fin de notre article dédié au Data Mesh, notre objectif étant de revenir sur les fondamentaux du concept et d’apporter un regard éclairé et circonstancié dessus. Notre premier article proposait une rapide introduction pour comprendre la genèse de l’apparition de ce paradigme avant de débuter une présentation détaillée des 4 grands principes encadrant le concept du Data Mesh : nous n’y avions abordé que le premier axiome portant sur l’ownership orienté domaine. Ce deuxième chapitre se concentrera donc sur 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.

Avant de commencer, un petit rappel des quatre grands principes encadrant 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).

b. La donnée comme un produit

Le second principe du « Data Mesh » applique la pensée produit aux données analytiques organisées par domaine : les données fournies par les domaines doivent être traitées comme de véritables produits, et les consommateurs de ces données comme de véritables consommateurs : à savoir que l’on recherche une satisfaction pleine de ces consommateurs. Selon Marty Cargan, leader d’opinion dans le développement et le management des produits (cf. l’ouvrage INSPIRED), un produit doit être réalisable, utilisable et apporter de la valeur. Ainsi, au même titre qu’une API (que l’on considère aujourd’hui aussi comme un produit), une donnée analytique, par exemple un dataset, doit présenter les caractéristiques suivantes, à savoir être :

• Découvrable : il doit être possible d’explorer le champ de toutes les données possibles et de trouver LA « bonne donnée » ;
• Compréhensible : il doit être possible de comprendre la réalité sémantique de la donnée, et la représentation qui a été adoptée pour cette donnée ;
• Adressable : il doit être possible de facilement accéder à la donnée de manière programmatique ou manuelle ;
• De confiance : pour être utilisable, le consommateur doit pouvoir avoir des indicateurs permettant de renforcer la confiance qu’il peut avoir sur la donnée, sur des éléments tels que la qualité, la fréquence de mise à jour, le lineage, etc. ;
• Interopérable : il doit être possible d’utiliser la donnée avec d’autres données venant d’autres domaines de données pour les croiser, les agréger, etc. ;
• Sécurisée : la donnée doit être conforme aux exigences réglementaires et aux différentes politiques de sécurité en vigueur (contrôle d’accès, confidentialité, chiffrage, etc.) ;
• Nativement exploitable : la donnée doit pouvoir être exploitable nativement par différentes populations ;
• Auto-suffisante en termes de valeur : la donnée doit être de valeur sans avoir nécessairement à la combiner avec d’autres données.

Pour mettre en œuvre ce principe, Zhamak Dehghani suggère, au niveau organisationnel, d’introduire deux rôles au sein de chaque Domaine :

• Un Domain Data Product Owner, qui prendrait les décisions sur la vision et la feuille de route des produits data du Domaine, serait responsable de la satisfaction des consommateurs, et assurerait l’amélioration continue de la qualité des produits data du Domaine ;
• Un ou plusieurs Domain Data Product Developer, qui seraient le pendant plus technique et opérationnel du Domain Data Product Product Owner, pour définir la sémantique et les règles de gestion, maintenir les logiques de transformation, et faire en sorte que la donnée présente effectivement toutes les qualités « produit » promises par le Domaine.

Ce principe est certainement, avec le premier principe sur l’orientation Domaine, le plus important autour du concept « Data Mesh » car il permet de voir la donnée autrement, non pas juste comme un actif de l’entreprise, mais davantage comme un produit, ce qui change à la fois la perception sur la donnée, mais aussi ce qu’on entreprend dessus.

c. Une plateforme data self-service

Ce principe permet de répondre aux détracteurs du 1er principe qui avancent que la décentralisation par domaine engendrerait une augmentation du coût total de possession en termes d’infrastructure et d’outils pour gérer le cycle de vie des produits data par chacun des domaines. Le 3ème principe énonce ainsi que le « Data Mesh » n’est viable que s’il existe une plateforme data en mode « self-service » à disposition de chacun des domaines, tant pour les Data Product Owner et Data Product Developer, que pour les consommateurs finaux afin qu’ils puissent découvrir, accéder et consommer les produits data.

L’idée sous-jacente est de mettre en place une plateforme qui aurait plusieurs caractéristiques en particulier :

• Être utilisable directement par les acteurs du Domaine, qui peuvent être des généralistes, et non juste par des équipes spécialisées ;
• Pouvoir gérer de manière unifiée l’ensemble des produits data (donnée + code + politiques) ;
• Pouvoir interconnecter et faire la jonction entre les données opérationnelles et les données analytiques ;
• Pouvoir rendre interopérables les différents Domaines entre eux.

Aujourd’hui, la plupart des plateformes Data offrent un grand nombreuses de capacités qui pourraient répondre à ces caractéristiques, mais le changement substantiel tient, avec ce principe, davantage dans la philosophie exposée par la plateforme et l’orientation « utilisation et consommation simple » par le plus grand nombre, et non « utilisation par des spécialistes dans une équipe centralisée ».

d. Une gouvernance fédérée

Tout comme le principe précédent, ce dernier principe du « Data Mesh » permet de contrebalancer dans une certaine mesure le premier principe d’orientation par Domaine afin assurer un minimum de coordination et établir des standards communs. Ces standards vont permettre entre autres :

• D’homogénéiser les moyens techniques d’accès aux données ;
• D’avoir des mécanismes et politiques de sécurité homogènes et cohérents, notamment en termes de gestion des accès, chiffrage, conformité règlementaire, etc. ;
• De garantir une certaine interopérabilité et maximiser la réutilisation des produits data.

Pour ce faire, l’organisation va mettre en place un modèle de gouvernance dit fédéré, avec une équipe regroupant des acteurs des différents domaines, de la plateforme Data, et autres SME (Subject Matter Expert) pour définir les règles en commun a minima à appliquer au sein de chacun des Domaines. La gouvernance va également mettre en place un système d’engagement et de responsabilités de manière à mettre en vigueur les politiques fédérales, mais aussi dans le même temps permettre la prise maximale d’autonomie par chacun des Domaines. Il s’agit donc, en somme, d’un système de gouvernance de données classique en mode fédéré, comme on peut le voir en vigueur dans beaucoup d’entreprises étendues

Data Mesh : quel regard porter sur cette approche ?

Ce fut un exposé assez long, et nous espérons de pas vous avoir perdu en cours de route ! Il nous semblait toutefois indispensable de bien reposer les principes fondamentaux du « Data Mesh » avant de pouvoir entamer une réflexion et un débat dessus. Alors, en résumé, est-ce une véritable révolution ou juste du « réchauffé » ? Tout d’abord, il convient de rappeler que l’idée de vouloir avoir une approche décentralisée sur les données et l’information n’a absolument rien de nouveau.

Dans les années 90, on parlait en effet déjà de « distributed information access ». Le terme fut rebrandé dans les années 2000 en « federated data », et ainsi de suite au fil des décennies. Ainsi, le « Data Mesh » est en réalité un concept vieux comme le monde, remis au goût du jour pour les besoins et le contexte des années 2020. Pour autant, est-ce que le « Data Mesh » est juste un concept marketing ou bien change-t-il la donne de manière fondamentale ?

De notre point de vue, il apporte un changement intéressant et fondamental dans la manière de voir la donnée avec le 2nd principe (Data as a Product) : celui-ci renforce en effet la nécessité absolue de devoir gérer la donnée pour qu’elle soit avant tout consommable et au service des consommateurs, avec en corollaire de devoir se conformer à certaines politiques ou standards pour qu’elle soit utilisable et de valeur.

Le 1er principe est également assez fondateur, et nous pouvons observer qu’il est aujourd’hui partiellement mis en œuvre dans de nombreuses entreprises avec la gouvernance de données et la mise en place d’un ownership / stewardship sur les données par domaine de données. Nous utilisons délibérément le mot « partiellement » car aujourd’hui, la gouvernance des données ne s’applique pas nécessairement sur les données analytiques mais justement plutôt sur les données opérationnelles. Or, sur ce point, les créateurs du concept « Data Mesh » ont peu à dire, car s’il existe effectivement un challenge sur l’organisation, la gestion et l’architecture des données analytiques, il n’en reste pas moins une difficulté fondamentale sur les données opérationnelles, car soumises à un cycle de vie potentiellement extrêmement complexe, sur une multitude de processus métier et systèmes, et à cheval sur plusieurs unités organisationnelles pour certaines données. La question reste donc entièrement ouverte à ce jour.

Faut-il unifier le découpage des domaines pour inclure à la fois les données opérationnelles et analytiques, ou bien opérer une séparation de représentations ? Le bon sens voudrait que ce soit la 1ère option qui soit adoptée. Dans ce cas, il faudra compléter et/ou remanier le modèle de rôles et opérationnel afin d’englober les deux dimensions données opérationnelles / données analytiques.Par ailleurs, si nous arrivons à résoudre cette dernière équation — ce qui est a priori réalisable — il restera encore de nombreux challenges à résoudre, notamment :

• Le challenge organisationnel : le « Data Mesh » fait la promotion d’unités de travail resserrées, avec différents rôles et responsabilités venant de différents horizons, et travaillant ensemble de manière intégrée dans un domaine. La réalité des entreprises est cependant différente, car la structure organisationnelle suit en général un schéma par grande ligne d’activité, ligne de produit, ou encore ligne de processus ;
• Le challenge des données communes : même si le « Data Mesh » ne fait pas la promotion des points uniques de vérité (SSOT : Single Source of Truth), ce point sujet ne peut être complètement éludé si nous envisageons de manière unifiée l’ensemble des données de l’entreprise. Certaines données sont fondamentalement des données communes, avec un besoin de représentation commune a minima (cf. données maîtres et de référence). Ce sujet devra donc être adressé d’une manière ou d’une autre ;
• Le challenge de la gouvernance de données : l’orientation produit, l’absence de centralisation technique et le besoin d’interopérabilité renforce le besoin d’avoir une gouvernance fédérale, comme exprimé par le 4ème principe. Cette gouvernance se doit d’être légitime, forte, et engageante pour l’ensemble des acteurs travaillant dans les Domaines. Or, nous le savons tous déjà, l’instauration d’une gouvernance des données à l’échelle reste un véritable challenge pour de nombreuses entreprises.

En conclusion, nous pouvons affirmer que le « Data Mesh » est intéressant et à creuser au vu des points énoncés ci-dessus. Il ne constitue cependant pas une formule miracle qui résoudra tous les maux liés aux données dans l’entreprise. Les fondamentaux du Data Management restent à mettre en place, et à faire évoluer en fonction du contexte, tout simplement. Et vous, quelle est votre opinion dessus ?