Pour les start-uppers, il s’agirait d’un facilitateur permettant de piloter et d’organiser sa data, autrement dit dans le jargon : un enabler du data-driven.
Chez les littéraires férus de concepts et de théorisation, il s’agirait d’un nouveau paradigme sociotechnique décentralisé ayant pour but de gérer et d’accéder aux données à l’échelle.
Du côté des « gens normaux » un peu sensibles à la data gouvernance, il s’agirait d’un nouveau cadre de gestion des données qui évite d’avoir recours à une équipe intermédiaire et centrale de gestion des données.
Pour les esthètes, il s’agirait d’une réponse, élégante, belle et raffinée, à la complexité et la volativité du business.
Chez les techniciens, le data mesh serait une architecture de données décentralisée (ou « distribuée » pour certains) qui organise les données par domaine. Bien sûr, avec cette définition factuelle, on reste bien dans la technique, rien que dans la technique. Et vas-y que je te tartine du cloud, de la sécurité et compagnie…
Du côté des modélisateurs, il s’agirait d’une nouvelle approche de conception des données.
Bon… choisissez donc votre camp ou bien mixez le tout, pas mieux éclairés que vous serez par l’article fondateur du 20 mai 2019, rédigé par Zhamak Dehghani, qui elle-même ne s’est pas risquée à donner une définition dudit data mesh, qu’elle a pourtant contribué à conceptualiser. Quant à Mick Levy, le spécialiste-pédagogue de la data et de l’intelligence artificielle, il a dit, lors d’une conférence, que le data mesh serait une utopie et que, comme pour le voyage, ce serait le chemin vers cette utopie qui serait intéressant.
Essayons alors d’y voir plus clair dans le côté obscur du data mesh…
Les 4 commandements du data mesh
Creusons donc le sillon de ce chemin… Et, tant qu’à faire, si nous empruntons une voie plutôt philosophique, tentons d’édicter « les 4 commandements du data mesh ». Cela semblera sans doute un peu biblique mais je m’y essaie en mode maître Yoda.
- Chaque domaine, souverain sur ses données sera, car nul ne peut servir deux maîtres à la fois.
- Comme des produits, tes données tu vénèreras, car elles sont la source de toute valeur.
- Le chemin vers la donnée tu éclaireras, car elle doit être accessible à tous les fidèles qui en sont dignes.
- L’ordre, dans ta maison règnera, sans pour autant étouffer toute liberté.
Tous ces concepts existent dans d’autres bibles de data management, notamment DMBOK (Data Management Body of Konwledge), qui proposent des pistes de réflexion sur :
- Domaine : DMBOK Chapitre 3 Data governance Psaume 1.3.3 Operating model types
- Produit : DMBOK Chapitre 11 Warehousing & BI Psaume 2.6 Maintain Data product
- Self service : DMBOK Chapitre 6 Interoperability Psaume 6 DII Governance
- Gouvernance fédérée : DMBOK Chapitre 16 Organization & Rôle Psaume 3.5 Federated Operating Model
Gardons en mémoire que le data mesh ne s’occupe que des données analytiques, pas des données opérationnelles.
Fédéré VS centralisé
Les principes énoncés plus haut ne sont pas sans poser de problèmes :
- Comment fait-on pour garder de la cohérence inter-domaines ?
- Qui garantit l’interopérabilité entre produits ?
- Comment fait-on pour que seules les bonnes personnes aient accès à l’information ?
- Comment fait-on pour prendre des décisions cohérentes ?
Pour répondre à ces problématiques, gageons que « centraliser », c’est tout de même pas si mal ! On ne sait plus là sur quel pied gouverner ses données… L’esprit embrouillé, rappelons d’abord que l’on parle d’un concept face à une technologie. Rappelons aussi qu’il est commun de dire que le data lake est monolithique et centralisateur alors que le data mesh promeut, lui, distribution et fédération. Or, selon moi, la technologie data lake est complètement utilisable dans une approche data mesh. Et la vraie question à vous/se poser est donc : plutôt fédéré ou plutôt centralisé ?
Quand la messe est dite et la bible lue, il est temps de passer en cuisine ! Comparons…
Un système centralisé serait comme une cantine avec cuisine centrale :
- Une seule grande cuisine qui prépare tout
- Des processus standardisés
- Des économies d’échelle
- Mais moins de flexibilité pour les spécialités
Un système fédéré (mais cohérent) serait comme un food court :
- Chaque restaurant gère sa cuisine
- Une spécialisation par type de cuisine
- Plus de flexibilité et d’innovation
- Mais des infrastructures dupliquées
Mettez les mains dans la farine : de la théorie à la pratique
Parce qu’à un moment il faut bien se lancer, voici quelques conseils pour la mise en place d’un data mesh au sein de votre organisation.
- En comprendre les principes :
Pour ce faire, je vous invite à lire le livre de Zhamak Dehghani Data Mesh (aux éditions O’Reilly) et à rencontrer vos pairs grâce au Data Mesh Live.
Être clair sur votre stratégie business et identifier les domaines éligibles au data mesh, ceux qui ont besoin d’agilité et d’indépendance pour être performants.
- Identifier vos premiers acteurs-projet et les former.
- Élaborer une première architecture technique data standard mais flexible.
- Démarrer sur deux de ces domaines qui ont néanmoins des données en commun.
- Penser vos formations, vos architectures, vos développements comme un produit.
- Automatiser tout ce que vous pouvez.
- Mesurer, analyser et recommencer (en corrigeant)
Data Mesh : toutes ces success stories que l’on ne vous raconte pas…
Ce pourrait être le titre d’un bon article feel good non ? Et probablement que vous pourriez en être, malgré les heures de labeur et de prise de tête, parce que derrière chaque cas d’usage réussi se cachent des nuits blanches et des crises de nerfs, qu’on se le dise. Évoquons quelques célébrités : JPMorgan Chase, Netflix, Zalando ou le Bon Coin qui ont adopté cette nouvelle approche avec brio.
Mais ceux qui réussissent (et ils sont nombreux et même sans faire explicitement de data mesh !), ce sont d’abord ceux qui créent de la collaboration autour de leurs données avec :
Une forte implication de la direction et une vision claire : si elle n’existe pas chez vous, prenez le pouvoir et construisez-la ! Le design sprint process est d’ailleurs un très bon atelier pour cela.
Une approche progressive, itérative et centrée sur la valeur : pourquoi ne pas tenter la méthodologie du Lean Startup ?
Un investissement important dans la formation des équipes : de nombreux budgets de formation sont sous utilisés dans les entreprises, à bon entendeur…
C’est notamment ce type d’approche qui a été utilisé par PlasticOrigins pour la création de deux produits distincts : une application qui permet de faire des relevés et une plateforme de traitement d’analyse. L’équipe est formée essentiellement de bénévoles : détail ou pas pour vous, cela veut dire beaucoup et que tout est possible !