Chapitre 7 – Positionner le référentiel dans le SI
7.4 Pour une insertion progressive du MDM dans les échanges du SI
Insertion du MDM dans le SI
On peut considérer qu’une donnée « voyage » dans le système d’information entre le moment où elle entre dans le SI et son ultime point de consommation.
Dans un SI sans solution de gestion des données de référence, une donnée de référence passe d’application en application au sein du SI transactionnel et jusqu’au SI décisionnel.
Par exemple, dans la grande distribution, une donnée « produit » provient en partie d’un fournisseur et en partie de divers services de l’entreprise (et donc de diverses applications dans le SI) tels que la logistique, les achats ou le marketing.
Cette donnée peut transiter par diverses applications pour finir avec l’application
« ligne de caisse » et le SI décisionnel comme consommateurs ultimes.
155 7.4 Pour une insertion progressive du MDM dans les échanges du SI
Dresser un tel état des lieux, une cartographie de l’existant, permet de mieux identifier où devra se situer la solution référentielle au sein de la chaîne de l’informa-tion (figure 7.14).
Figure 7.14 – Exemple de SI existant de la grande distribution
Cette cartographie de l’existant permet aussi de prévoir un plan de migration afin de rationaliser la « cascade » d’applications. On cherche notamment à mettre toutes les applications source ou consommatrices à un seul niveau du référentiel (en étoile autour du référentiel). Cette « migration » est établie en fonction de la criticité des applications liées, du portefeuille d’applications et de leur calendrier de remplace-ment au sein du SI…
Dans le SI d’une grande entreprise, cette évolution va potentiellement s’étaler dans le temps, sur une longue période, en passant par une (ou plusieurs) étape(s) intermédiaire(s) (figure 7.15) avant d’atteindre une cible (figure 7.16).
Figure 7.15 – Évolution du SI par rapport à la solution référentielle (étape intermédiaire)
Figure 7.16— Évolution du SI par rapport à la solution référentielle (étape finale)
157 7.4 Pour une insertion progressive du MDM dans les échanges du SI
Pour préparer votre « plan de transformation référentiel », identifiez les processus amont (ceux qui participent de la constitution de la donnée) et les processus aval.
Identifiez les applications qui supportent ces processus. À partir de cet inventaire, dressez une carte de la situation actuelle et, au travers du portefeuille projet, dressez la carte de votre cible.
Pondérez chaque processus en fonction de sa criticité pour l’entreprise. Votre analyse combinera ainsi pérennité des applications et criticité afin d’établir le rac-cordement de la solution de gestion de données de référence à votre SI.
En toute logique, la solution référentielle doit se situer au plus haut de la chaîne de consommation de la donnée, afin de fournir une information valide à l’ensemble du SI, puis devenir le centre d’une couronne d’alimentation. L’architecture de cen-tralisation est, suivant cette règle, celle qui permet une parfaite maîtrise de la don-née. Ensuite, les capacités de gestion des données et de pilotage décroissent suivant l’ordre suivant des architectures : coopération puis consolidation et enfin répertoire virtuel.
Notion de propriétaire
La cartographie des applications source, alliée à la nature du référentiel, induit des notions de propriété (voir plus en détail ces notions dans la troisième partie). Il faut distinguer les propriétaires du modèle et des instances.
La notion abordée ici porte sur le propriétaire du modèle qui est induit par la nature du référentiel et sur les propriétaires d’instances qui sont induits par la carto-graphie.
Propriétaire d’instances
En aval, le référentiel est propriétaire des instances d’objet pour chacun des attributs du paradigme qu’il détient.
En amont, une application supporte un ou plusieurs rôles utilisateurs intervenant sur l’application. Dans la mesure où on peut identifier les attributs détenus par l’application, on peut donc dresser les corrélations entre rôles et attributs.
Propriétaire de modèles
Au sein d’un référentiel globalisant, plusieurs métiers sont responsables de la défini-tion du modèle de donnée puis de la complédéfini-tion des données. Plusieurs proprié-taires sont chacun responsables de leur périmètre de données. Un responsable pour la cohérence de l’ensemble doit cependant valider l’évolution du modèle.
Pour les référentiels synthétiques, la définition du modèle s’apparente plus à la négociation d’un format pivot (un seul propriétaire).
Ce travail induit une documentation précise du modèle. Cette documentation commence dès la définition sémantique de chaque concept (glossaire) puis de cha-que attribut (dictionnaire). Ces définitions doivent être liées aux applications de métadonnées.
La copropriété d’un objet métier signifie la répartition stricte de chaque attri-but. Il n’y a pas de multipropriété pour un unique attribut au niveau du modèle.
En résumé
Les solutions de référentiel reposent d’abord sur les applications de MDM. Mais, répondre aux besoins métier liés à la solution MDM, intégrer cette solution dans le SI et en permettre le pilotage peut demander l’utilisation de briques transverses, de modules spécifiques ajoutés ou de briques complémentaires progiciel ou middleware.
Il faut porter une attention particulière aux applications d’intermédiation.
Cette intégration ne se fait pas en mode « big bang » mais par étapes à maîtriser en repérant les processus amont et aval et en élaborant un plan de transformation du SI. Il s’agit de faire du référentiel la pièce centrale d’une architecture en étoile.
8
Objectif
Comment choisir l’architecture (centralisation, consolidation, coopération) adap-tée à la gestion d’un type de donnée de référence ?
Quelle solution (MDM, DQM, progiciel, développement spécifique) adopter ? Quand privilégier en particulier une solution MDM ?
Telles sont les principales questions auxquelles nous répondrons dans ce chapitre.
Nous évoquerons aussi les bonnes pratiques métier, urbanisme et architecture.
8.1 CHOIX D’ARCHITECTURE
Nous avons abordé plusieurs critères de choix d’architecture liés à des objectifs et des besoins fonctionnels lors de leur présentation dans le chapitre 4. Nous les complé-tons ici avec quelques critères plus techniques qui sont détaillés dans le tableau 8.1.
Rappelons toutefois qu’au sein d’un SI il peut y avoir plusieurs référentiels et que le choix d’une architecture s’effectue par donnée de référence (une même solution abritant plus d’un référentiel peut donc implémenter plusieurs architectures).
Guide de choix
des architectures et solutions
Tableau 8.1— Guide complémentaire de choix d’architecture
Voir aussi la figure 4.13 pour un rappel illustré des principaux critères de choix d’architecture. La figure 8.1 synthétise et simplifie ces critères.
Critères Commentaires
Couplage lâche: les applications consommant la donnée de référence sont-elles découplées des applications fournissant la donnée de référence (désynchronisation) ?
Par défaut, toutes les architectures sont compatibles, avec une facilité accrue pour les architectures de consolidation qui jouent bien le rôle de
« concentrateur de la donnée », sans se lier avec une application en particulier.
Distribution: les données de référence sont-elles distribuées vers de nombreuses applications
destinataires ?
Comme son nom l’indique, une architecture de consolidation fédère plus les données qu’elle ne les distribue. L’architecture de centralisation est celle qui convient le mieux pour distribuer.
Recherche et analyse: est-il demandé d’avoir des services de type recherche, analyse et pilotage ?
Toutes les architectures sont aptes à ce type de critère.
Préservation de l’existant, accompagnement: souhaite-t-on éviter une conduite de changement trop forte dans un premier temps (exemple : préservation du patrimoine applicatif) ?
L’architecture de coopération permet de fournir des écrans et des workflows propres aux applications existantes.
Référentiel existant: existe-t-il un référentiel progiciel de fait (par exemple ERP) ? Existe-t-il une base de données de concentration ?
Ce référentiel progiciel existant est par nature une architecture de centralisation.
Une base de données de concentration est généralement un premier essai en développement spécifique pour une architecture de consolidation Processus d'acquisition: l’objectif
poursuivi est-il la simplification des processus d’acquisition ?
Les architectures de centralisation permettent de construire et de valider les processus complexes d’acquisition de la donnée.
Une architecture de coopération peut répartir ce processus sur plusieurs applications source, coordonnées du point de vue événementiel par la solution de gestion des données de référence.
Qualité: est-ce un problème de qualité de la donnée ?
Les architectures de consolidation et de coopération doivent proposer des mécanismes de gestion de la qualité de la donnée, les sources n’étant pas maîtrisées par la solution.
L’architecture de centralisation, par essence, travaille au travers des processus sur une source
d’acquisition de qualité : le référentiel lui-même. Les processus peuvent utiliser un outillage DQM, pour répondre à un besoin de traitement complexe (standardisation, déduplication).
161 8.2 Choix de solutions
Figure 8.1— Rappel des principaux critères de choix d’architectures
8.2 CHOIX DE SOLUTIONS
Nous avons évoqué plusieurs types de solutions et leurs besoins associés au chapitre 5. Nous nous focalisons ici sur la gestion des données de référence afin de déterminer si elle doit être effectuée par :
• un développement spécifique ;
• un progiciel métier (ERP, CRM) ;
• une solution de MDM (que l’on peut assimiler à un progiciel spécifique pour la gestion des données de référence).
Le tableau 8.2 et la figure 8.2 donnent quelques éléments de choix.
Notons à nouveau que les sous catégories d’outils MDM peuvent répondre diffé-remment aux critères exprimés ici. Notre analyse ne prend pas en compte cette seg-mentation. De plus, une solution MDM couvre, à notre sens, les applications référentielles MDM ainsi que le DQM ; nous ne faisons donc pas la distinction.
Figure 8.2 – Critères différenciateurs entre MDM, développements spécifiques et progiciels
Tableau 8.2— Guide de choix de solutions
Critères Commentaire
Modélisation
L’entreprise travaille-t-elle plus par définition de ses objets ou par alignement ?
Existe-t-il déjà un modèle d’objet métier pour le paradigme concerné (pivot, développements
spécifiques…) ?
Dans le cas de la définition ou de l’intégration d’un modèle existant, le MDM et le développement spécifique sont seuls à offrir suffisamment de flexibilité. Le spécifique demande une modélisation physique, contrainte par le relationnel. Le MDM se contente généralement d’une modélisation logique ou offre une modélisation flexible (XML).
Dans le cas de l’alignement, MDM et progiciel répondent au besoin. Les solutions progicielles viennent toutes avec un modèle et une méthode d’alignement. Les MDM arrive généralement avec des modèles pré-intégrés servant d’accélérateur.
Évolutivité du modèle
Le périmètre du paradigme concerné sera-t-il mis en œuvre par itération ? L’objet est-il appelé à évoluer fréquemment ou reste-t-il stable dans le temps ?
Dans le cas d’une évolutivité forte ou d’une mise en œuvre par itération, le MDM et le développement spécifique sont préférables. Les contraintes de modélisation du spécifique limiteront cependant son évolutivité à moyenne échéance.
Les solutions progicielles contraignent des périmètres de mise en œuvre (au niveau modèle, droits, règles, cohérence).
163 8.2 Choix de solutions
Gestion d’états multiples
Les cas d’utilisation, au long du cycle de vie métier de la donnée, sont-ils nombreux, multipliant ainsi les états que la donnée doit supporter ?
Seul le MDM permet la gestion de multiples états de la donnée avec les combinaisons de règles et de droits propres à chaque état.
Le développement spécifique est disqualifié.
Particularités métier fortes L’objet à supporter est-il très spécifique, propre à un métier peu répandu ? (cas des administrations)
Le développement spécifique semble être le plus indiqué, mais en apparence seulement. Le MDM offre en mode projet la flexibilité de la modélisation et une plus grande maîtrise des métadonnées (modèle et sémantique) et permet à terme plus de flexibilité pour l’évolution.
Volumétrie
Quel est le nombre d’occurrences de l’objet ou d’ID ?
Quel coefficient multiplicateur doit être appliqué en raison de l’historisation ?
La volumétrie en nombre d’objets peut aller de quelques centaines d’occurrences à plusieurs centaines de millions d’enregistrements.
Sur les fortes volumétries (plusieurs millions), les progiciels seront distancés en capacité de gestion, si ce n’est en nombre d’enregistrements.
Les solutions MDM ne sont pas toutes équivalentes face à la volumétrie et une étude particulière pour telle ou telle solution de tel ou tel éditeur devra donc être menée, d’autant plus si les capacités
fonctionnelles attendues incluent des recherches complexes. Certaines solutions supportent cependant de très fortes volumétries (dizaines de millions).
Le développement spécifique peut tirer son épingle du jeu sur les très grandes volumétries (plusieurs dizaines voire centaines de millions), couplées à des attentes particulières (modèle ou fonctions).
Taux de couverture des progiciels La couverture offerte par le modèle de donnée du progiciel en pourcentage du nombre d’attributs, ainsi qu’en criticité des attributs détenus, est-elle importante ?
L’écart entre le modèle détenu et la cible, ainsi que les fonctions ou règles à développer n’impliquent-ils pas un éloignement trop important du standard du progiciel ?
Le taux de couverture fonctionnel et celui du modèle doivent être maximaux pour être compatibles avec la mise en œuvre d’un progiciel.
Les écarts sont gênants pour le support et les montées de version.
Gestion des droits – nombre intervenants
Les intervenants humains ou machines sont-ils nombreux, multipliant les profils ?
Les droits doivent-ils être gérés avec précision, sur des périmètres très segmentés ou en multipropriété ?
Plus les profils et les besoins de maîtrise des droits sur la donnée sont importants, plus le MDM permet une gestion fine (au niveau attributs, fonctions, par rapport aux valeurs) et aisée (profils, groupe de profils, duplication de profils pour création…).
Critères Commentaire
Applications connectées – amont Plus le nombre d’applications source est important, plus le MDM est préférable. Que ce soit en coopération pour la maîtrise transactionnelle ou en consolidation pour les capacités de déduplication et de key mapping.
Applications connectées – aval Plus le nombre d’applications cibles est important, plus le MDM offre de flexibilité en termes de mode de connexion, de décorrélation avec les sources, de gestion des processus de synchronisation.
Flux « fil de l’eau » Les solutions progiciel ou MDM supportent mieux le « fil de l’eau ».
Les progiciels induisent souvent des traitements « fil de l’eau » ou synchrones.
Le MDM reste favori face au progiciel pour les fonctions supplémentaires qu’il apporte (gestion événementielle).
Flux ordonnancés – en masse Les flux ordonnancés et/ou en masse ne sont pas tellement différenciateurs.
Léger avantage cependant au MDM qui offre toujours sa flexibilité et intègre la gestion événementielle.
Mode classique, par extraction ou duplication sur le spécifique.
Mode classique sur les progiciels.
Fonctions qualité
La solution doit-elle couvrir des besoins de standardisation complexe (adresse, acronyme, abréviation) ou de déduplication ?
Seule la solution MDM offre un support complet à la qualité (en lien avec le DQM).
Le développement spécifique en fin de chaîne, de l’information s’il est couplé à un DQM, peut offrir un certain niveau de qualité en redressement (cas du BI standard).
Le progiciel n’offre pas de fonction qualité.
Historique IT
Les compétences et les habitudes de la DSI sont-elles plus orientées spécifique ou progiciel ?
Les entreprises ayant une forte culture du développement spécifique et/ou ayant de nombreuses applications et compétences internes pour gérer le spécifiques passeront plus difficilement au progiciel ou au MDM.
Si le pas est franchi, il se fera au bénéfice du MDM plutôt que du progiciel. Les progiciels sont généralement supportés par les métiers.
Administration – métiers ou IT L’administration de la solution de gestion des données de référence est-elle réalisée par les métiers ou l’IT ?
Si les équipes d’administration pressenties sont IT alors le MDM et le développement spécifique sont plus adaptés. Le MDM reste préférable car il offre des fonctions propres à l’administration.
Si les équipes d’administrations sont métiers, alors elles ont tendance à préférer les progiciels. Mais ce point sera contrebalancé au profit du MDM si les intervenants métier sont nombreux.
Critères Commentaire
165 8.2 Choix de solutions
Stratégie DSI – urbanisme – SOA L’entreprise est-elle dotée d’une cellule d’urbanisme ? Les préceptes de la discipline influent-ils sur le SI ? La démarche référentielle répond-elle à une vision d’ensemble, généralisée ? La DSI est-elle engagée dans une stratégie IT orientée SOA ? ou du moins profite-t-elle des outils urbanisants (par exemple, EAI) ?
Le MDM est une réponse logique d’urbaniste, d’autant plus adaptée que la démarche est généralisée (certains outils MDM peuvent couvrir de multiples paradigmes).
Idem dans le cadre d’une stratégie SOA, le MDM est considéré comme une brique constitutive de cette stratégie.
Besoin de gestion multi-entité, multimétier ou métier, mono-entité
La solution doit-elle couvrir plusieurs métiers, plusieurs entités
organisationnelles ?
Plus la solution est répartie entre entités et sur plusieurs métiers, moins le progiciel est adapté.
MDM et spécifique restent utilisables, avec un net avantage pour le MDM du fait de ses capacités de gestion (droits) et de contextualisation.
Coût – ticket d’entrée
L’entreprise a-t-elle estimé les coûts d’un projet référentiel à leurs justes valeurs ou a-t-elle tendance à considérer que cela revient à mettre une simple base dans une partie du SI ?
Le spécifique semble toujours offrir un coût facial moindre. Cela reste vrai sur de petits projets.
La mise en place d’un progiciel pour le métier (un CRM par exemple) peut aussi être ressentie comme l’opportunité d’utiliser celui-ci sans générer de coûts supplémentaires.
Seule une approche tactique permet la diminution de ce ticket d’entrée pour le MDM, sans l’annuler.
Coût - ROI/TCO Sur des projets de plus grande ampleur, l’analyse ROI/TCO profitera au MDM grâce à la diminution des points de gestion multiples dans le SI et l’amélioration des processus métier consommateurs (plus étendue qu’avec un simple progiciel qui n’améliore que ses propres processus).
Immaturité « processus » de l’entreprise
L’entreprise a-t-elle déjà documenté et outillé ses grands processus (par exemple, «Order to Cash») ? Ces processus ont-ils déjà été améliorés ?
Dans une entreprise qui n’en est qu’au début de l’outillage de ses processus, il y a beaucoup plus de valeur à générer par la mise en place des progiciels qui vont les structurer que par l’outillage de la donnée. On utilise dans une telle phase les progiciels comme référentiel.
Seule exception, quand le processus métier est un processus de gestion de données (par exemple référencement produit dans la grande distribution, ou gestion des catalogues pour les services achats), on outille préférentiellement avec une solution MDM adaptée.
Maîtrise des processus
La solution de gestion de données de référence outille-t-elle les processus d’acquisition de la donnée ?
Ces processus sont-ils complexes, font-ils participer de multiples proffont-ils intervenants ?
Le développement spécifique est disqualifié.
Le progiciel couvre les seuls processus prévus à son périmètre.
Avantage donc au MDM qui généralement favorise la modélisation des processus d’acquisition.
Critères Commentaire
La figure 8.3 résume les conclusions pour le choix de solutions.
Figure 8.3 – Principaux critères et choix de solutions
8.3 MODE D’IMPLÉMENTATION ET ÉLIGIBILITÉ DES SOLUTIONS DE MDM
Nous avons vu dans le chapitre 4 les modes d’implémentation dérivés des architec-tures types.
Suite aux critères de choix que nous venons d’étudier, la figure 8.4 résume l’éligi-bilité des solutions en fonction des modes d’implémentation.
167 8.3 Mode d’implémentation et éligibilité des solutions de MDM
Figure 8.4— Éligibilité des types de solution aux modes d’implémentation
On voit que les solutions de MDM sont à envisager prioritairement pour
« Référentiel central d’entreprise », « Harmonisation », et « Système d’enregistre-ment distribué ».
La mise en œuvre du MDM est moins prioritaire pour le « Pré-référentiel » (cela dépend du type de données) et pour le « Référentiel analytique » (un logiciel spéci-fique allié à du DQM peut suffire).
La figure 8.5 indique le choix du mode d’intermédiation en fonction du mode d’implémentation : mode fichier (appelé « batch » sur la figure, total ou delta) ou message (« fil de l’eau » ou synchrone). Nous avons simplifié les modes de con-nexion sans entrer dans le détail des protocoles.
Figure 8.5 – Préférence de choix des modes d’intermédiation