"Le Data Mesh et les data products."

Bonjour à tous, je suis Emmanuel Malherbe, j’ai la chance d’animer les Data coffee de la plateforme média The Bridge, le principe c’est un sujet et un expert et un café. Aujourd’hui le Data mesh, avec Violaine. Bonjour Violaine.

Bonjour, Violaine Berland, je suis directrice conseil chez Artefact, et j’accompagne des clients sur les sujets de transformation data.

Et donc de ton point de vue data mesh qu’est-ce qui est vraiment important ?

Pour moi le point essentiel du data mesh c’est ce qui en résulte, donc c’est ce qui est concrètement construit dans une organisation data mesh, et donc c’est surtout les Data product. Donc les data products c’est ce qui est construit par les différents domaines et donc en fait dans le Data mesh, chaque produit data est comme un nœud du maillage parce que mesh ça veut dire maillage.

Alors là je t’arrête tout de suite, qu’est-ce que c’est qu’un data product?

Le concept du data product, l’objectif c’est vraiment de traiter la donnée comme comme un produit et non pas par produit donc on va pas créer, enfin on va pas essayer de répondre à chaque use cas un par un avec un produit data sous-jacent, mais on va plutôt essayer de de comprendre les dénominateurs communs pour en créer des produits data et l’objectif c’est que du coup les différents domaines sur leur scope fonctionnel vont être en charge d’identifier quels sont les différents produits data à construire qui peuvent répondre à plein d’usages différents.

Et donc en termes de valeur business en quoi s’inscrire dans data mesh ça rentre dans les objectifs d’une entreprise?

Ce qui est intéressant c’est que l’intérêt du mesh, ça va être principalement de pouvoir croiser plusieurs data products entre eux. Donc en fait les domaines ils sont pas là pour construire les produits de leur domaine uniquement pour leur domaine. Ce qui est intéressant c’est de vraiment penser interopérabilité, et penser que son produit est disponible sur étagère à plein d’autres fonctions plein de business et donc là on va commencer à avoir une vraie valeur ajoutée, c’est quand toutes les guidelines qu’on donne dans le cadre du mesh donc être sur des mêmes plateformes, assurer que les différentes données soient interopérables, c’est là qu’on va permettre de débloquer des nouveaux usages qui étaient avant pas possible.
Par exemple, on pourrait citer l’envie de rapprocher par exemple la formule de matière première d’un produit aux ventes finales.

Très clair, donc ça sert vraiment à désiloter les différents domaines, d’avoir cette logique data products.

C’est ça, et aussi le fait de dire que les data products sont gérés par différents domaines, qui eux ont vraiment, sur leur scope fonctionnel, ils ont une autonomie de comment est-ce que je vais construire mes produits, enfin ils ont vraiment une autonomie sur leur scope de données, ça permet vraiment de refléter plus rapidement la réalité métier parce que ils vont être capables de challenger le produit existant parce que l’idée c’est que le data product n’est est pas figé dans le temps, il est vraiment maintenu par ce domaine, et donc par exemple s’ils se rendent compte que maintenant il y a de nouveaux canaux de distribution, il y a un nouveau retailer, donc on a besoin de nouvelles sources de données, ils vont mettre à jour ce data product et c’est vraiment des experts sur ce sujet donc le reste de l’entreprise est censé leur faire confiance sur le fait qu’ils auront bien reflété la réalité du business sur sur leur sujet.

00:03:33 – Et donc, qui est responsable, qui gère ces data products?

Comme dans des applications digitales il y a un nouveau rôle qui apparaît de plus en plus les Data product owner, donc pareil qu’un product owner, mais vraiment pour ces objets data, et leur objectif à eux c’est de s’assurer de construire cet ensemble de dataset en fait, qui seront ensuite mis à disposition d’autres, et qui soient facilement compréhensible sans qu’ils aient forcément besoin d’intervenir, donc pour que ce soit de plus en plus scalable, l’objectif c’est de donner en amont un maximum d’informations, il faut que les gens aient confiance dans ce cette asset de Data qui sont en train de mettre à dispo, et il faut également qu’il s’assure que l’accès soit sécurisé, donc il y a plein de problématiques d’Access management qui entrent en jeu, et leur objectif c’est vraiment de construire ces produits en s’assurant que tous ces éléments soient vérifiés pour que d’autres équipes puissent utiliser leurs données.

Justement quand l’autre équipe est dans un autre domaine, est-ce qu’il y a des difficultés et des impacts justement de cette interopérabilité ?

Evidemment on peut pas imaginer que un Data product soit construit une fois, figé dans le temps, et plus jamais bouger, même si le Data Product Owner doit avoir ce rôle de prendre un peu de hauteur sur les produits qui est en train de délivrer pour qu’ils adressent un plus grand nombre d’usages, par contre évidemment que vu que la réalité business bouge, enfin l’environnement bouge, on va avoir des des modifications trop importantes qui vont impacter du coup les différents utilisateurs, et c’est comme une application ça va être des logiques de versioning, de de la maintenance, pour que pour que tout le monde soit informé qu’il y a des modifications qui ont été apportées. Mais voilà il n’y a pas à zéro impact.

Est-ce que tu peux nous partager des exemples un peu plus concrets de Data product ?

Oui, alors l’étape, le concept dans le data mesh, c’est de se dire que toute table qui peut être potentiellement réutilisable soit correctement, enfin soit facile à trouver, faciles à explorer et à comprendre, par contre effectivement plusieurs niveaux potentiels au sein d’un même domaine de Data product; il y en a des très bruts, c’est à dire qu’ils vont vraiment copier presque les données du système source jusqu’à des dataset beaucoup plus enrichis avec la donnée transformée qui aurait été ajoutée, et après la construction de ces différents produits va vraiment suivre la transformation data de l’entreprise. C’est-à-dire qu’au début on va se concentrer sur déjà mettre les données dans la plateforme, donc ce qu’on concentrer sur les les couches un peu basses, un peu brutes. Voilà des dés des couches un peu plus basses avec des données plus brutes comme comme elles le sont sur les systèmes sources, jusqu’à des informations plus travaillées où on va calculer des métriques, des informations supplémentaires pour enrichir les tables qu’on donne à disposition à des utilisateurs de la donnée.

Et est-ce que tu as des exemples concrets, des livrables qui en ressortent derrière?

Du coup en termes de livrables, on a principalement d’un côté les tables concrètement dans la plateforme donc c’est un ensemble de dataset disponible dans la data platform, et en plus de ça on va souvent avoir les à côté qui permettent de bien découvrir, assurer la découvrabilité de la donnée, donc des catalogues, des informations où on regroupe toutes les meta data, donc les données qui décrivent la table, donc cette information doit être mise à disposition quelque part, on va centraliser des indicateurs de qualité pour permettre à un utilisateur qui veut utiliser une table de comprendre, est-ce que je peux avoir confiance dans cette table, et donc il y a un certain nombre de métriques qui vont être calculées sur les informations de la table, savoir si ça a été correctement ingéré, si l’ingestion s’est faite correctement, à l’heure, est-ce qu’il manque des informations, est-ce qu’il y a des informations qui semblent incohérentes, toutes ces infos on essaie de les donner à l’utilisateur final.

Et donc Violaine, est-ce que tu as un exemple à nous partager de Data product ?

Oui bien sûr, donc par exemple si on se met dans le domaine de la supply chain, chez un retailer français par exemple, on pourrait imaginer qu’il veut suivre du coup un paquet de yaourts, et donc on a des premières informations qui vont suivre les stocks des yaourts à différentes étapes du magasin, donc ça c’est une information assez brute qu’on va collecter. Ensuite par dessus on peut imaginer de calculer des métriques plus avancées par exemple de taux de rupture, donc là on va être sur un Data product déjà plus avancé, mais qui est intéressant à réaliser par plein de personnes, et on peut même imaginer plus tard avoir des des données de forecasting, donc de prédiction des ventes de ce yaourt, et donc tout ça c’est des donnée de supply chain, qui seront gérées par les Data Product Owner du domaine supply chain, et on a du coup différents types de produits plus à moins avancés selon la maturité de l’entreprise.

C’est très clair, et pour conclure est ce que tu aurais une vision du Data Product parfait selon toi ?

Le Data Product parfait ce serait surtout un data product qui est utilisé, donc c’est hyper important que un domaine n’ait pas juste envie de modéliser toutes les données modélisables de son sujet, c’est important que ce soit quelque chose d’utile pour l’entreprise, et réutiliser aussi donc c’est important. Plus un data product est réutiliser, plus ça veut dire qu’on a réussi à devenir plus agnostic de l’usage, et donc servir un grand nombre de personnes avec un même un même produit.

Merci Violaine;

Merci Emmanuel donc je vous donne rendez-vous pour un prochain épisode du Data coffee sur le sujet du data mesh.