Tribunes

Le scoubidou MDM : les nouveaux jeux de données

Passer du Playmobil au Lego : un nouveau terrain de jeu pour les utilisateurs du SI (3ème épisode sur 6). Avez-vous déjà essayé d'assembler 2 Playmobils ? C'est la quadrature du cercle permanente pour les utilisateurs et les informaticiens à chaque nouveau projet informatique, et inévitablement on rachète une nouvelle boite, plus jolie, plus complète que la précédente mais avec les mêmes bonshommes de base.

PublicitéLe but du jeu : maîtriser ses informations de référence, construire son scoubidou Le concept de base à l'origine du MDM (Master Data Management) n'est pas vraiment nouveau : il s'agit d'assurer la qualité et la fiabilité des données de référence (qu'on appelle les Master Data), mais il souvent été mis à mal par la vague des ERP ou la complexité croissante du SI et du nombre d'applications. Des exemples de Master Data : Référentiel Client/Personne/Usager, Référentiel Produit. L'idée Phare du MDM est d'assembler de manière cohérente dans un référentiel maître (le Master) les mêmes informations présentes sous des formes différentes (les variantes) dans les applications, puis de fournir les outils pour modéliser et administrer ces référentiels. Pour continuer le parallèle avec le scoubidou, chaque source est un fil de couleur différente, toutes ces sources s'assemblent via des opérations de transformation pour construire des référentiels cohérents. La règle du jeu : assembler des référentiels cohérents, trouver les bons fils Dans une approche toujours Urbanisation & SOA, le MDM permet de construire une zone référentiels : - dont l'utilisateur est propriétaire (du modèle et du contenu des données) : le QUOI, - dont l'informatique assure l'alimentation et la synchronisation : le COMMENT. En cohérence avec une approche services urbanisée, on crée une zone de dialogue MOA/MOE, la zone des référentiels (Master Data). D'un point de vue SOA, le MDM peut être vu comme un Bus Applicatif des Données, tout comme l'ESB (Enterprise Service Bus) est le Bus Applicatif des Services. En pratique, un référentiel Master Data devient la source unique des applications pour lire ou écrire les données de référence. Toute application souhaitant accéder à une donnée de référence doit passer par le « bus » MDM. Le processus MDM est focalisé uniquement sur les données partagées entre les applications, qui correspondant en général aux entités de référence de l'organisation qui les manipule (Client, Dossier, Contrat, Produit, Compte, ...). Dans sa mise en oeuvre, le MDM met en jeu un panel de technologies assez complexe, pour consolider, synchroniser et unifier les données partagées dans les différentes applications : - EAI pour les échanges inter-applicatifs, - SOA pour les échanges découplés, - ETL pour la gestion des flux batchs, - Outils de gestion de la qualité des données (exemple : dédoublonnage), - Outils de modélisation des données, - Outils d'administration des données. Qu'est-ce qu'on gagne : des données de référence centralisées et fiabilisées La plupart des situations existantes proposent aujourd'hui des données désynchronisées, incomplètes, inexactes et distribuées dans différents silos applicatifs. La présence de plusieurs progiciels pour gérer différents pans de l'activité aggrave généralement le phénomène. Le MDM entend répondre à ce problème de gestion des données de référence en offrant : - des espaces pour les données de référence, les Master Data, toujours fiables et à jour, - un nouveau mode de gouvernance des données, dans un usage centralisé et unifié. Les gains espérés : - Qualité et fiabilité des données de référence, - Evolutivité et maintenabilité des applications, qui deviennent indépendantes du modèle physique des données, - Organisation plus efficace, des responsabilités mieux partagées sur les données métier de référence. Dans un monde idéal : coexistence pacifique des référentiels, chacun ses fils La vision idéale du MDM serait une suite de référentiels (quartier des référentiels dans une vue urbanisée) contenant les données de référence de l'organisation, permettant à la MOA le réappropriation et le contrôle de données, indépendamment de leur représentation physique. L'approche MDM consacre également un nouveau rôle, celui de Steward (ou Business Steward) : responsable des données d'un domaine fonctionnel, il gère la cohérence et la qualité des données via les interfaces d'administration du MDM. Il est informé des actions sur le référentiel (création, anomalie, événement déclenché sur règle métier paramétrable). Dans la vraie vie : qui tire les fils ? On peut considérer aujourd'hui que les outils techniques arrivent à maturité pour gérer des référentiels MDM. Par contre, le MDM pose le problème difficile à résoudre de gouvernance des données, lié à l'organisation et à la légitimité réciproque de chacune des MOAs sur les différentes données de référence. Par exemple : - quelle Direction est responsable des contrats ? - quelle Direction gère et contrôle les données produits ? Le CRM avait déjà mis en évidence ce problème : à qui appartient le référentiel Client ? Et dans la pratique bien des projets CRM s'appuient sur des référentiels partiels ou insuffisamment consolidés, limités au périmètre de la solution retenue et non transverses au Système d'Information. En synthèse, c'est l'heure de faire ses premiers scoubidous Le MDM reste un concept assez récent qu'on peut encore qualifier d'émergent. La grande force qui devrait faciliter son adoption est sa totale compatibilité avec une approche Top-Down et SOA. On se rend compte actuellement que le fameux middleware orienté services du SOA expose essentiellement des interfaces d'accès aux objets métier, contenus dans les référentiels MDM. En effet, comme dans l'approche SOA, le MDM propose une approche par l'intégration et un découplage entre les vues métier et les vues techniques, permettant de garder l'agilité sur chacune des couches. Et sa mise en oeuvre peut tout à fait être progressive : on construit un référentiel et on « branche » progressivement les applications alimentant et consommant ce référentiel.

Article rédigé par

Rémi Moebs, Senior Manager chez Sopra Group Atlantique
Responsable de la cellule « Architecture et Solutions Collaboratives » au sein de la Division Business Consulting de Sopra Group Atlantique Consultant et agitateur technologique depuis 12 ans sur les sujets Web, Web 2.0, KM et collaboratif, e-commerce, Architecture agiles et distribuées.