Intelligence des données

Le voyage vers le Data Mesh - Partie 3 - Créer vos premiers produits de données

Actian Corporation

22 avril 2024

Bien que la littérature sur le maillage des données soit abondante, elle décrit souvent un état final, mais rarement la manière d'y parvenir dans la pratique. La question se pose alors :

Quelle approche adopter pour transformer la gestion des données et mettre en place un maillage de données ?

Dans cette série d'articles, vous trouverez un extrait de notre Guide pratique du maillage de données, dans lequel nous proposons une approche pour lancer un parcours de maillage de données dans votre organisation, structurée autour des quatre principes du maillage de données (propriété et architecture de données décentralisées orientées vers le domaine, données en tant que produit, infrastructure de données en libre-service en tant que plateforme, et gouvernance informatique fédérée) et en tirant parti des ressources humaines et technologiques existantes.

Tout au long de cette série d'articles, et afin d'illustrer cette approche pour construire les bases d'un maillage de données réussi, nous nous appuierons sur un exemple : celui de l'entreprise fictive Premium Offices - une société d'immobilier d'entreprise dont l'activité consiste à acquérir des biens immobiliers pour les louer à des entreprises.

Dans les premiers articles de la série, nous avons identifié les domaines, défini un premier cas d'usage et constitué l'équipe chargée de son développement. Il est maintenant temps de passer au deuxième principe du maillage de données, "les données en tant que produit", en développant les premiers produits de données.

L'approche de la réflexion sur les produits de la maille

Au cours de la dernière décennie, les domaines ont souvent développé une culture du produit autour de leurs capacités opérationnelles. Ils proposent leurs produits au reste de l'organisation sous la forme d'API qui peuvent être consommées et composées pour développer de nouveaux services et applications. Dans certaines organisations, les équipes s'efforcent d'offrir la meilleure expérience possible aux développeurs qui utilisent les API de leur domaine : recherche dans un catalogue global, documentation complète, exemples de code, environnements "bac à sable", niveaux de service garantis et contrôlés, etc.

Ces API sont ensuite gérées comme des produits qui naissent, évoluent dans le temps (sans rupture de compatibilité), s'enrichissent et finissent par être obsolètes, généralement remplacées par une version plus récente, plus moderne et plus performante.

Le maillage des données propose d'appliquer cette même approche de réflexion sur les produits aux données partagées par les domaines.

Caractéristiques des produits de données

Dans certaines organisations, cette culture axée sur le produit est déjà bien établie. Dans d'autres, elle devra être développée ou introduite. Mais ne nous y trompons pas :

Un produit de données n'est pas un nouvel artefact numérique nécessitant de nouvelles capacités techniques (comme un produit API). Il s'agit simplement du résultat d'une approche particulière de gestion des données exposée par un domaine au reste de l'organisation.

La gestion des API en tant que produit n'a pas nécessité de percée technologique : les intergiciels existants ont très bien fait le travail. De même, les produits de données peuvent être déployés sur des infrastructures de données existantes, quelles qu'elles soient. Techniquement, un produit de données peut être un simple fichier dans un lac de données avec une interface SQL ; un petit schéma en étoile, complété par quelques vues facilitant l'interrogation, instancié dans une base de données relationnelle ; ou encore une API, un flux Kafka, un fichier Excel, etc.

Un produit de données n'est pas défini par la manière dont il est matérialisé, mais par la manière dont il est conçu, géré et gouverné, ainsi que par un ensemble de caractéristiques permettant son exploitation à grande échelle au sein de l'organisation.

Ces caractéristiques sont souvent résumées dans l'acronyme DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure).

En outre, l'obtention d'un produit de données DATSIS ne nécessite pas d'investissements importants. Il s'agit de définir un ensemble de conventions globales que les domaines doivent respecter (dénomination, protocoles pris en charge, gestion des accès et des permissions, contrôles de qualité, métadonnées, etc.) La mise en œuvre opérationnelle de ces conventions ne nécessite généralement pas de nouvelles capacités technologiques - les solutions existantes sont généralement suffisantes pour démarrer.

Le catalogue constitue toutefois une exception. Il joue un rôle central dans le déploiement du maillage de données en permettant aux domaines de publier des informations sur leurs produits de données et aux consommateurs d'explorer, de rechercher, de comprendre et d'exploiter ces produits de données.

Bonnes pratiques pour la conception de produits de données

La conception d'un produit de données n'est certainement pas une science exacte - il pourrait n'y avoir qu'un seul produit, ou trois ou quatre. Pour guider ce choix, il est une fois de plus utile de s'inspirer des meilleures pratiques des architectures distribuées - un produit de données doit.. :

  • Avoir une responsabilité unique et bien définie.
  • Avoir des interfaces stables et assurer la compatibilité ascendante.
  • être utilisables dans plusieurs contextes différents et donc support polyglotisme.

Expérience de développeur de produits de données

L'expérience du développeur est également un aspect fondamental du maillage des données, avec l'ambition de faire converger le développement de produits de données et le développement de services ou de composants logiciels. Il ne s'agit pas seulement d'être convivial pour les ingénieurs, mais aussi de répondre à une certaine rationalité économique :

La décentralisation de la gestion des données implique que les domaines disposent de leurs propres ressources pour développer des produits de données. Dans de nombreuses organisations, l'équipe centralisée chargée des données n'est pas assez importante pour support équipes distribuées. Pour assurer le succès du maillage des données, il est essentiel de pouvoir puiser dans le vivier des ingénieurs logiciels, qui est souvent plus important.

L'état de l'art en matière de développement logiciel repose sur un niveau élevé d'automatisation : allocation déclarative des ressources d'infrastructure, tests unitaires et d'intégration automatisés, construction et déploiement orchestrés via des outils CI/CD, flux de travail Git pour la gestion des sources et des versions, publication automatique de la documentation, etc.

Le développement des produits de données doit converger vers cet état de l'art - et selon la maturité de l'organisation, ses équipes et sa pile technologique, cette convergence prendra plus ou moins de temps. La bonne approche consiste à automatiser le plus possible en utilisant les outils existants et maîtrisés, puis à identifier les opérations qui ne sont pas automatisées pour intégrer progressivement des outils supplémentaires.

En pratique, voici ce qui constitue un produit de données :

  1. Le code d'abord - Pour les pipelines qui alimentent le produit de données avec des données provenant de différentes sources ou d'autres produits de données ; pour toute API de consommation du produit de données ; pour tester les pipelines et contrôler la qualité des données ; etc.
  2. Les données, bien sûr - Mais le plus souvent, les données existent dans des systèmes et sont simplement extraites et transformées par des pipelines. Elles ne sont donc pas présentes dans le code source (sauf exceptions).
  3. métadonnées - Certaines documentent le produit des données : schéma, sémantique, syntaxe, qualité, lignage, etc. D'autres visent à assurer la gouvernance produit à l'échelle de la maille : contrats, responsabilités, politiques d'accès, restrictions d'utilisation, etc.
  4. L'infrastructure - Ou plus précisément, la déclaration des ressources physiques nécessaires à l'instanciation du produit de données : déploiement et exécution du code, déploiement des métadonnées, allocation des ressources pour le stockage, etc.

En ce qui concerne l'infrastructure, le maillage des données ne nécessite pas de nouvelles capacités - la grande majorité des organisations disposent déjà d'une plate-forme de données. La mise en œuvre du maillage de données ne nécessite pas non plus de plateforme centralisée. Certaines entreprises ont déjà investi dans une plateforme commune, et il semble logique d'exploiter les capacités de cette plateforme pour développer le maillage. Mais d'autres ont plusieurs plateformes, certaines entités, ou certains domaines disposant de leur infrastructure. Il est tout à fait possible de déployer le maillage de données sur ces infrastructures hybrides : tant que les produits de données respectent des normes communes d'adressabilité, d'interopérabilité et de contrôle d'accès, les modalités techniques de leur exécution importent peu.

Exemple de bureaux de primes :

Afin d'établir un cadre initial pour la gouvernance son maillage de données, Premium Offices a fixé les règles suivantes :

  • Un produit de données se matérialise par un projet dédié dans BigQuery - ce qui permet de définir 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 auquel ils appartiennent (dans notre exemple, "Brokerage").
  • Les produits de données doivent offrir des vues pour accéder aux données - ces vues fournissent une interface de consommation stable et permettent potentiellement de faire évoluer le modèle interne du produit sans avoir d'impact sur ses consommateurs.
  • Tous les produits de données doivent identifier les données en utilisant des références communes pour les données communes (clients, produits, fournisseurs, employés, etc.) - cela simplifie le recoupement des données provenant de différents produits de données (LEI, code produit, UPC, EAN, adresse électronique, etc.)
  • L'accès aux produits de données nécessite une authentification forte basée sur les capacités IAM de GCP - l'utilisation d'un compte de service est possible, mais chaque utilisateur d'un produit de données doit alors avoir un compte de service dédié. Lorsque les politiques d'accès dépendent des utilisateurs, l'identité de l'utilisateurfinal doit être utilisée via l'authentification OAuth2.
  • La norme est de n'accorder l'accès qu'aux vues - et non au modèle interne.
  • Les demandes d'accès sont traitées par le product owner données au moyen de flux de travail établis dans ServiceNow.
  • DBT est l'ETL préféré pour la mise en œuvre de pipelines - chaque produit de données a un dépôt dédié pour son pipeline.
  • Un produit de données peut être consommé soit via le protocole JDBC, soit via les API BigQuery (lecture seule).
  • Un produit de données doit définir son contrat - fréquence de mise à jour des données, niveaux de qualité, classification des informations, politiques d'accès et restrictions d'utilisation.
  • Le produit de données doit publier ses métadonnées et sa documentation sur une place de marché - en l'absence de système existant, Premium Offices décide de documenter ses premiers produits de données dans un espace dédié sur le wiki de son entreprise.

Ce premier ensemble de règles est bien sûr appelé à évoluer, mais il fixe un cadre pragmatique pour garantir les caractéristiques DATSIS des produits de données en s'appuyant exclusivement sur les technologies et les compétences existantes. Pour son pilote, Premium Offices a choisi de décomposer l'architecture en deux produits de données :

  • Analyse des contrats de location - Ce premier produit de données offre des capacités d'analyse sur les contrats de location - entité, société mère, emplacement 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 deux dimensions : le temps et 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 produit de données. Enfin, il comprend une vue permettant d'obtenir la liste la plus récente des locataires.
  • Notations des entités - Ce deuxième produit de données fournit des notations historiques d'entités sous la forme d'un simple jeu de données et d'une vue miroir servant d'interface, conformément à des règles communes. La notation est obtenue auprès d'un fournisseur spécialisé, qui la distribue sous forme d'API. Pour invoquer cette API, il faut fournir une liste d'entités, obtenue en consommant l'interface appropriée du produit Tenancy analytics.

En conclusion, l'adoption d'un état d'esprit consistant à traiter les données comme un produit est essentielle pour les organisations qui procèdent à la décentralisation de la gestion des données . Cette approche favorise une culture de la responsabilité, de la normalisation et de l'efficacité dans le traitement des données dans différents domaines. En considérant les données comme un actif précieux et en mettant en œuvre des cadres de gestion structurés, les organisations peuvent assurer la cohérence, la fiabilité et l'intégration transparente des données dans l'ensemble de leurs activités.

Dans notre dernier article, nous aborderons le quatrième et dernier principe du maillage de données : la gouvernance informatique fédérée.

Le guide pratique du Data Mesh : Mise en place et supervision d'un Data Mesh à l'échelle de l'entreprise

Rédigé par Guillaume Bodet, notre guide a été conçu pour vous fournir des stratégies pratiques pour mettre en œuvre le maillage des données dans votre organisation, en vous aidant :

  • Commencez votre parcours de maillage de données par un projet pilote ciblé.
  • Découvrez des méthodes efficaces pour augmenter la taille de votre maillage de données.
  • Reconnaître le rôle essentiel que joue une place de marché interne pour faciliter la consommation effective des produits de données.
  • Découvrez comment la plateforme Actian Data Intelligence se présente comme un système de supervision robuste, orchestrant un maillage de données à l'échelle de l'entreprise.

Obtenez le livre électronique.

logo avatar actian

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous couvrons des sujets allant de l'ingestion de données en temps réel à l'analyse pilotée par l'IA. Faites connaissance avec l'équipe dirigeante https://www.actian.com/company/leadership-team/