Un Data Catalog n’est pas une solution de Modélisation Business
Certaines organisations, souvent de grande taille, ont investi durant des années dans la modélisation de leurs processus métier et de leur architecture de l’information. Elles ont développé plusieurs couches de modèle (conceptuel, logique, physique) et mis en place une organisation permettant de maintenir et diffuser ces modèles à certaines populations (experts métier et IT principalement).
Je ne doute absolument pas de la valeur de ces modèles.
Ils jouent un rôle clé dans l’urbanisation, la définition de schémas directeurs, le pilotage du SI et la conformité réglementaire. Mais on doute radicalement de la capacité des outils de modélisation à fournir un Data Catalog décent.
Il y a là aussi un phénomène de marché: certains acteurs historiques de la modélisation métier cherchent à élargir leur offre en se positionnant sur le marché du Data Catalog. Après tout, ils gèrent déjà un grand nombre d’informations sur l’architecture physique, les classifications métier, les taxonomies d’actifs, les glossaires et ontologies, le lignage des informations, les processus et rôles, etc.
Mais je leur vois deux défauts à mon sens rédhibitoires.
Le premier est organique. Par nature, les outils de modélisation définissent des modèles, qui sont conçus par le haut (approche top- down) pour décrire l’organisation de l’information dans un SI. Aussi précis soit-il, un modèle reste un modèle: une représentation simplifiée de la réalité.
Ce sont des outils de communication très précieux dans beaucoup de domaines, mais il leur manque l’ancrage dans la réalité opérationnelle qui me semble indispensable pour tenir les promesses d’un Data Catalog (permettre aux équipes data de trouver, localiser, comprendre et savoir exploiter les jeux de données présents dans leur organisation).
Le second défaut est ergonomique.
Un outil de modélisation est un outil complexe, manipulant un nombre important de concepts abstraits, et qui demande une courbe d’apprentissage importante. C’est un outil d’expert.
On peut bien sûr imaginer des simplifications ergonomiques permettant de l’ouvrir à un public plus large. Mais la complexité intrinsèque de l’information ne disparaîtra pas. Comprendre l’information fournie par ces outils demande une maîtrise préalable des principes du modèle (classes d’objets, niveaux logiques, nomenclatures, plan d’urbanisation, etc.). C’est un effort conséquent pour les équipes data – et un effort dont l’intérêt est difficile à justifier sur le plan opérationnel.
La vérité, c’est que convertis en Data Catalog, les outils de modélisation souffrent d’un énorme problème d’adoption par les équipes opérationnelles (elles doivent faire des efforts conséquents pour apprendre à l’utiliser, pour finalement ne pas y trouver ce qu’elles cherchent).
Un prospect nous a récemment présenté le métamodèle qu’il avait conçu, en nous demandant s’il était possible de l’implémenter dans Zeenea. Dérivé de ses modèles métier, le métamodèle comprenait plusieurs dizaines de classes d’objets, et des milliers d’attributs. A la question, la réponse formelle était plutôt oui (le métamodèle de Zeenea est très souple).
Mais nous avons surtout passé du temps à le dissuader de se lancer sur cette voie: un métamodèle aussi sophistiqué risque selon moi de dérouter les utilisateurs finaux, et de faire échouer le projet de Data Catalog…
Faut-il pour autant oublier les modèles métier pour la mise en place d’un Data Catalog? Absolument pas.
Mais il faut se rappeler que les modèles métier existent pour répondre à certaines problématiques, et le Data Catalog à d’autres.
Certaines informations contenues dans les modèles permettent de structurer le catalogue et d’enrichir son contenu de façon très précieuse (je pense en particulier aux responsabilités, aux classifications et bien sûr aux glossaires métier). La bonne approche est donc de concevoir le métamodèle du catalogue en se focalisant exclusivement sur la valeur ajoutée aux équipes data (en se posant systématiquement la question suivante: cette information permet-elle de trouver, localiser, comprendre et exploiter correctement les données?), puis d’intégrer l’outil de modélisation et le catalogue afin d’automatiser l’alimentation de certains éléments du métamodèle déjà présents dans les modèles métier.
Take Away
Aussi utiles et complets soient-ils, les modèles métier restent des modèles: ils reflètent imparfaitement la réalité opérationnelle des systèmes, et peinent à fournir un catalogue de données efficace.
Les outils de modélisation, ainsi que les modèles métier, sont trop complexes et trop abstraits pour être adoptés par des équipes data. Définissez le métamodèle de votre catalogue pour répondre aux questions des équipes data, et alimentez certains aspects du métamodèle en vous intégrant à vos modèles métier.
Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !
