Le duel entre modèle de données et catalogue de données n’appelle-t-il qu’un seul gagnant ?
Souvent confondus et opposés, leur alliance bénéficie pourtant au plus grand nombre
Incipit: Les initiatives visant à décrire les données se confondent et s’opposent à la fois entre les partisans de la modélisation et ceux du catalogage. En dépit de cas d’emplois bien différents, les équipes de gouvernance des données auraient tout intérêt à coordonner les deux approches car leurs bénéfices conjoints dépassent ceux de chaque approche prise unitairement.
Pas d’amalgame
Les métiers sont de plus en plus sollicités pour expliquer et décrire leurs données. D’où une certaine lassitude, voire un agacement de recevoir des architectes, des data owners, des data scientists, ou autres MOA souhaitant comprendre leurs données, comment elles sont liées entre elles, ce qu’ils entendent exactement par « Client » par exemple, en quoi ce terme métier diffère d’un « Prospect », où est la source de référence de telle ou telle donnée, etc.
D’autant que chacun vient avec ses propres besoins et ses méthodes de représentation spécifiques. Toutefois deux approches ressortent régulièrement pour répondre à ce besoin commun de créer et décrire un langage commun autour du patrimoine de données de l’organisation : le modèle de données et le catalogue de données. Présentées trop succinctement, les deux approches se confondent dans leur objectif d’améliorer la connaissance des données. Cette confusion favorise l’impression chez les personnes sollicitées qu’il s’agit d’un doublon de travail et donc d’une perte de temps.
Vu de loin, les deux approches se mélangent et se confondent. Lorsque l’on s’en approche, cette confusion se mue en complémentarité et des signes distinctifs apparaissent alors.
Aussi je vous propose de nous attarder sur les cas d’usage propres à chaque approche afin de les distinguer et de marquer leurs bénéfices respectifs.
Le modèle de données, créer un langage commun
A ma gauche, le modèle de données ! Il est important de distinguer d’entrée de jeu les réalités très diverses que regroupent les modèles de données : Modèle Conceptuel, Modèle Logique, Modèle Physique, Modèle d’Objets Métiers.
Les Modèles Conceptuels, Logiques et Physiques de Données font partie des représentations historiques de l’informatique. Ils permettent aux MOA et MOE de se comprendre dans le cadre du développement d’une application[GE11] . Voici un exemple de MCD:
Le Modèle d’Objets Métiers (MOM) est assez différent, puisqu’il s’exonère de contraintes techniques et applicatives et vise à représenter sous forme d’un modèle relationnel les principaux concepts que le métier manipule (Client, Facture, Calendrier, etc.). Il sert donc de base de discussion entre les métiers, mais également de référence pour des équipes IT afin de modéliser et développer des applications ou des API respectant une sémantique commune et des relations métiers entre les objets manipulés. Le MOM est également un exercice itératif et collaboratif qui permet d’aligner des points de vue métiers divergents. Pour en savoir davantage, je vous recommande un précédent article qui détaille ce qu’est le MOM.
Dans cet article, nous nous concentrerons sur le MOM, puisqu’il est réalisé en dehors d’un contexte projet, et vise à décrire des relations entre concepts métiers. En voici un exemple:
Le catalogue de données, démocratiser l’existant
A ma droite, le catalogue de données ! Il donne de la visibilité sur le patrimoine des données de l’organisation et le rend compréhensible et exploitable à partir des “métadonnées”. Ces données sur les données qui permettent de les contextualiser. Le catalogue est également protéiforme, il comporte deux briques : le Glossaire Métier et le Dictionnaire de Données.
Là où le modèle de données donne une vision d’ensemble d’un réseau d’objets et de relations, le catalogue de données fournit une vue plus “éclatée” car il s’attache à documenter les données à un niveau unitaire. Si l‘exercice peut sembler fastidieux de prime abord, les techniques de balayage des plateformes existantes (ex: datalake) permettent d’automatiser en partie la qualification de ces données.
La composante Glossaire Métier couvre les métadonnées métiers. Elles décrivent les éléments métiers des données de façon à construire une base de connaissances accessible à tous (ex: définition, propriétaire, exigences qualité, localisation du point de vérité).
La composante Dictionnaire de Données capitalise les métadonnées techniques qui permettent aux équipes IT d’analyser la structure et le comportement des données (ex: droits d’accès, rôles utilisateurs, exigences de performance).
Je vous conseille également la lecture d’un article qui vous détaille la meilleure stratégie à suivre pour cataloguer vos données.
Dans le présent article, nous nous concentrerons sur le Glossaire Métier, puisqu’il s’agit de la brique permettant de décrire les données en des termes métiers.
Des outils différents pour des usages différents
Maintenant que nous avons clarifié la description de ces outils, tous deux essentiels à la compréhension des données de l’entreprise, regardons de plus près les différents cas d’usages auxquels ils répondent.
En dépit d’un nombre important de différences, on voit poindre en fin de tableau, un certain nombre de cas d’emplois auxquels peuvent répondre les deux approches. Et si, finalement, il n’était pas pertinent d’associer ces deux démarches ?
Joindre les deux approches pour augmenter la valeur
Je le confesse, la confusion entre ces deux approches vient du fait que la frontière entre elles demeure floue. Un MOM s’accompagne en général de définitions des objets concernés, voire de règles métiers, ce qui en ce sens est synonyme d’un début de catalogage des données.
De la même façon, un catalogue de données quant à lui va tendre à inclure des informations le rapprochant d’un modèle, avec des indications sur les relations avec d’autres données ainsi que les règles d’agrégation ou de calcul qui permettent de modéliser des relations entre les entrées d’un catalogue de données et donc d’aboutir à un modèle de données.
Dans ces deux exemples, on note qu’afin de tirer pleinement parti d’un modèle de données, il convient de regarder comment les données sont effectivement implémentées dans le SI, ce qui requiert un catalogage des données. De même que le catalogage des données est utile pour décrire l’existant (vision AS-IS) mais ne permet pas de décrire la structure cible de ces données (vision TO-BE).
Ce sont justement ces bénéfices réciproques que s’apportent modèle et catalogue de données qui fondent la conviction que nous portons chez Pramana: s’appuyer sur l’approche la plus aboutie ou celle qui répond aux cas d’emplois jugés critiques et anticiper le développement vers la seconde. En prévoyant dès le début la mutualisation des approches, on clarifiera la communication et l’outillage pour supporter ces approches et favorisera l’émergence d’une vue complète de description de données.
Vincent Thorette
Consultant Data
Pramana
