Ce qui distingue l’approche Data Mesh d’une architecture de données
Ce qui est communément appelé un Data Mesh correspond à une approche décentralisée de la gestion de données et de leur valorisation. Bien que compatible avec les Data fabric, entrepôts de données et data lakes, il sous-tend une philosophie opposée.
Les entreprises ne doivent pas négliger les besoins et la stratégie en matière de données lorsqu’elles recherchent des outils. Si elles le font, elles risquent de faire des choix technologiques sous-optimaux et de sous-estimer la gouvernance, la sécurité et la confidentialité des données, avance Srujan Akula, PDG de The Modern Data Company.
« Les professionnels doivent accorder la priorité à la communication, impliquer les parties prenantes et s’assurer de bien comprendre les objectifs et les exigences de leur organisation avant de mettre en œuvre une solution d’architecture de données », déclare Srujan Akula. En outre, la formation du personnel et le développement des compétences sont des éléments cruciaux de l’adoption d’une technologie.
Depuis plus de quarante ans, les entreprises ont choisi d’adopter des technologies favorisant la centralisation des données… sans jamais y parvenir réellement. Les entrepôts, puis les lacs de données n’ont pas éliminé les silos qui empêcheraient la pleine exploitation des informations à la disposition d’une entreprise. Ces mêmes silos peuvent être des bases de données isolées, des datawarehouses, voire des data lakes destinés à certaines entités.
Un concept formulé récemment, l’approche Data Mesh, doit permettre de fédérer ces silos et leurs propriétaires dans un écosystème au service de l’entreprise.
« [Une approche] Data Mesh répond à la fois aux besoins d’échelle et de variété des données, ainsi qu’à la rapidité de l’obtention d’informations à partir de ces systèmes », déclare Ravi Mayuram, directeur technique de l’éditeur de la base de données NoSQL Couchbase.
Qu’est-ce qu’une approche Data Mesh ?
L’approche Data Mesh consiste en la mise en place d’une architecture décentralisée qui organise les données par domaine et qui est principalement axée sur les personnes et les processus. Zhamak Dehghani, PDG de Nextdata, a été à l’origine de ce concept alors qu’elle travaillait pour le cabinet de conseil en technologie Thoughtworks.
Ce concept repose sur quatre principes fondamentaux :
Propriété des données par domaine. Les équipes du domaine sont propriétaires de leurs données et en autorisent l’accès.
Des données considérées comme des produits. Les équipes de domaine sont responsables de la qualité des données.
Libre-service. Les données sont disponibles en libre-service.
Gouvernance des données. La gouvernance permet d’instaurer la confiance dans le maillage de données grâce à la transparence de la propriété et de l’utilisation et fournit un cadre pour la responsabilité des produits de données.
Des oppositions philosophiques
Cette approche se différencie de la méthodologie traditionnelle consistant à confier l’ensemble des tâches de gouvernance et de traitements de données à des équipes centralisées. Ces équipes centralisées tentent de résoudre tous les problèmes, distingue Lior Gavish, directeur technique de Monte-Carlo Data, éditeur d’une solution d’observabilité des données. Selon le CTO, un Data Mesh devrait aider les entreprises à faire évoluer les équipes chargées des données. « Comment pouvons-nous permettre à un grand nombre d’équipes différentes d’utiliser les données de manière efficace et indépendante les unes des autres ? », théorise-t-il.
Data Mesh contre Data Warehouse
Un entrepôt de données a tendance à être monolithique et à charger les données dans un environnement unique, fonctionnant comme un référentiel de données qui soutient l’analyse et la prise de décision. Un maillage de données permet de créer un environnement distribué dans lequel les données n’ont pas besoin d’être déplacées pour fournir une valeur commerciale. Un entrepôt de données et un Data Mesh ne s’excluent pas mutuellement, car un entrepôt de données peut faire partie d’une architecture adaptée à l’approche Data Mesh.
La philosophie qui sous-tend la naissance des data warehouses vise à créer une version unique de la vérité et de la centraliser sous le contrôle du service informatique. Dans une approche Data Mesh, l’entrepôt de données peut être la plateforme de données ; c’est là que les utilisateurs stockent et créent des produits de données.
« Le maillage de données se concentre davantage sur un état d’esprit organisationnel qui traite les données comme des produits de première classe appartenant à des domaines individuels », précise Dipankar Mazumdar, developer advocate chez Dremio, un éditeur d’un data lake open source.
Or la forte croissance des volumes de données a mis en lumière les limites de la centralisation que représentent les data warehouse.
« Les données monolithiques entraînent des processus de gestion du changement complexes [et] engendrent des délais de mise en œuvre prolongés pour les nouveaux techniciens », indique Jon Osborn, directeur technique de terrain chez Ascend.io, une entreprise spécialisée dans l’automatisation des pipelines de données. « Elles alimentent également un carnet de commandes interminable pour les ingénieurs, alors que certaines demandes devraient être traitées en libre-service ».
Data Mesh vs Data Lake
Comme un data warehouse, un lac de données centralise le stockage et le traitement des données. La grande différence tient dans le fait qu’un data lake puisse stocker à la fois des données structurées et non structurées, principalement sous forme de fichiers ou d’objet. Conceptuellement, ce n’est que la prolongation de l’idée derrière un data warehouse à l’ensemble des données de l’entreprise.
Dans le cadre d’une approche Data Mesh, un Data Lake peut donc, lui aussi, faire partie du maillage de données de l’entreprise.
« Le concept de Data Mesh repose sur une couche qui tisse des liens entre les sources de données opérationnelles et les lacs de données spécifiques à un domaine », renchérit Ravi Mayuram de Couchbase.
Fondamentalement, lorsqu’il évalue cette décentralisation de la gestion des données, un responsable des données doit comprendre si les architectures techniques en place sont un frein à son implémentation. De fait, la centralisation des données plus ou moins bien assumée a pu générer des silos de données, silos qui sont, de surcroît, difficiles à intégrer, indique Bob Audet, partenaire et responsable de la gestion des données chez Guidehouse, une société de conseil, de services numériques et de services managés.
« Les consommateurs et les curateurs de données ne peuvent pas trouver les bonnes données, ce qui peut entraîner du retard sur la concurrence et empêcher de suivre le rythme de l’évolution rapide des besoins des métiers », signale-t-il.
Data Mesh et Data Fabric
Pour résoudre cette problématique est né le concept de Data Fabric. Ce « tissu » de données correspond à une couche technique d’une architecture permettant d’intégrer des sources disparates et de fournir une vue centralisée et holistique des actifs de données dans une entreprise. En théorie, cela contraste avec l’approche Data Mesh qui met l’accent sur la décentralisation de la propriété et des traitements de données.
« [Avec l’approche Data Mesh], chaque domaine, ou unité commerciale, est propriétaire de ses propres données qui sont gérées et gouvernées localement », rappelle Dipankar Mazumdar. « Cela signifie que les données sont traitées comme un produit et que les équipes du domaine sont responsables de la qualité, de la gouvernance et du cycle de vie de leurs propres produits de données ».
Un Data Fabric repose sur l’idée que les données doivent être facilement accessibles et découvrables, et organisées de manière à faciliter leur combinaison et leur analyse. La structure de données est généralement mise en œuvre au moyen d’une combinaison de technologies.
« Le tissu de données […] est le premier volet technologique qui commence vraiment à désiloter les données applicatives, une avancée attendue depuis longtemps », estime Sylvie Veilleux, membre du conseil consultatif de l’organisation à but non lucratif Data Collaboration Alliance et ancienne directrice des systèmes d’information de Dropbox. « L’écosystème de données moderne est incroyablement complexe, et nécessite de connecter tous les types de pipelines, des bases de données aux lacs de données ».
Un tissu de données repose sur une architecture qui établit une connexion entre les données et leurs métadonnées présentes dans les silos organisationnels, selon Sylvie Veilleux. Dans une solution Data Fabric, des systèmes d’autorisation contrôlent l’accès aux données, tandis que suivant les préceptes originels du Data Mesh, ce sont les propriétaires fonctionnels qui contrôlent les données et leur accès. Cela signifie qu’elle n’a pas besoin d’autorisation d’une autorité de contrôle centralisée.
La mise en place d’un Data Fabric représente « étape cruciale pour mettre fin à la pratique ancestrale consistant à faire des copies à l’infini de données même sensibles », assure Sylvie Veilleux.
Conseils aux praticiens
Il n’existe pas de mise en œuvre parfaite du maillage des données. Selon M. Osborn, les organisations peuvent tirer profit de mises en œuvre simples ou partielles.
« Une stratégie Data Mesh efficace produira des données plus accessibles et permettra à un plus grand nombre de personnes de les exploiter. »
Jon OsbornDirecteur technique de terrain, Ascend.io
« Une stratégie Data Mesh efficace produira des données plus accessibles et permettra à un plus grand nombre de personnes de les exploiter », avance Jon Osborn. « Analystes, data scientists, business analysts, et potentiellement, n’importe quel métier pourront participer à cet effort. Il faut s’y préparer ».
Mais pour cela, le CTO de Monte-Carlo considère qu’il faut bien assimiler les hypothèses fondatrices d’un Data Mesh. Elles sont, selon lui, au nombre de trois :
Les experts des domaines technologiques et commerciaux sont disponibles pour définir et construire des domaines de données significatifs.
Le pipeline de données et les capacités et technologies de partage de données existent dans l’environnement. Un manque de maturité à ce niveau débouchera sur un « bricolage » décevant et chronophage.
Une stratégie de gouvernance fonctionnelle peut aider à définir et à communiquer les normes et autres attentes.
En clair, l’ensemble des parties prenantes ont voix au chapitre. En concordance avec la direction des systèmes d’information, la ou les directions des données doivent avoir établi les responsables et les solutions d’intégration de données (orchestration de pipelines Apache Spark, ETL/ELT, virtualisation de données, fédération de requêtes, etc.) accessibles. Cette même association doit déboucher sur la mise en pratique d’un concept, comme ce fut le cas lors du déploiement des premiers lacs de données.
