Si la littérature sur le data mesh est très fournie, elle décrit souvent un état final, rarement comment y parvenir en pratique. La question se pose alors :
Quelle démarche adopter pour transformer le data management et mettre en place un data mesh ?
Dans cette série d’articles, vous trouverez des extraits de notre Guide Pratique du Data Mesh dans lequel nous proposons une démarche itérative de mise en place d’un data mesh au sein de votre organisation. Cette démarche s’articule autour de ses quatre principes clés (domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance) et s’appuie sur les ressources humaines et technologiques existantes.
- Partie 1: Définir le périmètre de votre projet pilote
- Partie 2: Constituer l’équipe de développement et la plateforme data du projet pilote
- Partie 3: Produire vos premiers Data Products
- Partie 4: Passer à un modèle de gouvernance fédérée
Tout au long de cette série d’articles, et dans le but d’illustrer cette démarche itérative pour la mise en place d’un data mesh, nous nous appuierons sur un exemple : celui de l’entreprise fictive Premium Offices – il s’agit d’une société d’immobilier commercial dont l’activité consiste à acquérir des biens pour les louer à des entreprises
–
Dans les premiers articles de la série, nous avons identifié les domaines, défini un premier use case et composé l’équipe qui sera en charge de son développement. Il est temps de passer au second principe du data mesh, data as a product, avec le développement des premiers data products.
L’approche produit du mesh
Au cours de la dernière décennie, les domaines ont très souvent déjà développé une culture produit autour de leurs capacités opérationnelles. Ils les proposent au reste de l’organisation sous forme d’APIs qui peuvent être consommées et composées pour développer de nouveaux services et applications. Dans certaines organisations, les équipes ont à cœur de proposer la meilleure expérience possible aux développeurs utilisant les APIs de leur domaine : recherche dans un catalogue global, documentation exhaustive, exemples de code, bac à sable, niveaux de service garantis et monitorés, etc.
Ces APIs sont alors gérées comme des produits qui naissent, évoluent (sans rupture de compatibilité), s’enrichissent puis sont dépréciés, généralement remplacés par une nouvelle version plus moderne, plus performante, plus riche.
Le data mesh propose d’appliquer cette même approche produit (product-thinking) aux données partagées par les domaines.
Les caractéristiques d’un data product
Dans certaines organisations, cette culture produit est déjà bien ancrée. Dans d’autres, elle devra être développée, voire introduite. Mais ne nous trompons pas :
Un data product n’est pas un nouvel artefact numérique requérant des capacités techniques nouvelles (au même titre qu’un API Product). Il est simplement le fruit d’un mode de gestion particulier des données exposées par un domaine au reste de l’organisation.
Gérer les APIs comme un produit n’a pas demandé de rupture technologique : les middlewares existant faisaient très bien l’affaire. De la même manière, les data products peuvent parfaitement être déployés sur les infrastructures data déjà en place, quelles qu’elles soient.
Sur le plan technique, un data product peut être un simple fichier dans un data lake doté d’une interface SQL ; un petit schéma en étoile, complété de quelques vues facilitant le requêtage, et instancié dans une base relationnelle ; ou encore une API, un stream Kafka, un fichier excel, etc.
Un data product ne se définit donc pas par la façon dont il se matérialise, mais par la façon dont il est conçu, géré, gouverné ; et par un ensemble de caractéristiques permettant son exploitation à grande échelle dans l’organisation.
Ces caractéristiques sont souvent condensées dans l’acronyme DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure).
Obtenir un data product DATSIS ne demande pas non plus d’investissements importants. Il s’agit de définir un ensemble de conventions globales que les domaines devront suivre (nommage, protocoles supportés, gestion des accès et des permissions, contrôles qualité, métadonnées, etc.). La mise en place opérationnelle de ces conventions ne requiert pas dans la grande majorité des cas de nouvelles capacités technologiques – les solutions existantes sont généralement suffisantes pour se lancer.
Une exception cependant : le catalogue. Il joue un rôle central dans le déploiement du data mesh, en permettant aux domaines de publier les informations relatives à leurs data products, et aux consommateurs d’explorer, de rechercher, de comprendre et d’exploiter ces data products.
Bonnes pratiques pour la conception d’un data product
La conception d’un data product n’a bien sûr rien d’une science exacte – il est possible de faire un seul produit, ou bien trois ou quatre. Pour guider ce choix, il est une nouvelle fois utile d’exploiter certaines bonnes pratiques issues des architectures distribuées – un data product doit :
-
Avoir une responsabilité unique et bien définie. -
Avoir des interfaces stables et en garantir la rétro-compatibilité.
-
Pouvoir être utilisé dans plusieurs contextes différents, et donc supporter le polyglottisme.
L’expérience de développement des data products
L’expérience développeur est également un aspect fondamental du data mesh, avec pour ambition de faire converger le développement de data products et le développement de services ou composants logiciels. Il ne s’agit pas seulement d’être aimable avec les ingénieurs, mais aussi de répondre à une certaine rationalité économique :
La décentralisation du data management implique que les domaines disposent de leurs ressources propres pour développer les data products. Dans beaucoup d’organisations, l’équipe data centralisée n’est pas assez nombreuse pour alimenter des équipes distribuées. Pour assurer le succès du data mesh, il est donc indispensable de pouvoir puiser dans le pool d’ingénieurs logiciels, souvent plus important.
L’état de l’art du développement logiciel repose sur un niveau d’automatisation très poussé : allocation déclarative des ressources d’infrastructure, tests unitaires et d’intégration automatisés, build et déploiement orchestrés via des outils de CI/CD, workflows Git pour la gestion des sources et des versions, publication automatique de la documentation, etc.
Le développement de data products doit converger vers cet état de l’art – et selon la maturité de l’organisation, celle de ses équipes, et sa stack technologique, cette convergence prendra plus ou moins de temps. La bonne approche consiste à automatiser autant que possible en utilisant les outils déjà existants et maîtrisés, puis d’identifier les opérations qui ne sont pas automatisées afin d’intégrer progressivement de l’outillage additionnel.
En pratique, voici de quoi est constitué un data product :
1. De code tout d’abord – pour les pipelines qui alimentent le data product avec des données en provenance de différentes sources, ou d’autres data products ; pour les éventuelles APIs de consommation du data product ; pour tester les pipelines et contrôler la qualité des données ; etc.
2. De données, bien sûr – mais le plus souvent les données existent dans les systèmes, et sont simplement extraites et transformées par les pipelines. Elles ne sont donc pas présentes dans le code source (sauf exceptions).
3. De métadonnées – dont certaines permettent de documenter le data product : schéma, sémantique, syntaxe, qualité, lignage, etc. D’autres sont destinées à assurer la gouvernance du produit à l’échelle du mesh – contrats, responsabilités, politiques d’accès, restrictions d’usage, etc.
4. D’infrastructure – ou plus précisément de la déclaration des ressources physiques nécessaires pour instancier le data product : déploiement et exécution du code, déploiement des métadonnées, allocation de ressources pour le stockage, etc.
EXEMPLE PREMIUM OFFICES
Afin de poser un cadre initial pour la gouvernance de son data mesh, Premium Offices a fixé les règles suivantes :
✅ Un data product se matérialise par un projet dédié dans BigQuery – cela permet de fixer des règles d’accès au niveau du projet, ou plus finement si nécessaire. Ces projets seront placés dans un répertoire “data products” et un sous-répertoire portant le nom du domaine auxquels ils appartiennent (dans notre exemple, “Brokerage”).
✅ Les data products doivent proposer des vues pour accéder aux données – ces vues permettent d’offrir une interface de consommation stable, et de potentiellement faire évoluer le modèle interne du produit sans impacter ses consommateurs.
✅ Tous les data products devront identifier les données à l’aide de références communes pour les données communes (Clients, Produits, Fournisseurs, Employés, etc.) – ceci pour simplifier le croisement des données de différents data products (LEI, code produit, UPC, EAN, adresse mail, etc.).
✅ L’accès aux data products nécessite une authentification forte reposant sur les capacités IAM de GCP – l’utilisation d’un compte de service est possible, mais chaque usager d’un data product devra alors disposer d’un compte de service dédié. Quand les politiques d’accès dépendent des utilisateurs, l’identité de l’utilisateur final devra être utilisée via une authentification OAuth2.
✅ La norme est de ne donner l’accès qu’aux vues – et non au modèle interne.
✅ Les demandes d’accès sont traitées par le Data Product Owner au travers de workflows mis en place dans Service Now.
✅ DBT est l’ETL privilégié pour implémenter les pipelines – chaque data product possède un repository dédié pour son pipeline.
✅ Un data product doit définir son contrat – fréquence de mise à jour des données, niveaux de qualité, classification des informations, politiques d’accès, restrictions d’usage.
✅ Un data product peut être consommé soit via le protocole JDBC, soit via les APIs BigQuery (en lecture seule).
✅ Le data product doit publier ses métadonnées et sa documentation dans une place de marché – faute d’un système existant, Premium Offices décide de documenter ses premiers data products dans un espace dédié de son wiki d’entreprise.
Ce premier jeu de règles sera bien sûr amené à évoluer, mais il fixe un premier cadre pragmatique pour garantir les caractéristiques DATSIS des data products en exploitant exclusivement des technologies et des compétences déjà présentes. Pour son pilote, Premium Offices a choisi de décomposer l’architecture en deux data products :
- Tenancy analytics – ce premier data product qui offre des capacités analytiques sur les contrats de location – entité, maison mère, localisation du bien, date de début du bail, date de fin du bail, type de bail, montant du loyer, etc. Il est modélisé sous la forme d’un petit schéma en étoile permettant l’analyse selon 2 dimensions : le temps, le locataire – ce sont les dimensions d’analyse nécessaires pour construire la première version du tableau de bord. Il comprend également une ou deux vues qui exploitent le schéma en étoile pour fournir des données préagrégées – ces vues constituent l’interface publique du data product. Enfin, il comprend une vue permettant d’obtenir la liste la plus récente des locataires.
- Entity ratings – ce second data product fournit le rating historisé des entités sous forme d’un simple dataset et d’une vue miroir pour servir d’interface, conformément aux règles communes. Le rating est obtenu auprès d’un fournisseur spécialisé, qui les distribue sous forme d’APIs. Pour invoquer cette API, il faut fournir une liste d’entités qui est obtenue en consommant l’interface idoine du produit Tenancy analytics.
Dans notre dernier article de la série, nous nous pencherons sur le quatrième et dernier principe du data mesh : federated computational governance.
Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise
Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :
✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise
