Business process management and workflow automation diagram with gears and icons with connection line network in background. Manager touching interface

Les 7 mensonges de fournisseurs de Data Catalog – n°6 – Un Data Catalog doit s’appuyer sur l’automatisation

juillet 9, 2021

Le marché du Data Catalog a beaucoup évolué depuis ses débuts, et ce composant est désormais identifié comme une brique essentielle dans le déploiement d’une stratégie data-centric.

Victime de son succès, ce marché a attiré un grand nombre d’acteurs opérant sur des marchés adjacents et qui ont revu leur positionnement marketing pour se présenter comme solution de Data Catalog.

En réalité, faibles sur les promesses du Data Catalog, ils cherchent à convaincre, avec un succès proportionnel à leurs moyens marketing, qu’un Data Catalog n’est pas simplement un outil de recherche ultra-performant destiné aux équipes data, mais une solution intégrée susceptible d’adresser tout un tas d’autres sujets.

C’est le discours de ces vendeurs de Data Catalog de la dernière heure que l’on souhaite déconstruire dans cette série d’articles.

Voici selon nous, les 7 principaux mensonges des vendeurs de Data Catalog :

  1. un Data Catalog est une plateforme de gouvernance des données,
  2. un Data Catalog permet de mesurer et piloter la qualité des données,
  3. un Data Catalog permet de gérer la conformité réglementaire,
  4. un Data Catalog permet de requêter directement les données,
  5. un Data Catalog permet de modéliser l’architecture logique et les processus métiers autour de la data,
  6. un Data Catalog est un outil collaboratif de cartographie et de gestion de métadonnées impossible à automatiser,
  7. un Data Catalog est un projet long, complex et très couteux.

Un Data Catalog doit s’appuyer sur l’automatisation

Certains vendeurs de Data Catalogs, dont la culture vient plutôt du monde de la cartographie, développent une rhétorique selon laquelle l’automatisation est un sujet secondaire, qui peut être adressé dans un second temps.

Ils vous expliqueront qu’il suffit de quelques imports de fichiers manuels, d’un peu d’huile coude et d’une communauté d’utilisateurs collaborant sur leur outil pour alimenter et utiliser le catalogue.

Un peu d’arithmétique permet de bien comprendre pourquoi cette approche est vouée à l’échec dans une organisation data-centric.

Un data lake actif, même de taille modeste, contient rapidement, sur ses différentes couches, plusieurs centaines voire milliers de jeux de données. A ces jeux de données viennent s’ajouter ceux des autres systèmes (bases de données applicatives, API diverses, CRMs, ERPs, no-SQL, etc.) que l’on souhaite généralement intégrer dans le catalogue.

Les ordres de grandeur dépassent rapidement plusieurs milliers voire dizaines de milliers de jeux de données. Chaque jeu de données contient à son tour plusieurs dizaines de champs (ou colonnes, si vous préférez). Jeux de données et champs représentent donc à eux seuls plusieurs centaines de milliers d’objets (on pourrait également comptabiliser les autres actifs: modèles ML, tableaux de bord, rapports, etc.).

Pour que le catalogue soit utile, il ne suffit pas d’inventorier tous ces objets.

 

Il faut également leur associer toutes les propriétés (métadonnées) qui permettront aux utilisateurs finaux de trouver, comprendre et savoir exploiter ces actifs. Les métadonnées sont de plusieurs natures: informations techniques, classification métier, sémantique, sécurité, sensibilité, qualité, normes, usages, popularité, contacts, etc.

On parle donc là aussi, pour chaque actif, de plusieurs dizaines de propriétés. Faites le calcul: au final, il s’agit de millions d’attributs à définir, puis maintenir.

Une telle volumétrie à elle seule devrait disqualifier irrévocablement l’approche manuelle.

Mais ce n’est pas tout. Le stock d’actifs informationnels n’est pas statique. Il grossit en permanence. Dans une organisation data-centric, chaque jour, des jeux de données sont créés, d’autres sont modifiés ou déplacés.

Le catalogue doit refléter ces changements. A défaut, son contenu sera en permanence obsolète, et les utilisateurs finaux ne l’adopteront pas (qui ferait confiance à un catalogue dont le contenu est structurellement incomplet et faux?).

Si vous pensez que votre organisation est en mesure d’absorber la charge nécessaire pour maintenir le catalogue à jour, très bien. Sinon, nous vous invitons vivement à vérifier très tôt le niveau d’automatisation proposé par les différentes solutions que vous évaluez.

 

Que peut-on automatiser dans un Data Catalog?

En matière d’automatisation, la capacité la plus fondamentale, c’est l’inventaire. Un Data Catalog doit pouvoir scanner en permanence toutes vos sources de données, et mettre à jour automatiquement l’inventaire des actifs (jeux de données, structures et métadonnées techniques à minima) pour refléter la réalité opérationnelle des systèmes qui les hébergent.

Croyez-nous: un Data Catalog qui ne sait pas se connecter à vos sources de données deviendra vite inutile, car son contenu sera toujours douteux.

 

Une fois l’inventaire traité, la question suivante est de savoir comment automatiser l’alimentation du métamodèle. Sur ce plan, et au-delà des métadonnées techniques, une automatisation intégrale est difficilement imaginable.

Mais il reste possible de réduire de façon significative la charge de travail nécessaire à la maintenance du métamodèle.

La valeur de certaines propriétés (ou attributs) peut ainsi être déterminée en appliquant simplement des règles au moment de l’intégration des objets dans le catalogue (on sait par exemple que les jeux de données provenant de tel système appartiennent à telle classification métier, sont destinés à tel type d’usage, ou sont sous la responsabilité de tel individu).

Il est également possible de suggérer des valeurs de propriétés en utilisant des algorithmes plus ou moins sophistiqués (détection de types logiques, analyse sémantique, pattern matching sur le contenu du catalogue, etc.).

Enfin, il est souvent possible d’alimenter une partie du catalogue en s’intégrant aux systèmes produisant ou contenant de la métadonnées. Ce peut être le cas par exemple pour les mesures de qualité (qui peuvent être intégrées dans le catalogue au moment où elles sont réalisées), pour les informations de lineage (connues par votre pipeline ou votre ETL), pour votre ontologie métier (qui peut être gérée dans un autre logiciel spécialisé), etc. Pour que cette approche soit possible, le Data Catalog doit être ouvert, et proposer un jeu d’APIs complet permettant de mettre à jour les métadonnées depuis d’autres systèmes.

Take Away

Un Data Catalog recense des millions d’informations sur un patrimoine en mutation permanente.

Maintenir ces informations manuellement est virtuellement impossible, ou extrêmement coûteux. Sans automatisation au moins de l’inventaire, le contenu du catalogue sera en permanence douteux, et les équipes data ne l’adopteront pas.

 

 

Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !

0 commentaires

zeenea logo

At Zeenea, we work hard to create a data fluent world by providing our customers with the tools and services that allow enterprises to be data driven.

zeenea logo

Chez Zeenea, notre objectif est de créer un monde “data fluent” en proposant à nos clients une plateforme et des services permettant aux entreprises de devenir data-driven.

Be(come) Data Fluent

Read the latest trends on big data, data cataloging, data governance and more on Zeenea’s data blog.

Join our community by signing up to our newsletter!

Devenez Data Fluent

Découvrez les dernières tendances en matière de big data, data management, de gouvernance des données et plus encore sur le blog de Zeenea.

Rejoignez notre communauté en vous inscrivant à notre newsletter !

LET’S GET STARTED

Make data meaningful & discoverable for your teams

Démarrer MAINTeNaNT

Donnez du sens à votre patrimoine de données