Ç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! 
Désolé de ne pas ouvrir de débat cette fois mais je trouve ce billet très intéressant 🙂
La caractérisation des fonctionnalités « vertes », c’est qu’elles permettent de « raconter une histoire » correspondant à une activité bien précise de l’utilisateur et ça c’est important.
J’aurais une question : au fil des implémentations de ces diverses fonctionnalités, on risque d’avoir le besoin de modifier ce qui a déjà été fait précedemment.
Est-ce qu’il y a des techniques spécifiques au datawarehousing qui permettent de se prémunir des régressions sans passer trop de temps à tout re-tester ?
Ca me rappelle une discussion qui s’est tenue lors de l’Open Space Agile Innovation à Grenoble. C’est une bonne restitution / extension de ce qu’on s’est dit (notre résultat était beaucoup moins abouti que ton article, mais l’esprit était le même). Et ça correspond à ce que j’ai pratiqué dans un cadre décisionnel à partir de briques libres. Et ça fonctionne !
@Oaz: Très bonne question!
A ma connaissance il n’existe pas vraiment de bonnes pratiques reconnues spécifiques au décisionnel pour l’automatisation des tests de non-régression. De même, je n’ai pas connaissance de l’existence de frameworks automatisés de test dans l’eco-système décisionnel Microsoft.
C’est doucement en train de se mettre en place avec l’arrivée de PowerPivot (et BISM Tabular) qui vont permettre de requêter un cube et une base en même temps, pour par exemple comparer les données à différents niveaux des étapes de transformation.
Ce qu’on essaye de faire c’est comparer les valeurs des données de bout en bout – source versus reporting, pour les totaux, quelques ventilations importantes, le détail, en incluant également des cas spécifiques typiques complexes. Et évidemment chaque anomalie donne lieu à un test (une requête SQL qui donne juste un OK/KO) à intégrer à la batterie existante et à exécuter à chaque livraison. Mais c’est plus du bon sens qu’à proprement parler des techniques.
Point de vue implémentation, Andy Leonard avait fait une série d’articles connexes mais assez intéressants sur le TDD sur SQL Server.
Mon constat à l’heure actuelle c’est qu’il faut développer ses tests à la mano, avec les soucis de maintenabilité et de confiance que cela peut avoir. On en reparle dans 1 an et je suis sur que ça ira mieux 🙂
@Pierrick: merci beaucoup pour le retour 🙂
Loulou, ca sert à rien d’écrire autant d’articles sur la gestion de projet. Les MVP c’est sur des domaines techniques
😥
Pour revenir sur ton dernier paragraphe, dans les projets en méthodologie agile (SCRUM pour ne pas la citer) que j’ai pratiqués, l’installation des composants ou les prototypages étaient faits au sein d’un sprint (et donc d’une itération).
De plus, mais là je demanderai validation d’un SCRUM Master, il me semble qu’il n’y a pas de « premiers besoins », mais une définition du backlog qui définit les besoins de manières exhaustives avant mise en route des sprints.
Après je sais que tu fais un peu de l’agile Custom, et que ta boîte refuse de te certifier SCRUM Master
Mais c’est intéressant à lire 😉
Tu fais bien de le préciser, par « premiers besoins » j’entendais en effet la première alimentation du backlog.
Après autant monter un prototype on peut considérer que ça a de la valeur pour l’utilisateur, autant installer les softs je vois pas en quoi cela constitue une fonctionnalité. Mais c’est couper les cheveux en 4 😉
Et puis je suis peut-être pas SCRUM Master mais je suis MCT moi Monsieur… Hum hum…
Encore une fois de l’excellent travail.
Pour alimenter le débat sur la regression, il y a un projet très prometteur chez Microsoft qui s’appelle Barcelona et qui fait une cartographie de tous les flux (sources, ETL, DWH, cubes, rapports, BISM, Sharepoint, etc.).
Ca ne garantit rien mais ça fait gagner du temps sur les études d’impact.
Le projet est en beta privée et j’ai un article en préparation sur le sujet. J’en ai un peu parlé aux Journées SQL Server mais sans réseau, impossible de faire une démo.
http://projectbarcelona.cloudapp.net/
http://blogs.msdn.com/b/project_barcelona_team_blog/
PS : Mr Oaz, passez prendre une bière sur Paris à l’occasion 🙂
Wahou ! Quel Style ! Bel article.
bonjour,
bien ce billet, mais j’ai une question.
Les fournisseurs de données sources, eux ne respectent pas forcément l’agilité, et donc dans ce cas le sprint peut échoué (nombre de point non atteint) comment les contraindre à fournir en temps et en heures le informations notament dans le cadre de l’alimentation ????
Didier,
Le mieux est sans doute d’impliquer un membre de l’équipe du fournisseur de données dans l’équipe projet, et donc de le faire contribuer en mode agile.
Quand ce n’est pas possible, et si le fournisseur est indispensable (pas possible d’accéder en lecture aux bases sources, ou à un miroir des bases sources), là vous êtes devant un cas typique de frein à la réalisation, qui est un fort indicateur qu’il faut éviter le mode agile (https://fleid.net/2012/01/10/gestion-de-projet-decisionnel-methodes-agiles-ou-cycle-en-v/).
En résumé: pas de recettes miracles, soit vous contournez le problème en accédant vous mêmes aux bases (cas typique), soit vous évitez le mode agile.
J’espère avoir répondu à votre question 🙂
Bonjour,
Pensez-vous qu’un design de type DataVault permet en effet de diminuer le degré de dépendance du DWH avec la source?
Bonjour Christophe,
En théorie je ne pense pas. Quelle que soit la modélisation choisie, nous serons toujours dépendants de la source. C’est une constante du décisionnel.
En pratique je n’en ai aucune idée, puisque je ne fais pas de DataVault.
Ce que je sais c’est que je ne recommanderais pas cette modélisation dans une approche agile. L’objectif est en effet de rester le plus léger et simple possible dans l’architecture, pour garantir un temps d’implémentation minimal et une facilité d’évolution maximale.
A mon sens DataVault n’entre pas tellement dans cette catégorie. A moins peut-être d’être un génie du DataVault, mais je n’en ai encore jamais vu 😉
Pour répondre à Didier et Florian,
J’ajouterai que le Scrum Master à pour role de retirer les obstacles que peut rencontrer l’équipe de développement. Il peut travailler sur la question avec un responsable de l’équipe en charge du systeme source.
Lors du Product backlog refinement, il peut aussi etre interessant que l’équipe de développement remonte le point/risque au PO.