Dans tout projet de développement informatique la mise en place rapide d’un vocabulaire commun est :

– un facteur clé de succès (pour éviter les incompréhensions et les ambiguïtés) ;

– un gage de productivité (pour éviter que chacun ne doive se livrer aux mêmes recherches sur le sens des différents concepts intervenant dans le projet) ;

– un gage de qualité en uniformisant toute une série de conventions et contraintes à respecter par tous, ceci en vue d’éviter les interprétations divergentes.

Cette problématique est adressée en construisant un glossaire projet.

Un data dictionary n’est rien d’autre qu’un subset de ce glossaire, dont le scope est centré sur les données, matière première des applications à construire.

Un data dictionary est un repository qui contient des données sur les données (soit des méta données).

Les données traditionnellement stockées dans un data dictionary sont, sans être exhaustif :

• les noms des entités de données et les tables correspondantes de la ou des bases de données ;
• les attributs des entités et les colonnes correspondantes dans les tables ;
• les relations entre entités ;
• les dupliquas éventuels (auquel cas il convient de préciser la source maître) ;
• la signification métier des données, éventuellement dans plusieurs langues ;
• les domaines de valeurs si des contraintes existent de ce point de vue ;
• les autres contraintes (telles que les contrôles croisés entre données);
• les libellés à utiliser dans les écrans ;
• les dispositifs d’alimentation et de consultation ;
• les schémas XSD éventuels;
• …

Il est facile de comprendre que la présence d’un data dictionary aura un effet significatif immédiat sur les équipes de développement. Ainsi, par exemple, les développeurs sauront où aller chercher les données et quels intitulés leur donner dans les écrans. De même, quels contrôles appliquer dans les écrans d’encodage. Le data dictionary peut aller jusqu’à inclure les traductions des libellés dans les différentes langues utilisées par l’organisation.

Faut-il insister sur les heures perdues par tout un chacun lorsqu’une information vitale pour l’exercice de son activité est absente ou difficile à localiser ? Faut-il mettre en évidence les heures perdues à chercher et rechercher une information sortie de sa mémoire en interpellant / distrayant régulièrement des collègues (avec les effets collatéraux sur la productivité de ceux-ci) ou en « fouinant » dans une documentation de qualité médiocre ?

Faut-il aussi insister sur les effets absolument pervers de documentations personnelles construites par les uns et les autres sur de l’information en fait utile à tous ? Elles sont le plus souvent parcellaires, dispersées et soumises à interprétation personnelle, avec bien entendu des risques de désynchronisation par rapport à la dernière vérité et toutes les conséquences qui peuvent en découler en termes de divergence dans les implémentations des différentes parties d’un même projet.

Beaucoup d’efforts dans le cadre du master data management pourraient sans doute être épargnés si une attention plus grande était portée à l’effort transversal de documentation sur les données.

Les approches Agile, qui mettent exagérément l’accent sur la réduction du « time to market » au détriment de la qualité et de la documentation ne contribuent malheureusement pas à aller dans ce sens. Avec inévitablement des conséquences sur ce que j’appellerai “la dette fonctionnelle sur les données” et les efforts qui devront être fournis pour la corriger. Mieux vaut prévenir que guérir.

Dans le cadre des dispositifs B2B destinés à supporter les échanges entre partenaires, la présence d’un data dictionary est un facteur de succès déterminant. Comment en effet faire adhérer l’ensemble des partenaires à un format canonique sur le bus d’échange si celui-ci n’est pas clairement défini dans un data dictionary. Le glossaire de données (c’est le nom que nous lui avons donné) mis en place pour la Sécurité Sociale belge est là pour en témoigner. Vu le nombre d’intervenants impliqués, ce dispositif s’est avéré indispensable pendant la phase de développement et tout autant aujourd’hui dans les opérations de maintenance trimestrielle.

Bien entendu les efforts liés au data dictionary se doivent d’être « raisonnables », pour garantir le retour sur investissement d’un strict point de vue budgétaire. Comme pour toute initiative transversale, tout ce qui est fait doit être directement utile aux projets. Cela suppose une attention permanente à la maîtrise de sa complexité pour en garantir la facilité d’utilisation et de maintenance, sans quoi il sera vite abandonné par ceux que l’on veut servir.

J’espère vous avoir convaincu que le data dictionary, et au delà le glossaire d’enterprise, sont des initiatives transversales amplement justifiées. Elles ont un coût, certes, mais leur retour sur investissement est prouvé.

Dans un prochain blog nous nous intéresserons à la manière de construire un data dictionary.