linkedin twitter
fermer le menuMenu
linkedin twitter
image illustrant l'architecture des données dans le data mesh
Blog Architecture d'entreprise

Data Mesh, définition d’une data révolution

Frédéric Orain

Publié le

L’élément fondateur du Data Mesh : le domain-driven design ou la conception orientée domaine

Pour comprendre ce qu’est le Data Mesh, il est d’abord primordial de se pencher sur le concept du domain-driven design (ou conception orientée domaine). En effet, ce concept qu’Éric EVAN détaille dans son ouvrage en 2003[1], est un élément fondateur sur lequel repose le Data Mesh.

Le domain-driven design est une méthode de conception logicielle qui suit sur le mantra suivant : la compréhension du métier par l’ensemble des équipes. Ainsi, l’objectif du domain-driven design est double :

  1. Vulgariser ce que les métiers réalisent pour assurer une compréhension mutuelle. Cela permet une compréhension aussi bien par tous les métiers mais aussi par les équipes techniques.
  2. Développer des solutions logicielles qui correspondent aux processus métiers.

Concrètement, cela implique que le code développé doit refléter ce que le métier réalise pour répondre aux enjeux business.

 

Les étapes de la conception orientée domaine

La première étape de la conception orientée domaine consiste à étudier et à détailler, à un niveau le plus fin possible, les processus métiers d’un domaine. C’est à cette étape qu’interviennent les modélisations ou encore les diagrammes de flux. Ils permettent à la fois de documenter les réalisations des métiers mais aussi de créer des schémas compréhensibles par tous. Également, cette étape de base pour rédiger les spécifications fonctionnelles (ou « user stories ») à développer.

La deuxième étape, naturellement, est le développement de la solution logicielle. La conception pilotée par le domaine garantit une meilleure assimilation de la solution finale. Aussi, elle garantit une meilleure efficacité en termes de réponse aux enjeux business pour le métier. Pour cette deuxième étape, on rentre dans une partie classique de gestion de projet informatique, en cycle en V ou en Agile selon les préférences et les compétences.

 

Qu’est-ce qu’un domaine ?

Pour certaines entreprises, les domaines correspondent aux différents départements de la société : marketing, logistique, ressources humaines…

Pour d’autres, dont les activités sont plus complexes, les domaines correspondent à des activités déterminées et précises comme le processus d’achat sur le site marchand ou la gestion du recrutement.

Ce découpage est propre à l’organisation. Quoiqu’il en soit, il doit représenter la réalité business pour adapter et concevoir au mieux la solution logicielle.

 

A présent, qu’est-ce que le Data Mesh ?

IBM définit le Data Mesh comme une architecture de données décentralisée qui organise les données par domaine. Ainsi, le Data Mesh est l’application du domain-driven design appliquée aux données et à l’utilisation des données.

 

Très bien, mais concrètement, qu’est-ce que cela change ?

Tout. Depuis l’architecture, aux rôles et responsabilités en passant par la culture d’entreprise, le Data Mesh révolutionne la manière de travailler des organisations.

Comme l’explique Zhamak Dehghani [2]qui à l’origine de ce concept, grâce au Data Mesh, nous passons d’un modèle architectural centralisé et monolithique à un modèle architectural décentralisé et fragmenté par domaines de données.

 

Le modèle monolithique et centralisé

Ce premier schéma illustre un modèle nominal que bon d’entreprises utilisent aujourd’hui :

Organisation Big Data

 

 

Des producteurs créent de la donnée. Ces données diverses et variées sont stockées dans un même environnement Big Data (Data Hub, Data WareHouse, Data Lake…). Il revient à une équipe Data (généralement la DSI) de transformer cette donnée afin de répondre aux besoins des équipes consommatrices de la donnée.

 

Les écueils de ce système sont nombreux

Dans ce modèle, les organisations font face à de nombreuses problématiques de taille concernant la gestion de la donnée.

Tout d’abord la gestion et la qualité de la donnée. Dans ce process, aucun acteur n’est réellement responsable du suivi de la qualité de la donnée. C’est pourquoi beaucoup de traitements spécifiques, le plus souvent manuels, sont réalisés. Ils s’assurent de la bonne qualité et du bon format de la donnée au sein des organisations. Chronophage et sans réelle valeur ajoutée, cette tâche reste néanmoins nécessaire pour ne pas exploiter de la mauvaise donnée. Par ailleurs, d’après une étude Gartner de 2020[3], la mauvaise qualité de la donnée représente un coût de 11 millions d’euros par an aux entreprises.

Également, la problématique du volume de données généré par l’effervescence du big data est omniprésent. Du fait d’équipes de production et de consommation de la donnée qui travaillent en silo, les producteurs créent et stockent un volume de données conséquent. Parmi ces données, une majorité ne répond pas ou pas complètement aux besoins et aux usages des consommateurs. L’équipe Data ne fait que le « passe-plat » dans cette opération sans réellement comprendre les enjeux des consommateurs de la donnée. Cela représente donc un coût de stockage et de maintenance important pour les organisations.

Enfin, la multiplication des projets data indépendants est aussi un problème auquel les organisations font face. Pour consommer des données qui répondent à leurs enjeux métiers, les consommateurs de donnée deviennent commanditaires de nombreux projets data. Ces projets permettent de transformer, nettoyer ou enrichir la donnée stockée. Mais cela représente un risque important de voir des projets similaires – voire identiques – se développer entre plusieurs équipes.

Également, le développement des ETL et autres traitements informatiques représente un coût important tant sur la partie développement (AMOA et développement) que sur la maintenance. Enfin, chacun de ces projets ayant son propre cycle de vie, cela impacte la bonne gestion des projets pour l’équipe Data avec des problématiques de ressources, de staffing ainsi que de compétences.

 

Le modèle du Data Mesh

Le second schéma explique le fonctionnement du Data Mesh :

Découpage Data Mesh

 

Dans ce modèle, la partie Big Data se décompose en trois parties distinctes. Au lieu de ne représenter qu’une activité de stockage des données, ce découpage fonctionnel repense la manière dont mettre à disposition la donnée pour les consommateurs. Ces parties amènent à réfléchir sur les patterns d’alimentation et de mise à disposition des données (architecture évènementielle, intégration des données en streaming, API, batch…) :

  • La partie ingestion de la donnée définit la manière dont la donnée récupérée ou créée en amont du process va être envoyée dans le flux de traitement
  • La partie traitement définit les actions à faire pour nettoyer, uniformiser, enrichir la donnée afin de respecter les directives décidées par la gouvernance de la donnée
  • Et enfin la partie mise à disposition répond à deux objectifs différents : l’usage fonctionnel/opérationnel de la donnée par les métiers et l’usage analytique de la donnée par les data analystes.

 

Ce découpage implique que les producteurs de la donnée sont en lien constant avec les consommateurs de la donnée. Cela aide à comprendre et répondre au mieux à leurs besoins.

In fine, ce modèle garantit une continuité dans la gestion de la donnée tout au long de son traitement. Il faut bien entendu que l’organisation, avec des process, des rôles et des responsabilités correctement définis, supporte une telle implémentation architecturale. Comme souvent, la dimension technique n’est qu’un moyen et non une fin en soi.

 

Ce principe génère beaucoup de modifications

Ce mode de conception de création et de mise à disposition de la donnée génère donc beaucoup de modifications. Et cela, tant sur la partie technique, que sur la partie organisationnelle. Le Data Mesh ne résout pas les problématiques de management ou de gouvernance de la donnée mais aide à y répondre. En remettant la donnée au centre des réflexions, le Data Mesh réorganise l’architecture, les besoins métiers et les équipes.

Un article dédié détaille ces différents sujets pour mieux les comprendre. Il permet d’aider les organisations à se préparer au mieux à l’implémentation du Data Mesh au sein de leur organisation.

 

Sources :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Voir plus
scroll to top