Comprendre, à l’aide d’exemples, les similitudes et les différences entre un « data product » et des « data as a product ».
Un article rédigé par Xavier Gumara Rigol (qui nous a très aimablement autorisé à le traduire.)
Cet article a été originellement publié ici : https://towardsdatascience.com/data-as-a-product-vs-data-products-what-are-the-differences-b43ddbb0f123
Depuis la publication de l’article d’introduction au data mesh par Zhamak Dehghani, la définition de ce qu’est un « data product » dans un contexte data mesh a fait l’objet de nombreuses discussions.
En clarifiant quelques définitions dans cet article, nous espérons que les concepts de « data product » et de « data as a product » deviendront plus clairs pour toute personne entrant dans le monde des données et du data mesh.
Data Product : de quoi parle t-on ?
Commençons par la définition générique de « Data Product ». DJ Patil, ancien Chief Data Scientist, a défini un data product comme « un produit qui facilite un objectif final grâce à l’utilisation de données » (extrait de son livre Data Jujitsu : The Art of Turning Data into Product, 2012).
Cela signifie que tout produit ou fonctionnalité numérique peut être considéré comme un ”data product” s’il utilise des données pour faciliter un objectif défini en amont. Par exemple, la page d’accueil d’un journal numérique peut être un produit de données si les actualités présentées sur cette derniere sont sélectionnées dynamiquement en fonction de mes données de navigation précédentes.
En 2018, Simon O’Regan a publié un article intitulé Designing Data Products qui énumère des exemples très clairs de produits de données et les regroupe par type : données brutes, données dérivées, algorithmes, aide à la décision et prise de décision automatisée.
Voici une liste d’exemples de data product incluant la catégorie à laquelle ils appartiennent et les interfaces utilisées pour y accéder :
- Un tableau de bord d’entreprise permettant de visualiser les principaux indicateurs clés de performance de votre entreprise. Ce data product est un système d’aide à la décision dont l’interface est une visualisation.
- Un data warehouse. Ce produit de données est un mélange de données brutes, de données dérivées et de système d’aide à la décision. L’interface pour y accéder est probablement une requête SQL.
- Une liste de restaurants recommandés à proximité. Comme la liste est établie spécifiquement pour vous, ce data product est un outil de prise de décision automatisé. L’interface pour y accéder est une application ou un site web.
- Une notification « itinéraire plus rapide maintenant disponible » sur Google Maps est un data product d’aide à la décision (puisque c’est vous qui prenez la décision de suivre la recommandation ou non) et l’interface dédiée est en général un site web et/ ou une application.
- Une voiture à conduite autonome est également un data product ! En effet, une voiture autonome conduit automatiquement, elle est donc du type décisionnel automatisé. Son interface est… La voiture elle-même !
Zoom sur la Data as a Product
L’un des principes du paradigme du data mesh est de considérer les données comme un produit. Ce principe a parfois été abrégé en « Data as a Product », ce qui a engendré certaines confusions.
Comme expliqué ci-dessus, la “Data Product” est un concept générique, tandis que la « Data as a Product » est un sous-ensemble de tous les produits de données possibles. Pour être plus précis, si nous utilisons les catégories de Simon O’Regan (voir partie précédente), les « Datas as a Product » appartiennent au type de données brutes ou dérivées du « Data Product ».
Si nous nous plongeons dans le monde du data mesh, cette citation de l’article original de Zhamak Dehghani est essentielle pour comprendre la définition des Data as a Product : « Les équipes de Data Domains doivent appliquer la pensée produit […] aux ensembles de données qu’elles fournissent ; en considérant leurs actifs de données comme leurs produits et le reste des Data Scientists, des ML et Data engineers de l’organisation comme leurs clients. »
En résumé, les “Datas as a Product » sont le résultat d’une vision orientée produit appliquée à l’ensemble des données, tout en s’assurant qu’elles possèdent une série de capacités, comme la découvrabilité, la sécurité, l’explorabilité, la compréhensibilité et la fiabilité (entre autres !)
Un exemple de Data as a Product
Après avoir fait un tour d’horizon des définitions de ces concepts, nous pouvons nous demander : à quoi ressemblent concrètement les Datas as a Product ?
Un Data Product contient le code, ses données et métadonnées, ainsi que l’infrastructure nécessaire à son fonctionnement. De plus, il doit remplir les conditions décrites précédemment.
Dans une conférence donnée à la conférence du Data Council à Barcelone en 2019 intitulée « Une infrastructure d’information fédérée qui fonctionne »), nous avons présenté un exemple de Data as a Product, telle qu’utilisée dans Adevinta en énumérant ses qualités :
Découvrable
Pour que les Datas as a Product puissent être découvertes, un moteur de recherche est nécessaire et les utilisateurs doivent être en mesure d’enregistrer les ensembles de données dans ce moteur et d’en demander l’accès (cela augmentera la sécurité, une autre capacité expliquée ci-dessous).
La première itération de cette capacité pourrait être simplement une liste d’ensembles de données dans votre intranet interne de facto et vous pouvez itérer et construire progressivement à partir de cela. N’oubliez pas que les processus et la culture sont plus importants que le déploiement trop précoce de l’outil ultime de catalogue de données (qui peut être trop complexe à utiliser pour les employés).
An example of Adevinta’s custom build data catalogue that makes datasets discoverable Un exemple du catalogue de données personnalisé d’Adevinta qui rend les datasets accessibles.
Adressable
Avoir des datasets adressables rend vos équipes plus productives. D’un côté, les Data analysts et les Data Scientists sont autonomes pour trouver et utiliser les data dont ils ont besoin. D’autre part, les Data ingénieurs sont beaucoup moins interrompus par des demandes sur telles ou telles données.
Des métadonnées pour les « data as a product » qui rendent les datasets adressables.
Autodescriptif et interopérable
Les ensembles de données doivent contenir des métadonnées qui les rendent compréhensibles et qui suivent les mêmes conventions de nommage (pour rendre les datasets interopérables). Nous avons trouvé ces éléments de métadonnées très utiles pour nos analystes de données :
- Localisation des données (comme vu précédemment)
- Provenance des données et cartographie des données
- Échantillon de données
- Temps d’exécution et fraîcheur
- Préconditions d’entrée
- Exemple de notebook ou de requêtes SQL utilisant l’ensemble de données
Digne de confiance et sûr
Le contrôle régulier et automatique de la qualité des données est indispensable pour garantir leur fiabilité en tant que produit. Les propriétaires des ensembles de données doivent réagir en fonction des résultats de ces contrôles.
En général, ces contrôles de qualité doivent être effectués à l’entrée et à la sortie du pipeline et des informations contextuelles sur la qualité des données peuvent être fournies aux consommateurs de données (comme par exemple dans les dashboards Tableau)
Qualité des données contextuelles présentées dans un dashboard Tableau.
Enfin, les ensembles de données enregistrées ne doivent pas être automatiquement accessibles à tous. Les collaborateurs doivent demander l’accès à chacun d’entre eux et les responsables du traitement des données doivent accorder ou refuser l’accès individuellement. Lors de la demande d’accès, il est obligatoire de préciser jusqu’à quand l’accès est nécessaire et dans quel but.
Autres lectures
La compréhension des Datas as a Product est fondamentale pour réussir la mise en œuvre d’un data mesh dans votre organisation. Vous pouvez approfondir vos connaissances sur ce sujet en lisant les articles suivants cités dans ce billet :
- Designing Data Products by Simon O’Regan
- How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh by Zhamak Dehghani
- Data Mesh Principles and Logical Architecture by Zhamak Dehghani
- Building a data mesh to support an ecosystem of data products at Adevinta by Sandra Real and Xavier Gumara Rigol
- A Federated Information Infrastructure that Works by Xavier Gumara Rigol
