Mise en oeuvre : Master Data Management (MDM)

Qu'est que le MDM ?

Wikipedia pourra vous renseigner...

En résumé l'objectif du MDM, si dans un système d'information une entité (unité de sens, par exemple le client) est stockée dans plusieurs logiciels ou bases de données dont les informations arrivent dans chaque système avec des processus différents. Le MDM va être le lieu ou toutes ces informations vont être consolidées, identifiés et dont on va extraire un enregistrement de référence (en utilisant des règles), souvent appelé Golden Record, qui sera alors redistribué à tous les systèmes pour unifier la notion (le client) dans l'organisation.

Principe

Ici 3 sources de données sont poussées dans le MDM, pour chaque enregistrement il y a une mise en qualité (quatity gate) qui peut s'appuyer sur des règles, des données de références, une base de connaissances.

Puis l'enregistrement est intégré et rapproché par des règles à un cluster qui contient tous les enregistrements d'une même instance d'entité (ex : le client André Dupont).

A partir de tous les enregistrements du cluster d'une instance, un golden record est réalisé en faisant du picking par des règles sur les champs des enregistrements du cluster.

En théorie un cluster doit être composé d'un enregistrement par source, ou moins.

Si dans un cluster, 2 enregistrements de la même source se retrouvent regroupés alors il a un problème, cela demande une remédiation. Il est possible qu'un doublon soit présent dans une des bases, et cela peut nécessiter une intervention métier pour dédoublonner (ex: que faire des points de fidélité dans le CRM qui sont sur deux comptes alors que c'est la même personne ?), et cela montre qu'il a peut-être une amélioration a réalisé au niveau des processus de ce système.

C'est à ce niveau qu'intervient le workflow de remédiation et le rôle du Data Steaward, il est alerté d'un doublon et a pour objectif d'analyser l'origine du problème :

• règles de rapprochement à améliorer (les champs utilisés ne sont pas tous pertinants)
• mise en qualité trop intrusive (modification d'un prénom en utilisant la base de connaissance)
• problème de  la base d'origine (doublon réel)
• ...

En suite il doit prendre des actions :

• Correction manuel du cluster et association avec un autre cluster ou création d'un cluster dédié
• Ne rien faire cela n'a pas d'impact métier
• Remonter le problème au responsable de l'application d'origine pour réaliser une intervention métier
• Modifier les règles de rapprochement

L'approche MDM est l'amélioration continue, on ne sait pas encore quelle donnée posera un problème mais le système est prêt à être amélioré, affiné lorsqu'un nouveau cas est rencontré.

Performance et volumétrie

Regroupant l'ensemble des données de l'organisation pour une unité de sens, stockant l'historique pour permettre l'analyse et retracer le comportement d'un cluster, le MDM va nécessiter une volumétrie beaucoup plus importante que les bases des systèmes métier l'alimentant.

Jouant pour chaque nouvelle enregistrement un ensemble de règles pour le rapprochement à un cluster puis réalisant un nouveau Golden record pour ce cluster (ce dernier est aussi stocké), l'ajout dans le MDM d'un enregistrement est coûteuse. Il est peu probable pour que cela puisse être réalisé en temps réel ou de façon synchrone. En consultation on peut avoir une performance correct mais l'utilisation de cache semble indispensable. 

La rechercher dans le MDM peut-être coûteuse si on souhaite respecter la même logique que celle utilisé pour le rapprochement (mise en qualité et règle de rapprochement). 

Mise en oeuvre

Une fois les unités de sens identifiés, elles représenteront les entités du modèle MDM. Chaque entité doit être sémantiquement indépendante les unes des autres, le modèle MDM n'est pas un modèle relationnel : une table du MDM contient l'intégralité de son sens, le sens d'une entité n'est pas le produits de plusieurs tables, il peut y avoir des relations entre les entités.

Exemple :

Nous souhaitons intégrer à un MDM une entité client, quid de l'adresse. Deux modélisations sont possibles :

1. Le client doit avoir une adresse cela faire partie de son unité de sens et permet de le déterminer : une entité client
2. L'adresse et le client sont indépendants mais il y a une relation possible entre les deux : une entité client et une entité adresse

Dans le cas 1 les champs de l'adresse (rue, code postal...) sont ajoutés au client, et permettent de différentier les clients aussi bien que le nom et le n° de téléphone. Le déménagement d'un client risque d'avoir pour conséquence la création d'un nouveau client si cela n'est pas spécifiquement géré côté métier.

Dans le cas 2 les champs de l'adresse ne peuvent être un discriminant pour distinguer les clients et l'entité Adresse contiendra un ensemble d'adresse dont l'objectif sera de fournir des adresses le plus juste possible indépendamment des clients. Le volume de données est aussi moins important.

Les 2 approches sont valides, tout dépendant des volumes et des objectifs du MDM. Si vous êtes un opérateur majeur de la grande consommation et que votre base client est très volumineuse et représente une part importante de la population alors le modèle 2 est plus adéquate car l'entité adresse aura une valeur ajoutée, vous arriverez à discriminer les adresses valides et invalide : un nom de rue rencontrée qu'un fois est suspect, vous aurez rapidement exhaustivité des nom de rue. Sur un ensemble plus restreint, comme sur une base client B2B, le modèle 1 sera plus pertinent.

  

Java vs .Net C#

C'est un débat sans fin mais comme je développe sur les deux environnements je me dois d'y participer un peu, d'apporter mon caillou au tas de gravats.

Je vais balayer d'un revers de main l'aspect performance : c'est pareil ou presque. Bon quand même on va dire que les Winform sous Windows ont un rendu certainement plus rapide et réactif que du Java swing ou autre. Pour le reste cela dépend beaucoup du développeur et on peut voir une programmation d'un algo en Java battre le même en C à cause de la mise en oeuvre : un mauvais développeur C/C++ fera pire qu'une mauvais développeur Java/C#.

Et on peut jouer avec cela : http://benchmarksgame.alioth.debian.org/

Donc grosso c'est pareil.

Attaquons d'un point de vue langage et syntaxe. Ce sont des syntaxes très proches, C# est fortement inspirées de Java et C et Java est elle-même inspirée de C. Mais plus en détail question langage, le C# est clairement meilleur, plus flexible et plus juste. Son secret, le C# n'est pas rétrocompatible ce qui lui a permis de briser certaines barrières et d'évoluer plus vite.

Ainsi les generics sont vraiment gérés au runtime ce qui n'est pas le cas de Java et dès qu'on s'attaque à faire de la réflexion on réalise que cela a de l'importance.

En suite le gros apport de C# c'est linq qui permet de réaliser des requêtes dans les structures de données les plus divers (SQL, XML, objets...).

Le foreach multi threads et quelques raccourcis pour faire un code utilisant plusieurs threads mais je crois que maintenant il y a un équivalent en Java.

De plus il y a une certaine flexibilité dans la gestion des fichiers de code source : une classe peut-être implémentée dans plusieurs fichiers, pratique pour le code généré, et la structure namespace-classe ne doit pas comme en Java être identique à celle répertoire-fichier (mais cela n'a pas que du bon). 

Enfin à chaque nouvelles versions ils progressent et l'écart se réduit ou change de géométrie.

Ensuite l'environnement de développement, Visual Studio contre Eclipse, Intelij, Netbean... bon aujourd'hui ils sont tous très aboutis, mais le développement d'une application reste complexe, et il fini par y avoir pléthores de menus et sous menu et modules... bref c'est ainsi. Visual Studio intègre nativement plus de chose ce qu'il fait qu'il est plus simple d'approche. Il faut aussi noté qu'il y a dans l'ASP.NET et autre finalement pas mal de code généré par Visual Studio qui est masqué à l'utilisateur. Après pour avoir la couverture de code par les test dans Visual Studio faut s'attaquer à une licence qui vaut quelques milliers d'€...

En en arrive a la réalisation d'un projet Web par exemple, c'est quand même mieux intégré dans Visual Studio, on est tenu par la main. En Java il faut déjà faire beaucoup de choix, Java EE, Spring, JPA, JSF, JSP, GWT... tout ça décliné en version, cela demande un certain savoir faire sans compter que cela change régulièrement aujourd'hui on partirait plus sur Java EE REST, JPA + Angular (ce qui simplifie la donne ou déplace le problème vers le développement javascript). En ASP.NET y a moyen de chercher du Nhibernate, Castle, EntLib, Unity et autres mais étrangement c'est assez peu couru de méditer sur la stack ASP.NET.

Ce que fait la grande différence lors de la réalisation c'est la gestion des librairies tiers, d'un côté Maven (ou Gradle) pour Java et Nuget pour .net. Mais il faut dire que Maven a des années d'avance et une pratique assez généralisée aussi bien dans les projets tiers qu'au sein même de l'entreprise. Nuget commence a entrer dans les mœurs.

Un autre aspect qui fait la différence est l'écosystème, en Java il y a de grandes organisations qui gèrent de l'opensource (Apache, Redhat, Spring...) de gros éditeurs (Oracle, IBM...). Du coup c'est très riche on peut vite s'y perdre, mais il y a aussi Java EE pour normaliser et cadrer un peu tout cela. A contrario le monde .Net est plus fermé, il a quelques éditeurs spécialisés dans les composant d'interfaces et autres outils : Telerik, ComponentArt, ComponentOne. Les projets opensource en c# dans http://www.codeproject.com/ et http://codeplex.com ont rarement un gouvernance clair, les bonnes idées finissent absorbées par Microsoft sous une forme ou une autre, alors souvent le plus simple est de ne surtout rien faire et attendre la prochaine version du framework. Et inversement Microsoft y déverse les éléments qu'il ne souhaite plus maintenir (ex : Entlib, Unity).

Finalement la grande différence c'est le développeur. Le développeur .Net et le développeur Java sont très différents dans leurs approches et leurs travers. Mais cela mérite son propre post.

On continue l'aventure GAE Endpoint et SEO

Voila depuis quelques temps que mon application de compteur en ligne est en production en version Alpha. Bien entendu personne ne l'utilise, même par mégarde. Du coup je me dit qu'un petit effort de SEO, optimisation pour les moteurs de recherche, s'impose.

Pour cela 2 axes possibles :

• Plus de contenus
• Une URL plus parlante

Pour le 1er axe, c'est possible en réalisant des pages de documentation pour l'utilisation de l'application, c'est prévu mais il faut du temps. Par contre modifier l'URL du site pour que cela soit plus efficace semble assez rapide. L'URL compte beaucoup pour les moteurs d'indexation, car c'est un champ limité en taille, obligatoire et potentiellement compliqué à modifier, très engageant : achat de domaine, mise à jour DNS, redirection du site...

Pour mon cas je ne vais pas investir dans un domaine, mais j'en ai déjà un capverszero.fr, du coup je vais faire un sous domaine bien parlant : https://onlinetallycounter.capverszero.fr

Alors avec Google Cloud Endpoint c'est le parcours du combattant...

Première étape enregistrer le nouveau domaine, au travers de la console Google AppEngine, montrer patte blanche et prouver que vous êtes bien propriétaire du domaine. J'ai opté pour la validation au travers de l'ajout d'une directive DNS. Une fois ceci passé Google donne la directive DNS à ajouter pour redirigé le sous domaine vers l'application GAE. 

Il faut bien noter que chaque mise à jour du DNS prend un certain temps... plusieurs heures... donc faut pas être pressé.

Et là stupeur les Cloud Endpoints ne supportent pas les custom domain... oui c'était une petite note dans la documentation... Heureusement la page HTML est bien accessible sur le nouveau domaine mais les services ne sont pas disponibles sur ce domaine. Argh !!! 

Donc il faut se lancer dans la modification du code de l'application pour utiliser CORS (Cross-Origin Resource Sharing). Ça marche dans les nouveaux navigateurs, ça signifie tout simplement qu'il faut appeler les services REST de Google Cloud Endpoints sur l'adresse contingit.appspot.com, en dur, et ça marche ouf.

Et maintenant il faut mettre à jour le référencement de mon site dans les outils Google (Webmaster Tools et Analytics), et là il demande qu'une redirection HTTP 301 soit mise en place pour valider que c'est bien une migration de site. Et là impossible de réaliser cette redirection côté serveur : je n'ai qu'une page statique... Je me lance sur une redirection par balise meta... c'est pas classe mais il parait que ça peu marcher. Mais la blague c'est que je n'ai qu'une page et c'est physiquement la même au 2 adresses donc tout cela semble compromis je risque d'être redirigé indéfiniment. J'ai bien fait le test en mettant une seconde page mais cela ne m'a pas permis de valider la migration du site dans l'outil google... du coup c'est comme s'il y avait 2 sites...

Enfin je m'arrête ici et j'attends de voir si je monte un peu dans le ranking google, à suivre...