Un métamodèle universel et statique ne peut être smart
Le nombre de métadonnées nécessaire pour exploiter efficacement les actifs informationnels peut être considérable. Et ces métadonnées seront spécifiques à chaque organisation, voire à des populations distinctes dans une même organisation. Par exemple, un business analyst ne cherchera pas nécessairement les mêmes informations qu’un ingénieur ou un responsable produit.
Partant de là, chercher à définir un métamodèle universel ne nous semble pas spécialement malin. En effet, un tel métamodèle devrait s’adapter à tous les contextes imaginables, tombant fatalement dans l’un des trois écueils classiques de l’universalisme :
- Un simplisme excessif, qui ne permettra pas à terme de couvrir tous les cas d’usage ;
- Un niveau d’abstraction excessif, potentiellement capable de s’adapter à de nombreux contextes mais au prix d’un apprentissage long et difficile des concepts – difficilement compatible avec le déploiement à grande échelle du catalogue ;
- Un niveau d’abstraction trop faible, qui oblige à multiplier les concepts concrets en combinant les notions issues d’un grand nombre de contextes différents – mais qui pour beaucoup seront inutiles dans un contexte particulier, compliquant inutilement le métamodèle, potentiellement au point de le rendre incompréhensible.
La métamodélisation Smart, selon nous, doit permettre d’adapter le métamodèle à chaque contexte, et de l’enrichir à mesure que les cas d’usage, ou le niveau de maturité de l’organisation se développent.
L’approche organique du métamodèle
Un métamodèle est un domaine de connaissance, et la structure formelle d’un modèle de connaissance porte le nom d’ontologie.
Une ontologie définit un ensemble de classes d’objets, leurs attributs et les relations qu’elles peuvent avoir entre elles. Dans un modèle universel, l’ontologie est statique – les classes, les attributs et les relations sont prédéfinis, avec un niveau d’abstraction et de complexité variable.
Chez Zeenea, nous avons choisi de ne pas nous appuyer sur une ontologie statique, mais plutôt de nous reposer sur un graphe de connaissance complètement évolutif.
Au démarrage, le métamodèle est donc volontairement très simple – il ne comprend qu’une poignée de types, représentant les différentes classes d’actifs informationnels (sources de données, jeux de données, champs, tableaux de bords), chacun doté de quelques attributs que nous jugeons universels (nom, description, contacts).
Ce métamodèle de base est complété automatiquement par les métadonnées techniques extraites des sources de données, qui varient en fonction de la technologie sous- jacente (les métadonnées techniques d’une table dans un data warehouse ne sont pas strictement les mêmes que celles d’un fichier parquet dans un data lake).
Cette métamodélisation que l’on pourrait qualifier d’organique, est selon nous la façon la plus smart d’aborder la problématique de l’ontologie dans un data catalog. Elle présente en effet plusieurs intérêts majeurs :
- Le métamodèle peut être complètement adapté à chaque contexte, s’appuyant sur une modélisation souvent pré- existante, intégrant la nomenclature et la terminologie maison sans nécessiter un cycle d’apprentissage long et coûteux ;
- Le métamodèle n’a pas besoin d’être intégralement défini pour démarrer l’exploitation du catalogue – il suffira de se focaliser sur les quelques classes d’objets et les quelques attributs nécessaires pour couvrir les premiers cas d’utilisation, puis d’augmenter ce modèle à mesure que la portée du catalogue se développe ;
- Les feedbacks utilisateurs pourront être intégrés progressivement, améliorant l’adoption du catalogue, et par conséquent le retour sur investissement de la gestion de métadonnées.
L’ajout d’attributs fonctionnels au métamodèle pour faciliter la recherche
Cette approche de la métamodélisation présente des avantages massifs, mais également un inconvénient majeur : le métamodèle étant complètement dynamique, il est difficile pour le moteur d’en comprendre la structure, et par conséquent d’assister efficacement les utilisateurs pour l’alimenter et le consommer (ces deux sujets étant au cœur du Smart Data Catalog).
Une partie de la solution concerne le métamodèle, et notamment les attributs de l’ontologie. Classiquement, les attributs d’un métamodèle sont définis par leur type technique (une date, un chiffre, une chaîne de caractères, une liste de valeurs, etc.). Chez Zeenea, la bibliothèque de types contient bien sûr ces types techniques, mais également des types fonctionnels – un niveau de qualité, un niveau de confidentialité, un caractère personnel, etc.
Utiliser ces types fonctionnels permet au moteur Zeenea de mieux comprendre l’ontologie pour affiner ses algorithmes et adapter la représentation de l’information.
Pour comprendre comment un métamodèle “smart” (malin) renforce les capacités d’un data catalog, téléchargez notre eBook :
“Qu’est-ce qu’un Smart Data Catalog ?” dès maintenant!
