Master Data Services 2012, toutes les raisons de l’implémenter

Une petite discussion de la semaine dernière avec mon excellent petit collègue Charles-Henri amène ce post sur MDS, l’outil de MDM (Master Data Management, gestion de référentiel) de Microsoft, qui est sorti en mars dernier dans sa seconde version (qui a dit « première version utilisable? » :)). Pour résumer:

  • Je pense que non seulement nous allons être amenés à en mettre de plus en plus en place dans le cadre de projets décisionnels,
  • Mais en plus  que le produit répond à une problématique décorrélée de la BI qui peut elle même être génératrice de projets

Un bref historique

Le terme MDM, vous l’entendez depuis quelques temps – probablement depuis les années 2006-2007 je n’ai pas vérifié mon Décidéo. Ce vocable en vogue à l’époque – et toujours aujourd’hui d’ailleurs – verbalise simplement le fait que les applications d’une entreprise ont potentiellement vocation à partager un certain volume de référentiels.

Diantre la belle affaire.

On parle à cette époque déjà depuis longtemps d’outils de CDI (pas les contrats, la Customer Data Integration, le fait de disposer d’un seul référentiel client), et de PIM (pas l’onomatopée, Product Information Management, pour les produits). Le MDM est simplement la mise sous le même chapeau de ces deux domaines, en considérant que l’intégration des référentiels d’une entreprise se doit d’aller plus loin que le traditionnel diptyque Client-Produit.

Quel rapport avec la BI et le Data Warehousing en particulier?

Je suis moins bon en schémas que le pote Florian Eiden mais je vais m’y coller. Quand on parle d’alimentation d’entrepôt et spécifiquement de dimension, on désigne les opérations réalisées par les environnements de stockage.

  • On procède d’abord à un Staging des données: l’intégration dans un environnement technologique unique de données hétérogènes.
  • Puis on rapproche et on nettoie ces données dans un Operational Data Store non historisé.
  • Très schématiquement l’historisation de l’ODS donne la dimension du Data Warehouse.

<Flagellez moi si vous êtes en désaccord hein>

Si on enlève ces barbarismes technologiques, et sachant qu’un certain nombre de transformations peuvent s’effectuer dans un environnement ou un autre selon le doigt mouillé l’expérience (i.e. le nettoyage des données…), j’ai tendance à plutôt voir le boulot comme ça, indépendamment de l’emplacement où les tâches se font, et ce bien avant l’apparition du terme MDM

Flux

Pour un produit par exemple on va intégrer des « référentiels » hétérogènes (Excel, Access, SGBD loufoques), que l’on va rapprocher au moyen de méthodes floues et de règles métier.  A ce stade, on dispose de Master Data (données de référence). Une dimension sur ces Master Data en est simplement une potentielle historisation (SCD) en plus de modification structurelles liées au frontal ou aux principes de Ralph.

Dit autrement: la BI s’occupe de Master Data depuis un petit bout de temps, mais uniquement pour son petit besoin analytique.

Comment partager le travail réalisé sur un projet BI avec les application métier?

Un ancien chef de produit SQL Server, très bon en MDX, fondateur de l’ex-Winsight et inventeur d’expressions célèbres comme « la première année de souris » décrivait ce genre d’usage par l’anaphore « boucler la boucle analytique ».

C’est joli et cela sied bien à l’usage présent je trouve: en effet pourquoi vouloir tenir à l’écart le reste de l’entreprise des efforts de normalisation effectués en aval dans la BI? On le fait bien parfois en ouvrant les ODS à certaines applis non décisionnelles. Aller plus loin est donc possible technologiquement.

Bon pour être honnête, rien de ne l’a jamais empêché dans l’absolu, sauf à mon humble avis des besoins fonctionnels assez peu conciliables entre la BI et les utilisateurs des référentiels.

– Les utilisateurs ont besoin d’outil intuitifs pour modifier un faible volume de données, réaliser des insertions, avec une restitution compréhensible: en gros ils font de l’Access ou achètent un outil de PIM.

L’IT et la BI en particulier de solution industrialisables, permettant du chargement en bloc de données de référence depuis des systèmes tiers: ils font de l’ETL.

Mettre sous le même chapeau ETL et PIM étendu à tout le spectre des référentiels: c’est ce que fait MDS en 2012.

Principe de Master Data Services 2012

Master Data Services, comme en 2008R2, s’installe avec une base de données dédiée sur laquelle tourne un jeu de services WCF. Un site Web permet la configuration, la création de modèles de données (Client, Produit…), des règles métier associées en utilisant ces services… Il est installé et sa base créée un peu comme RS via un Configuration Manager.

D’un point de vue process, les données sont exposées entité par entité via des vues SQL, donc facilement interrogeables. Le CRUD sur les entités peut se faire directement à travers SQL via des tables de staging SQL Server ou à travers l’API de services WCF.

7840.MDS Architecture

Deux principales choses changent par rapport à 2008R2:

  1. La modification côté utilisateur se base sur Excel. WCF – qui n’est en effet pas le moyen le plus facile d’intéragir de manière graphique avec un client final sans développement tiers – a été utilisé pour proposer un addin Excel en VSTO très choupi. Cet addin, destiné aux clients qui maintenaient leur référentiel local de manière autonome, va leur permettre de modifier le référentiel central que vous mettez en place, tout en respectant de potentielles règles métier (celles-ci étant définies dans le client Web). Cet addin est téléchargeable depuis le site MDS (comme Report Builder depuis Report Manager, tiens tiens). Il est puissant puisqu’il permet de créer des entités et de modifier intégralement leur structure et/ou leur contenu si on possède les droits ad-hoc.  (NB: Pour Office 2013, bien télécharger la toute dernière version sur le site de Microsoft en revanche, sinon vous aurez un bug d’affichage assez rédhibitoire )
  2. L’import des données en bloc se fait désormais par des tables de staging par entité (dit autrement une table pour les Produits, les Couleurs de Produit, les Catégories… avec une colonne par information à renseigner, un truc normal quoi), plutôt qu’avec les inutilisables tables clé/valeur de 2008R2 (vous pouvez regarder le tutorial en 2008R2 de l’équpe produit, c’était à vomir original). En plus, les codes des entités sont maintenant auto-générés (oui pour les fans de SSAS Multidim dans MDS on a un code et un libellé par entité). C’est fini, plus de script dans SSIS pour faire de la surrogate. Une fois ces tables remplies de données source, on peut déclencher le processus de chargement en WCF, via une procédure stockée SQL, ou depuis le frontal Silverlight. En cas de présence de l’entité considérée dans le référentiel, c’est la propriété ImportType de la ligne de l’entité dans la table de staging qui gouverne la mise à jour ou pas des données, avec ou sans erreur levée. En fin de chargement, il est bien sûr possible de consulter le résultat de l’import, comme depuis l’addin Excel (et donc les raisons d’un éventuel échec: infraction vis à vis d’une règle métier… etc…).

Excel Conclusion: l’avenir des projets BI?

Un certain volume d’ETL sur les phases amont des projets BI a, à mon avis, vocation à disparaître tant il est anormal que seule la mise en place de solutions décisionnelles  entraîne un effort d’intégration/standardisation de données.

La qualité de données commence dès sa saisie et l’analyse n’est que le sommet de la pyramide. Donc la prochaine fois que vous constituerez un référentiel juste pour la BI en vous alimentant depuis des bases Access/DBase/MySQL gérées par les métier en local, demandez vous si par hasard votre référentiel ne leur serait pas utile, et testez MDS🙂

9 réflexions sur “Master Data Services 2012, toutes les raisons de l’implémenter

  1. J’ajouterai juste que la place de l’humain est bien plus importante dans un processus MDM que dans une simple consolidation.
    La phase de validation et d’audit est très importante dans MDS avec une vrai responsabilité sur l’entité. MDS (et le MDM en général) permet d’impliquer les utilisateurs métiers dans un processus qui est fait généralement par des développeurs d’ETL.

    • Je ne peux que plussoyer pour tout, c’est d’ailleurs bien symptomatique du fait ça que 2008R2, non muni d’outils pour « humains », n’était pas encore prêt pour la mise en production.🙂

  2. A mon sens un outil de MDM c’est:
    > Des tables de transcodage
    > Une interface graphique pour y accéder
    > Des workflows de validation

    Si avec ton retour on sent bien l’effort positif de l’équipe MDS sur les 2 premiers points – l’add-in Excel, excellente idée – je t’avoue être encore dans le flou sur l’utilisabilité du dernier. Sur ces projets la perversion des utilisateurs s’exprime souvent par l’aspect tortueux des processus de validation, reste à voir si l’ensemble tient la distance.

    Enfin j’irais plus loin que JP en disant que le vrai problème d’un projet de MDM, c’est bien qu’il fait resurgir les problèmes de politique/management de l’entreprise, d’ailleurs bien plus qu’un projet de BI ou qu’un projet d’ERP (j’avais assisté à une conf ERP, et même eux veulent se débarrasser du sujet MDM jugé trop politique).

    Dans ce genre de contextes explosifs, il faut des outils qui savent se faire oublier, pour éviter que les problèmes techniques deviennent des champs de bataille dans lesquels les Business Units viennent régler leurs comptes. En intégrant Excel, MDS prend clairement ce bon chemin. Ça me rassure.

    • Toujours aussi pertinent Flo🙂 Sur la partie Workflow effectivement c’est encore un poil flou (et pour être honnête là ou j’ai mis du MDS, je n’ai pas encore joué avec, j’ai juste testé pour voir): entre le développement des Workflow Extenders, l’attache à Sharepoint et les soucis de Service Broker, ça fait encore un peu cuisine. D’accord avec toi, c’est le gros point à enrichir pour la vNext.

    • Excellente réflexion sur le sujet. Si je peux me permettre (et même si je manque clairement de maturité sur les problématiques abordées), c’est pour les raisons que tu évoques que le processus BI me semble un peu « tardif », au niveau du schéma du SI, pour y intégrer le sujet Master Data.
      Certes il sera incontournable, car avec l’expérience, l’intervention humaine me paraît indispensable pour dénouer la réconciliation de certaines dimensions, avant de les intégrer dans le DW (les dimensions critiques de l’entreprise : chez nous c’est le catalogue produits, comme par hasard… on pose la question « qu’est-ce qu’un contrat d’assurance vie pour vous ? », et chaque service aura une réponse différente en fonction de sa vision métier). Mais avec le recul, je pense que le problème des Master Data de l’entreprise devrait être résolu plus en amont dans le SI, tellement il est sensible et peut avoir des impacts partout, et générer de la perte d’information au passage (avec toujours le risque d’obtenir des faits qu’on ne sait plus rapprocher correctement dans le DW). Bien évidemment, ce sera moins le cas pour des dimensions « mineures », ou de simples problématiques de transcodage technique.
      Et donc oui, je vous le confirme en tant que client final : de belles prises de tête en perspective entre les services, car le MDM deviendra rapidement la couverture que chacun essaie de tirer à soi !
      En tout cas merci François pour cet article, une fois de plus très intéressant.

      • Tout à fait d’accord Arnaud, le MDM devrait être traité en amont, comme première brique d’une politique de gouvernance des données d’entreprise. Si je ne m’abuse c’est d’ailleurs la position assez ferme de notre camarade David Joubert sur le sujet.

        Maintenant dans la vraie vie, on laisse toujours les sujets délicats trainer au fond du panier, et c’est en bout de chaîne qu’on se ramasse la problématique: dans le datawarehouse. À nous d’assumer ça comme on peut🙂

      • Tiens la Gouvernance des données… Y’a une session aux TechDays sur le sujet cette année, dans le parcours décideurs il me semble 😉
        Sinon, pour compléter, un projet de MDM doit être porté par la direction générale d’une entreprise !

      • De rien Arnaud! Mais la problématique soulevée ici – portée par des projets BI pour fiabiliser l’activité métier – me fait pas mal penser à ce que l’on peut faire côté BI opérationnelle ou Data Mining: mettre en lumière des problèmes de données en aval qui découlent de soucis de process ou de données en amont, et fournir les outils pour les traiter dès la source. L’avantage des projets BI pour porter ces modifications là est qu’ils sont souvent transverses et impliquent des niveaux de responsabilité élevés, et que sur le modèle de la carotte et du bâton, les gens comprennent bien le ROI d’une analyse fiable. Alors que faire du référentiel pour que… pour que ça soit propre ça draine moyen les foules vu de ma fenêtre.

  3. Les Master Data, ce sont tes référentiels importants, valables pour toute l’entreprise, nettoyés, qui font foi. Ce sont les fiches clients, les fiches produits… Le Master Data Management c’est le processus de gestion de ces données. MDS sert à ça. Typiquement dans une entreprise (et pour nous qui faisons de la BI), on se retrouve souvent à faire du Master Data Management sans le dire en même temps que du Data Warehousing: dit autrement on nettoie les données, on constitue des référentiels en même temps que de consolider une base d’analyse. L’idée du MDM c’est que l’entreprise aurait bien besoin du même genre de référentiel « nettoyé » que celui fourni par l’entrepôt, sans pour autant subir ses contraintes (périmètre réduit, aggrégé et temps de latence). Le MDM c’est de la gestion de de référentiel appliqué à l’entreprise et donc à tous les systèmes, OLTP compris. Comment ça interragit avec les ETL (puisque c’est ta question): et bien on va dire que ça enlève un peu de boulot à l’ETL pour le périmètre des données géré par MDS, que celui-ci va juste récupérer. Mais il restera d’une part toujours des données non masterisées, et en plus l’ETL ne se borne pas simplement à de la vérification de cohérence des référentiels… (Quid des aggrégations, des règles métier sur les faits…). Donc MDS prend une part du boulot de SSIS pour faire bénéficier à l’entreprise de données propres pour tous les systèmes, et non plus seulement DW/OLAP. Mais il reste encore beaucoup d’ETL dans les projets… J’espère que mon babillage verbeux t’a un peu éclairé.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s