Img_couverture_blog_Ysance

    Data as a Product vs Data Product : Quelles différences ?

    [fa icon="calendar"] 09/11/21 15:59 / par Laurent Letourmy

    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

    Data-product-article

    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 :



    Thèmes : product, Data Mesh

    Laurent Letourmy

    Par Laurent Letourmy

    Ingénieur EPITA, entrepreneur dans le monde des technologies et de la Data, il est CTO de Cross Systems en 1996 qui est introduite en bourse 3 ans plus tard. Depuis 2005, il pilote depuis le fort développement d’Ysance, qui excelle dans le déploiement de solutions très innovantes (Cloud Computing, BigData & IA…). La Société ajoute à son portefeuille une activité d’éditeur de plateforme marketing SaaS, lève 5M€ en 2015 avec Créadev (famille Mulliez) et se déploie à grande vitesse dans le monde du retail, est reconnue par le Gartner en 2017 et devient ainsi la plateforme marketing de référence dans ce secteur. Il rachète en 2018 Mazeberry, spécialiste Français des solutions d’Attribution et de Merchandising et crée ainsi un précédent dans la consolidation d’acteurs du SaaS Marketing en France, l’activité prend le nom d’Easyence en 2020. Le groupe Devoteam réalise en 2020 l’acquisition de l’activité Conseil Data d’Ysance et il est nommé Head of Data de Devoteam France.

    S'abonner au blog