"Le Data Mesh : une gestion décentralisée de la data qui crée de la valeur."

Bonjour à tous, je suis Emmanuel Malherbe, directeur de la recherche d’Artefact et j’ai la chance d’animer ce Data Coffee, aujourd’hui sur le thème du data mesh avec Arvand. Bonjour Arvand. 

Bonjour Emmanuel. 

Qui es-tu ? 

Je suis partner chez Artefact, lead sur la practice CPG, et expert sur les sujets Data Platform.

Donc c’est parfait puisque justement on parle du data mesh, tout le monde en parle et qu’est-ce que c’est au juste alors ?

Alors le data mesh, c’est un sujet effectivement très en vogue en ce moment mais relativement récent, même à l’échelle de la data et du digital vous savez, qui évolue super vite donc c’est inventé en 2019, c’est un concept qui est en fait une approche d’architecture data décentralisée orienté autour de domaine de données, et en fait ça se présente plutôt en opposition à l’approche traditionnelle et datawarehouse et des Data Lake, qui avaient toujours une approche très monolithique de la donnée, où toute la donnée était centralisée.

Le data mesh vise à régler trois problèmes récurrents qui arrivent dans les approches traditionnelles qui étaient 1) la question de l’ownership de la donnée; en fait il était jamais clair entre les équipes infra et les équipes business au niveau des sources qui était le propriétaire de la donnée, 2) le deuxième problème que le data mesh vise à régler, c’est sur la qualité de la donnée; en fait le travail de qualité traditionnellement était dans les équipes d’infrastructures, mais ils ne sont pas des experts métiers donc ils ne sont pas capables de juger la réalité réelle de la donnée et d’apporter les corrections nécessaires, et 3) le troisième problème qu’adresse le data mesh, c’est le problème de scalabilité; dans les systèmes ou les organisations traditionnelles, les équipes centrales étaient un goulot d’étranglement dans tous les processus d’ingestion de transformation de mise à disposition de la donnée; en fait le data mesh, en distribuant ce travail accélère tout ces efforts de mise à disposition de la donnée.

Et donc c’est quoi exactement les principes du data mesh ? 

Alors les principes du data mesh, en fait il y a quatre blocs: le premier grand principe c’est la structuration de l’architecture autour de domaine de données, ou de Data domaines. Ces data domains sont des blocs homogènes qui reproduisent le business, par exemple un domaine va être relatif aux produits, un autre domaine va être relatif au client, ou un domaine peut-être lié à la Supply Chain; donc en fait des data domaines vont être propriétaires de la donnée en end to end, du cycle de vie de  la donnée.
Le second bloc c’est le fait que la donnée est considérée comme un produit, elle est traitée tout le long de la chaîne de valeur de la donnée; c’est à dire depuis l’ingestion, sa transformation, et sa mise à disposition. Le troisième bloc c’est la gouvernance fédérée de la data; comme on l’a dit elle est structurée par domaine, et donc la gouvernance de la donnée se fait par domaine, mais pour garder la cohérence on parle de gouvernance fédérée parce que chacun des domaines doit suivre les mêmes lois, les mêmes règles, les mêmes principes, les mêmes outils, afin de s’assurer de la qualité de la mise à disposition. Le quatrième bloc c’est la data platform en libre-service, et donc là c’est une boîte à outils, un ensemble d’outils communs à l’ensemble des domaines, pour justement faire ce travail d’ingestion, de transformation de données, mais également sur les thématiques d’accessibilité, tout ce qui va être lié à la sécurité par exemple de la donnée.

Donc tout le travail autour de ces quatre blocs, la construction data domains, la gestion de la data en produit, la gouvernance fédérées, et la plateforme commune, visent justement via la décentralisation mais à une plateforme commune, d’assurer la cohérence de la mise à disposition de la donnée et, dans ce qu’on appelle une interopérabilité entre les domaines, de sorte à ce que toute personne dans l’organisation puisse consommer de la donnée sûre et en qualité provenant de toute autre part de l’organisation.

Dit comme ça, ça a l’air très convaincant, mais la question c’est est-ce que c’est pour tout le monde, et est-ce que c’est pour moi le data mesh?

Alors le data mesh, c’est important avant tout c’est vraiment un concept, c’est une approche, en fait quand on parle data mesh, la vision extrême du data mesh serait de dire, tout est décentralisé, toute personne dans toute partie de l’organisation peut ingérer la donnée, la mettre à disposition des autres, et consommer toutes les données.
En fait concrètement si on l’appliquait à l’extrême, on pourrait dire une entreprise de 10 000 employés, on aurait 5000 personnes qui créent de la donnée, la consomment, crée des produits etc, et ça à l’échelle c’est impossible. Cette approche data mesh, en fait ce qu’il faut faire, c’est l’appliquer, et l’adapter aux spécificités du business. Si on prend des grandes boîtes technologiques qui ont des plateformes hypers centralisées, hyper commune, l’approche data mesh va être relativement globale, et structurée autour de grands domaines ou grandes fonctions comme le marketing, la production, la finance, et avec quelques grands blocs du Data mesh, on est capable d’adresser tous les besoins.
Si on prend des industries beaucoup plus décentralisées, ou en fait la création de la donnée va se faire à plein d’endroits différents dans l’organisation parce que les systèmes vont être très épars, parce que les utilisateurs vont être de nature très différentes, les usages vont être de nature très différentes, en fait on va devoir avoir une approche un peu plus flexible du Data mesh, en se focalisant sur d’un côté les grandes fonctions comme la finance, peut être la Supply Chain, de grandes fonctions supports, qui globalement fonctionnent avec des systèmes IT homogènes et des modèles de données relativement homogène, et donc en fait on est sur un data mesh très global, fonctionnel; et après dans des métiers beaucoup plus décentralisés, comme le commerce, comme le marketing, tout ce qui va être très top line en fait dans une entreprise, là on va dans être dans une approche datamesh qui va être beaucoup plus décentralisée, avec des mesh qui peuvent être par exemple géographiques; donc imaginez un groupe international, il va avoir des structures commerciales très différentes ou des approches de go to market très différents par pays avec des systèmes différents, et en fait il va considérer que la manière d’adresser la donnée commerciale c’est de le faire par pays. Donc en fait cette approche data mesh aura peut-être 5, 10, 15, 20 hubs différents, qui traitent de la donnée commerciale. A l’inverse, peut-être que la finance est homogène, elle est déjà centralisée, et en fait une seule équipe fonctionnelle finance est capable de servir l’ensemble des usagers de l’organisation.

Donc si par exemple je suis une entreprise qui a déjà commencé ma transformation digitale, avec par exemple déjà un data lake existant, comment je vais relier le data mesh à l’existant? 

Alors en fait là, la question c’est pas de se dire il faut que je fasse du data mesh parce que tout le monde dit qu’il faut que je fasse du data mesh, c’est vraiment revenir aux problèmes business auquels j’essaie de répondre, et concrètement quand on revenait à la définition du data mesh et pourquoi c’était né, c’était est ce que j’ai des problèmes de qualité, est ce que j’ai des problèmes de scalabilité, on va dire même de vitesse; donc on peut dire time-to-Insight par exemple, et est-ce que j’ai des problèmes organisationnels d’ownership. En fait, la réponse à ces questions va dépendre de mon business, de mon industrie, mais au sein même de mon organisation, va dépendre des différentes fonctions, et des différentes business units, et donc quand on applique l’approche data mesh, on dit quelles sont les parties de mon business, de mon IT, de ma data, qui sont relativement homogènes et centralisées, et donc là, en fait j’ai pas de problème, donc j’ai pas besoin de changer d’approche; par contre quelles sont les parties de mon business dans lesquelles j’ai des difficultés, qui peuvent être liées à la qualité, à la scalabilité, à la vitesse, ou à l’ownership; et c’est là que l’approche data mesh va me permettre d’apporter des réponses, qu’elles soient technologiques, qu’elles soit organisationnelles, ou qu’elles soient de mode de travail. Et en répondant à ces questions je peux avoir mon approche différenciée entre des domaines de données, généralement facilement gouvernables au central, et des domaines de données que je peux décider de décentraliser en termes de gouvernance, et du coup en termes de plateforme, et du coup appliquer le data mesh.

Comment ça émerge les sujets data mesh, est-ce que les organisations ont conscience d’un besoin, ou ce que c’est toi qui va pousser justement ce concept et ce modèle?

En fait, encore une fois le data mesh c’est un mode de pensée, c’est pas une solution, donc en fait normalement les organisations elles se disent pas “il faut que je fasse du data mesh”, de la même manière que on va se dire, “il faut que du 6 Sigma, où il faut que je fasse du lean, ou il faut que je fasse du product”; en fait, toutes ces solutions, tous ces modes de pensée, sont des manières d’arriver à des fins; et donc en général les organisations vont se poser la question, est-ce que j’arrive à avoir de la donnée en qualité, est-ce que j’arrive à déployer des use cases, ou des produits analytiques, est-ce que j’arrive dans les coûts; peut-être que je y arrive, mais en fait j’ai déployé des ressources infinies pour y arriver, et donc c’est là que l’approche data mesh va être une manière d’aborder ces questions là et une manière de s’organiser, mais l’ancienne transformation de l’IT data mesh parce que on se dit que c’est en vogue, c’est important, mes voisins le font c’est pas la bonne manière d’aborder le problème.

Très bien, donc c’est vraiment de commencer par le problème à la source auquel le data mesh peut répondre?

Absolument, et en fait la logique toujours, dans tous les programmes de mise en place que ce soit de Data platform, ou plus généralement de gouvernance, et une approche de ta mesh, on commence toujours par la valeur; et quand on parlait plutôt des modes d’organisation qui peuvent dépendre des différentes fonctions d’une entreprise, en fait même dans le déploiement de ces organisations la priorisation qu’on va faire sur la mise en place du data mesh, sur tel ou telle fonction, ou sur telle ou telle géographie, en fait tout ce travail de priorisation doit être d’abord motivé et justifié par le gain business qu’on essaie de générer en termes de cas d’usage. Donc concrètement est-ce que ma stratégie d’entreprise c’est d’augmenter mon chiffre d’affaires, est-ce que c’est de réduire mes coûts, est-ce que c’est de faire de la croissance, est-ce que c’est optimiser mes marges, et donc en fonction de ces questions, on peut identifier quels sont les cas d’usage qui vont me permettre de les atteindre, ces cas d’usage, quelle donnée ils consomment, et du coup ces données-là, quelles sont les challenges, que j’ai en qualité, en disponibilité, en ownership. Une fois qu’on a fait toutes ces étapes, on est capable de définir les domaines prioritaires sur lesquels on veut structurer cette approche data mesh, et cette fois-ci commencer de l’amont, vers l’aval, tout le cycle de vie du produit, pour construire des produits data de qualité, qui seront consommés par des produits analytiques qui entreront dans la main des utilisateurs finaux, qui permettront derrière, de dégager des bénéfices business.

Bon ça fait une très belle conclusion, il n’y a plus rien à ajouter c’est parfait; ça a été très clair; je te remercie Arvand, pour ce discours sur le data mesh.

Merci Emmanuel.

Et je vous donne rendez-vous pour le prochain épisode du Data coffee de la plateforme the Bridge.