Introduction : qu’est-ce que le data mesh?
Avec la prise de conscience de l’importance stratégique de la donnée pour leur activité, les entreprises ont tenté de s’organiser afin de libérer tout le potentiel de leur patrimoine data. La question du stockage de la donnée a ainsi fait émerger progressivement diverses solutions pour tenter d’y répondre : datamarts, data warehouses puis data lakes pour permettre d’absorber des volumes de données de plus en plus importants et mettre à disposition ces actifs data au plus grand nombre et de façon centralisée, afin de briser les silots de l’entreprise.
Mais les entreprises peinent encore à répondre aux besoins des métiers. En effet, la vitesse de production, de transformation et la complexité grandissante des données (natures, provenance, etc.) mettent à l’épreuve les capacités de scalabilité d’une telle organisation centralisée. Le puit central de données tend à devenir un goulot d’étranglement où les équipes de data management ne peuvent répondre efficacement à la demande des métiers et où ne s’y retrouvent que quelques équipes expertes.
Ce constat est d’autant plus vrai dans un contexte où les entreprises sont issues de fusions, de rachats, ou sont organisées en filiales. La construction d’une vision et d’une organisation commune entre toutes les entités peut s’avérer complexe et laborieuse.
C’est fort de ce constat que Zhamak Dehghani a développé le concept de “Data Mesh”, proposant un changement de paradigme dans la gestion des données analytiques, avec une approche décentralisée.
Le Data Mesh n’est en effet pas une solution technologique mais plutôt un objectif, une étoile du Nord comme l’appelle Mick Lévy, qu’il faut suivre pour relever les défis lancés aux entreprises dans le contexte actuel :
- Répondre avec élégance à la complexité, la volatilité, et l’incertitude du business
- Maintenir l’agilité face à la croissance
- Accélérer la production de valeur, proportionnellement à l’investissement
Comment le Data Catalog facilite la mise en place d’une approche Data Mesh ?
Un outil Data Catalog a pour objectif de cartographier l’ensemble des données de l’entreprise et de les mettre à disposition des équipes techniques ou métier de façon à faciliter leur exploitation, la collaboration autour de leurs usages et ainsi à maximiser et accélérer la création de valeur.
Dans une organisation comme le Data Mesh où les données sont stockées à différents endroits et gérées par différentes équipes, le défi du Data Catalog est d’assurer un point d’accès central aux ressources data pour toute l’entreprise.
Mais pour cela, le Data Catalog doit soutenir les quatres principes fondamentaux du Data Mesh qui sont :
- « Domain-driven ownership of data »,
- « Data as a product »,
- « Self-serve data platform »
- « Federated computational governance »
Domain ownership
Le premier principe du Data Mesh est de décentraliser les responsabilités autour de la donnée. L’entreprise doit d’abord définir des domaines métier, de façon plus ou moins granulaire, en fonction de son contexte et de ses cas d’usages (ex : Production, Distribution, Logistique, etc.).
Chaque domaine devient alors responsable des données qu’il produit. Les domaines gagnent en autonomie pour gérer et valoriser plus facilement des volumes grandissant de données. La qualité de la donnée est notamment améliorée, profitant d’une expertise métier au plus proche de la source.
Cette approche remet notamment en question la pertinence d’un Master Data Management centralisé proposant une modélisation unique de la donnée, exhaustive mais par conséquent complexe à comprendre par les consommateurs des données et difficile à maintenir dans le temps.
Grâce au Data Catalog, les équipes métier doivent pouvoir s’appuyer sur le Data Catalog pour faire l’inventaire de leurs données et décrire leur périmètre métier grâce à une modélisation orientée par les usages propres au domaine.
Cette modélisation doit être accessible par l’intermédiaire d’un glossaire métier associé au Data Catalog. Ce glossaire métier tout en restant une source unique de vérité doit permettre de refléter les différentes facettes de la donnée en fonction des usages et des besoins de chaque domaine.
En effet, si par exemple le concept de “produit” est commun à toute l’entreprise, ses attributs n’auront pas le même intérêt s’il on s’intéresse à la logistique, au design, ou à la vente.
Un glossaire métier basé sur un graphe sera donc plus approprié de par la souplesse et les capacitiés de modélisation et d’exploration qu’il peut offrir comparativement à une approche hiérarchique prédéfinie. Tout en assurant la cohérence globale de cette couche sémantique à l’échelle de l’entreprise, un glossaire métier basé sur un graphe permet aux responsables des données de mieux prendre en compte les spécificités de leurs domaines respectifs.
Le Data Catalog doit donc permettre aux différents domaines de collaborer à la définition et la maintenance du métamodèle et de la documentation des assets, afin d’en assurer la qualité.
Pour cela, le Data Catalog doit donc également offrir un système de gestion de permissions approprié, pour permettre de découper les responsabilités de façon non ambigüe et permettre à chaque responsable de domaine de prendre en main la documentation de son périmètre.
Data as a product
Le second principe du Data Mesh consiste à penser la donnée non plus comme un asset mais comme un produit avec son expérience utilisateur et son cycle de vie. L’objectif est notamment d’éviter de recréer des silos dans l’entreprise du fait de la décentralisation des responsabilités.
Chaque domaine est ainsi responsable de mettre un ou plusieurs data products à disposition des autres domaines. Mais au-delà de cet objectif de décloisonnement, penser la donnée comme un produit permet d’avoir une démarche centrée sur les attentes et les besoins des utilisateurs finaux : quels sont les personas consommateurs de données ? dans quel(s) format les utilisateurs utilisent-ils la donnée ? avec quels outils ? comment mesurer la satisfaction des utilisateurs ?
En effet, avec une approche centralisée, les entreprises pennent à répondre aux besoins des utilisateurs métiers et à passer à l’échelle. Le Data Mesh va par conséquent participer à faciliter la diffusion de la culture data en réduisant la hauteur de la marche à franchir pour exploiter la donnée.
Selon Zhamak Dehghani, un data product devrait répondre à différents critères et le Data Catalog permet d’aider à y répondre en partie :
Découvrable : La première étape pour un Data analyst, un Data Scientist ou tout autre consommateur de données dans son parcours de recherche de données est de savoir quelles données existent et quels types d’insights il va pouvoir creuser. Le Data Catalog adresse cette problématique grâce à un moteur de recherche intelligent permettant de rechercher par mots clés, acceptant les erreurs de frappe ou de syntaxe, grâce à la génération de suggestions, ainsi que par capacités de filtrage avancées et intuitives. Le Data Catalog doit également proposer des parcours d’exploration personnalisés de son contenu afin de mieux promouvoir les différents data products. Enfin, l’expérience de recherche et de navigation dans le Data Catalog doit être simple et basée sur des standards du marché comme Google ou Amazon, afin de faciliter l’onboarding des utilisateurs non techniques.
Compréhensible : Les données doivent être facilement comprises et consommées. C’est également une des missions du Data Catalog d’apporter tout le contexte nécessaire à la compréhension de la donnée : description, concepts métiers associés, classification, relations avec les autres data products, etc. Les domaines métier peuvent s’appuyer sur le Data Catalog pour rendre les consommateurs autonomes autant que possible dans la compréhension de leurs data products. Un plus serait une intégration avec les outils data, des sandbox pour mieux appréhender le comportement de la donnée.
Digne de confiance : Les consommateurs doivent avoir confiance dans les données qu’ils utilisent. Là encore le Data Catalog va jouer un rôle important. Un Data Catalog n’est pas un outil de Data Quality mais les indicateurs de qualités doivent pouvoir être récupérés et mis à jour automatiquement dans le Data Catalog pour pouvoir les exposer aux utilisateurs (complétude, fréquence de mise à jour, etc.). Le Data Catalog devrait pouvoir également remonter lorsque c’est possible, des informations statistiques sur les données ou reconstituer le lignage de la donnée, grâce notamment à des systèmes automatisés pour en comprendre l’origine et les différentes transformations opérées.
Accessible nativement : Un data product devraient être délivré sous la forme attendue par les personas (data analysts, data scientists, etc.). Un même data product peut donc potentiellement être délivré dans plusieurs formats, en fonction des usages et des compétences des utilisateurs ciblés. Il devrait être aussi facile à interfacer avec les outils qu’ils utilisent. Sur ce point, le catalogue n’a par contre pas de rôle particulier à jouer.
Valorisable : Une des clés de succès d’un data product est aussi qu’il puisse être consommé de façon autonome, qu’il soit significatif en soi. Il doit être pensé afin de limiter le besoin de réaliser des jointures avec d’autres data products, afin de délivrer lui même une valeur mesurable à ses consommateurs.
Adressable : Une fois que le consommateur a trouvé le data product dont il a besoin dans le Data Catalog, il doit pouvoir y accéder facilement ou pouvoir y demander l’accès de façon simple et efficace. Pour cela, le Data Catalog doit pouvoir s’interfacer avec des systèmes de policy enforcement qui facilitent et accélérent l’accès à la donnée grâce à l’automatisation d’une partie du travail.
Sécurisé : Ce point est lié au précédent. Les utilisateurs doivent pouvoir accéder facilement aux données mais de façon sécurisée, en fonction des polices mises en place sur les droits d’accès. Là aussi, l’intégration du Data Catalog avec une solution de policy enforcement permet de faciliter cet aspect.
Interopérable : Afin de faciliter les échanges entre les domaines et éviter une nouvelle fois les silos, les data products doivent répondre à des normes définies au niveau de l’entreprise afin de pouvoir facilement consommer tout type de data product et pouvoir intégrer les data products entre eux. Le Data Catalog doit pouvoir également permettre de diffuser les métadonnées des data products pour interconnecter les domaines grâce à des APIs.
Self-serve data infrastructure
Dans une organisation de type Data Mesh, les domaines métier sont donc responsables de mettre à disposition les Data Products pour toute l’entreprise. Mais pour atteindre cet objectif, les domaines doivent disposer de services leurs facilitant cette mise en place et d’automatiser au maximum les tâches de gestion. Ces services doivent permettre de masquer la complexité de l’architecture sous-jacente dans l’objectif de rendre les domaines le plus autonomes possible vis-à-vis des équipes infrastructure.
Dans une organisation décentralisée, cette couche de service va également permettre de réduire les coûts, notamment liés à la charge des data engineers, ressources qui plus est difficiles à trouver.
Le Data Catalog fait partie de cette couche d’abstraction en permettant aux domaines métier de facilement inventorier les sources de données dont ils sont responsables. Pour cela, le Data Catalog doit proposer lui-même un catalogue de connecteurs supportant les diverses technologies utilisées (stockage, transformation, etc.) par les domaines et automatiser au maximum les tâches de curation.
Grâce à des APIs simples d’utilisation, le Data Catalog permet également aux domaines de synchroniser facilement leurs référentiels métiers ou techniques, connecter leurs outils de gestion de la qualité, etc.
Federated computational governance
Le Data Mesh propose une approche décentralisée de la gestion des données où les domaines acquièrent uen certaine souveraineté. Cependant, la mise en place d’une gouvernance fédérée permet d’assurer la cohérence globale des règles de gouverance, l’interopérabilité des data products et un monitoring à l’échelle du Data Mesh.
Le Data Office intervient donc plus en tant que facilitateur, diffusant les principes de gouvernances et les politiques qu’en tant que contrôleur. En effet, le CDO n’est plus responsable de la qualité ou de la sécurité mais responsable de définir ce qui constitue la qualité, la sécurité, etc. Les responsables de domaines prenant le relais de façon locale pour l’application de ces principes.
Ce changement de paradigme est possible notamment grâce à l’automatisation de l’application des politiques de gouvernance. L’application de ces politiques est ainsi accélérée par rapport à une approche centralisée car effectuée au plus proche de la source.
Le Data Catalog peut être utilisé ici aussi dans la diffusion des principes et des politiques de gouvernances qui peuvent être documentées ou répertoriées dans le Data Catalog et liées aux data products auxquels ils s’appliquent. Le Data Catalog va fournir également des métadonnées aux systèmes responsables d’automatiser l’application des règles et politiques.
Conclusion
Dans un environnement data de plus en plus complexe et changeant, le Data Mesh apporte une réponse socio-architecturale alternative aux approches centralisées qui peinent à passer à l’échelle et à répondre aux besoins des métiers de qualité et de réactivité.
Le Data Catalog joue un rôle central dans cette organisation, en fournissant un portail d’accès central pour la découverte et de partage des data products à toute l’entreprise, en permettant aux domaines métier de gérer simplement leurs data products mais aussi en diffusant les métadonnées permettant l’automatisation de politiques nécessaire à une gouvernance fédérée.
