[SÉRIE] Data Shopping Partie 2 – L’expérience de Data Shopping dans Zeenea

[SÉRIE] Data Shopping Partie 2 – L’expérience de Data Shopping dans Zeenea

Tout comme l’achat de biens en ligne implique de sélectionner des objets, les ajouter à un panier et de choisir les options de livraison et de paiement, le processus d’acquisition de données au sein des organisations a évolué de manière similaire. À l’ère des data products et du data mesh, les data marketplaces internes permettent aux utilisateurs métiers de rechercher, de découvrir et d’accéder aux données pour leurs cas d’usage.

Dans cette série d’articles, vous trouverez un extrait de notre Guide Pratique du Data Mesh et découvrirez tout ce qu’il y a à savoir sur le data shopping ainsi que l’expérience de Zeenea en matière de shopping de données via son Enterprise Data Marketplace :

  1. La consommation de Data Products
  2. L’expérience de Data Shopping dans Zeenea

 

Dans notre précédent article, nous avons abordé le concept de data shopping au sein d’une data marketplace interne, en abordant des éléments tels que la livraison des data products et la gestion de l’accès. Dans cet article, nous allons explorer les raisons qui ont poussé Zeenea à étendre son expérience de data shopping au-delà des frontières internes, ainsi que la façon dont notre interface, Zeenea Studio, permet l’analyse de la performance globale de vos data products.

Le Data Product Shopping dans Zeenea

 

Dans notre article précédent, nous avons abordé les complexités de la gestion des droits d’accès aux data products en raison des risques inhérents à la consommation de données. Dans un data mesh décentralisé, le propriétaire du data product évalue les risques, accorde l’accès et applique des politiques basées sur la sensibilité des données, le rôle, la localisation et l’objectif du demandeur. Cela peut impliquer une transformation des données ou des formalités supplémentaires, avec une livraison allant de l’accès en lecture seule à des contrôles granulaires.

Dans une data marketplace, les consommateurs déclenchent un workflow en soumettant des demandes d’accès, que les propriétaires de données évaluent et pour lesquelles ils déterminent les règles d’accès, parfois avec l’avis d’experts. Pour la marketplace Zeenea nous avons choisi de ne pas intégrer ce workflow directement dans la solution, mais plutôt de s’interfacer avec des solutions externes.

L’idée est de proposer une expérience uniforme pour déclencher une demande d’accès, mais d’accepter que le traitement de cette demande puisse être très différent d’un environnement à l’autre, voire d’un domaine à l’autre dans la même organisation. Là aussi, le principe est hérité des marketplaces classiques. La plupart proposent une expérience unique pour réaliser une commande, mais débranchent sur d’autres systèmes pour la mise en œuvre opérationnelle de la livraison – dont les modalités peuvent être très différentes en fonction du produit et du vendeur.

Ce découplage entre l’expérience de shopping et la mise en œuvre opérationnelle de la livraison nous semble indispensable pour plusieurs raisons.

La principale est l’extrême variabilité des processus impliqués. Certaines organisations disposent déjà de workflows opérationnels, s’appuyant sur une solution plus large (la demande d’accès aux données est intégrée à un processus général de demande d’accès, supporté par exemple par un outil de ticketing tel que ServiceNow ou Jira). D’autres se sont équipées de solutions dédiées, supportant un fort niveau d’automatisation, mais dont le déploiement n’est pas encore généralisé. D’autres reposent sur les capacités de leur plateforme data, en d’autres encore sur rien du tout – l’accès se fait via des demandes directes adressées au propriétaire des données, qui les traite sans processus formel. Cette variabilité se manifeste d’une organisation à l’autre, mais aussi dans une même organisation – structurellement, quand différents domaines utilisent des technologies différentes, ou temporellement, quand l’organisation décide d’investir dans un dispositif plus efficace ou plus sécurisé et doit migrer progressivement la gestion des accès vers ce nouveau dispositif.

Découpler permet donc d’offrir une expérience homogène au consommateur, tout en s’adaptant à la variabilité des modes opératoires

Pour le client de la data marketplace, l’expérience de shopping est donc très simple. Une fois le ou les data products d’intérêt identifiés, il déclenche une demande d’accès en fournissant les informations suivantes :

  1. Qui il est – cette information est en principe déjà disponible.
  2. À quel data product il souhaite accéder – là aussi l’information est déjà présente, ainsi que les métadonnées nécessaires pour réaliser les arbitrages.
  3. Quel usage il entend faire des données – ce point est fondamental, puisqu’il pilote la gestion de risque et les exigences de conformité.

Avec Zeenea, une fois la demande d’accès soumise, elle est traitée dans un autre système, et son statut peut être suivi depuis la marketplace – c’est le strict équivalent du suivi de commandes que l’on trouve sur les sites e-commerce.

Du point de vue du consommateur, la data marketplace fournit un catalogue de data products (et d’autres produits digitaux), et un système simple et universel pour obtenir l’accès à ces produits.

Pour le producteur, la data marketplace remplit un rôle fondamental dans le pilotage de son portefeuille de produits.

Améliorez la performance des data products avec Zeenea Studio

 

Comme évoqué précédemment, outre le système de e-commerce, qui est destiné aux consommateurs, une marketplace classique propose aussi des outils dédiés aux vendeurs, leur permettant de superviser leurs produits, de répondre aux sollicitations des acheteurs et de contrôler la performance économique de leur offre. Et d’autres outils encore, destinés aux gestionnaires de la marketplace, pour analyser la performance globale des produits et des vendeurs.

L’Enterprise Data Marketplace de Zeenea intègre ces capacités dans un outil de back-office dédié, Zeenea Studio. Il permet de gérer la production, la consolidation et l’organisation des métadonnées dans un catalogue privatif, et de décider quels objets seront placés dans la marketplace – qui est un espace de recherche accessible au plus grand nombre.

Ces activités relèvent avant tout du processus de production – les métadonnées sont produites et organisées conjointement avec les data products. Mais il permet également de superviser l’utilisation de chaque data product, notamment en fournissant la liste de tous ses consommateurs, et des usages qui leur sont associés.

Ce suivi des consommateurs permet d’asseoir les deux piliers de la gouvernance du data mesh :

  • La conformité et la gestion de risque – en mettant en place des revues régulières, des certifications, et des analyses d’impact lors des évolutions des data products.
  • Le pilotage de la performance – le nombre de consommateurs, ainsi que la nature des usages qui en sont fait, sont les principaux indicateurs de la valeur d’un data product. En effet, un data product qui n’est pas consommé n’a aucune valeur.

Outil de support pour les domaines permettant de contrôler la conformité de leurs produits et leurs performances, l’Enterprise Data Marketplace de Zeenea offre également des capacités d’analyse globale du mesh – lineage des data products, scoring et évaluation de leurs performances, contrôle de la conformité globale et des risques, éléments de reporting réglementaire, etc.

C’est la magie du graphe fédéré, qui permet d’exploiter l’information à toutes les échelles – et fournit une représentation exhaustive de tout le patrimoine data.

Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise

 

Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :

✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise

Signature Data Mesh Fr
[SÉRIE] La data marketplace pour le data mesh –  Partie 3 : Alimenter la marketplace via des data catalogs par domaine

[SÉRIE] La data marketplace pour le data mesh –  Partie 3 : Alimenter la marketplace via des data catalogs par domaine

Au cours de la dernière décennie, les catalogues de données ont émergé en tant que piliers dans l’écosystème data. Cependant, de nombreux fournisseurs ne répondent pas aux attentes – avec en cause des délais prolongés, des projets complexes et coûteux, des modèles bureaucratiques de gouvernance des données, des taux d’adoption faibles et une création de valeur limitée. Cette problématique va au-delà des projets de gestion des métadonnées, reflétant un échec plus général au niveau de la gestion des données.

Face à ces lacunes, un nouveau concept a le vent en poupe, celui de place de
marché interne à l’organisation, que nous appelons Enterprise Data Marketplace (EDM) chez Zeenea.

Dans cette série d’articles, vous trouverez des extraits de notre Guide Pratique du Data Mesh dans lequel nous expliquons l’intérêt des data marketplaces internes pour la production et la consommation de data products, comment une EDM prend en charge l’exploitation du data mesh à l’échelle, et comment elles vont de pair avec une solution de catalogue de données :

  1. Faciliter la consommation des data products avec les métadonnées
  2. Déployer une marketplace à l’échelle de l’entreprise
  3. Alimenter la marketplace via des data catalogs par domaine

 

La structuration du data management autour de domaines et de data products est une transformation organisationnelle qui ne change pas la réalité opérationnelle de la plupart des organisations : les données sont disponibles en grande quantité, en provenance de nombreuses sources, évoluent rapidement, et leur maîtrise est complexe.

Les Data Catalogs ont traditionnellement pour fonction d’inventorier l’ensemble des données disponibles, et de gérer un ensemble de métadonnées permettant d’en assurer la maîtrise et d’asseoir les pratiques de gouvernance.

Le data mesh ne supprime pas cette complexité : il permet de distinguer certaines données, gérées sous forme de data products, et qui sont destinées à être partagées et utilisées au-delà du domaine auquel elles appartiennent. Mais chaque domaine est également chargé de gérer ses données internes, celles qui lui serviront à développer des data products – ses données privatives en somme.

Gestion des métadonnées dans le contexte d’une marketplace interne alimentée par des catalogues par domaine

 

Dans le data mesh, le besoin d’un Data Catalog ne disparaît pas, bien au contraire : chaque domaine devrait disposer d’un catalogue lui permettant de gérer efficacement ses données privatives, de supporter la gouvernance du domaine, et d’accélérer le développement de data products robustes et à forte valeur ajoutée. La gestion des métadonnées se fait donc à deux niveaux :

  • Au niveau de chaque domaine – sous la forme d’un catalogue permettant de documenter et d’organiser l’univers de données du domaine. Le Data Catalog étant une brique privative, il n’est pas nécessaire que tous les domaines utilisent la même solution.
  • Au niveau du mesh – sous la forme d’une marketplace dans laquelle sont enregistrés les data products partagés par tous les domaines ; la marketplace est par nature commune à tous les domaines.

Avec un composant marketplace dédié, l’architecture générale de la gestion de métadonnées est la suivante :

Architecture Générale Pour La Gestion Des Métadonnées

Dans cette architecture, chaque domaine dispose de son propre catalogue – qui peut s’appuyer sur une solution unique ou non, mais devrait être instancié pour chaque domaine afin de lui permettre d’organiser ses données de la façon la plus efficace pour lui, et éviter les chausse-trappes d’une organisation universelle des métadonnées.

La marketplace est un composant dédié, offrant une ergonomie simplifiée, et dans laquelle chaque domaine déploie les métadonnées (voire les données) de ses data products. Cette approche demande d’intégrer étroitement les différents modules :

  • Les catalogues privatifs doivent être intégrés avec la marketplace – afin de ne pas dupliquer les efforts de production de certaines métadonnées – on pense au lignage en particulier, mais aussi au dictionnaire de données (schéma), ou encore aux définitions métier qui seront présents dans les deux systèmes.
  • Les catalogues privatifs doivent potentiellement être intégrés entre eux – afin de partager/synchroniser certaines informations, en premier lieu le glossaire métier mais aussi certains référentiels.

Les capacités du catalogue de données vs l’EDM

 

Quand on se penche sur les capacités respectives d’une Enterprise Data Marketplace et d’un Data Catalog, on se rend compte que ces capacités sont très similaires :

Data Catalog Vs Enterprise Data Marketplace

Au final, sur le strict plan fonctionnel, leurs capacités sont très proches. Ce qui va distinguer un Data Catalog moderne d’une EDM sont :

 

  • Leur périmètre – le Data Catalog a pour vocation de couvrir l’ensemble des données, quand la marketplace se limite aux objets partagés par les domaines (data products et autres produits data du domaine).

 

  • Leur expérience utilisateur – le Data Catalog est souvent un outil assez complexe, destiné à supporter globalement les processus de gouvernance – il est centré sur les workflows de data stewardship. La marketplace quant à elle offre typiquement une ergonomie très simple, fortement inspirée de celle d’une plateforme de e-commerce, et propose une expérience centrée sur la consommation – le data shopping.

Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise

 

Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :

✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise

Signature Data Mesh Fr
[SÉRIE] La data marketplace pour le data mesh – Partie 2 : Construire une marketplace à l’échelle de l’entreprise

[SÉRIE] La data marketplace pour le data mesh – Partie 2 : Construire une marketplace à l’échelle de l’entreprise

Au cours de la dernière décennie, les catalogues de données ont émergé en tant que piliers dans l’écosystème data. Cependant, de nombreux fournisseurs ne répondent pas aux attentes – avec en cause des délais prolongés, des projets complexes et coûteux, des modèles bureaucratiques de gouvernance des données, des taux d’adoption faibles et une création de valeur limitée. Cette problématique va au-delà des projets de gestion des métadonnées, reflétant un échec plus général au niveau de la gestion des données.

Face à ces lacunes, un nouveau concept a le vent en poupe, celui de place de
marché interne à l’organisation, que nous appelons Enterprise Data Marketplace (EDM) chez Zeenea.

Dans cette série d’articles, vous trouverez des extraits de notre Guide Pratique du Data Mesh dans lequel nous expliquons l’intérêt des data marketplaces internes pour la production et la consommation de data products, comment une EDM prend en charge l’exploitation du data mesh à l’échelle, et comment elles vont de pair avec une solution de catalogue de données :

  1. Faciliter la consommation des data products avec les métadonnées
  2. Déployer une marketplace à l’échelle de l’entreprise
  3. Alimenter la marketplace via des data catalogs par domaine

 

Comme mentionné dans notre précédent article, une Enterprise Data Marketplace est un système simple dans lequel les consommateurs peuvent rechercher parmi l’offre de data products celui ou ceux éligibles pour réaliser un cas d’usage spécifique, prendre connaissance des informations relatives à ces produits, puis les commander. La commande se matérialise par une ouverture d’accès, une livraison physique des données, ou encore une demande d’évolution des data products pour couvrir le nouveau cas d’utilisation.

Les trois grandes options pour mettre en place une data marketplace interne

 

Lors de la mise en place d’une data marketplace interne, les organisations envisagent généralement trois approches principales :

La développer

 

Cette approche consiste à créer une marketplace personnalisée, adaptée aux besoins uniques de l’organisation. Bien qu’elle offre la possibilité d’une expérience utilisateur optimisée, cette option implique souvent un investissement important en temps et en argent.

Intégrer une solution du marché

 

Les organisations peuvent également opter pour des solutions préexistantes disponibles sur le marché. Conçues à l’origine pour la commercialisation de données ou l’échange de données externes, ces solutions peuvent être reconverties pour un usage interne. Cependant, elles peuvent nécessiter une personnalisation pour s’aligner sur les flux de travail internes et les normes de sécurité.

Utiliser les systèmes existants

 

Certaines organisations choisissent de tirer parti de leur infrastructure actuelle en réutilisant des outils tels que les catalogues de données et les wikis d’entreprise. Bien que cette approche puisse offrir une certaine familiarité et une intégration avec les flux de travail existants, elle peut ne pas offrir les fonctionnalités spécialisées des solutions dédiées au marché des données.

Les inconvénients des marketplaces commerciales

 

Bien que proposant une expérience utilisateur souvent satisfaisante, et un support natif de la notion de data product, les marketplaces commerciales présentent quant à elles souvent des inconvénients importants : très focalisées sur les aspects transactionnels (distribution, licence, contractualisation, achat ou souscription, paiement, etc.), elles sont souvent mal intégrées aux plateformes data et aux outils de contrôle d’accès interne. Elles nécessitent généralement que les données soient également distribuées par la marketplace – ce qui signifie qu’elles constituent un nouveau composant d’infrastructure sur lequel les données devront être transférées pour être partagées (un tel système est parfois appelé Data Sharing Platform).

L’Enterprise Data Marketplace de Zeenea

 

Dans une approche pragmatique, nous ne croyons pas que, dans la plupart des cas, il soit souhaitable d’introduire une nouvelle brique d’infrastructure pour déployer un data mesh – comme déjà évoqué, il semble très préférable d’exploiter les capacités déjà existantes autant que possible.

C’est pourquoi, chez Zeenea, nous avons fait évoluer notre Data Discovery Platform et son data catalog pour offrir une solution unique, un miroir du data mesh au niveau des métadonnées pour s’adapter continuellement à l’évolution de l’architecture de la plateforme data de l’organisation. Cette Entreprise Data Marketplace (EDM) intègre une place de marché interdomaines avec des catalogues de données privatifs adaptés aux besoins de chaque domaine.

Une approche que nous détaillons dans le prochain article de notre série, rendue possible par ce qui a longtemps distingué Zeenea et le différencie de la plupart des autres catalogues ou métadonnées : un knowledge graph évolutif.

Dans notre dernier article de la série, découvrez comment une data marketplace interne associée à des catalogues spécifiques par domaine constitue un système de supervision du data mesh complet.

Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise

 

Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :

✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise

Signature Data Mesh Fr
[SÉRIE] La data marketplace pour le data mesh –  Partie 1 : Faciliter la consommation des data products avec les métadonnées

[SÉRIE] La data marketplace pour le data mesh –  Partie 1 : Faciliter la consommation des data products avec les métadonnées

Au cours de la dernière décennie, les catalogues de données ont émergé en tant que piliers dans l’écosystème data. Cependant, de nombreux fournisseurs ne répondent pas aux attentes – avec en cause des délais prolongés, des projets complexes et coûteux, des modèles bureaucratiques de gouvernance des données, des taux d’adoption faibles et une création de valeur limitée. Cette problématique va au-delà des projets de gestion des métadonnées, reflétant un échec plus général au niveau de la gestion des données.

Face à ces lacunes, un nouveau concept a le vent en poupe, celui de place de
marché interne à l’organisation, que nous appelons Enterprise Data Marketplace (EDM) chez Zeenea.

Dans cette série d’articles, vous trouverez des extraits de notre Guide Pratique du Data Mesh dans lequel nous expliquons l’intérêt des data marketplaces internes pour la production et la consommation de data products, comment une EDM prend en charge l’exploitation du data mesh à l’échelle, et comment elles vont de pair avec une solution de catalogue de données :

  1. Faciliter la consommation des data products avec les métadonnées
  2. Déployer une marketplace à l’échelle de l’entreprise
  3. Alimenter la marketplace via des data catalogs par domaine

 

 

Avant d’aborder le concept de data marketplace interne, revenons un instant sur la notion de data product, qui selon nous constitue la pierre angulaire du data mesh, et la première étape de la transformation du data management.

Partage et exploitation des data products grâce aux métadonnées

 

Comme mentionné dans notre précédente série d’articles sur le data mesh, un data product est un jeu de données gouverné, réutilisable, évolutif, et offrant des garanties en matière de qualité de données et de conformité aux différentes réglementations et règles internes. Notons que cette définition est assez restrictive – elle exclut d’autres types de produits tels que les algorithmes ou modèles de machine learning (ML), ou encore les tableaux de bord.

Il est bien sûr souhaitable que ces artefacts soient également gérés comme des produits, mais ce ne sont pas des data products. Ce sont d’autres types de produits, que l’on pourrait qualifier de façon très générale d’Analytics Products, et dont les data products sont l’une des sous-catégories.

En pratique, un data product opérationnel est constitué de deux choses :

  • Data (1)1. Les données - matérialisées sur une plateforme data centralisée ou non, et garantissant l’adressage, l’interopérabilité et la sécurisation de l’accès aux données.
  • Metadata (1)2. Les métadonnées - qui fournissent l’ensemble des informations nécessaires pour partager et exploiter les données.

Les métadonnées permettent d’assurer que les consommateurs disposent de toutes les informations nécessaires pour utiliser le produit.

Elle couvrent typiquement les aspects suivants :

Schema

Le schéma – qui fournit la structure technique du data product, la classification des données, des échantillons, ainsi que leur origine (lignage).

Governance

La gouvernance – qui identifie le ou les responsables du produit, ses versions successives, son éventuelle dépréciation, etc.

Semantics

La sémantique – qui fournit une définition claire des informations exposées, idéalement rattachée au glossaire métier de l’organisation, et une documentation exhaustive du data product.

Contract

Le contrat – qui définit les garanties en matière de qualité, les modalités de consommation (protocoles et sécurité), les éventuelles restrictions d’usage, les règles de redistribution, etc.

Dans la logique du data mesh, ces métadonnées sont gérées par l’équipe produit, et déployées selon le même cycle de vie que les données et les pipelines. Reste une question fondamentale : où déployer les métadonnées ?

Utilisation d’une data marketplace pour déployer les métadonnées

 

La plupart des organisations disposent déjà d’un système de gestion des métadonnées, généralement sous la forme d’un Data Catalog.

Mais les Data Catalogs, sous leur forme actuelle, présentent des inconvénients majeurs :

Dont Support Data Product

Ils ne supportent pas toujours la notion de data product – elle doit être plus ou moins émulée avec d’autres notions.

Complex To Use

Ils sont complexes à utiliser – ils ont été conçus pour cataloguer un grand nombre d’assets avec une granularité parfois très fine, et souffrent très souvent d’un déficit d’adoption au-delà des équipes de data management centralisées.

Rigid Organization

Ils imposent le plus souvent une organisation rigide et unique des données, décidée et conçue en central – cela peine à refléter la variété des différents domaines ou les évolutions de l’organisation à mesure que le data mesh s’étend.

Limited Search Capacities

Leurs capacités de recherche sont souvent limitées, particulièrement pour les aspects exploratoires – il est souvent nécessaire de savoir ce que l’on cherche pour pouvoir le trouver.

Lacks Simplicity

L’expérience qu’ils proposent manque parfois de la simplicité à laquelle les utilisateurs aspirent – je recherche avec quelques mots-clés, j’identifie le data product adéquat, puis je déclenche le processus opérationnel de demande d’accès ou de livraison des données.

Une data marketplace interne, ou Enterprise Data Marketplace (EDM), est donc un nouveau concept qui gagne en popularité dans le domaine du data mesh. Au même titre qu’une place de marché généraliste, l’EDM a pour vocation à fournir une expérience de shopping aux consommateurs de données. Elle est une composante indispensable pour assurer l’exploitation du data mesh à grande échelle – elle permet aux consommateurs de données de disposer d’un système simple et efficace pour rechercher et accéder aux data products des différents domaines.

Dans notre prochain article, découvrez les différentes façons de mettre en place une data marketplace interne, et pourquoi elles sont essentielles pour l’exploitation du data mesh.

Le Guide Pratique du Data Mesh: Mettre en place et superviser un data mesh à l’échelle de l’entreprise

 

Rédigé par Guillaume Bodet, co-fondateur et CPTO chez Zeenea, ce guide vous apportera une approche pratique pour mettre en œuvre un data mesh dans votre organisation, en vous aidant à :

✅ Entamer votre démarche data mesh avec un projet pilote focalisé
✅ Découvrir des méthodes efficaces pour mettre votre mesh à l’échelle,
✅ Comprendre le rôle essentiel joué par une data marketplace interne pour faciliter la consommation des data products
✅ Découvrir pourquoi Zeenea est un système de supervision robuste du data mesh à l’échelle de l’entreprise

Signature Data Mesh Fr
Qu’est-ce qu’une API ?

Qu’est-ce qu’une API ?

Vous avez forcément entendu parler d’API… Elles sont omniprésentes mais pourtant méconnues. Envie de tout connaître sur les API, ou Application Programming Interface ? Levons le voile sur leur rôle, leurs atouts et leur fonctionnement !

API… Trois lettres sans lesquelles aujourd’hui, les entreprises ne pourraient pas déployer leurs stratégies data aussi aisément. Une Application Programming Interface (traduisez Interface de Programmation Applicative) est un ensemble de règles et de protocoles qui permettent à deux logiciels distincts de communiquer entre eux. Elle définit les méthodes et les formats de données autorisés pour l’échange d’informations, facilitant ainsi l’intégration de différentes applications ou services.

Le concept d’API remonte aux premières heures de l’informatique. Dans les années 2000, avec la croissance d’Internet et l’émergence des services web, les API ont gagné en importance. Les entreprises ont commencé à fournir des API pour permettre l’intégration de leurs services avec d’autres applications et systèmes. On estime qu’en 2020, près de 2 milliards d’euros ont été investis dans le monde pour développer des API !

Comment fonctionne une API ?

 

Dans le monde de la diplomatie, il y a les interprètes. Dans l’univers IT, il y a les API. Cette comparaison un peu triviale résume la fonction d’une API. Elle agit comme un intermédiaire, recevant des requêtes et retournant des réponses structurées. Une API fonctionne en définissant des points de terminaison (endpoints) accessibles via des requêtes HTTP. Ces points de terminaison représentent des fonctionnalités spécifiques de l’application, et les développeurs interagissent avec ces derniers en utilisant des méthodes HTTP standard telles que GET, POST, PUT, et DELETE. Les données sont alors échangées au format JSON ou XML. L’API spécifie les paramètres nécessaires, les types de données attendus, et les réponses possibles. Les requêtes HTTP contiennent des informations telles que les en-têtes et les corps de requête, permettant la transmission de données. Les réponses renvoient des codes de statut pour indiquer le succès ou l’échec, accompagnés de données structurées.

La documentation de l’API, généralement basée sur des spécifications comme OpenAPI, décrit de manière détaillée comment interagir avec chaque endpoint. Les tokens d’authentification peuvent être utilisés pour sécuriser l’accès à l’API. En somme, une API agit comme une interface externe, facilitant l’intégration et la communication entre différentes applications ou services.

Quels sont les bénéfices des API ?

 

Le recours aux API présente une multitude d’avantages dans l’univers du logiciel et de l’intégration de systèmes. Elles simplifient l’accès aux fonctionnalités d’une application, permettant aux développeurs d’exploiter des services externes sans avoir nécessairement à comprendre leur implémentation interne. Cela favorise la modularité et accélère le développement d’interconnexion entre solutions métiers indispensables à l’efficacité de vos collaborateurs.

De plus, Les API facilitent par ailleurs l’intégration entre différentes applications, créant des écosystèmes logiciels interconnectés. L’avantage clé ? Une efficacité opérationnelle sensiblement améliorée ! En effet, les mises à jour ou les améliorations peuvent être apportées à une API sans affecter les clients qui l’utilisent. La réutilisation de code est encouragée, car les développeurs peuvent exploiter des fonctionnalités existantes via des API plutôt que de recréer des solutions similaires, ce qui induit des économies sensibles sur les coûts de développement et des délais plus courts qui contribuent à l’agilité de votre entreprise.

Enfin, les API sont une perspective de collaboration améliorée entre équipes, car différents groupes peuvent travailler indépendamment en utilisant des API comme interfaces définies.

Les différents types d’API

 

Les API constituent une famille nombreuse ! Il en existe différents types qui répondent à des besoins spécifiques.

Open API

 

Également appelée API externe ou API publique, elle est conçue pour être accessible au public. Les Open APIs suivent des standards comme REST ou GraphQL. Elles favorisent la collaboration, permettant à des développeurs tiers ou à d’autres applications d’accéder aux fonctionnalités et aux données d’un service donné de manière contrôlée.

Partner API

 

Les Partner APIs ou API partenaires sont, comme leur nom l’indique, dévolues à des partenaires spécifiques ou à des développeurs externes de confiance. Ces API offrent un accès plus restreint et sécurisé. Elles sont souvent utilisées pour étendre les fonctionnalités d’une application à des partenaires stratégiques sans exposer toutes ses fonctionnalités au public.

Composite API

 

Derrière le terme de Composite API, on trouve la combinaison de plusieurs appels d’API différents en une seule requête. L’intérêt ? Simplifier l’accès à plusieurs fonctionnalités en un seul appel, réduisant d’autant la complexité des interactions et améliorant les performances.

Internal API ou API interne

 

Conçu pour être utilisé à l’intérieur d’une organisation, ce type d’API facilite la communication entre les différentes parties d’un système ou entre différents systèmes internes. Il contribue à la modularité et à la cohérence des applications au sein de l’entreprise.

Les différents protocoles d’API

 

Si l’on peut comparer les API à des interprètes, les protocoles qu’ils utilisent sont en quelque sorte, les langues qui leur permettent de communiquer. Ces protocoles sont au nombre de quatre !

SOAP (Simple Object Access Protocol)

 

Utilisant XML, SOAP est un protocole standardisé qui offre des fonctionnalités avancées telles que la sécurité et la gestion des transactions. Cependant, il peut être complexe et nécessiter des ressources importantes.

XML-RPC (XML Remote Procedure Call)

 

La principale qualité de ce protocole, c’est sa simplicité ! Basé sur XML, il permet l’appel de procédures distantes. Bien que moins complexe que SOAP, il offre des fonctionnalités limitées et est souvent remplacé par des alternatives plus modernes.

REST (Representational State Transfer)

 

Fondé sur les principes HTTP, REST utilise des méthodes standard comme GET, POST, PUT, et DELETE pour manipuler des ressources. Il exploite le format de données JSON dont il tire sa simplicité, sa scalabilité et sa flexibilité !

JSON-RPC (JavaScript Object Notation Remote Procedure Call)

 

Léger et basé sur JSON, JSON-RPC facilite l’appel de procédures distantes. Il offre une alternative simple à XML-RPC et est souvent utilisé dans des environnements web et mobiles.

Quelle est la différence entre une Data Fabric et le Data Mesh ?

Quelle est la différence entre une Data Fabric et le Data Mesh ?

Pendant des années, les entreprises ont été confrontées au défi de collecter de la donnée. Désormais, le véritable enjeu consiste à mettre de l’intelligence dans une profusion de data difficile à maîtriser. De nombreuses technologies et solutions promettent une valorisation optimale de vos données. Parmi celles-ci, on trouve notamment la Data Fabric et le Data Mesh. Si ces concepts peuvent sembler similaires, il existe des différences fondamentales entre ces deux approches. Explications.

Une exigence de connaissance des clients pour se différencier dans un contexte d’hyper-concurrence, des parcours et des usages digitaux qui se développent, les volumes de données à disposition de votre entreprise explosent ! Mais l’abondance d’information n’est rien sans intelligence et sans exploitation fine. Cette réalité influence l’ensemble de l’écosystème de la data.

Si l’on se réfère aux prévisions de Gartner, d’ici 2024, plus de 25 % des fournisseurs de solutions de gestion de données fourniront un support complet de structure de données via une combinaison de leurs propres produits et de ceux de leurs partenaires, contre moins de 5 % aujourd’hui.

Dans ce contexte, plusieurs voies peuvent être explorées, mais deux pistes sortent du lot : la Data Fabric et le Data Mesh.

Qu’est-ce qu’une Data Fabric ?

Le concept de Data Fabric a été introduit par Gartner dès 2019. Le célèbre institut décrit la Data fabric comme l’utilisation combinée de plusieurs technologies existantes pour permettre une implémentation basée sur les métadonnées et une conception d’orchestration augmentée.

En d’autres termes, la Data Fabric constitue un environnement au sein duquel les données et les métadonnées sont analysées en permanence pour faire l’objet d’enrichissements continus et d’une valorisation optimale. Mais, attention ! Une data fabric n’est pas un produit ou une solution finie. C’est un environnement composable qui repose sur la combinaison de différentes solutions ou applications qui interagissent entre elles pour raffiner les données.

La fabrique de données s’appuie sur des API et sur une dimension No Code qui permet de créer des synergies entre des applications et des services variés qui permettent de transformer les données pour en extraire la quintessence de la connaissance tout au long de leur cycle de vie. Très schématiquement, la Data Fabric peut être comparée à une raffinerie avec ses assemblages de tuyaux hétéroclites.

Qu’est-ce que le Data Mesh ?

La paternité du concept de Data Mesh est attribuée à Zhamak Dehghani de Thoughtworks. Dès la fin 2018, la définition était posée. Le principe ? Une nouvelle approche de l’architecture des données, un nouveau mode d’organisation fondé sur le maillage des données. Le Data Mesh repose sur la création d’une structure des données multi-domaines. Les données sont cartographiées, identifiées et réorganisées en fonction de leur usage, de leur cible ou de leur exploitation éventuelle.

Le Data mesh s’appuie sur des principes fondamentaux : le propriétaire des données ou Data Owner, le self-service et l’interopérabilité. Ces trois principes permettent de créer une gestion décentralisée de la donnée. L’avantage ? Faire naître des interactions entre différents domaines de données disparates pour générer toujours plus d’intelligence.

Les principales différences entre Data Fabric et Data Mesh

Pour bien comprendre les différences qui opposent Data Fabric et Data Mesh, commençons par évoquer ce qui les rapprochent. Dans les deux cas, il n’existe pas de solution « clés en mains ».

Alors que la Data Fabric repose sur un écosystème composable de solutions logicielles d’exploitation de la données, le Data Mesh est un mode d’organisation et de gouvernance de la data. Dans le cas de Data Mesh, les données sont stockées de manière décentralisée dans leurs domaines respectifs au sein d’une entreprise. Chaque nœud dispose d’un stockage local et d’une puissance de calcul, et aucun point de contrôle unique n’est nécessaire pour le fonctionnement.

Dans le cas d’une Data Fabric en revanche, l’accès aux données est centralisé avec des clusters de serveurs à haut débit pour le réseau et le partage de ressources hautes performances. Sur le plan de l’architecture de données, il existe également des différences. Ainsi, Data Mesh introduit une perspective organisationnelle, indépendante des technologies spécifiques. Son architecture suit une conception axée sur le domaine et une réflexion sur les produits.

S’ils répondent à des logiques différentes, Data Mesh et Data Fabric servent un même objectif d’exploitation optimale de vos actifs data. En ce sens, malgré leurs différences, il ne faut surtout pas les opposer mais plutôt les considérer comme complémentaires.

Les métadonnées vues par les géants du Web

Les métadonnées vues par les géants du Web

L’analyse du cycle de vie des données fait partie des éléments les plus difficiles à mettre en oeuvre par les entreprises ces dernières années.

Les organisations à la pointe de l’innovation par la donnée telles que Uber, LinkedIn, Netflix, Airbnb ou encore Lyft ont également perçu la valeur des métadonnées dans l’ampleur de ce défi.

Elles ont ainsi développé une gestion des métadonnées à l’aide de plateformes dédiées. Fréquemment développées de manière custom, elles facilitent l’ingestion, l’indexation, la recherche, l’annotation et la découverte des données afin de maintenir des jeux de données de haute qualité.

Des exemples ci-dessous ressortent une constante partagée : la difficulté, accrue par la volumétrie et la variété, à transformer les données de l’entreprise en connaissance exploitable.

Voyons ensemble l’analyse et le contexte de ces grands du Web :

Uber

Chaque interaction sur la plate-forme Uber, qu’il s’agisse des VTC ou des livraisons de repas à domicile est basée sur les données. Grâce à leur analyse, les données permettent des expériences utilisateurs plus fiables et plus pertinentes.

Uber en chiffres, cela représente :

  • des milliers de milliards de messages Kafka par jour,
  • des centaines de pétaoctets de données dans HDFS dans des data centers,
  • des millions de requêtes analytiques hebdomadaires.

Cependant, la volumétrie de données générée ne suffit pas à elle seule à tirer parti des informations qu’elles représentent ; pour être utilisées de manière efficace et efficiente, les données nécessitent plus de contexte pour prendre des décisions commerciales optimale.

Pour fournir des informations supplémentaires, Uber a donc développé “Databook”, la plateforme interne d’Uber qui collecte et gère les métadonnées sur les jeux de données internes, afin de transformer les données en connaissances.

La plateforme Databook est conçue pour permettre aux employés d’Uber d’explorer, de découvrir et d’utiliser efficacement les données de chez Uber.

Databook garantit le contexte sur les données – ce qu’elles signifient, leur qualité, etc. – pour les milliers de collaborateurs qui essaient de les analyser. En bref, les métadonnées de Databook permettent aux parties prenantes des données de passer de l’affichage de données brutes à des connaissances exploitables.

Dans l’article « Databook: Turning Big Data into Knowledge with Metadata at Uber », l’article conclut que l’un des plus gros défis du Databook était de passer d’une mise à jour manuelle du répertoire de métadonnées à l’automatisation.

Airbnb

Lors d’une conférence menée en mai 2017, John Bodley, Data Engineer chez AirBnB, exposait les nouvelles problématiques issues de la forte croissance de la société : celles d’un paysage confus et non unifié qui ne permettait pas d’accéder à l’information toujours plus importante.

Que faire de toutes ces données collectées quotidiennement ? Comment les transformer en une force pour tous les employés d’Airbnb ?

Une équipe dédiée s’est mise en ordre de bataille pour développer un outil qui démocratiserait l’accès aux données au sein de l’entreprise. Leur travail s’est à la fois fondé sur la connaissance des analystes et leur capacité à comprendre les points critiques et sur celle des ingénieurs, à même de proposer une vision plus technique de l’ensemble. Au cœur du projet, des interviews des employés et de leurs problématiques ont été menées.

De cette enquête est ressortie : une difficulté à trouver les informations dont les collaborateurs avaient besoin pour travailler, et des démarches encore trop tribales dans le partage et la détention d’informations.

Pour répondre à ces enjeux, AirBnB a créé le Data Portal, plateforme de gestion de métadonnées. Le Data Portal centralise et partage ces informations via cette plateforme en self-service.

Lyft

La société Lyft est un service de VTC. Sur le marché américain, elle est le principal concurrent d’Uber.

Lyft est partie d’un constat d’inefficience dans l’accès aux données pour ses profils analytiques. Ses réflexions se sont axées sur la mise à disposition de la connaissance des données pour optimiser ses processus. En quelques mois seulement, l’initiative de proposer une interface de recherche de données a porté des fruits concrets sur ces 2 grands défis :

La productivité – Que ce soit pour créer un nouveau modèle, instrumenter une nouvelle métrique ou effectuer une analyse ad hoc, comment Lyft peut utiliser ces données de la manière la plus productive et la plus efficace possible ?

La conformité – Lors de la collecte de données sur les utilisateurs d’une entreprise, comment Lyft peut se conformer aux exigences réglementaires croissantes et préserver la confiance de ses utilisateurs ?

Dans leur article Amundsen — Lyft’s data discovery & metadata engine, Lyft affirme que la clé ne réside pas dans les données, mais dans les métadonnées !

Netflix

En tant que leader mondial du streaming vidéo, l’exploitation des données chez Netflix est, bien évidemment, un axe stratégique majeur.

Compte tenu de la diversité des sources de données, la plateforme vidéo souhaitait proposer un moyen de fédérer et d’interagir avec ces assets depuis un même outil. Cette recherche de solution a abouti à Metacat.

Cet outil agit comme une couche d’accès aux données et métadonnées depuis les sources de données de Netflix. L’outil permet ses utilisateurs un accès aux données et ce, quelque soit leurs systèmes de stockage grâce à trois fonctionnalités différentes :

  1. L’ajout de métadonnées métier : à la main ou définies par les utilisateurs, des métadonnées métier peuvent être ajoutées via Metacat.
  2. La data discovery : l’outil publie des métadonnées de schéma et métier définies par ses utilisateurs dans Elasticsearch, facilitant ainsi la recherche en texte intégral d’informations dans les sources de données.
  3. La notification de modification de données et audits : Metacat enregistre et notifie toutes les changements apportés sur les métadonnées depuis les systèmes de stockage.

Dans l’article Metacat: Making Big Data Discoverable and Meaningful at Netflix, la firme confime qu’ils sont loin d’avoir fini ! Il y a quelques fonctionnalités supplémentaires sur lesquelles ils doivent encore travailler pour améliorer l’expérience data warehousing :

 

  • Schéma pour fournir l’historique d’un tableau,
  • Fournir des informations contextuelles sur les tableaux pour un meilleur data lineage,
  • Ajouter un support pour les datastores comme Elasticsearch et Kafka.

Vous voulez en savoir plus sur les solutions de data discovery ?

Téléchargez notre livre blanc : « Le Data Discovery vu par les Géants du Web »

Dans ce livre blanc, nous faisons un focus sur le contexte et la mise en œuvre des solutions de data discovery développées par les grandes entreprises du web, dont certaines font partie du célèbre «Big Five» ou «GAFAM» (Google, Apple, Facebook, Amazon, Microsoft).

data-discovery-mockup-FR-no-shadow

Databook : Comment Uber transforme ses données en connaissances exploitables d’entreprise

Databook : Comment Uber transforme ses données en connaissances exploitables d’entreprise

Créée en 2009, Uber est devenue une des entreprises les plus fascinantes au monde ! La startup a complètement changé le monde avec son business model basé sur la mise en relation de personnes proposant des services. Le succès de la firme a même mené à la création du terme “uberisation”, c’est dire !

De service VTC à livraison de commandes de restaurants, il est évident que la stratégie de la plateforme d’Uber est guidée par leurs données. Elles sont effectivement au cœur du business d’Uber, créant de meilleures expériences utilisateur à travers leurs services pour leurs clients, tout en permettant à leurs employés d’être plus efficaces dans leur travail.

Cependant, le Big Data à lui seul n’est pas suffisant pour accomplir la mission de ce géant. Le volume de données généré chez Uber demande qu’elles soient contextualisées et fiables afin de prendre les bonnes décisions stratégiques. Donc, comme beaucoup de “unicorns”, telle que Airbnb avec le Data Portal, l’équipe d’ingénieurs de Uber a développé Databook. Cette plateforme interne a pour objectif de scanner, collecter et agréger les métadonnées afin de voir plus clair sur la localisation des données dans le SI de Uber et leurs référents. Bref, une plateforme qui veut transformer des données brutes en données contextualisées

L’évolution d’Uber (et de ses données)

Depuis 2016, Uber a ajouté plusieurs services à sa plateforme comme Uber Eats et Jump Bikes. Quelques statistiques :

  • 15 millions de courses par jour
  • Plus de 75 millions d’utilisateurs actifs
  • 18 000 employés depuis sa création en 2009

Plus l’entreprise grandit, plus elle génère de la donnée ! Pour s’assurer que leurs data et analytics poursuivent rythme d’une croissance exponentielle basée sur la data, Uber avait besoin d’un système beaucoup plus puissant pour gagner en efficacité dans la recherche et la découverte de données pertinentes.

Ceci a mené à la création de Databook, le curateur de métadonnées d’Uber.

L’arrivée de Databook

La plateforme Databook agrège et gère les métadonnées sur les jeux de données d’Uber. Elle permet aux employés d’explorer, découvrir et utiliser efficacement leurs données. En d’autres termes, Databook veut aider les analysts et tout autre consommateur de données dans l’entreprise à mieux comprendre et contextualiser la ressource qu’il s’apprête à utiliser à l’aide de métadonnées. Les métadonnées de Databook permettent à tous les ingénieurs, data scientists et équipes informatiques de passer de la simple visualisation de leurs données à leur transformation en connaissances exploitables.

 

Databook permet aux employés d’accéder à des métadonnées actualisées et à jour grâce à des imports automatisés. Elles sont collectées principalement depuis Hive, MySQL, Cassandra et quelques autres systèmes de stockage internes. Pour les rendre accessibles et recherchables, Databook propose à ses consommateurs une interface utilisateur avec un moteur de recherche à la Google ou son API RESTful.

 

L’architecture de Databook

L’architecture de Databook est divisée en trois parties: comment les métadonnées sont collectées et stockées, et comment leurs données sont remontées.

Sur le plan conceptuel, l’architecture de Databook a été conçue pour permettre quatre fonctionnalités clés:

  • Extensible : de nouvelles métadonnées, le stockage et les entités sont faciles à ajouter.
  • Accessibilité : les services peuvent accéder à toutes les métadonnées
  • Évolutivité : prendre en compte dans le temps les besoins des utilisateurs et des nouveautés technologique..
  • Puissance et rapidité

Pour aller plus loin sur l’architecture de la plateforme, cliquez ici https://eng.uber.com/databook/

 

L’avenir du Databook ?

Avec le Databook, Uber a réussi à transformer ses métadonnées en super connaissances !

La plateforme a su montrer sa puissance et sa nécessité dans une organisation data-driven. De nouvelles fonctionnalités ne devraient pas tarder à être apportées : les capacités de générer des informations sur les données avec des modèles d’apprentissage automatique et de créer des mécanismes avancés de détection, de prévention et d’atténuation des problèmes. L’avenir du Databook semble radieux !

 

 

Sources

Vous voulez en savoir plus sur les solutions de data discovery ?

Téléchargez notre livre blanc : « Le Data Discovery vu par les Géants du Web »

Dans ce livre blanc, nous faisons un focus sur le contexte et la mise en œuvre des solutions de data discovery développées par les grandes entreprises du web, dont certaines font partie du célèbre «Big Five» ou «GAFAM» (Google, Apple, Facebook, Amazon, Microsoft).

data-discovery-mockup-FR-no-shadow