AUTEURS

Marco Pesarini
Partner @Bip xTech

Giuseppe D’Agostino
Senior Cloud & Data
Architect @Bip xTech

Luca Natali
Senior Cloud & Data
Architect @Bip xTech

Martino Ongaro
Cloud & Data Engineer
@Bip xTech

Le lac de données a toujours été l’un des piliers à la base des organisations axées sur les données, une philosophie commerciale vers laquelle toutes les entreprises modernes se sont efforcées de tendre au cours de la dernière décennie. Par essence, un lac de données est une grande archive informatique où toutes les données de l’entreprise peuvent être transférées, telles quelles, sans transformation, afin de rendre les données accessibles à toutes les fonctions ; en d’autres termes, une démocratisation de l’accès aux données.

Dans cette conception, les données se voient attribuer une valeur intrinsèque, presque naturelle.  En s’appuyant sur les nouvelles technologies, allant de l’ingénierie des données à la science des données, n’importe qui peut accéder aux données et en tirer des preuves, un sens, sans avoir besoin d’avoir une trop grande expérience du contexte d’où proviennent les données.

En travaillant au fil des ans sur de nombreux projets connexes, nous avons toutefois constaté que ce modèle souffre de certaines complications sous-jacentes. Cette volonté d’extraire les données brutes de leur domaine de naissance et de les traiter dans des plates-formes centralisées a créé deux problèmes familiers à toute personne ayant pratiqué dans ce domaine : la difficulté inhérente à la recherche et à l’interprétation des données pour ceux qui ignorent leur origine, et la mauvaise qualité chronique des données découlant du fait que celui qui extrait les données de leur domaine de naissance n’est pas ensuite rendu responsable de leur utilisation.

Pour faire face à ces problèmes, les entreprises se dotent de plus en plus de structures complexes de gouvernance des données, qui définissent les responsabilités, les processus et les rôles pour assurer la clarté des données et préserver leur qualité. Cependant, la solution à ces problèmes ne peut être uniquement organisationnelle. Les entreprises ont également besoin d’une aide technique pour simplifier la substance du modèle.

A cet égard, l’intuition de Zhamak Dehghani, professée dans son article “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh[1] est très intéressante. Elle y propose une nouvelle façon de gérer les données de l’entreprise en prévoyant l’analyse des données dans le domaine d’origine lui-même, le domaine où les données sont nées. Selon cette approche, ce sont les experts du domaine d’origine eux-mêmes qui sont tenus responsables de l’interprétation et de la qualité desdites données. La responsabilité des données clients relève du domaine CRM, celle des données budgétaires du système de gestion, celle des données de vente du domaine e-commerce, et ainsi de suite. Il est facile de comprendre comment, dans cette conception, les problèmes liés à l’interprétation et à la qualité des données diminuent considérablement, étant donné l’expérience qui abonde dans le domaine d’origine des données.

L’aspect principal de l’intuition concernant le Data Mesh réside toutefois dans la solution proposée pour éviter de retomber dans l’ancien monde des silos d’information, dans lequel les données étaient masquées et perdues dans les différents domaines d’origine. Dans les domaines de maillage de données, on confie la responsabilité de créer des produits de données qui sont des outils logiciels de visualisation et d’interprétation des données à publier dans toute l’entreprise. Ces produits sont mis à disposition sur le marché interne de l’information de l’entreprise et peuvent être rémunérés, c’est-à-dire dotés d’un budget pour leur croissance, en fonction de leur utilisation effective ou de leur souscription par d’autres utilisateurs.

Un marché libre est créé – et c’est là le défi des outils soutenant le maillage des données – dans lequel tous les utilisateurs peuvent trouver et consommer tous les produits de données d’entreprise, et de la concurrence naturelle pour le budget entre les domaines découle une impulsion bénéfique pour divulguer et partager les données.

Les données sont donc déclarées sous la responsabilité du domaine, mais dans un marché où les domaines individuels sont motivés pour exposer ces données et les rendre compréhensibles et de qualité. L’expérience du domaine est ainsi à la base de la valorisation des données.

Comment est composé un maillage de données

Le maillage de données fonde ses bases théoriques sur le modèle architectural de la conception pilotée par le domaine (DDD), selon lequel le développement de logiciels doit être étroitement lié aux domaines d’activité d’une organisation. Dans le DDD, chaque domaine organisationnel peut être représenté par un modèle de domaine, c’est-à-dire une combinaison de données, de comportements caractéristiques et de logique d’entreprise qui guide le développement du logiciel du domaine. L’objectif principal du DDD est de créer des logiciels pragmatiques, cohérents et évolutifs, en décomposant l’architecture en services au sein des domaines individuels et en se concentrant sur leur réutilisation dans la composition des différents produits logiciels soutenant l’entreprise. La première mise en œuvre de la DDD dans les logiciels d’entreprise a été la révision des applications monolithiques vers des architectures basées sur les micro-services : chaque micro-service est circonscrit dans un domaine et est chargé de satisfaire les exigences d’une fonctionnalité spécifique en fournissant une fonction d’application à tous les produits qui la demandent.

Le maillage de données applique la DDD aux architectures du domaine des données. Les produits de données, comme ils les nomment, permettent d’accéder aux données du domaine par le biais de fonctions élémentaires qui exposent des interfaces précises et mettent à disposition des données brutes, des données prétraitées ou traitées. Tout comme les micro-services sont des composants logiciels qui exposent des fonctionnalités élémentaires d’application, les produits de données sont des composants logiciels qui exposent des fonctionnalités élémentaires de données et d’analyse dans le domaine. Les produits de données ont pour objectif de diviser les fonctions analytiques du domaine en produits élémentaires et réutilisables, comme les micro-services subdivisent les fonctions d’application.

Comme pour les micro-services, également dans le maillage de données, le nouveau modèle désagrégé nécessite une série de règles et d’outils pour maintenir une bonne gouvernance de l’ensemble.

Tout d’abord, les produits de données doivent respecter certaines caractéristiques, qui sont fonctionnelles pour créer le marché libre dont nous parlions. Indépendamment de la manière dont l’interface spécifique d’accès aux données est créée – il est possible de donner accès par le biais d’une API, d’une vue sur une base de données ou d’un système de virtualisation – ou du type de données qui est mis à disposition, les produits de données doivent respecter les règles identifiées dans l’acronyme DATSIS selon lesquelles un produit de données doit être :

  • Découvrable – les consommateurs doivent être rendus autonomes dans la recherche et l’identification des produits de données créés par les différents domaines.
  • Adressable – les produits de données doivent être identifiés par un nom unique suivant une nomenclature commune.
  • Digne de confiance – les produits de données sont construits par les domaines qui détiennent les données et ils doivent mettre à disposition des données de qualité.
  • Autodescriptible – les consommateurs doivent pouvoir utiliser les données sans avoir à demander aux experts du domaine ce qu’elles signifient.
  • Intégré – doit être créé selon des normes partagées afin d’être facilement réutilisé pour créer d’autres produits de données.
  • Sécurisé – les produits de données doivent être sécurisés dès la conception et l’accès aux données doit être réglementé de manière centralisée par des politiques d’accès et des normes de sécurité.

Ce n’est qu’en respectant ces règles qu’il est possible de créer des produits de données qui permettent une conception efficace et fiable du maillage.

En ce qui concerne les outils, il existe deux facteurs essentiels à la création d’un maillage de données fonctionnel : l’infrastructure de données en tant que plateforme et la gouvernance de l’écosystème.

En imposant aux domaines d’application individuels de développer leurs produits de données, l’organisation risque de voir augmenter le taux d’hétérogénéité des technologies utilisées, rendant ainsi la stratégie de sourcing très complexe. Lors de la mise en œuvre d’un maillage de données, il est donc important qu’une organisation se dote d’une plate-forme d’infrastructure commune – l’infrastructure de données en tant que plate-forme – qui fournit à tous les domaines les éléments de base nécessaires à la création et à l’utilisation de produits de données : stockage, pipeline, base de données, fonctions de calcul, pour n’en citer que quelques-uns. Tout domaine qui souhaite mettre en place ses propres produits de données devra utiliser ces briques en accédant à l’infrastructure de données en tant que plateforme en mode libre-service. Cela permet de standardiser le développement des produits de données et d’introduire un langage commun entre les différents domaines. Les plateformes cloud PaaS constituent une option intéressante pour construire cette infrastructure commune sur laquelle bâtir des produits de données ; une option qui pourrait offrir une adoption à coût contrôlé et une rapidité de mise en œuvre.

La création de produits de données en mode distribué risque également d’augmenter le taux de duplication et la complexité de l’accès aux données, en perdant les objectifs de qualité et de responsabilité relatifs au paradigme du maillage de données. Pour cela, il est très important que l’organisation se dote d’outils de gouvernance de l’écosystème qui aident à fournir une visibilité et une compréhensibilité aux produits de données, des outils où chaque produit de données peut être enregistré et rendu par conséquent consultable et réutilisable selon des politiques d’authentification et d’autorisation spécifiques.

Perspective technique

Maintenant que les concepts de produit de données, d’infrastructure de données en tant que plateforme et de gouvernance de l’écosystème ont été présentés, entrons dans une perspective plus technique pour donner du concret à cette introduction.

Tout d’abord, les produits de données ne sont rien d’autre que des ensembles de composants technologiques, souvent déjà connus des entreprises pour charger, stocker, traiter et analyser des données. Par exemple, prenons un produit de données qui est un outil permettant de produire un rapport sur les données d’un domaine et examinons les briques qui peuvent composer le produit de données.

Comme mentionné, les éléments constitutifs du produit de données proviennent de l’infrastructure de données en tant que plateforme. Nous y trouvons des technologies établies, notamment le stockage d’objets et les files d’attente d’événements, une couche de traitement par lots et en continu, ainsi que des outils de consommation de données pour le reporting, la BI, le ML et l’IA. Ce sont des outils déjà largement connus et adoptés.

Si l’on prend l’exemple du produit de données qui produit un rapport, les éléments constitutifs pourraient être un stockage qui contient les fichiers à partir desquels extraire les données, un moteur Spark pour l’extraction et le traitement, une base de données où prendre en charge les données traitées, une interface pour l’analyse et une vue pour le rapport et une API pour fournir les résultats.

Pour la réalisation du produit de données, l’infrastructure de données en tant que plateforme a également pour tâche de fournir les outils permettant l’orchestration des composants et la collaboration entre les utilisateurs. On y trouve des technologies d’orchestration (telles que Airflow, Dagster, DataFactory), qui permettent de coordonner l’exécution des traitements, et les outils de modélisation de données les plus récents, pour faciliter la collaboration en phase de développement entre les ingénieurs et les analystes (par exemple, Dremio, et le Data Build Tool).

Dans le cas de notre produit de données, ces outils permettent l’exécution ordonnée des commandes et fonctions qui génèrent le rapport et une collaboration plus efficace entre l’ingénieur de données qui utilise Spark pour gérer les données sur le stockage, le modélisateur qui structure le modèle de données sur la base de données, l’analyste qui l’utilise pour l’exploration et le développeur qui distribue les résultats sous forme d’API.

À ce stade, le produit de données est prêt à être consommé même en dehors du domaine, et c’est là qu’interviennent les outils de gouvernance de l’écosystème adaptés à la gestion du catalogue et de la distribution des produits de données. Parmi les principaux outils d’organisation inter-domaines, nous trouvons les technologies fédérées, les technologies de catalogage des produits de données et les technologies de découverte des données (comme Amundsen, Metacat, Atlas), qui les rendent visibles et utilisables par les utilisateurs finaux. Avec l’inclusion de ces outils, les utilisateurs d’autres domaines peuvent rechercher et accéder au produit de données, en utilisant les capacités de recherche sémantique ou en faisant défiler le catalogue central de produits de données de l’entreprise.

Pour compléter la plateforme de gouvernance de l’écosystème, il existe des fonctions supervisant la conformité, la qualité des données, le contrôle d’accès et la surveillance. Le nouveau Data Stewart dans l’hypothèse d’un écosystème basé sur AWS exploitera les alertes automatiques d’AWS Comprehend pour identifier les violations de la vie privée, Glue DataBrew pour contrôler la qualité de la sortie du nouveau produit de données, Lake Formation pour contrôler ses permissions internes et externes au domaine et CloudTrail pour surveiller l’accès et l’utilisation.

Perspective organisationnelle

Un dernier aspect important à considérer dans l’évaluation du paradigme du maillage de données est l’adaptation organisationnelle que son introduction peut nécessiter. De ce point de vue, la transition est plus facile pour ceux qui ont déjà adopté des modèles organisationnels agiles avec des ensembles de domaine de compétence et des équipes de projet.

Le principe de la fourniture de données en tant que “produit” voit la naissance de nouvelles figures telles que les Data Product Owners – similaires aux Product Owners historiques – au sein des différents domaines ; des figures responsables du cycle de vie des produits de données (planification, surveillance, etc.) et de l’exécution de la stratégie de données du domaine.

Les profils professionnels déjà présents dans les organisations actuelles seront répartis dans les domaines d’activité : la décentralisation de la propriété des données et de leur traitement par le domaine de compétence signifie que des figures telles que les Data Engineers et les Data Architects sont réparties dans les différents domaines. Les Data Engineers du domaine “client” sont à identifier, pour donner un exemple, comme par le passé les développeurs de microservices verticaux sont nés au sein du même domaine.

Dans une telle organisation répartie sur plusieurs domaines, la fonction responsable des politiques de gouvernance (interopérabilité, sécurité, conformité, etc.) reste toutefois centralisée. C’est une entité organisationnelle centrale qui assure l’application des politiques au niveau de chaque domaine. Cette entité est composée de personnalités techniques au niveau de l’entreprise (par exemple, Enterprise Data Architects, Enterprise IT Architects, etc.), de représentants des domaines et d’experts en sécurité et conformité.

La seule autre fonction qui reste centralisée dans le modèle est celle de la supervision de l’infrastructure de données en tant que plateforme qui gère l’infrastructure pour tous les domaines avec des compétences d’ingénierie et d’exploitation.

Le maillage de données est donc une composition de nombreux aspects, dans une possible transformation du monde des données vers un modèle plus agile et fédéré.

Bip xTech, notre centre d’excellence sur les technologies exponentielles, emploie des experts dans toutes les disciplines les plus avancées autour de la gestion des données ; de l’ingénierie des données au cloud, de la gouvernance des données aux architectures de microservices ; nous pouvons fournir tous les ingrédients pour la transition vers le maillage des données.


Si vous souhaitez en savoir plus sur notre offre ou avoir un entretien avec l’un de nos experts, veuillez envoyer un courriel à [email protected] avec pour objet “Data Mesh”, et vous serez contacté rapidement.


[1] https://martinfowler.com/articles/data-monolith-to-mesh.html

Read more insights

red lines

Get in touch

Milan, Italy | BIP xTech Head Office

Torre Liberty Building
Galleria de Cristoforis 1, Milan, 20121

[email protected]

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.