Ces dernières années, le data management connaît un changement de paradigme avec l’émergence du Data Mesh. Inventé par Zhamak Dehghani en 2019, le Data Mesh est une architecture qui favorise une approche décentralisée et orientée vers les domaines pour la gestion des données. Un principe notable dans l’architecture Data Mesh consiste à considérer les données comme des produits, introduisant ainsi le concept de Data Products. Cependant, le terme Data Product est souvent utilisé sans une compréhension claire de son essence. Dans cet article, nous partageons tout ce que vous devez savoir sur les Data Products et l’approche centrée sur le produit (product thinking).
Transition vers une approche de type product thinking
Pour que les organisations considèrent les données comme des produits et transforment leurs jeux de données en Data Products, il est essentiel que les équipes adoptent d’abord une mentalité orientée produit. Selon J. Majchrzak et al. dans Data Mesh in Action,
L’approche centrée sur le produit sert comme méthodologie pour la résolution de problèmes, en accordant une priorité à la compréhension complète des besoins des utilisateurs et du problème central avant de se plonger dans le processus de création du produit. L’objectif principal est de réduire l’écart entre les exigences des utilisateurs et la solution proposée.
Dans leur livre, ils mettent en avant deux principes fondamentaux :
- Agir sur le problème, pas sur la solution : Avant d’entamer la phase de conception d’un produit, il est impératif de comprendre les utilisateurs et le problème spécifique qui est adressé.
- Penser produit, pas fonctionnalité : Bien qu’il y ait une inclination naturelle à se concentrer sur l’ajout de nouvelles fonctionnalités et la personnalisation, il est crucial de considérer les données comme un produit qui satisfait directement les besoins des utilisateurs.
Ainsi, avant de dévoiler un jeu de données, adopter une approche de type product thinking implique de se poser ces questions essentielles :
- Quel problème souhaitez-vous résoudre ?
- Qui utilisera votre produit ?
- Pourquoi faites-vous cela ? Quelle est la vision derrière ?
- Quelle est votre stratégie ? Comment allez-vous faire ?
Voici quelques exemples de réponses à ces questions tirées d’un extrait de Data Mesh in Action :
Quel problème souhaitez-vous résoudre ? : Actuellement, les données déclaratives sur les coûts de production sont utilisées pour la facturation directe, entre l’équipe de production et l’équipe financière. Le fichier de données a également des coûts ventilés par catégories. Ces informations pourraient être utilisées pour des analyses plus complexes et des comparaisons de coûts entre les catégories de différentes productions. Par conséquent, rendre ces données plus largement disponibles pour des analyses complexes a du sens.
Qui utilisera votre produit ? : Le data analyst l’utilisera pour analyser manuellement et compiler les coûts de production et prévoir les budgets pour de nouvelles productions. L’ingénieur de données l’utilisera pour importer des données dans la solution analytique.
Pourquoi faites-vous cela ? Quelle est la vision derrière ? : Nous créerons une solution dédiée et personnalisée pour analyser les données des coûts de production et les activités de planification. Les ingénieurs de données peuvent utiliser les fichiers originaux pour importer des données historiques.
Lire l’extrait complet : https://livebook.manning.com/book/data-mesh-in-action/chapter-5/37
Définition du Data Product
La philosophie du product thinking nous pousse donc à voir un Data Product à travers un développement continu à long terme, une adaptation issue des retours utilisateurs et un engagement pour l’amélioration continue et la qualité. Un produit peut être un objet, un système ou un service mis à disposition pour l’utilisation du consommateur, à sa demande. Alors, qu’est-ce qui fait d’un produit un Data Product ?
Chez Zeenea, nous définissons un Data Product comme un ensemble d’actifs de données de valeur, spécifiquement conçus et gérés pour être consommés rapidement et en toute sécurité, tout en garantissant le plus haut niveau de qualité, de disponibilité, et de conformité aux réglementations et aux politiques internes.
Selon Data Mesh in Action, l’utilisation délibérée du terme produit dans le contexte Data Mesh est intentionnelle et s’oppose au terme couramment utilisé de projet dans les initiatives organisationnelles. Il est important de souligner que la création d’un Data Product n’est pas synonyme de projet. Comme décrit dans Products Over Projects de Sriram Narayan, les projets sont des efforts temporaires visant à atteindre des objectifs spécifiques, avec une fin définie qui ne conduit pas nécessairement à une continuité.
Caractéristiques Fondamentales d’un Data Product
Dans How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, Zhamak Dehghani affirme qu’un Data Product doit présenter les caractéristiques suivantes :
Découvrable
Assurer la facilité de découverte d’un Data Product est impératif. Une approche largement adoptée consiste à mettre en œuvre un registre ou un catalogue de données contenant des méta-informations complètes telles que les propriétaires, la source, le lignage et des extraits de jeux de données pour tous les Data Products disponibles. Cette découvrabilité centralisée permet aux consommateurs de données, aux data engineers et data scientists au sein d’une organisation de localiser facilement des jeux de données d’intérêt.
Addressable
Une fois découvert, un Data Product doit posséder une adresse unique suivant une convention globale. Les organisations, influencées par le stockage et le format de leurs données, peuvent adopter différentes conventions de dénomination. À la recherche d’un accès facilité, les conventions communes deviennent indispensables dans une architecture décentralisée.
Fiable et digne de confiance
Les propriétaires de Data Products doivent s’engager sur des Objectifs de Niveau de Service concernant la véracité des données, nécessitant l’arrêt des extractions traditionnelles sujettes aux erreurs. L’utilisation de techniques telles que le nettoyage des données et les tests automatisés d’intégrité sont cruciales pour garantir un niveau de qualité acceptable lors de la création du Data Product.
Une sémantique et une syntaxe auto-descriptives
Les Data Products de haute qualité exigent une expérience utilisateur autonome – ils doivent être indépendamment découvrables, compréhensibles et consommables. Pour construire des jeux de données en tant que produits avec un minimum de friction pour les ingénieurs et les data scientists, il est essentiel d’articuler rigoureusement la sémantique et la syntaxe des données.
Interopérable et gouverné par des normes globales
Corréler des données à travers des domaines dans une architecture distribuée repose sur le respect de normes globales et des règles d’harmonisation. La gouvernance des normes, comprenant le formatage des champs, l’identification des polysèmes, les conventions d’adresse, les champs de métadonnées et les formats d’événements, assurent l’interopérabilité et une corrélation significative.
Sécurisé et gouverné par un contrôle d’accès global :
Sécuriser l’accès aux jeux de données des produits est impératif, que l’architecture soit centralisée ou non. Dans le monde des Data Products décentralisés et orientés vers les domaines, le contrôle d’accès opère à un niveau plus nuancé – spécifiquement adapté à chaque Data Product d’un domaine. Tout comme les domaines opérationnels définissent de manière centralisée les politiques de contrôle d’accès, ces politiques sont appliquées dynamiquement lors de l’accès aux jeux de données individuels. Tirer parti d’un Système de Gestion de l’Identité d’entreprise, souvent facilité par une authentification unique (SSO), et l’utilisation de politiques de contrôle d’accès basées sur les rôles (RBAC), offre une approche pratique et efficace pour mettre en œuvre le contrôle d’accès pour les jeux de données des produits.
Exemples de Data Products
Un Data Product potentiel peut prendre diverses formes, avec différentes représentations de données qui apportent de la valeur aux utilisateurs. Voici plusieurs exemples de technologies contenant des Data Products :
- Moteurs de Recommandation : Des plateformes telles que Netflix, Amazon et Spotify utilisent des moteurs de recommandation en tant que Data Products pour suggérer du contenu ou des produits en fonction du comportement et des préférences des utilisateurs.
- Modèles d’Analyse Prédictive : Les modèles prédisant la perte de clients, les prévisions de ventes ou les défaillances d’équipements sont des exemples de Data Products qui fournissent des informations précieuses pour la prise de décision.
- Systèmes de Détection de Fraude : Les institutions financières déploient des Data Products pour détecter et prévenir les activités frauduleuses en analysant les modèles de transactions et en identifiant les anomalies.
- Campagnes de Marketing Personnalisées : La publicité ciblée et les campagnes de marketing personnalisées utilisent des Data Products pour adapter le contenu en fonction des données démographiques, du comportement et des interactions historiques des utilisateurs.
- Outils de Diagnostic Médical : Les outils de diagnostic qui analysent les données médicales, telles que les dossiers des patients et les résultats d’analyses, dans le but d’aider les professionnels de santé à poser des diagnostics précis.
