Ça y est, vous avez bien intégré les valeurs de l’Agilité et vous vous êtes décidés pour construire votre datawarehouse en utilisant une méthode Agile. Excellent !
Déjà vous allez devoir convaincre les gens autour de vous que c’est possible. En effet la réaction naturelle dès qu’on parle de construire une solution décisionnelle en mode Agile c’est l’incrédulité. Autant pour la partie reporting personne ne voit vraiment de problème, souvent c’est même le contraire, autant côté back end – l’ETL et le datawarehouse à proprement parler – les reproches fusent :
- Les alimentations sont lourdes et compliquées, on ne peut pas les réaliser rapidement
- L’entrepôt est monolithique, vu les volumes on ne pourra pas le faire évoluer facilement
Pourtant, dès 1998 Kimball (notre père à tous 😉 ) publie les 3 concepts de base (PDF) du cycle de vie du datawarehouse :
- Mettre l’accent sur l’ajout de valeur métier pour toute l’entreprise
- Délivrer les données à travers les dimensions
- Développer une solution de façon itérative, livrer des incréments compréhensibles, plutôt que de travailler en mode big bang.
Vous avez vu la 3 ? Et la 1 ? Quel talent ce Ralph, en 1998 il faisait déjà de l’Agilité 🙂
Si le pape du datawarehousing dit qu’il faut le faire – notez qu’il ne dit pas qu’on devrait le faire, mais qu’il faut le faire – c’est bien que c’est faisable non ! Le tout c’est de savoir comment.
Là encore on écoute Monsieur Kimball, qui applique parfaitement l’Agilité et qui nous donne le mantra du découpage (Slide 19) : « Meaningful but Manageable » – « Porteur de sens mais Gérable ».
Point de vue implémentation l’objectif devient d’identifier la plus petite fonctionnalité qu’on puisse livrer à l’utilisateur qui porte encore du sens par rapport à ses besoins. Si on suit la méthodologie Kimball, cela veut dire qu’on va se concentrer sur un seul processus métier à livrer à chaque fois. Autrement dit, une seule table de fait (ou une poignée de tables) et les quelques dimensions qui lui vont bien. Soit on livre ces tables et on les rend accessibles en SQL, donc exploitable par l’utilisateur, soit on les accompagne d’un petit rapport SSRS ou un petit cube SSAS tout simple généré en une demi-journée. Là on a une itération courte et qui apporte de la valeur.
Oui mais même une table de fait et 4 dimensions ça peut prendre bien plus que 2 semaines à fabriquer, recetter et livrer ! Si on a des problèmes de qualité de données, si on fait du multi-source…
Ok. Alors on va se concentrer sur une seule source de données (une seule instance, un seul applicatif source…), sur un seul périmètre de données dans une même source (la France parmi le monde…), pour réduire le périmètre métier de la fonctionnalité, tout en maintenant son intérêt pour l’utilisateur, jusqu’à obtenir quelque chose d’unitaire et de livrable.
Par exemple, dans le cas d’une solution décisionnelle RH, on commencerait par importer uniquement les données actuelles, sans reprise d’historique. On récupèrerait uniquement les effectifs, uniquement d’une source choisie et d’une seule instance de cette source. On ne ferait de la qualité de données que de bas niveau (unicité, validation des types…) en rejettant tout ce qui n’est pas conforme. On ne ferait que peu de transcodage (uniformisation des critères type sexe, situation familiale…). Et on arriverait à générer un premier rapport simple mais précis sur la situation actuelle des effectifs sur ce premier périmètre. A partir de là on pourra itérer pour améliorer la couverture et/ou la qualité de la solution, en fonction des priorités arbitrées par l’utilisateur. Parfait ! 😉
Ce qui est important, c’est qu’il faut découper son projet selon l’axe métier, le périmètre fonctionnel, et pas selon l’axe technologique. Il faut faire du bout en bout (de l’ETL au reporting) en traitant un sujet simple, plutôt que de faire tout l’ETL, avant de passer à une autre brique :
Il faut penser ses fonctionnalités comme les vertes, et pas comme les rouges!
Au départ cela peut paraître difficile, voir même contre-productif. Et ça le sera d’ailleurs certainement au début. Mais cela mène à une plus grande expertise, une plus grande maîtrise de la solution de bout en bout et à une bien meilleure satisfaction client. En 2 semaines on va pouvoir lui générer un premier rapport qu’il pourra effectivement employer pour améliorer son quotidien.
Evidemment il existe des cas particuliers. Si vous êtes à fond dans la qualité de données, on peut considérer qu’une table de transcodage propre, avec une petite interface d’administration en ASP.NET, c’est une fonctionnalité qui a de la valeur pour l’utilisateur. Dans ce cas on n’est pas obligé d’aller jusqu’au modèle dimensionnel pour avoir de la valeur.
Et une fois que votre datawarehouse sera monté et stable, vous pourrez faire des itérations facilement au niveau de SSAS, SSRS ou tout autre outil de haut niveau, là on retombe sur quelque chose de plus facile à gérer.
Un conseil important au niveau de l’ETL : perdez le réflexe de vouloir importer tous les champs de tous les fichiers ou tables sources. Il faut savoir minimiser la largeur (le nombre de colonnes) à importer après la collecte (Extract d’ETL) dans le phase de nettoyage/transformation (Transform d’ETL). Chaque colonne a un coup de maintenance, que vous l’utilisiez ou pas, elle a un impact sur les performances (largeur du buffer), sur la maintenabilité (les bugs qu’elle peut générer) et dans l’évolutivité (lourdeur des métadonnées à mettre à jour). Il faut savoir rester lean de bout en bout, même si nos instincts d’écureuils de la forêt nous encouragent à stocker toutes les noisettes qu’on peut trouver !
Si vous voulez stocker ces informations parce qu’elles sont périssables, utilisez ce type d’architecture comportant une base d’archivage des données au format source. Vous pourrez l’utiliser si besoin de reprise d’historique :
Enfin, tout cycle de développement Agile commence par une phase d’initialisation : rencontre des intervenants, découverte des premiers besoins, installation des produits, prototypage… qui ne sont pas à proprement parler des itérations. C’est normal, pas d’inquiétudes à avoir, la transition vers les itérations se fera naturellement quand on vous demandera la première date de livraison 🙂
Voilà, on a fait le tour de l’itération décisionnelle, n’hésitez pas à poser vos questions dans les commentaires. Mais notez tout de même que cela ne suffit pas pour avoir un vrai décisionnel Agile. La brique essentielle qu’il manque encore c’est le cycle d’amélioration continu, tant au niveau de l’équipe que du datawarehouse. Ça c’est un sujet pour un autre jour 😉
La BI ça vous gagne! 