Validation et qualité

La validation

Tout objet entrant dans le périmètre de la solution MDM doit être validé. Cette validation repose sur différentes règles en fonction du cycle de vie métier de la donnée (ainsi, dans le paradigme client, les règles de gestion sont différentes pour un prospect et pour un client actif).

On préférera les solutions offrant une grande souplesse dans la mise en œuvre de ces règles. Il est bon que ces règles soient décrites au niveau de la définition du modèle ou par d’autres règles indépendantes et programmatiques, librement appelées par les services de validation, ou encore par des règles portées par un système tiers (autres référentiels ou moteur de règles).

On citera au moins trois types de règles :

• règles syntaxiques ;

• règles de gestion ;

• règles de cohérence.

Les règles syntaxiques reposent sur la vérification du format de l’attribut (par exemple : date, chaîne alphanumérique de six caractères…). Généralement définies au niveau du modèle, elles sont aussi vérifiées par les outils d’intermédiation.

Les règles de gestion sont portées par un algorithme de vérification de la valeur d’un attribut ou de plusieurs attributs. Par exemple, le volume d’un article ne doit pas être supérieur à 1 m³ en s’appuyant sur les attributs hauteur, largeur, et profon-deur. On inclut au sein du référentiel les seules règles communément répandues. Les applications métier restent seules responsables des règles de gestion métier, on ne les réplique pas au sein du référentiel.

Les règles de cohérence sont décrites par des contraintes entre niveaux de don-nées, c’est-à-dire entre données maître, ou données maître et constitutives ou avec les données de paramètres. Par exemple, on vérifiera le lien entre un objet article et le référentiel fournisseurs, entre l’objet constitutif « profil financier » et son objet maître client ou encore la valeur d’un attribut par rapport à un référentiel de para-mètres (devises, pays…). Certaines solutions du marché obligent à supporter toutes les données au sein d’une même instance de serveur pour assurer ce contrôle. Il est préférable d’avoir la possibilité de supporter les différentes données dans des référen-tiels sur des serveurs distincts.

Traitements qualitatifs

La solution de gestion des données de référence doit permettre le traitement en volume et au fil de l’eau des aspects qualitatifs de la donnée (voir le chapitre sur le DQM).

• Conformation – Mise en conformité des formats en fonction d’une norme interne ou externe. Exemple : conformation à la norme ISO/IEC 15434 sur les adresses postales.

• Dédoublonnage – Il peut prendre deux formes :

– déterministe, s’il répond à une reconnaissance de clef(s) ;

– probabiliste, s’il obéit à des règles complexes, elles-mêmes enrichies éven-tuellement de dédoublonnages précédents.

L’identification

Générateur d’identifiant unique (centrale d’identification)

Il convient pour l’entreprise d’avoir un identifiant unique afin de permettre une meilleure réconciliation des identifiants sur l’ensemble du SI et plus encore dans le cas d’échanges avec des partenaires (processus transverse entre commercialisateur et distributeur dans le secteur des Utilities, par exemple).

Les solutions référentielles se comportent comme toutes les applications du point de vue des ID (identifiants). Elles génèrent leurs ID propres. Cependant, ces ID ne peuvent pas toujours être utilisés comme identifiants uniques. Deux raisons princi-pales à cela :

• les référentiels peuvent être multi-instanciés. Ainsi, cet ID n’est pas assuré d’être unique ;

• pour les données de référence à durée de vie longue, l’identifiant de référence doit être indépendant de l’application.

Un générateur d’identifiant unique peut ainsi être implémenté au sein de la solution référentielle afin de répondre aux besoins de conciliation. Le référentiel stockera cet ID comme un ID externe, cet ID devient alors le pivot des transcodifi-cations mises à disposition des outils d’intermédiation (voir transcodification dyna-mique).

La centrale d’identification utilisera un algorithme connu et maîtrisé par l’entre-prise, permettant ainsi son portage dans le temps ou la reprise de données en cas de

« crash ».

Il est préférable que les identifiants générés par la centrale d’identification soient non signifiants. On transgressera éventuellement cette règle dans le cas de référen-tiels multi-instanciés afin de donner un indicatif (de zone par exemple) comme dis-criminant des ID de chaque instance.

L’identifiant d’instance

Une instance (ou occurrence) de donnée évolue dans le temps (modification d’adresse par exemple). Ces évolutions ne modifient pas l’unicité de cette donnée, l’identifiant de la donnée n’est donc pas concerné par une modification sur des attri-buts non-discriminants. Ainsi, le fait que M. Jean Dupont déménage de la rue des Chaumes à Aix en Provence pour l’avenue du Moulin à huile à Marseille ne remet pas en question son identité.

Nous préconisons d’identifier aussi les instances de donnée à chaque modifica-tion. Ainsi, le contenu d’une instance à un instant t sera identifié lui aussi de manière unique ce qui permettra notamment son suivi (voir « contrôle de

113 6.1 Fonctionnalités d’une solution de gestion de données de référence

synchronisation », section 6.1.7), ainsi que l’enregistrement de l’identifiant de l’ins-tance précédente lors de l’historisation. Certaines applications MDM offrent native-ment cet identifiant (EBX Platform par exemple).

Figure 6.3 – Illustration identifiant d’instance

La transcodification

La mise en œuvre d’une solution de MDM amène à reconsidérer certaines règles acquises du système d’information. En la matière, ces règles concernent généralement l’usage et le périmètre des fonctions auparavant attribuées à d’autres outils de traite-ment des données (EAI, ETL, workflow…). La transcodification est de deux natures :

• transcodification des tables (ou transcodification statique) ;

• transcodification des identifiants (ou transcodification dynamique).

Transcodification des tables (transcodification statique)

Elle assure la transcodification entre N champs d’un objet source et M champs de l’objet cible suivant une grille prédéterminée et finie de correspondances entre les valeurs sources et cibles.

Figure 6.4 – Exemples de transcodifications statiques

Au périmètre d’un projet, la transcodification des tables ne semble pas poser de problèmes architecturaux. Elle semble naturellement supportée et réalisée par les outils d’intermédiation. Au périmètre du SI, la normalisation du middleware, notam-ment dans un contexte multi-référentiels, peut conduire à une analyse différente.

Un outil de transcodification est en pratique un référentiel des tables et listes de valeurs de l’ensemble des applications du SI, décrivant les liens entre les champs de tables d’une même catégorie (devises, pays…) . Ainsi, plutôt que de limiter la trans-codification statique à l’intermédiation, il est possible de bâtir un référentiel de tables (ou référentiel de paramètres) incluant par exemple :

• un service de transcodification à destination de l’intermédiation ;

• un service de gestion des tables par IHM ou par fichier d’import/export permettant une gestion centrale de l’ensemble des tables du SI ;

• un service de diffusion des tables à destination des applications du SI ;

• un service de validation des contraintes pour tout processus consommateurs.

Un tel référentiel offrira, de plus, des fonctions standard telles que l’édition des tables (export) ou le pilotage (par exemple, une alerte pour vérification des tables ISO à chaque début de mois).

Figure 6.5 – Référentiel de paramètres

En pratique, et par souci de performance, on utilisera le référentiel de paramètres comme outil de gestion et ce référentiel alimentera les outils d’intermédiation, bien plus performants pour la réalisation de l’opération de transcodification.

115 6.1 Fonctionnalités d’une solution de gestion de données de référence

Transcodification d’identifiants (transcodification dynamique)

Elle porte sur les identifiants d’objets : client ou fournisseur par exemple. Cette transcodification ou key mapping est la capacité offerte par le référentiel de pouvoir rapprocher ces ID entre eux.

Cette capacité dépend des rapprochements amont et aval offerts par la solution et son architecture de mise en œuvre :

• les rapprochements amonts sont liés aux objets sources et à leurs éventuelles fusions ;

• les rapprochements avals sont liés aux ID des objets applications consomma-trices et à leur capture par le référentiel.

Le rapprochement amont repose sur les capacités de « matching » (recoupe-ment) offertes par les algorithmes déterministes ou DQM puis sur le stockage et l’historisation des ID externes (sources) et internes (ID unique).

Pour l’aval, les identifiants ne sont pas prédéfinis et doivent être récupérés au moment de la création d’un identifiant par les applications consommatrices afin de stocker la relation entre les objets échangés.

Ainsi, en fonction du type d’architecture nous aurons les types de rapprochement suivants :

• centralisation – rapprochement aval seulement ;

• coopération – rapprochement amont et aval ;

• consolidation – rapprochement amont principalement, aval si connecté à un système transactionnel.

Le référentiel en tant que source de vérité est maître des identifiants. Cela est notamment sensible avec les référentiels de consolidation ou en coopération. En effet, ces derniers focalisent des données pouvant provenir de sources distinctes, générant potentiellement des doublons. La mise en œuvre d’un outil de DQM et de règles de dédoublonnage permet de fusionner ces objets. Cependant, qu’en est-il des identifiants des objets d’origine ? De plus, les référentiels fusionnent rarement sur un identifiant existant mais déversent les données des identifiants corrélés dans un nou-vel objet portant un nounou-vel identifiant. Enfin, les objets créés dans les applications consommatrices ne peuvent être effacés car ils participent aux transactions au sein de l’application consommatrice.

On préconisera donc de résoudre les rapprochements amont avant d’émettre un objet vers les applications consommatrices. Ceci n’est pas toujours possible, le cas le plus complexe sera celui illustré ci-dessous.

Figure 6.6 – Étape 1 : Simple rapprochement aval sur objet d’origine App A

Figure 6.7 – Étape 2 : Simple rapprochement aval sur objet d’origine App B

117 6.1 Fonctionnalités d’une solution de gestion de données de référence

Figure 6.8 – Étape 3 : Rapprochement amont a posteriori

De la figure 6.8, on notera qu’il faudra établir une règle de transformation quand une occurrence du référentiel possède plusieurs ID cibles pour une même application consommatrice (diriger vers le dernier ID créé par exemple).

Avant la mise en œuvre de référentiels, l’opération de transcodification était gérée et réalisée par les outils d’intermédiation. L’introduction d’un référentiel remet cette vision en cause. Le référentiel est source de vérité pour les ID donc pour la transcodification. Mais l’opération de mapping entre ces ID a lieu au sein de la cou-che d’intermédiation afin de délivrer le bon ID aux applications consommatrices.

Ainsi, les architectes sont amenés à :

• positionner le stockage et les liens entre identifiants au niveau du référentiel, en offrant un service de transcodification d’identifiant aux outils d’intermé-diation (cas A, attention ce cas peut générer de nombreux appels de services et ainsi générer une contrainte de performance sur le référentiel) ;

• stocker les identifiants dans le référentiel et conserver la réalisation de la transcodification (le mapping lui-même) au sein des outils d’intermédiation.

Ce qui se traduit par deux sous-possibilités :

– émettre au sein du message l’ensemble des ID et l’intermédiation fait le tri (solution que nous préférons) (cas B) ;

– ou dupliquer les ID détenus vers la couche d’intermédiation au fur et à mesure de leur consolidation au sein du référentiel (cette dernière solution étant moins conseillée).

Illustrons les cas A et B par les figures 6.9 et 6.10.

Figure 6.9 – Cas A : service de transcodification sur le référentiel

119 6.1 Fonctionnalités d’une solution de gestion de données de référence

Figure 6.10 – Cas B : émission de l’ensemble des ID et transcodification par l’intermédiation

Hierarchy Mapping

Le hierarchy mapping est la capacité de rapprocher entre elles des données ou des familles de données au travers des hiérarchies ou nomenclatures desquelles elles participent ou auxquelles elles sont rattachées.

Par exemple, les catalogues de deux filiales d’un même groupe de distribution peuvent avoir une structure différente mais on veut pouvoir comparer des familles de produits semblables entre elles. On pourra ainsi être amené à rapprocher les structu-res suivantes afin de comparer les ventes d’eaux en bouteille 1,5 litre :

• filiale A

• Alimentaire/Liquide/Non alcoolisé/Eaux/Non gazeux/1,5 litre ;

• filiale B

• PGC/Liquide/Eaux/Eaux plate/Bouteille plastique/1,5 litre ;

• PGC/Liquide/Eaux/Eaux plate/Bouteille verre/1,5 litre.

Le référentiel doit donc permettre de traiter les informations de l’ensemble des objets rattachés aux structures de catalogue de chaque filiale.

Ainsi, la capacité à gérer de multiples hiérarchies et nomenclatures doit se dou-bler d’une capacité à les lier entre elles.