Matthias Patzak - Data Mesh – Successful with People, Process, and Technology

[00:00:05] Donc, la dernière conférence de la soirée. Je suis Matthias, Matthias Patzac. Je suis allemand, évidemment, et je m'excuse pour mon horrible accent allemand et pour tout problème de prononciation et de grammaire. Donc, je suis stratège d'entreprise chez AWS. Personne ne sait vraiment ce qu'est un stratège d'entreprise. Je le traduirais par : nous sommes des références clients vivantes. Je fais donc partie d'une équipe composée de 13 anciens cadres clients qui partagent leur propre expérience de ce que nous voyons dans la communauté et de la manière d'innover à grande échelle, d'introduire le lean agile ou de réaliser des transformations cloud. J'étais CTO d'AutoScout24, c'est une place de marché européenne pour les voitures d'occasion, et directeur général de Home Shopping Europe, c'est donc une entreprise d'e-commerce en...
[00:00:51] en Allemagne. Et j'ai introduit le terme de maillage de données qui n'était pas encore inventé à l'époque, mais nous l'avons appelé une plateforme de données distribuée en 2017. Et je vais partager ma propre expérience et ce que je vois dans la communauté, comment les clients d'AWS mettent en œuvre les maillages de données. Qui a entendu l'affirmation selon laquelle les données sont le nouveau pétrole ? Certains. Et cela a été inventé en 2008 par un scientifique britannique. Et quelle a été la conséquence de cette personne disant que les données sont le nouveau pétrole ?
[00:01:36] La conséquence a été que chaque grande organisation a commencé à stocker chaque morceau de données qu'elle pouvait trouver dans ses applications. Et lors d'une récente conférence sur les données, j'ai entendu un consultant de ThoughtWorks, une entreprise avec laquelle j'adore travailler, dire que les données sont le nouveau lait. Parce que si vous l'utilisez rapidement, ça tourne mal. En fait, je pense que ce n'est pas vraiment vrai, de mon point de vue, les données sont le nouveau vin. Donc, il y a certains types de vins, si vous les utilisez rapidement, ils sont très bons, mais si vous les stockez pendant une plus longue période, vous ne pouvez plus les consommer. Alors que d'autres types de vins, si vous les produisez et les stockez correctement, deviennent de plus en plus savoureux et de plus en plus précieux avec le temps. Et c'est ce que nous constatons dans l'industrie. Nous constatons que 90% des données actuelles ont été créées au cours des deux dernières années seulement. Mais néanmoins, seulement 24% des entreprises se caractérisent comme étant axées sur les données. Donc, ils stockent beaucoup de pétrole, mais ils ne sont pas vraiment capables d'exploiter la valeur qui est censée être dans ces données.
[00:02:51] Et il y a une enquête de NewVantage Partners, ils ont été rachetés par une autre entreprise, mais si vous êtes dans le domaine des données, Je peux vraiment recommander l'enquête sur le Big Data de NewVantage Partners. Et ils enquêtent auprès des 5000 plus grandes entreprises clientes aux États-Unis. Ils ont un grand nombre de personnes qui répondent. Et pendant des années, le plus grand défi de l'adoption des données par les entreprises, c'est-à-dire non pas la construction d'un lac de données, mais la création de valeur à partir des données, l'adoption des données par les entreprises, est la culture. En fait, ce nombre diminue, c'est donc un bon signe. Il y a deux ans, c'était 90%. Il y a deux ans, 90% des entreprises qui ont répondu à cette enquête ont déclaré que le plus grand défi de l'adoption des données par les entreprises était la culture. Mais maintenant, avec l'IA générative, les gens sont plus nerveux à propos de la technologie.
[00:03:50] Et pourquoi cela ? Pourquoi la culture, les gens, la communication et les processus sont-ils le plus grand défi pour être axé sur les données ? Et jetons un coup d'œil à l'histoire des données. J'ai commencé ma carrière en 1995 dans une entreprise de fournisseurs automobiles. Et je me souviens très bien de l'époque où nous avions ce service AS400. Et chaque matin, ce service imprimait cette longue liste de papier sans fin, vert et blanc, avec les matériaux que nous, en tant que fournisseur automobile, utilisions. C'est ce que nous appelons chez AWS la zone de données avec juste des bases de données transactionnelles.
[00:04:33] Et si vous regardez les modèles de collaboration, il n'y avait que deux parties impliquées. Nous avions donc les producteurs de données, les équipes qui devaient partager les données. Ils ne voulaient vraiment pas partager les données, ils voulaient juste maintenir leurs machines AS400 en fonctionnement. Et nous avions les consommateurs, des équipes qui voulaient utiliser les données. Il s'agissait principalement de chefs de département. Le chef du département financier, le chef du département logistique, le chef du département des achats. Et ceux-là étaient principalement les administrateurs de bases de données.
[00:05:10] Mais après un certain temps, les tâches par lots créant ces listes infinies de papier vert et blanc, prenaient de plus en plus de temps. Et puis, en tant qu'industrie, nous avons développé une nouvelle technologie.
[00:05:23] Et c'est ce que nous appelons la deuxième génération, le domaine des entrepôts de données. Nous avons donc mis au point une nouvelle technologie, un élément technologique très spécialisé et spécifique. Et nous avons créé une nouvelle équipe avec de nouveaux rôles de spécialistes pour gérer cette nouvelle technologie. Aujourd'hui, nous dirions que nous avons appliqué la manœuvre de la loi inverse de Conway. Nous avons donc créé une architecture, et en suivant cette architecture, nous avons eu un modèle organisationnel. Nous avons mis en place ces équipes spécialisées pour faciliter la vie des producteurs et des consommateurs.
[00:06:04] Vous pourriez dire, d'accord, nous avons mis en place une organisation faiblement couplée. Ce que vous avez réellement mis en œuvre est un proxy entre les producteurs et les consommateurs. Et ces équipes spécialisées bloquent la communication.
[00:06:20] Et puis nous avons inventé les lacs de données. Une nouvelle technologie géniale. Avec l'entrepôt de données, nous étions seulement capables de gérer des données structurées, maintenant nous sommes capables de gérer des données non structurées et des blobs.
[00:06:33] Mais l'anti-modèle organisationnel, l'organisation proxy entre les consommateurs et les producteurs est toujours là.
[00:06:42] Et regardons une organisation simplifiée de lac de données, vous verrez qu'elle n'est pas si simplifiée. Donc, c'est un domaine que je connais bien. Je viens du commerce électronique. Vous avez donc un domaine et ce sont six équipes e-commerce, vous avez une équipe responsable de la page d'accueil, de la page de liste, de la page de détail du produit et de la page de paiement. Et vous avez un domaine d'exécution. Ce sont donc des équipes, elles utilisent probablement différents modules d'un système SAP pour l'approvisionnement,
[00:07:15] acheter, stocker, manipuler le matériel, produire, vendre, gérer les retours.
[00:07:25] Ensuite, vous avez un département marketing. C'est juste un département, 27 personnes, 150 outils de logiciels en tant que service, tous partageant un seul compte. Vous avez l'équipe de direction, c'est sûr. Et vous avez un département de contrôle.
[00:07:41] Et vous avez un département financier.
[00:07:45] Et comme je l'ai dit, vous avez un lac de données. Et à quoi ressemblent les modèles de communication dans ces organisations et le flux analytique logique ? Personne ne se parle.
[00:07:59] Tout le monde parle au lac de données, et très souvent même les spécialistes du lac de données. Et ce sont des gens vraiment, vraiment compétents, très bons, mais même eux ne parlent pas aux producteurs ou aux consommateurs des données. Donc c'est vraiment faiblement couplé, mais c'est un modèle de communication brisé.
[00:08:18] Imaginez si quelqu'un du marketing a besoin de quelque chose d'une équipe de paiement du domaine e-commerce. Vers qui se tournent-ils ? S'ils s'adressent à quelqu'un de l'équipe de paiement et demandent des données spécifiques dont ils ont besoin pour une campagne marketing, quelle sera la réponse ? Oui, bien sûr, nous créons ces données. La personne du marketing demande alors, oui, où est-ce stocké dans le lac de données ? Et la réponse sera, je ne sais pas.
[00:08:42] À qui devrions-nous parler ? Nous ne savons pas, demandez à Pablo. Mais alors vous réaliserez que cette organisation centrale, mise en place comme un goulot d'étranglement, est submergée par les priorités, l'organisation marketing, il leur faudra généralement des semaines ou des mois pour obtenir la priorité pour le cas d'utilisation.
[00:09:01] Quel est un autre nom pour lac de données ?
[00:09:07] Beaucoup de gens les appellent des marais de données. Et c'est un peu injuste, mais je compare parfois les lacs de données à un marché aux puces. Et les trésors sont difficiles à trouver dans un lac de données comme dans un marché aux puces si vous y allez, c'est une grande salle avec beaucoup de parfois des trésors, parfois c'est juste une vieille pièce de merde, mais vous devez vraiment savoir où trouver les trésors dans ce lac de données et dans ce marché aux puces.
[00:09:37] Et ces parties, ces trois parties, ces pauvres trois parties, elles ont des problèmes. Pour les producteurs, les propriétaires d'applications transactionnelles. Monolithes, micro-services, produits commerciaux sur étagère ou logiciels en tant que service. Ils n'ont aucune incitation à partager des données. Leur incitation, je la trouve à livrer des fonctionnalités dans la plupart des organisations pour apporter de la valeur commerciale dans certaines organisations. Ils sont très déconnectés des consommateurs de leurs données.
[00:10:11] La qualité des données, en particulier à des fins analytiques, est très faible. Et ils ont de fortes compétences transactionnelles mais très faibles en analyse. Au milieu, nous avons l'équipe du lac de données.
[00:10:24] Et ils sont submergés par les sources de données. Généralement, les équipes de lacs de données sont en sous-effectif. Et ils sont même tellement dépassés par la demande des consommateurs. Très souvent, les lacs de données sont une configuration très complexe avec beaucoup de pipelines ETL.
[00:10:43] Ils ont des priorités constamment changeantes parce que les consommateurs veulent des données, le département financier veut des données. Et la direction veut des données et généralement qui gagne la direction ? Ils sont déconnectés des deux parties et ne sont souvent pas dignes de confiance. Et ce qui aggrave les choses, c'est qu'ils sont très spécialisés du point de vue d'un rôle orienté vers l'activité, donc très souvent ils ne sont pas généralistes, ils ne sont pas configurés de manière transversale.
[00:11:08] Et puis nous avons les consommateurs qui sont très souvent frustrés de n'avoir aucune priorité, aucune transparence, et qui ne tirent souvent pas beaucoup de valeur des données et des produits de données.
[00:11:20] Très souvent, ils n'ont pas beaucoup de compétences analytiques. Beaucoup de gens savent juste dans Excel comment additionner une colonne et changer la couleur d'une cellule. Mais ils ne connaissent pas vraiment les cohortes, la visualisation appropriée, la médiane ou d'autres compétences statistiques de base. Et ils sont déconnectés des producteurs.
[00:11:46] Il y a trois hypothèses classiques qui ont conduit à la configuration technique et organisationnelle actuelle dans les organisations de lacs de données. Et l'une est que les données doivent être centralisées. Et cela vient du fait que oui, nous avons acheté notre premier entrepôt de données, et depuis lors, nous centralisons nos données.
[00:12:04] La technologie, l'organisation et l'architecture sont monolithiques. C'est aussi une conséquence des premiers entrepôts de données et des modèles de données d'entreprise qui ont été créés dans les années 90 et au début des années 2000. Et la technologie pilote l'architecture et l'organisation. Et c'est faux. Mes convictions profondes sont
[00:12:27] Les données, le lac de données et le maillage de données doivent créer de la valeur pour les consommateurs. Et donc, nous avons besoin de qualité à la source, et la source n'est pas le lac de données, la qualité ce sont les systèmes transactionnels. Et les données proviennent de manière distribuée.
[00:12:47] Et donc, cela doit être géré de manière décentralisée. Et la technologie, l'architecture et les organisations sont également distribuées. Et l'organisation, la communication et les personnes, c'est cela qui pilote l'architecture et la technologie et non l'inverse.
[00:13:05] Et c'est pourquoi 2015, 16, 17. Les premières entreprises, principalement natives du numérique, ont appliqué les enseignements de leurs implémentations de microservices, de systèmes transactionnels distribués, au monde des données.
[00:13:22] Et ils ont retiré l'intermédiaire entre les producteurs et les consommateurs, et ici, on dirait qu'il n'y a qu'un producteur et un consommateur. En fait, si vous êtes responsable d'un service transactionnel dans une organisation de microservices ou d'une application, félicitations, dans une organisation de maillage de données, vous êtes maintenant responsable des données analytiques. Donc, vous avez beaucoup de producteurs.
[00:13:48] Mais ils ont supprimé l'intermédiaire et ont placé la responsabilité des données analytiques là où elle doit être, et elle se trouve entre les mains des producteurs, les équipes qui doivent partager les données.
[00:14:00] Et ils ont confié la responsabilité aux équipes qui utilisent les données. Et c'est sur la base de ces onduleurs et des premiers adoptants que le livre Data Mesh a été écrit. Et il y a toujours une troisième partie. Et c'est une plateforme. Et la plateforme est constituée d'équipes qui fournissent des outils et une infrastructure aux producteurs de données et aux consommateurs de données pour construire des produits de données.
[00:14:30] Et regardons une organisation de maillage de données simplifiée.
[00:14:34] Et le chemin de communication et le chemin du flux de données analytiques ont changé. Et comme vous le voyez, il n'y a pas de flux de données ni de flux de communication vers la plateforme de maillage de données. Et c'est parce qu'aucune donnée n'est réellement stockée dans un maillage de données centralisé. Plateforme. Il existe une variante, vous pouvez avoir d'un point de vue technique un lac de données centralisé, mais la responsabilité des différentes données stockées dans le lac de données incombe aux consommateurs et aux producteurs. Mais dans la vraie nature d'un maillage de données, les données sont stockées de manière distribuée à l'endroit où elles sont générées.
[00:15:14] Alors, regardons de plus près les producteurs de données.
[00:15:19] Et comme je l'ai dit, lorsque vous possédez des données transactionnelles ou un microservice transactionnel, félicitations, il y a de fortes chances que vous soyez maintenant aussi un producteur de données. Et j'ai choisi ici l'exemple de l'équipe de caisse, et l'équipe de caisse, ils avaient plusieurs microservices pour gérer la logique métier complexe d'un microservice. Et oui, ils avaient des bases de données OLTP. Certaines d'entre elles sont des bases de données SQL, d'autres des bases de données NoSQL, peu importe ce que l'équipe choisit comme meilleur stockage de données pour leur microservice. Mais dans un monde de maillage de données, ils doivent également maintenir un pipeline de données. Et ils doivent fournir des produits de données, des produits de données analytiques qui fournissent des données extraites, transformées et chargées à partir du service de paiement pour quiconque a besoin de ces données au sein de l'organisation. Et cela pourrait être simplement des interfaces OLAP standard avec une API. Ou il pourrait s'agir de modèles IAML très sophistiqués et de cas d'utilisation.
[00:16:27] Donc, cela pourrait être juste un rapport de ventes, combien d'articles ont été vendus aujourd'hui ? Et c'est juste un ensemble de données.
[00:16:37] Ou cela pourrait être un moteur de recommandation de produits. Basé sur des produits similaires, quand quelqu'un a acheté un certain article, quels étaient les produits similaires qu'il a achetés ? Et c'est alors un point d'accès qui peut être appelé par toute autre application.
[00:16:53] Et le produit de données, le terme que j'ai beaucoup utilisé. Ce n'est pas juste une API, ce n'est pas juste un point d'accès. Comme je l'ai dit, les premiers adoptants de l'infrastructure de maillage de données ont appliqué beaucoup de réflexions et de modèles mentaux issus du monde des microservices. Et aussi dans un monde de microservices, un microservice dans un système autonome est plus que de simples données ou du code. Et un produit de données dans un monde de maillage de données est constitué des données réelles, vous devez donc prendre soin de vos données, et bien sûr des métadonnées. Qui sait en quelque sorte ce que sont réellement les données.
[00:17:33] C'est le code dont vous avez besoin pour fournir les données, les transformer, les extraire et les charger. L'infrastructure, et certainement l'infrastructure en tant que code aussi. Et la configuration de votre infrastructure, de votre pipeline de données.
[00:17:50] Ce que nous voyons, et nous pouvons en débattre lors de la session de questions-réponses, c'est l'équipe de paiement.
[00:17:59] Ils ne sont pas vraiment capables de construire des produits de données. Oui, ils ont un chef de produit et des développeurs de logiciels en T ou en V qui peuvent, même dans une configuration de type "vous le construisez, vous le gérez", créer une application mobile, une page web, un front-end, un back-end, des bases de données et une infrastructure dans le cloud. Et maintenant, nous leur demandons de créer également des produits de données, des ensembles de données, des recommandations de produits AML. C'est difficile. Et c'est pourquoi nous proposons que vous amélioriez vos équipes de produits traditionnelles avec deux nouveaux rôles. Et l'un est un propriétaire de produit de données, et c'est une personne très axée sur les affaires. Et cette personne comprend le contexte de l'équipe ou du département, les processus métier réels qui se déroulent. Les données qui résultent du processus métier, comment les données transactionnelles de ces processus métier sont stockées dans le magasin de données transactionnelles. Mais ils comprennent aussi les besoins des clients et des consommateurs des données. Donc, ils élaborent une feuille de route et une vision pour le produit de l'équipe de paiement.
[00:19:10] Ils doivent être de bons communicateurs car le maillage de données met l'accent sur la communication directe entre les équipes de production et les équipes de consommation. Et nous voyons aussi que, euh, les équipes reçoivent un ingénieur de données supplémentaire. Au début, plus tard, ce que nous proposons et ce que nous constatons que les organisations qui réussissent sont capables de faire, c'est que leurs ingénieurs transactionnels traditionnels en forme de T sont également capables de développer des compétences analytiques et de construire des parties du produit.
[00:19:41] Mais au début, injectez cet ensemble de compétences supplémentaires dans vos équipes. L'ingénieur de données travaille avec les développeurs d'applications pour mapper les données transactionnelles aux produits de données analytiques. Et cela doit être un généraliste dans la sphère des données. tailles, communication directe entre les équipes de production et les équipes consommatrices. Et nous voyons également que les équipes obtiennent un ingénieur de données supplémentaire au début. Plus tard, ce que nous proposons et ce que nous voyons que les organisations qui réussissent sont capables de faire, c'est que même les ingénieurs traditionnels en forme de T
[00:19:34] les ingénieurs transactionnels sont également capables de développer des compétences analytiques et de construire des parties du produit. Mais au début, injectez cet ensemble de compétences supplémentaires dans vos équipes.
[00:19:47] L'ingénieur de données, il travaille avec les développeurs d'applications pour mapper les données transactionnelles aux produits de données analytiques. Et cela doit être un généraliste dans le domaine des données.
[00:20:02] Alors, quelles sont les responsabilités d'une telle équipe de production de données ?
[00:20:08] Chaque équipe gère les données et publie son produit de données. Ainsi, l'équipe de caisse publie ses données. Ce que je vois chez certains clients, c'est qu'ils ont ce domaine e-commerce et ensuite ils créent une équipe supplémentaire à l'intérieur du domaine e-commerce et c'est l'équipe data. Et c'est bien, mais vous avez toujours une organisation proxy maintenant dans votre domaine e-commerce. Et ils ne sont pas très familiers avec les transactions réelles qui se déroulent dans les équipes. Alors, améliorez et encouragez vos équipes transactionnelles actuelles à produire des produits de données.
[00:20:44] Ce qui est également un aspect important, c'est que les équipes de producteurs de données décident de la technologie qu'elles veulent utiliser.
[00:20:53] Et pensez à l'organisation que j'ai présentée avec le domaine e-commerce. Il pourrait s'agir d'une architecture basée sur les microservices, basée sur Java, la technologie cloud, des bases de données no SQL. Pourquoi le domaine d'exécution utilise un système SAP. Et pourquoi ces deux équipes, avec des architectures transactionnelles et des technologies totalement différentes, devraient-elles utiliser la même technologie de données ? C'est tout à fait acceptable, tant qu'elles respectent toutes la macro-architecture et la pile technologique de l'organisation globale, qu'elles choisissent leur propre technologie. Et chaque produit fournit des interfaces pour permettre à d'autres d'interagir avec le produit. Ils fournissent des métadonnées et l'aspect le plus important est que le produit de données doit apporter de la valeur commerciale. Et ne construisez pas un produit de données si vous n'avez pas de consommateur pour celui-ci.
[00:21:46] Alors, et les consommateurs, À titre d'exemple, j'ai choisi l'équipe marketing, soit les 27 personnes avec les 150 outils. Et actuellement, ils utilisent beaucoup de données, ils utilisent le trafic des médias sociaux, ils utilisent la segmentation des utilisateurs et ils utilisent leurs produits de données de paiement. Et dans une organisation de lac de données, un ingénieur de données et un scientifique de données de l'organisation du lac de données, s'ils avaient le temps, aideraient l'équipe marketing à créer des outils d'analyse, d'IA et de ML nécessaires dans le domaine du marketing. Ici, même les producteurs, l'organisation marketing, l'organisation financière, l'organisation de contrôle et même l'organisation e-commerce, qui est un producteur, est probablement aussi un consommateur de certaines données. Mais chaque consommateur acquiert également de nouvelles compétences et un nouveau rôle. Ainsi, il y a le même rôle de propriétaire de produit de données avec les mêmes compétences et les mêmes responsabilités. Et dans le domaine des consommateurs de données, vous avez probablement plus besoin de l'échelle d'un scientifique de données que d'un ingénieur de données. Euh parce que là, vous avez besoin de quelqu'un qui peut travailler avec l'équipe commerciale pour construire des informations et des produits de données pertinents. Et vous avez encore besoin de quelqu'un qui soit un généraliste dans le domaine des données. Ainsi, le « I » dans la forme en T est davantage un scientifique de données, mais il possède également des compétences d'ingénieurs de données.
[00:23:17] Et quels sont les produits de données grand public dans le domaine du marketing ? Il pourrait s'agir d'un ensemble de données pour la prédiction de l'attrition. Il pourrait s'agir d'un ensemble de données sur le clustering de clients, utilisé dans toute l'organisation pour le marketing ciblé par e-mail, dans le contrôle et également dans les rapports au conseil d'administration sur la segmentation des clients. Mais il pourrait également s'agir d'un point de terminaison pour des décisions de tarification dynamique en temps réel. Ou il pourrait simplement s'agir d'un tableau de bord sur l'analyse du panier d'achat.
[00:23:52] Nous avons donc une équipe de caisse, qui est un producteur de données, et nous avons l'équipe marketing, qui est un consommateur. Et j'ai dit, très facilement, nous leur donnons des rôles supplémentaires et nous leur donnons une capacité supplémentaire et ensuite ils pourront construire des produits de données avec leur propre technologie. Ce n'est pas si facile. Parce que l'analyse n'est pas une compétence essentielle de ces équipes.
[00:24:16] Et c'est là que nous introduisons la plateforme de maillage de données.
[00:24:23] Et la plateforme de maillage de données fournit des outils et une infrastructure, du conseil et de la formation, parfois aussi des capacités et des ressources supplémentaires. Mais c'est aussi le centre névralgique pour faciliter et modérer une approche de gouvernance et de sécurité fédérée. Et la mission, de mon point de vue, d'une plateforme de maillage de données est de rendre la vie des producteurs et des consommateurs simple, efficace et sans stress. Il ne s'agit pas de réduire les coûts, il ne s'agit pas de définir des normes technologiques. L'objectif principal est de rendre la vie des producteurs et des consommateurs simple, efficace et sans stress. Et sans stress inclut bien sûr les directives de sécurité. Et la sécurité en tant que service et la sécurité en tant que code intégrées dans l'infrastructure de données et les outils que la plateforme fournit.
[00:25:12] Alors, quels sont les outils courants que personne n'a besoin d'avoir deux fois dans une organisation ?
[00:25:16] Donc, les produits typiques qu'une plateforme de maillage de données construit sont les mécanismes de contrôle d'accès. Et vous devez avoir un mécanisme de contrôle d'accès. Personne ne devrait avoir accès à toutes les données de votre organisation.
[00:25:28] Ils fournissent la surveillance et la facturation, ils fournissent des pipelines CICD. Ils fournissent des environnements préparés pour les scientifiques de données et les ingénieurs de données. Ils fournissent un catalogue de données. Mais de mon point de vue, dans de nombreuses organisations, les catalogues de données sont surestimés. Euh dans de nombreuses organisations, il y a un espoir, c'est comme un annuaire téléphonique. Vous recherchez juste un morceau de données et ensuite vous lisez ou quelques métadonnées et vous savez alors vraiment quelle est la source de données appropriée. Mais ce n'est pas si facile que ça. Pour moi, un catalogue de données est plutôt un indice dans la bonne direction pour savoir à quelle équipe je devrais parler. Donc, ne surinvestissez pas dans un catalogue de données. Et ils fournissent des informations sur la gestion des coûts. Chaque équipe est bien sûr responsable de son produit de données et de son coût, mais vous devez consolider votre facture globale en un seul endroit.
[00:26:18] Et la partie essentielle également de la plateforme est l'éducation et le conseil des équipes.
[00:26:27] J'ai dit que les équipes peuvent choisir leur propre technologie. Mais vous devez être prudent avec cet aspect.
[00:26:35] Alors, ce qui se passe habituellement quand vous donnez aux équipes l'autonomie, l'autonomie de choisir leurs propres piles technologiques par exemple.
[00:26:44] Vous découplez votre organisation et la performance des équipes augmente. Et la performance de l'organisation augmente également. Mais seulement jusqu'à un certain point.
[00:26:56] Il y a un point idéal dans tout modèle d'exploitation et dans chaque organisation où vous devez trouver l'équilibre entre les besoins de l'organisation globale. Et les besoins des équipes individuelles.
[00:27:08] Et l'un des points idéaux est de savoir quelles technologies nous voulons vraiment avoir ici.
[00:27:13] Imaginez dans un monde de microservices où chaque équipe est autorisée à choisir son propre langage de programmation. C'est très cool pour l'équipe, mais c'est un cauchemar pour l'organisation.
[00:27:23] En fonction de votre modèle de propriété du code et d'échange de code. Mais vous devez créer un alignement. Et cela fait partie de la plateforme. Et la plateforme n'a pas d'architecte de données qui définit la macro-architecture du paysage de maillage de données et la pile technologique. Mais les personnes de la plateforme, les technologues seniors de la plateforme, ils fournissent une plateforme de communication et un foyer où les technologues seniors des équipes de production et de consommation du maillage de données peuvent se rencontrer et ils co-créent et définissent la stratégie de la plateforme de maillage de données, la macro-architecture et la pile technologique.
[00:28:04] Mais la plateforme est aussi le hub de gouvernance central et vous avez besoin, dans le monde des données, d'une gouvernance en place.
[00:28:15] Mais en substance, la plateforme aide l'organisation, l'organisation du maillage de données à fonctionner en douceur.
[00:28:23] Alors, comment ces parties collaborent-elles, co-créent-elles et s'alignent-elles ? Et c'est nécessaire parce que c'est un maillage de données. C'est faiblement couplé, fortement aligné, mais ce n'est pas autonome.
[00:28:36] Donc, un aspect que nous voyons que les organisations et une entreprise de la communauté mettent en œuvre est d'avoir un conseil de gouvernance fédéré qui augmente l'acceptation. Donc nous avons cette organisation.
[00:28:52] Et puis vous mettez en œuvre un conseil de gouvernance fédéré, vous pouvez l'appeler comme vous voulez. C'est un conseil de maillage de données, c'est une communauté de maillage de données, mais ce n'est pas seulement le partage des connaissances, mais comme je l'ai dit. Chaque domaine envoie un technologue senior dans ce conseil, et ils co-créent la stratégie de la plateforme de maillage de données, ils définissent la pile technologique, les politiques et les priorités. Et cela augmente la probabilité que les équipes, les équipes de maillage de données, les producteurs et les consommateurs acceptent et adaptent les outils fournis par la plateforme. Parce que c'est le plus grand problème avec la plateforme. Le syndrome du 'pas inventé ici'. Que les équipes et c'est vrai aussi dans les systèmes transactionnels et les plateformes de microservices que les équipes ne l'acceptent pas. Ce qui stimule vraiment le taux d'adoption, c'est la rotation des postes. Donc, dans mon organisation chez Outscout, ce que nous avons fait avec notre plateforme, chaque trimestre, nous faisions pivoter un tiers des ingénieurs de plateforme hors de la plateforme vers les équipes de fonctionnalités pour libérer des places dans la plateforme. Et pour que les ingénieurs de plateforme doivent manger leur propre nourriture pour chien, utiliser leurs propres services de données.
[00:30:04] Et nous ferions pivoter des volontaires dans les équipes de plateforme.
[00:30:08] Pour qu'ils construisent la prochaine itération, la prochaine version d'un service de plateforme. Ce que vous créez également avec cette configuration est un réseau. Entre les personnes des équipes de fonctionnalités, les réseaux informels et les personnes de la plateforme. Et cela vous aide à construire la prochaine version d'un service qui sera adoptée.
[00:30:33] Et bien sûr, vous devriez mettre en œuvre une communauté de pratique. Où les gens peuvent se rencontrer, partager leur expérience sur la technologie qu'ils utilisent, sur les cas d'utilisation qu'ils implémentent, sur les informations qu'ils génèrent.
[00:30:46] Alors, par où commencer avec une organisation de maillage de données ?
[00:30:53] La plupart ou toutes, toutes les organisations que je connais sont actuellement des organisations de données centralisées.
[00:31:02] Et la beauté d'un maillage de données est comparée à une implémentation de lac de données. Les projets de lac de données sont généralement des configurations big bang où vous avez besoin de grands projets qui durent deux ou trois ans pour implémenter un lac de données. Avec le maillage de données et la nature distribuée d'un lac de données, vous pouvez avoir une approche beaucoup plus fluide, plus incrémentale et plus itérative. Donc, dans notre exemple, vous pourriez commencer par ce cas d'utilisation de l'équipe marketing qui veut avoir des données de l'équipe de caisse. Et vous pourriez commencer à extraire les données pour ce cas d'utilisation du lac de données central et, selon le produit de données, le stocker de manière décentralisée dans la même pile technologique, soit comme l'équipe de caisse, soit comme le premier produit de données dans le domaine marketing. Et pendant que vous faites cela,
[00:31:52] Pendant que vous créez ce cas d'utilisation dans une configuration de maillage de données entre ces deux parties, vous créeriez également votre première petite équipe de plateforme pour un maillage de données.
[00:32:03] Ainsi, vous auriez toujours votre lac de données, mais vous auriez la première petite équipe de plateforme de maillage de données créant la première itération et la première version d'une infrastructure qui supporte le tout premier cas d'utilisation entre l'équipe marketing et l'équipe de caisse.
[00:32:23] Ce que j'ai également mentionné auparavant, c'est que vous pouvez avoir une configuration où, d'un point de vue technique, vous avez un lac de données. Vous stockez donc toujours toutes vos données dans un magasin de données technique centralisé. Mais du point de vue des responsabilités, comme un catalogue de services dans un monde de microservices, il est très clair quelle pièce de données, quel seau, quel catalogue de métadonnées relève de la responsabilité de quelles équipes. Donc, sans avoir à faire de changement, vous pourriez commencer votre migration vers le maillage de données d'un point de vue technique juste avec un changement organisationnel, en ayant une responsabilité claire pour vos données du lac de données avec les équipes qui les consomment ou les produisent.
[00:33:08] Et ensuite, vous auriez toujours des données stockées dans un lac de données, écrites et lues, mais d'un point de vue communication, vous auriez une collaboration et une communication entre les producteurs et les consommateurs.
[00:33:23] Et il y a quatre étapes que vous devez suivre pour décentraliser votre lac de données. Donc, vous devez vous assurer que dans votre organisation globale, vous avez une structure axée sur le domaine. Et cela ne se limite pas aux organisations de microservices, vous pouvez avoir des modèles de collaboration basés sur le domaine dans toutes les parties de votre organisation. Vous devez établir des rôles clés et vous devez vous assurer que des incitations sont en place pour aligner les équipes dans la direction commune. Vous devez transférer la propriété aux systèmes source et aligner les formats de données. Et vous avez besoin de ce conseil de gouvernance fédéré. Sans un mécanisme pour créer un alignement, votre initiative de maillage de données échouera.
[00:34:06] Ce que je crois, c'est que de nombreuses organisations finiront par adopter une configuration hybride de lac de données en maillage. Parce qu'il n'y a pas de solution unique qui convienne à tout le monde. Et vous aurez certains domaines qui ont ce style de maillage de données direct et vous aurez toujours d'autres organisations ou des parties de votre organisation qui stockent des pièces dans un lac de données. Mais c'est, c'est tout à fait bien. Et c'est l'une des beautés de l'approche du maillage de données, c'est que vous n'avez pas besoin d'avoir une solution unique pour tous les produits de données et de données analytiques dans toute votre organisation. Vous pouvez appliquer différents modèles opérationnels, différents modes de travail et vous pouvez appliquer différentes configurations technologiques dans votre organisation.
[00:34:51] Mais quoi que vous fassiez, Lorsque vous appliquez un changement, ne faites pas bouillir l'océan. Alors, commencez simplement à implémenter un maillage de données, commencez par votre premier cas d'utilisation, faites face à l'incertitude et il y a de l'incertitude.
[00:35:05] Mais ensuite, observez, orientez, décidez et agissez juste dans la bonne direction. Essayez quelque chose, mesurez vos progrès et ensuite adaptez-vous.
[00:35:15] Alors, merci beaucoup. Comme je l'ai dit, nous sommes un peu en avance, des questions ?
[00:35:51] Euh si nous pensons aux euh différents types d'équipes, euh en termes de topologie d'équipe, euh où se situe le Conseil de Gouvernance Fédéré ?
[00:36:07] Est-ce une sorte d'équipe d'habilitation ou pas du tout ?
[00:36:14] Une partie des responsabilités de la plateforme est l'habilitation. Et vous pourriez, quand vous pensez à une grande plateforme, avoir des personnes dédiées s'occupant uniquement de l'habilitation et de l'activation, et alors vous pourriez appeler une équipe de cinq, par exemple, si une plateforme de données est une équipe d'activation. Je ne pense pas que j'implémenterais une équipe d'habilitation dédiée, au début peut-être, mais plus tard je n'aurais pas l'équipe de plateforme de données vraiment comme une équipe d'habilitation.
[00:36:49] Oui, merci, merci pour la présentation. Euh, j'ai assisté à deux présentations aujourd'hui où on nous a dit que nous devions réduire le lien de communication entre toutes les équipes au sein d'une organisation et j'ai un peu l'impression que nous faisons le contraire avec ce que vous avez présenté en passant d'un lac de données où la communication est entre une équipe et une équipe de données. à cette structure de maillage de données avec beaucoup de communications différentes.
[00:37:24] Oui, donc chaque communication est une dépendance et chaque dépendance vous ralentit. Mais lorsque vous avez une dépendance et que vous avez évidemment besoin d'une certaine communication et dépendance entre un consommateur et le producteur, avoir une dépendance entre deux parties est préférable à avoir une dépendance entre trois parties ou dans le cas de nombreuses organisations de lacs de données, vous avez une dépendance entre deux parties, mais l'une ne répond guère ou elles ne sont pas vraiment familières avec le cas d'utilisation réel dans les données réelles. Et c'est pourquoi la communication est alors lente et fastidieuse. Merci.
[00:38:08] Oui, euh merci pour la présentation. Euh, disons que j'ai un cas d'utilisation, je veux agréger les transactions pour mes clients à partir de différents services gérés dans différents services. Comment gérer ce cas d'utilisation avec le maillage de données ? Qui sera responsable de l'agrégation ?
[00:38:32] Vous avez dit la plateforme.
[00:38:34] Ah oui, transformer.
[00:38:35] Oui, cela dépend, cela dépend. Donc, beaucoup de clients avec qui je parle ont alors le réflexe de le mettre dans la plateforme et de proposer un simple produit d'agrégation.
[00:38:47] Et dans de très rares cas, il y a une justification pour un simple service d'agrégation, mais dans de nombreux cas que j'ai vus d'un point de vue implémentation, ces services d'agrégation sont devenus trop complexes.
[00:39:02] Euh et ils ont trop de conceptions spéculatives et ils couvrent trop de cas d'utilisation pour qui pourrait en avoir besoin à l'avenir. Et c'est pourquoi mon conseil général, le consommateur qui a besoin d'agréger des données de différentes sources effectue cette agrégation et fournit un produit de données qui agrège les services.
[00:39:22] Comme un pipeline de données, puis dans la deuxième étape, il crée ses cas d'utilisation. Et puis ce qui arrive parfois quand c'est bien implémenté, c'est que ce service d'agrégation, ce produit de données, ce produit de données d'agrégation est également utilisé par d'autres équipes. Et ensuite, vous devez décider qui prend la responsabilité de ce service d'agrégation. Euh là, ça commence à devenir délicat. Et si vous avez une très grande organisation, alors c'est un candidat euh comme vous avez avec des systèmes complexes et des topologies d'équipe, où vous avez alors une équipe dédiée soit dans le domaine du consommateur, soit du producteur qui s'occupe juste de ce service d'agrégation. Mais ne le faites pas trop tôt. Ensuite, dans la deuxième étape, cela crée ses cas d'utilisation. Et puis ce qui arrive parfois quand c'est bien implémenté, c'est que ce service d'agrégation, ce produit de données, le produit de données d'agrégation est utilisé par d'autres équipes également. Et ensuite, vous devez décider qui prend la responsabilité de ce service d'agrégation. Alors ça commence à devenir délicat et si vous avez une très grande organisation, alors c'est un candidat comme vous avez avec des systèmes complexes dans les topologies d'équipe où vous avez alors une équipe dédiée soit dans le domaine du consommateur du producteur de produits qui s'occupe juste de ce service d'agrégation. Mais ne le faites pas trop tôt.
[00:40:11] Euh, pour autant que j'aie compris, c'est comme s'il y avait une réplication des données entre ce qui est produit et ce qui est consommé, vous savez, quand les données sont transférées d'un système à un autre. pouvez-vous estimer le coût total de cela ? Parce que si les données sont répliquées presque partout, c'est c'est c'est comme.
[00:40:35] Alors, la première réponse est que le stockage est bon marché. Euh, mais le deuxième point est aussi que dans un lac de données, euh et peut-être même dans les lacs de données, euh vous avez vous avez euh plusieurs versions de vos données. Euh, donc je ne suis pas vraiment sûr que le data mesh duplique vraiment plus de données. Je dirais que parce qu'un data mesh est beaucoup plus clair, qui utilise quelles données de qui et a la propriété locale et la supervision de l'architecture réelle du produit de données. Et la responsabilité des coûts, parce que qui est responsable du coût d'un lac de données ? C'est l'autre organisation du lac de données. Ce n'est pas le consommateur, c'est le producteur, mais avec cette propriété et cette responsabilité des produits de données, vous mettez aussi la responsabilité du coût entre les mains des consommateurs et des producteurs. Et c'est pourquoi généralement, euh la redondance des données est moindre que dans un lac de données. Mais cela dépend de la culture de l'organisation réelle.
[00:41:35] D'accord, merci.
[00:41:45] Euh vous avez montré une diapositive avec euh la notion d'adressabilité, de confiance, de découverte, d'interopérabilité et celles que j'ai oubliées. Euh, est-ce que la notion de données, oui, merci. La notion de contrat de données à la frontière d'un produit de données, euh, fait-elle partie de la réponse ?
[00:42:12] Oui, ça l'est. Oui, oui, donc vous avez clairement besoin d'avoir un contrat de données sous forme écrite et sous forme technique pour que ce soit évident pour tout le monde dans l'organisation.
[00:42:23] Euh, peut-on considérer qu'il existe une norme de facto pour les contrats de données ? Comme euh celui que PayPal a publié, ou est-ce trop tôt ?
[00:42:37] Je pense que c'est trop tôt.
[00:42:54] J'ai une question concernant la qualité des données. Parce que qui est responsable de la qualité des données ? Est-ce le, nous disons, le producteur. Ou parce que nous discutons du contrat entre le consommateur et le producteur. C'est qui doit livrer la qualité et si vous avez comme une chaîne de responsabilités entre différents producteurs et consommateurs, comment surveillez-vous la qualité de bout en bout, je dirais ?
[00:43:30] Je ne suis pas sûr que vous puissiez vraiment surveiller la qualité, mais il est clair que la qualité commence à la source. Donc, le propriétaire des systèmes transactionnels et des services transactionnels qui construisent maintenant des produits de données rendant les données transactionnelles disponibles en tant que produit analytique pour les consommateurs, doit veiller à la qualité de ce produit de données. Et s'ils changent quelque chose ou si quelque chose change dans le processus métier et dans les données transactionnelles, ils doivent veiller à ce que la qualité des données analytiques, du produit de données, soit en phase avec tous les changements du monde transactionnel. Donc, si vous recevez une user story et que vous devez modifier quelque chose dans votre microservice, vous devez également modifier votre produit analytique dans le cadre de la même story. Et par conséquent, vous devez informer les consommateurs de votre produit de données du changement. Et j'espère que vous ferez un changement qui ne casse pas, comme vous le faites avec d'autres API et services, tous les consommateurs. Mais néanmoins, si un consommateur de données crée un rapport à partir de données, il doit également s'assurer que les données qu'il utilise dans ce rapport sont également correctes.
[00:44:59] Euh, vous avez présenté une diapositive avec une limitation des lacs de données. Quel genre de limitation voyez-vous dans le data mesh ?
[00:45:09] Alors, quand le microservice est apparu, Martin Fowler a dit qu'il fallait être aussi grand que ça pour les microservices. Et c'était une métaphore tirée de ces montagnes russes dans les parcs de loisirs américains où il faut être assez grand pour euh oui, utiliser ces montagnes russes dangereuses. La même chose est vraie avec le data mesh.
[00:45:33] Euh, donc vous devez avoir une certaine maturité dans votre organisation pour être capable de faire fonctionner une telle configuration distribuée avec une responsabilité distribuée, des canaux de communication distribués avec un alignement sur la technologie, avec liberté et autonomie. Mais et c'est pour moi la beauté du data mesh que, en tant que communauté, en tant qu'industrie, nous avons beaucoup appris au cours des 10 dernières années, les microservices ont, selon la façon dont on les compte, une décennie ou une décennie et demie, nous avons beaucoup appris à gérer des organisations distribuées et décentralisées. Et tous les apprentissages s'appliquent au data mesh. Donc ce n'est pas aussi nouveau, aussi effrayant que beaucoup d'organisations le pensent. Mais oui, ce n'est pas pour les débutants.
[00:46:33] Peut-être moi. J'ai une question. Dernière question. Oui, vous parlez d'un propriétaire de produit de données. Donc de mon côté, je travaille principalement sur des équipes de développement logiciel classiques, donc avec le backend, le front end et un product owner normal, la plupart du temps les personnes chargées des données sont quelque part dans l'entreprise. Euh, quand vous oui, quand vous parlez du propriétaire du produit de données, est-ce que cela signifie qu'ils viennent dans notre équipe ? Et comme j'ai une équipe avec un product owner normal et un product owner de données, ou sont-ils une autre équipe mais dans mon domaine ? Comment ça fonctionne exactement ?
[00:47:09] Votre équipe, votre équipe reçoit deux nouveaux membres d'équipe et ce sont des membres d'équipe à temps plein. Et l'un est un propriétaire de produit de données, et l'autre est un ingénieur de données. Et cet ingénieur de données résout et construit des produits de données au début, mais il vous forme aussi pour que vous soyez capable, sur une perspective d'un ou deux ans, comme vous êtes capable en tant que développeur full stack de développer le front-end et le back-end pour aussi euh gérer la plupart des cas d'utilisation des données dans votre périmètre et domaine limités.
[00:47:43] Cela signifie-t-il aussi que les membres de l'équipe devraient peut-être commencer à apprendre des choses sur les données afin qu'il n'y ait pas qu'une seule personne experte en données ?
[00:47:54] Exactement.
[00:47:55] Donc nous voulons des personnes Dev Sec Ops data et etc, etc.
[00:47:59] Oui, oui, oui. Votre forme en T s'élargit et elle s'élargit de plus en plus. Et c'est pourquoi vous avez besoin, et c'est pourquoi la plateforme doit également fournir des outils et pourquoi, et ce n'est pas seulement parce que je viens d'AWS, euh les services natifs du cloud et les services gérés. Ils réduisent la charge cognitive pour une grande partie de cette gestion de l'infrastructure et ensuite vous pouvez vraiment vous occuper de l'aspect métier des cas d'utilisation transactionnels et des cas d'utilisation des données. Mais vous devriez euh utiliser de moins en moins d'efforts sur la seule technologie.
[00:48:42] Existe-t-il des outils existants qui prennent déjà en charge le data mesh ?
[00:48:47] Oui, tous les outils utilisés pour les lacs de données peuvent également être utilisés pour le data mesh.
[00:48:52] D'accord.
[00:48:53] Il n'y a rien de spécifique, c'est juste la même technologie mais appliquée différemment, distribuée.
[00:49:00] Et n'achetez pas un data mesh.
[00:49:04] Et avez-vous vu cela fonctionner en dehors d'AWS ?
[00:49:09] Pardon ?
[00:49:10] Avez-vous vu cela fonctionner en dehors de.
[00:49:12] Oui, oui, oui. Donc vous voyez cela avec Azure et GCP également, vous pouvez également l'implémenter sur site mais c'est beaucoup plus difficile pour les producteurs et les consommateurs de données avec euh oui la gestion des outils open source et tout. Donc la charge cognitive et la courbe d'apprentissage sont beaucoup plus élevées.
[00:49:33] Et quelles ont été les principales difficultés que vous rencontrez toujours lorsque vous essayez de passer à ce genre de ?
[00:49:40] Oui, les gens ne veulent pas apprendre. Je suis un développeur front-end, je ne veux pas m'occuper des données, je suis un développeur back-end, je ne veux pas m'occuper des données, je suis un développeur de base de données, je ne veux pas m'occuper des données. D'accord. Euh oui, c'est s'adapter au changement. Et c'est toujours un équilibre dans votre modèle d'exploitation. Donc, bien sûr, vous rendez la tâche un peu plus difficile pour les équipes en ce qui concerne la construction de certaines choses, mais d'un point de vue global, d'un point de vue organisationnel, il est beaucoup plus facile pour l'organisation de tirer parti des données. Mais je n'ai pas, je ne voulais pas critiquer les data lakes, donc il y a beaucoup d'implémentations de data lakes qui répondent très bien aux besoins de leurs organisations. Donc, les deux sont des modèles architecturaux valides et des modèles organisationnels pour l'organisation. Et chacun a des forces et des faiblesses. Mais je suis un peu fan du data mesh.
[00:50:40] Bien. Merci beaucoup. Merci à tous.

Transcription (Traduit)