AXOPEN

Les différents modèles de gestion des données de référence (MDM)

1.Qu'est ce qu'une donnée de référence

On distingue trois grands types de données de référence qui appellent différents types de gouvernance et de socle technique :

– Les données "maitre" sont en général les objets métier principaux ("cœur de métier") d'un domaine fonctionnel. Ces données sont donc au cœur du système d'information et structurent les principales applications. En général, elles sont donc référents dans de nombreuses applications. Exemples: client, article, fournisseur…
 
– Les données "constitutives" sont des données constituées elles-mêmes d'attributs, qui caractérisent en général des données maitre mais aussi d'autres objets métier. Exemple: adresse. Elle peut caractériser des données maitre comme client, fournisseur… mais aussi d'autres objets métier comme interlocuteur (adresse postale) ou bon de livraison (adresse de livraison)…
 
– Les données "paramètre" sont des tables de valeurs ou des nomenclatures. Exemples: codes postaux, codes devises, taux des taxes des communes. Par essence, ce sont les données les plus partagées au sein du système d'information et donc celles qui doivent faire l'objet d'une attention particulière.
 

2.Les différents modèles de gestion des données de référence

Il existe plusieurs modèles de gestion des données de référence au sein d’un système informatique, nous retiendrons dans le cadre de cette étude uniquement les 4 modèles les plus courants : Le modèle réparti, distribué, centralisé et virtuel.

 

2.1.Le modèle réparti

Dans le modèle réparti, chaque application est maître des données de référence du domaine métier qui les concernent et dont elle maîtrise le cycle de vie. Par exemple, dans un système où les clients sont créés par l’application CRM, c’est cette application et uniquement celle-ci qui est le référent de ces données. Toutes les autres applications du SI devront interagir avec cette application pour récupérer les données d’un client (appel synchrone) d’où une problématique de performance importante.

 

Cette solution est conseillée lorsque la qualité des données manipulée (mise à jour) prévaut sur la performance du système.

Modèle répartiFigure 1 : Modèle de gestion des données de référence réparti

 

2.2.Le modèle distribué

 

Dans le modèle distribué, chaque application est maître des données de référence du domaine métier comme dans le modèle réparti. Par contre, lorsqu’une application a besoin d’accéder à une information maîtrisée par une autre application elle accède directement à une copie locale. Ce modèle implique que tout changement d’une donnée de référence doit être diffusé à l’ensemble des applications possédant une copie.

 

Cette solution est conseillée pour les systèmes où la performance en lecture prévaut sur la mise à jour des données.

 

Le système n’ayant pas de point central de vérité mais un ensemble, la supervision fonctionnelle de l’état de synchronisation du système ainsi que la gestion de la diffusion des modifications lors d’une désynchronisation s’avère complexe.

Modèle répartiFigure 2 : Modèle de gestion des données de référence distribué

 

2.3.Le modèle centralisé

Dans le modèle centralisé, les données de référence du SI sont contenue dans une seule application (souvent une solution de MDM) qui va être le point de vérité du système et qui va permettre par la même occasion de mettre en place des solutions de validation des données issues des points acquisitions par l’intermédiaire de workflows humains ou de solutions automatisées.

 

Cette solution est conseillée lorsque le cycle de vie de la donnée ou son contenu nécessite un besoin fort de validation et/ou de supervision.

Modèle répartiFigure 3 : Modèle de gestion des données de référence centralisé

 

2.4.Le modele virtuel

Dans le mode virtuel, lorsqu’une application souhaite obtenir ou modifier une donnée elle s’adresse directement au repository virtuel qui est le seul à connaitre l’emplacement physique de la donnée. Cette solution permet alors en restant dans un mode réparti une supervision quasi-équivalente au mode centralisé. Par contre, les performances ne sont pas au rendez-vous puisque tout accès à une donnée nécessite le passage par ce tiers de médiation que constitue le serveur virtuel. De plus, il est difficile de savoir à un instant donné par quelles applications sont gérées les données de références.

 

Cette solution est conseillée pour les systèmes où la notion de données de référence évolue fréquemment et dans les cas extrêmes cette notion est dynamique (routage par contenu ou par contexte).

Modèle répartiFigure 4 : Modèle de gestion des données de référence virtuel

 

2.5.Synthese des 4 modèles

Critère / Modèle

Modèle réparti

Modèle distribué

Modèle centralisé

Modèle virtuel

Performance en lecture

Mauvaise

Bonne

Moyenne

Mauvaise

Performance en  mise à jour (CUD)

Bonne

Mauvaise (diffusion)

Moyenne

Mauvaise

Supervision fonctionnelle des données

Moyenne

Mauvaise

Bonne

Mauvaise

Avantage(s)

Aucun impact en mise à jour et aucune latence dans la synchronisation du système

Performances en lecture et autonomie des applications

Le référentiel centralisé est le point de vérité du système, il permet de mettre en place des solutions de validation de la donnée

 

Inconvénient(s)

Couplage fort entre les applications et mauvaise performance en lecture

Le système n’a pas de point de vérité et complexité de la reprise sur erreur

Le référentiel centralisé est le Single Point of Failure du système et la gestion des accès concurrents est complexe

Difficulté de mise en œuvre et mauvaises performances