Comment initier un Data Mesh ? – Partie 4 – Passer à un modèle de gouvernance fédérée

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, composé l’équipe qui sera en charge de son développement et créé nos premiers data products. Il est temps de passer au dernier principe du data mesh, federated computational governance.

Qu’est-ce que la gouvernance computationnelle fédérée ?

Federated computational governance fait référence à un système de gouvernance où les processus décisionnels sont répartis entre plusieurs entités ou organisations, utilisant des algorithmes computationnels et des technologies distribuées. Dans ce système, l’autorité décisionnelle est décentralisée, chaque entité participante conservant un degré d’autonomie tout en collaborant au sein d’un cadre plus large. La gouvernance fédérée repose sur les caractéristiques suivantes :

• La décentralisation : L’autorité décisionnelle est répartie entre plusieurs entités plutôt que concentrée dans une seule autorité centrale.

• Des algorithmes : Les algorithmes jouent un rôle significatif dans les processus de gouvernance, aidant à automatiser la prise de décision, à faire respecter les règles, et à garantir la transparence et l’équité.

• Un cadre collaboratif : Les entités collaborent au sein d’un cadre plus large, partageant des ressources, des données et des responsabilités pour atteindre des objectifs communs.

• Transparence et responsabilité : L’utilisation d’algorithmes et de registres distribués peut améliorer la transparence en fournissant un enregistrement clair des processus et en garantissant la responsabilité des entités participantes.

• Adaptabilité et résilience : Les systèmes de gouvernance computationnelle fédérée sont conçus pour être adaptables et résilients, capables d’évoluer et de répondre aux changements dans l’environnement ou aux besoins des participants.

Les défis d’une gouvernance fédérée dans le data mesh

Le dernier principe du data mesh, federated computational governance, implique qu’un organe central définisse les règles et standards auxquels les domaines doivent se conformer. Des responsables locaux sont chargés de mettre en place ces règles dans leur domaine, et de fournir à l’organe central la preuve de leur conformité – le plus souvent sous forme de reporting.

Bien que le modèle soit en principe simple, sa mise en place se heurte souvent à la culture interne. C’est le cas notamment dans les secteurs fortement réglementés, où les équipes de gouvernance centralisée sont réticentes à l’idée de déléguer tout ou partie des contrôles dont elles avaient historiquement la responsabilité.

La gouvernance fédérée se heurte également à une réalité de terrain rarement favorable : la gouvernance des données est fortement liée à la gestion du risque et à la conformité, deux domaines qui suscitent rarement l’enthousiasme des équipes opérationnelles.

Dès lors, il devient difficile d’identifier les responsables locaux, ou de transférer certains aspects de la gouvernance aux Data Product Owners – qui, pour la plupart, doivent déjà apprendre un nouveau métier. Il est donc probable que, dans la plupart des grandes organisations, la structure fédérale sera émulée par l’organe central, puis très progressivement mise en place dans les domaines à mesure que leur maturité progresse.

Pour éviter une explosion des coûts de la gouvernance, ou sa fragmentation, Dehghani imagine que la plateforme data pourra à terme prendre en charge de façon automatique des pans entiers de la gouvernance.

Les aspects d’une gouvernance fédérée pouvant à automatisés

Chez Zeenea, nous croyons fermement que l’automatisation permet de relever ce défi sur plusieurs fronts :

Le chemin est long, bien sûr, mais la décentralisation autorise des progrès très itératifs, domaine par domaine, produit par produit. Et rappelons aussi que tout progrès dans l’automatisation de la gouvernance, sur quelque aspect que ce soit, repose sur la production et le traitement de métadonnées.

 EXEMPLE PREMIUM OFFICES

Chez Premium Offices, le Data Office a une culture de gouvernance très défensive – la société intervenant sur le marché des capitaux, elle est soumise à un ensemble de contraintes réglementaires très strictes.
Dans le cadre du pilote, il a été décidé de ne pas toucher au framework de gouvernance. La qualité et la traçabilité restent du ressort du Data Office, et seront traitées a posteriori avec leurs outils et méthodes. Le contrôle des accès sera également de sa responsabilité – un process est déjà en place, sous la forme d’un workflow ServiceNow (la mise en place des permissions sur BigQuery demande plusieurs opérations manuelles, ainsi que des revues). Seule concession, le workflow sera modifié pour que les demandes d’accès soient vérifiées par le Data Product Owner avant d’être validées et traitées par le Data Office. Un petit pas vers la gouvernance fédérale, donc.

Côté métadonnées, les nouvelles tables et vues dans BigQuery devront être documentées, au niveau conceptuel et physique, dans le data catalog central (qui ne connaît pas la notion de data product). C’est un processus déclaratif que l’équipe pilote connaît déjà. Le tagging éventuel des colonnes sera réalisé par le Data Office après évaluation.

Pour le reste, la documentation utilisateur des data products sera diffusée dans un espace dédié du wiki interne, organisé par domaine, qui permet d’écrire une documentation très riche et structurée, et possède un moteur de recherche décent.

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