Data Warehouse et intégration

Data Warehouse et intégration

“Data integration involves combining data residing in different sources and providing users with a unified view of these data”.

Si on considère que pour couvrir tous ses domaines métiers, une entreprise a souvent besoin de plusieurs systèmes opérationnels (CRM, Finance, Logistique, HR, …). Il m’est difficile de croire qu’une plateforme décisionnelle puisse exister sans volonté de reconstituer dans un entrepôt toutes les composantes des différents cycles de vie et processus.

Je pense qu’il n’y a pas de Data Warehouse sans intégration.

Si on compare toutes les méthodologies de data modelling pour la couche Data Warehouse (B.Inmon, R.Kimball ou D.Lindstedt), on retrouvera cette idée comme concept commun et central. Tout comme l’historisation, l’homogénéisation ou la non-redondance des données.

DWH

Prenons l’exemple de Kimball, il n’a pas inventé le modèle en étoile (Nielsen dans les années 70) mais bien le moyen de construire un Data Warehouse en utilisant le modèle en étoile. Ceci avec comme concept central, les « conformed dimension » (en vert sur le schéma), le résultat de l’intégration des données depuis des sources hétérogènes dans une structure unique.

La « vraie vie » m’a démontré que ce type de Data Warehouse existe et qu’il n’est clairement pas impossible à mettre en place.  Il est vrai que la construction des dimensions va être un peu plus compliquée par rapport à du «Reporting opérationnel amélioré» (amélioré grâce aux hiérarchies) qui va simplement construire un Data Mart indépendant (ou plusieurs Data Warehouse ????) par système source et des dimensions différentes (client, produit, employé) par source opérationnelle.

Le coût des « Conformed Dimensions » est vite récompensé car il permet deux choses qui me semblent essentielles pour l’utilisateur:

  • Avoir les attributs, provenant de tous les systèmes autour d’un concept regroupés, et donc la multiplication des possibilités d’analyse
  • La possibilité de créer des indicateurs complexes entre tables de faits

Cette reconstitution révèle souvent des problématiques d’intégration entre systèmes opérationnels, et donc de potentiels problèmes dans le suivis des processus métiers. C’est selon moi une autre valeur ajoutée que doit apporter la mise en place d’une plateforme de business Intelligence, le reporting des erreurs et différences entre système opérationnels dans le but d’améliorer l’ensemble des interactions systèmes au niveau qualitatif. Ce reporting ne représente pas une grosse charge de travail, il ne contient ni plus ni moins que les tests effectués lors du développement des objets intégrés du Data Warehouse.

Je pense qu’il n’y a pas de besoin qui justifie de ne pas intégrer les données, car si je pars sur un mode de « reporting opérationnel amélioré », le chemin vers une vision globale sera long et fastidieux. Si on regarde au niveau des coûts projets, les quelques jours supplémentaires de développement passeront sans trop de problème en cours de projet. Autant armer suffisamment la plateforme décisionnelle en lui permettant de couvrir plus de besoins, il me semble que c’est le compromis gagnant.

Les « Conformed Dimensions » peuvent être complexes à maintenir et à faire évoluer. Cette complexité s’accroit avec le nombre de sources qui les alimentent. Il est évident que si l’entreprise ne possède qu’un seul système source pour gérer toute son activité (très rare), il est aisé de les reconstituer.

C’est exactement à ce moment dans la réflexion, qu’intervient le Data Vault ! Et c’est précisément, ce critère qui me semble être le plus déterminant au choix du Data Vault dans une plateforme BI. Plus les sources sont nombreuses et l’intégration incertaine, plus le Data Vault va être intéressant.

La possibilité qu’offrent les satellites (plusieurs satellites par HUB) dans le Data Vault, facilite l’intégration et minimise les impacts. Le nombre de tables induites par le modèle peut effrayer mais , c’est cet éclatement par type de données et fréquence de changement qui donne sa flexibilité au modèle.

Tout ceci pour dire que commencer un projet en excluant toute intégration me semble erroné et surtout une manière de limiter la croissance de la plateforme Bi dès sa naissance. Si le reporting Bi n’offre pas cette possibilité, il y a de grande chance que le reporting décisionnel réside dans une sheet Excel construisant cette réconciliation de manière aléatoire et non-contrôlée. Ce qui personnellement me fait penser que probablement la plateforme décisionnelle est un échec.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s