Relever les défis organisationnels lors de la conception d’un data mesh

Nous connaissons tous ce sentiment de frustration face à un goulot d’étranglement, comme lorsque vous vous retrouvez à faire la queue au télésiège. Ainsi, pendant les congés d’hiver, les vacanciers en quête de sensations fortes doivent bien souvent prendre leur mal en patience avant de pouvoir conquérir les pistes. Certains cherchent alors de nouvelles méthodes pour accéder au sommet, d’où la popularisation du ski de randonnée ou de « l’ascension à ski », avec pour devise de « mériter son tour ».  

Imaginez maintenant la demande croissante que suscitent les données et informations. Traditionnellement, les entreprises comptaient sur des équipes centrales en charge des données, qui dépendaient souvent du service informatique, pour construire des pipelines de données et fournir des données. Parfois, elles comptaient même sur des équipes centrales d’analyse pour fournir directement des informations. Cette centralisation était à l’origine de goulots d’étranglement et de délais d’attente frustrants. Quand il faut des semaines voire des mois pour obtenir des données ou fournir des informations, l’opportunité que vous vouliez saisir risque fort de n’être plus qu’un vague souvenir, telle la neige fraîche qui a déjà été foulée au moment où le télésiège vous dépose enfin au sommet de la montagne. 

Le paradigme du data mesh entreprend de résoudre certains de ces problèmes. En effet, le data mesh s’appuie sur quatre principes de base qui interagissent entre eux et soutiennent les objectifs de l’entreprise : 

• Responsabilité des domaines : cela permet la distribution ou la décentralisation de la responsabilité des données. Pour autant, ce n’est pas une foire d’empoigne. Le paradigme du data mesh établit des garde‑fous. 
• Infrastructure en libre‑service : la gouvernance et l’utilisation des données sont permises par une infrastructure ou une plateforme data commune. Celle‑ci empêche la prolifération des technologies. 
• Données en tant que produit : cela signifie que les données doivent être traitées comme un produit qui sera utilisé par d’autres personnes. Les domaines du data mesh ne les isolent pas. Ils mettent les données à la disposition des autres utilisateurs, en s’occupant des exigences telles que les formats, la qualité, la documentation ou encore la fréquence de rafraîchissement des données.
• Gouvernance de calcul fédérée : une gouvernance des données à l’échelle de l’entreprise doit être appliquée à tous ; elle doit être coordonnée de manière centralisée, mais appliquée de manière distribuée, sans perdre de vue les exigences relatives aux sources de données, aux propriétaires de domaines et aux utilisateurs. 

Si ce nouveau paradigme semble prometteur en théorie, de nombreuses questions restent en suspens quant à sa mise en pratique. On dit souvent que la technologie constitue la partie la plus facile, même si tout est relatif. En effet, ce n’est à aucun moment un jeu d’enfant. Les décisions concernant l’architecture et la modélisation des données peuvent s’avérer difficiles à prendre. Mais les considérations organisationnelles peuvent être particulièrement épineuses. Nous avons regroupé quelques questions parmi les plus fréquemment posées :

Quelle est la meilleure façon d’introduire un data mesh dans une entreprise ? 

En général, un data mesh ne fait pas son apparition du jour au lendemain. Le client de Snowflake Vio (anciennement FindHotel) s’est orienté vers un data mesh presque par hasard. Alors que la demande commençait à dépasser l’équipe centralisée en charge des données, Vio s’est demandé comment répartir les responsabilités. Certains domaines potentiels étaient plus matures que d’autres. Ceux‑ci se sont donc imposés logiquement comme points de départ. Ainsi, l’équipe a adopté une organisation plus distribuée par pure nécessité. Elle s’est ensuite rendu compte qu’elle essayait en fait de mettre en place un data mesh. Pour en savoir plus sur le parcours de Vio, rendez‑vous ici.

Roche Diagnostics a également commencé à petite échelle, avec un seul domaine en mai 2021. Moins d’un an plus tard, l’entreprise comptait plus de six domaines et plusieurs équipes produits qui travaillaient sur sa plateforme. 

Pour adopter une approche systématique, commencez par ces premières étapes :

• Évaluez les besoins et les frustrations actuelles au sein de votre entreprise : on vous parlera probablement de goulots d’étranglement qui entraînent des retards dans le pipeline de données, de longs délais d’attente pour obtenir les données et informations voulues, ainsi que de frustrations quant à la qualité des données. Mais vous constaterez peut‑être aussi un sentiment de confusion concernant les objectifs de l’entreprise et de la stratégie data. Les niveaux de maturité diffèrent considérablement d’une entreprise à l’autre. 
• Communiquez les résultats de cette évaluation aux principaux dirigeants et aux autres parties prenantes pour obtenir leur soutien : le soutien de la direction est souvent cité comme le principal facteur de réussite lors de l’exécution d’une stratégie data. Toutefois, n’oubliez pas d’obtenir un soutien plus large en impliquant des responsables et des analystes de l’ensemble de l’entreprise. 
• Déterminez les niveaux de compétences et les lacunes des différentes équipes : les différents domaines n’auront pas tous le même niveau de maturité. Évaluez ceux qui peuvent être plus autonomes au départ et comment soutenir les autres. Ces domaines seront vraisemblablement les meilleurs défenseurs de votre data mesh, et ils seront au cœur d’un conseil data, qui pourra faire avancer la stratégie et œuvrer pour coordonner les exigences et répartir les responsabilités. Vous en apprendrez davantage sur ce conseil data ci‑après.
• Commencez avec un domaine et un cas d’usage, puis répétez l’opération : le premier cas d’usage sert de démonstration de faisabilité pour démontrer comment un domaine peut fournir un produit exploitable par les autres à partir des données. Idéalement, ce cas d’usage répond à un besoin immédiat de l’entreprise, afin de recueillir le plus de soutien possible et de donner une impulsion. L’adoption de ce modèle pour d’autres cas d’usage peut permettre d’étendre les responsabilités des domaines et l’accès à des infrastructures en libre‑service. Toutefois, « commencer petit » ne signifie pas forcément « commencer d’en bas ». En effet, le soutien de la direction est généralement nécessaire dès le début. 

Quelles sont les principales parties prenantes à convaincre ? 

La pression incitant à prendre des mesures peut émaner des utilisateurs, qui en ont assez d’attendre les données et informations dont ils ont besoin, ou des équipes centrales en charge des données, qui sont frustrées d’être devenues un goulot d’étranglement. Tous les acteurs de la chaîne de données doivent être impliqués, des responsables de sources de données jusqu’aux utilisateurs. Comme nous l’avons déjà mentionné, le soutien de la direction facilite la mise en œuvre des changements requis. D’autres considérations peuvent inclure un représentant du service juridique ou de la conformité, susceptible de fournir (éventuellement de manière périodique) des informations sur les exigences en matière de gouvernance à l’échelle de l’entreprise, ou un représentant des ressources humaines, pour favoriser un processus de gestion du changement plus formel et un programme d’initiation dans toute l’entreprise. L’évolution culturelle nécessaire pour devenir une entreprise data‑driven exige de convertir et de rallier le maximum de personnes. Il n’est pas nécessaire d’inclure tout le monde dans le processus central, mais les communications doivent cibler une audience plus large. 

Comment choisir les domaines et définir leur portée et leurs responsabilités ?

Roche Diagnostics a quelques recommandations pour définir les domaines. À l’origine, les responsables commerciaux et informatiques avaient défini les domaines en fonction des limites des processus, et pas nécessairement de leur structure fonctionnelle. Si cette approche avait du sens, ces définitions ne permettaient pas un alignement parfait. Il restait une zone grise. L’astuce ? « Ce qui compte, c’est de s’assurer de mettre en place des responsabilités à proximité de l’origine des données dans le système source. » La collaboration entre les parties prenantes permet ensuite l’optimisation.

Voici quelques considérations courantes pour choisir les domaines :

• Les domaines doivent être définis en respectant les secteurs fonctionnels, qui regroupent des membres de l’entreprise avec un même objectif fonctionnel.
• Les domaines ne doivent pas être définis autour des piles technologiques existantes, afin d’éviter de créer des domaines technologiques plutôt que des domaines de données fonctionnels.
• Les domaines de données doivent être choisis avec des responsabilités clairement définies. Les entreprises s’efforcent en général d’éviter tout chevauchement de responsabilités des données entre les domaines.
• Il est parfois logique d’avoir des domaines orientés sources ou des domaines orientés utilisateurs. Les premiers servent à assurer la mise à disposition des données issues de sources de données opérationnelles, en respectant le niveau de qualité et de standardisation requis par les autres domaines. Les deuxièmes créent des produits de données intégrés de plus grande valeur, répondant plutôt aux exigences des utilisateurs de données côté métier, par exemple, un domaine vue client à 360° agrégeant des données provenant de plusieurs sources.

Comment convaincre un responsable de domaine potentiel de le devenir et d’assumer la responsabilité de ses données (produits) ? Certaines équipes produisent des données mais n’en utilisent pas. Percevront‑elles l’avantage de la transformation apportée par un data mesh, ou n’y verront‑elles qu’une charge de travail supplémentaire ? Comment susciter leur adhésion à cette approche et à un état d’esprit tourné vers les données en tant que produits ?

J’avoue que je pensais que les domaines réclameraient d’être responsables de leurs données. Pourtant, ce n’est pas toujours le cas, en particulier à cause des obligations qui découlent du data mesh. La responsabilité d’un domaine inclut celle de la qualité des données, des pipelines de données et des produits de données. Il n’est pas seulement question de sécuriser et de stocker des données. Peu habituées à ce genre de responsabilités étendues, certaines équipes en charge de domaines ont rechigné à assumer celle‑ci, qui leur apparaissait comme un travail supplémentaire. 

Le défi consiste à créer un environnement propice au succès du responsable des données. Tout d’abord, ce rôle doit être compris, valorisé et récompensé. Pour susciter un changement de comportement, il faut des carottes et des bâtons. Tout le monde ne se motive pas de la même façon, et il peut donc être utile de mettre en place plusieurs méthodes pour encourager les comportements souhaités. Passons d’ailleurs à la prochaine question. 

Comment encourager les domaines à prendre et assumer la responsabilité de leurs données, c’est‑à‑dire à s’assurer de la qualité des données, pas nécessairement pour répondre à leurs propres besoins, mais pour répondre à ceux d’autres domaines ou utilisateurs de données ? 

Les changements organisationnels nécessitent des modifications de comportement, en se concentrant à la fois sur les collaborateurs et les processus au sein de l’entreprise. De nouveaux objectifs doivent être établis afin d’encourager le comportement voulu. Les équipes comme leurs membres auront de nouveaux indicateurs de succès. Les objectifs seront plus centrés sur l’utilisateur des données, l’exploitation de ces dernières et la valeur apportée à l’entreprise. 

Vous devez investir pour :

• Le rendre possible (comment faire ?) 

Toutes les équipes doivent comprendre ce qu’on attend d’elles. Elles doivent avoir des indicateurs clairs qu’elles peuvent contrôler. Elles doivent également disposer des bons outils en libre‑service pour faire leur travail. Elles doivent aussi être formées pour exploiter efficacement ces outils. Mais peut‑être plus important encore, elles doivent être formées pour comprendre comment fonctionne l’entreprise, comment recueillir les exigences des utilisateurs de données et comment collaborer avec leurs pairs d’autres domaines pour assurer un développement efficace de nouveaux produits de données, qui répondent aux besoins de leurs « clients ». 

• L’encourager (pourquoi le faire ?)

Pour faire évoluer les comportements, les domaines doivent être incités à faire les choses différemment, c’est‑à‑dire à assumer la responsabilité des produits de données. Si certains peuvent savoir comment s’y prendre, il faut néanmoins leur montrer ce qu’ils ont à y gagner. Les nouvelles mesures incitatives peuvent être de nature sociale, en faisant davantage connaître le rôle joué par les équipes pour fournir de nouvelles informations au service de l’activité, en reconnaissant la valeur apportée à l’échelle de l’entreprise et en appréciant explicitement le travail bien fait. Il faut cependant être réaliste : ces incitations sociales doivent être associées à des incitations matérielles, pour les équipes comme pour leurs membres. Celles‑ci peuvent inclure des dotations à l’échelle d’une équipe pour acquérir de nouvelles ressources, une augmentation des effectifs, des budgets et des promotions, ou encore des primes pour les personnes qui se démarquent.  

• L’appliquer (que se passe‑t‑il dans le cas contraire ?)

Enfin, ces responsabilités doivent également faire l’objet de mesures coercitives (le bâton, selon la formule consacrée). On suppose donc que les exigences étaient claires et réalisables, et les indicateurs mesurables et raisonnables. La première étape consiste alors à travailler avec les équipes pour comprendre les défis auxquels elles sont confrontées. Il peut s’agir d’un manque de formation ou de la nécessité de trouver de nouveaux outils. Mais en définitive, ces nouvelles responsabilités doivent être appliquées dans toute l’entreprise. D’un point de vue social, les autres équipes sauront qui n’assume pas les siennes. D’un point de vue matériel, ceux qui ne parviennent tout simplement pas à s’y faire trouveront peut‑être mieux leur place ailleurs dans l’entreprise. Pour permettre un changement organisationnel, il est essentiel de rendre des comptes.

Comment éviter autant que possible les duplications des tâches et/ou des données entre les domaines ?

La première question est de savoir si la duplication est toujours une mauvaise chose. La duplication permet parfois de gagner en agilité, sans perdre en constance. La clé de la coordination réside dans la communication, qui constitue finalement la seule façon de contrôler les duplications inutiles entre les domaines. Par conséquent, la communication doit être multidirectionnelle : descendante, ascendante et de pair à pair. Voici quelques mécanismes essentiels pour promouvoir la communication et la coordination :

• Le leadership sur les données facilite la coordination et favorise le changement : de nombreuses entreprises ont désigné des responsables des données. L’intitulé de leur poste peut varier. Certaines entreprises ont nommé un CDO, quand d’autres ont un responsable des données et des analyses, ou encore un vice‑président des informations. Quel que soit l’intitulé de son poste, un responsable des données endosse bien souvent le rôle d’un diplomate, œuvrant dans toute l’entreprise pour définir une stratégie data, développer une culture data et accroître la valeur des données. Si le rôle et les priorités des responsables des données peuvent changer quand les responsabilités sont réparties, ils doivent néanmoins toujours faire preuve de diplomatie, de coordination et de communication pour démontrer les avantages d’un tel changement et cultiver une vision partagée. Ces responsables des données participent également à la mise en place des mesures incitatives et coercitives pour favoriser le changement.
• Un conseil data permet de coordonner les parties prenantes : un conseil data rassemble les représentants des différents domaines et de leurs utilisateurs, ainsi que d’autres parties prenantes importantes. Par exemple, un représentant du service juridique peut être convié, afin de s’assurer de prendre en compte les exigences de conformité réglementaire. Ce conseil sert ensuite d’instance de coordination pour identifier les besoins autour d’une infrastructure commune, définir des conditions et des formats communs pour les données, développer des politiques de gouvernance à l’échelle de l’entreprise et allouer des ressources en fonction des priorités. Le résultat est alors mis en œuvre au niveau des domaines, comme le stipule le principe de gouvernance fédérée du data mesh. Le conseil data peut également servir de centre d’excellence ou même de bureau de service, offrant conseils et assistance pour permettre aux domaines les moins matures et même aux utilisateurs de rattraper leur retard.

Quels critères de réussite ou KPI pouvons‑nous utiliser pour mesurer la progression de la transformation organisationnelle vers le data mesh ?

La mesure ultime du succès des équipes en charge des données est leur impact sur l’activité, que ce soit par une réduction des coûts ou la valeur apportée. Tout au long d’un parcours de data mesh, les KPI se concentrent essentiellement sur la maturité des domaines, l’efficacité de la gouvernance fédérée, la valeur des produits de données et la facilité d’utilisation d’une plateforme data en libre‑service. Par exemple, pendant le transfert des responsabilités liées aux produits de données d’une équipe centrale vers des domaines distribués, une entreprise peut mesurer le nombre de produits de données partiellement ou entièrement pris en charge localement dans les domaines. Elle peut également s’efforcer de suivre à quelle fréquence un domaine sollicite de l’aide de la part d’une équipe centrale en charge de l’infrastructure. 

À mesure que l’entreprise gagnera en maturité, le succès se mesurera davantage à l’utilisation des données et à la valeur apportée. Certaines entreprises mesurent l’utilisation des produits de données au fil du temps en se basant sur le nombre de requêtes portant sur un produit donné ou sur la fréquence des consultations. Si de tels indicateurs sont extrêmement précieux, il ne faut pas oublier qu’une faible utilisation n’est pas toujours synonyme de faible valeur ou faible qualité du produit de données. Par exemple, un domaine peut fournir un produit de données de valeur et de priorité élevées, dont les utilisateurs n’ont besoin qu’une fois par mois. En fin de compte, l’indicateur de valeur doit refléter la contribution à un cas d’usage spécifique, par exemple l’augmentation des taux de conversion des campagnes marketing ou encore la précision des algorithmes de détection des fraudes. 

Pour pérenniser l’apport de valeur, les commentaires et les évaluations des utilisateurs de données concernant les produits peuvent également constituer un indicateur particulièrement intéressant à recueillir. Parmi les autres indicateurs utiles figurent l’amélioration de la qualité des données, l’exhaustivité de la documentation autour des produits de données, le degré d’automatisation, le coût et la résilience des produits de données ou encore le temps que mettent les utilisateurs de données à tirer de la valeur d’un produit de données.     

Comment généraliser le data mesh en tant que méthodologie et état d’esprit dans toute l’entreprise ?

Pour généraliser le data mesh, il convient de s’attarder sur des considérations à la fois architecturales et organisationnelles. D’un point de vue organisationnel, un data mesh, tout comme un état d’esprit data‑driven, nécessite une évolution de la culture d’entreprise. Il faut cultiver les deux côtés, à savoir la fourniture et la demande de données : les utilisateurs de données établissent les exigences auxquelles les équipes des domaines doivent répondre. C’est un défi de taille. 

Le développement d’une nouvelle culture data nécessite de la communication. Il faut commencer par répondre aux questions « Que sont les données ? », « Comment les utiliser ? », « Quelle est leur valeur ? » et surtout « Quel est mon rôle ? ». Évidemment, les utilisateurs et les domaines doivent comprendre leur rôle, mais tous les autres collaborateurs de l’entreprise aussi. En effet, tout le monde a un rôle à jouer dans la collecte, la protection ou l’utilisation des données. Cela ne concerne pas seulement les équipes en charge des données. Mais ce n’est pas le sujet de cet article de blog.

Dans le cadre du data mesh, il est indispensable d’expliquer comment fonctionne l’architecture distribuée mais coordonnée. Prenons l’exemple de la gouvernance fédérée. D’après Omar Khawaja, Head of Business

Intelligence chez Roche Diagnostics, « nos collaborateurs ont entendu parler de la gouvernance, qui n’est rien d’autre pour eux que de la bureaucratie 90 % du temps. C’est pourquoi on parle de « gouvernance fédérée ». Cela permet d’amener ces collaborateurs à prendre part à la discussion, en leur expliquant qu’elles participent désormais aux prises de décision. C’est un facteur qui favorise l’adhésion dans certains cas. » Pour ce faire, il convient d’expliquer les nouveaux processus et les nouveaux rôles. Une communication efficace permet de faire comprendre la valeur et de favoriser l’adhésion.

Bien sûr, il y a beaucoup d’autres questions à poser pour comprendre comment mettre en place efficacement un data mesh. Par exemple : Comment convaincre les équipes de standardiser les technologies ? Comment arrêter ou inverser la prolifération d’outils ? Comment estimer les coûts et les bénéfices ? Nous répondrons à ces questions et à bien d’autres dans un nouvel article de blog à venir. 

En attendant, pour en savoir plus sur l’utilisation de Snowflake pour le data mesh, consultez notre site web.