A l’heure de la Business Intelligence 2.0 et 3.0, je suis d’accord que le titre de ce billet n’est pas très vendeur. Cependant, il est encore difficile d'attribuer ces 3 qualités à nos systèmes décisionnels, c’est pourquoi j’aime à croire que le sujet reste d'actualité.
L'objectif de ce post n’est pas de résoudre tous les problèmes des systèmes décisionnels mais de formuler une proposition qui a le mérite de fournir un premier pas pour tendre vers ces 3 qualités simultanément.
Tout d’abord, pour éviter les incompréhensions, j’aimerais définir un peu les 3 qualités susnommées.
Quand je parle de qualité, je ne parle de la qualité de données (un autre sujet sans fin dans le décisionnel), mais plutôt de qualité logicielle. Je vais ici m’intéresser à l’un des axes de la qualité au sens OCTO lorsque nous réalisons des audits, à savoir les tests. En effet, il y a une corrélation forte entre la qualité d’un système et sa politique de test et malheureusement, ce n’est pas le fort des systèmes décisionnels : au-delà de quelques tests unitaires et de la recette, on est loin d’une politique de tests exhaustive comme peut le représenter le schéma ci-dessous :
Bien sûr, ces tests sont à réaliser à chaque livraison pour éviter les régressions. Retrouver un tel harnais de test incluant la non-régression est extrêmement rare dans les projets décisionnels.
Un système décisionnel, qui souhaite prendre le chemin de la qualité, ne présente peut-être pas tous ces tests mais doit au moins comprendre des tests unitaires, des tests d’intégration et des tests de performances.
Sans rentrer sur l’opportunité ou non des méthodes agiles, je présenterais un système agile comme un système regroupant les qualités suivantes :
C’est un vaste programme mais pas irréalisable, à partir du moment où l’on respecte quelques pré-requis. Il y a en 2 sur lesquels j’insiste systématiquement lorsque je travaille en clientèle sur la mise en place d’une méthode agile : les tests et l’industrialisation…
Des trois qualités, c’est sûrement celle qui mérite le plus un éclaircissement au sens où l’industrialisation, quand on parle de développement logiciel, porte en elle à la fois le meilleur et le pire en termes de pratiques. Ce qui m’intéresse dans l’industrialisation, c’est principalement l’automatisation de tâches à faible valeur ajoutée et/ou répétitives, et le partage de standard au sens lean :
Ce qui est bien plus douteux quand on parle d’industrialisation, se cache derrière les approches top-down visant à maîtriser le développement logiciel et mène souvent à l'échec en dehors de cas balisés, par exemple : les pratiques de type MDA et les frameworks de génération de code, la spécialisation des acteurs et le sur-découpage des tâches, ou n’importe quelle approche de modélisation mise en oeuvre sans discernement (3NF , datavault…). Toutes ces mauvaises pratiques partagent en fait un même ADN : pousser à l’extrême une initiative intéressante dans un contexte, ou un modèle élégant sur le plan théorique ne résistant pas à la mise en pratique.
Un système d’information décisionnel industriel est donc selon moi un système ayant réalisé l’automatisation de tâches à faible valeur ajoutée et/ou répétitives et partageant des standards, tout cela avec bon sens et un souci constant de remise en question.
Comme je le disais en introduction, ma proposition constitue un premier pas pour améliorer les 3 qualités précédemment explicités simultanément. Cette proposition n’apporte rien de très neuf si l’on regarde les systèmes opérationnels où elle est courante depuis la fin de la décennie précédente. Cette proposition, c’est l’usine de développement.
La promesse de cette usine est de jouer sur 3 facteurs comme indiquer dans le schéma ci-dessous :
Cette usine est constituée d’une panoplie d’outils mise à la disposition d’un projet combinée avec la définition d’un processus et de règles. Pour la description fonctionnelle précise d’une usine et de ce qu’elle permet de réaliser en détail, je vous renvoie vers ce très bon article (la suite de ce billet risque d’ailleurs d’être un peu abscond si vous n’êtes pas familiarisé avec ces concepts).
Attention tout de même, pas de silver bullet, cette usine ne résoudra pas tous vos problèmes, ce n’est qu’une première pierre à l’édifice pour consolider les bases de votre système d’information décisionnel et surtout ce n’est pas :
Alors qu’est-ce que serait une usine de développement pour un système décisionnel ? Prenons comme exemple l’usine de développement ci-dessous :
Illustrons tout d'abord le fonctionnement de cette usine sur le cas d'usage suivant : une modification du modèle de base de données. Tout d’abord le développeur opère sa modification, réalise les tests associés et commit finalement cette modification vers le gestionnaire de source (notamment des scripts de bases de données sont envoyés comprenant les modifications, ses différentes étapes et le retour arrière). Ensuite via le gestionnaire de build, nous avons maintenant la possibilité de tagger cette modification pour une release et de déployer automatiquement ces modifications sur les environnements souhaités. Ce déploiement pourra prendre une forme différente pour la production par exemple, mais sera toujours réalisé à partir des mêmes sources afin d’éviter les erreurs.
Pour préciser le fonctionnement, je ne reviendrai pas sur les composants de base d’une usine de développement (gestionnaire de source, de build et le serveur d’intégration, reporting, wiki que vous retrouverez dans l'article en suivant le lien précédent) mais je vais revenir sur les spécificités d’une usine de développement BI.
Une grande différence réside dans la place centrale de la donnée et des bases de données dans l’architecture. A ce titre, des outils spécifiques sont nécessaires pour gérer les modifications de base de données (ici liquibase) sur le principe de refactoring database et les tests sur les bases de données via l’utilisation d’un framework de test unitaire (ici dbunit).
Concernant les tests unitaires, si l'on peut rappeler qu'ils sont importants, il faut bien comprendre qu'ils sont en fait vitaux dans ce type d'architecture. La spécificité des tests unitaires dans le décisionnel est qu'ils sont rattachés à des langages scriptés (script shell par exemple) ou à des L4G qui sont bien moins servis en analyseur de code qu'un langage de programmation comme Java disposant de plus de la compilation comme verrou supplémentaire de vérification.
Une autre spécificité se cache derrière l'importance et la complexité des tests d'intégration. En effet, dans un contexte de système d'information décisionnel fortement corrélé avec les systèmes en amont voire en aval, ces tests prennent une ampleur et une importance capitale pour garantir la qualité et éviter les régressions vis-à-vis de systèmes évoluant eux aussi. Cela constitue d'ailleurs un très bon test pour identifier, à posteriori, des modifications de systèmes sources ayant échappé à votre attention...
Dans le même ordre d'idée, les tests de performance dans un contexte à forte volumétrie sont clés. Dans un monde où Big Data est notre pain quotidien, la recherche de la performance (ou son maintien) est vitale. Cependant, au lieu de parler de disponibilité ou d'utilisateurs concurrents (quoique), c'est bien la performance des flux et des transformations qui doit être testée via une usine BI.
En conséquence, c'est la logique de build qui doit être adaptée. On peut par exemple mettre un build d'intégration continue pour vérifier toute la chaîne sur une volumétrie raisonnable et un build de nuit orienté performance notamment pour les batchs consommateurs. Cette notion de build pourra aussi nous permettre de tester des scénarios que l'on retrouve souvent dans le décisionnel comme une initialisation ou une pré-production, une migration ou des rejeux.
Enfin, certains composants ou pratiques ne sont pas transposables d'une usine traditionnelle vers une usine BI. Par exemple, la notion de couverture du code ou l'utilisation de Sonar dans un contexte où le reporting est une fonctionnalité de base du système paraissent inappropriées. Un vrai travail d'adaptation des usines traditionnelles à votre contexte et à vos usages est donc à réaliser.
Bien entendu, tout n’est pas parfait et quelques limitations freinent le déploiement de ce type de solution :
La mise en place de ce type d'usine n'est pas difficile techniquement mais une implémentation progressive est à privilégier (comme tout projet en fait) afin notamment d'adapter les processus associés et la culture des acteurs du projet. Un premier PoC, se limitant par exemple aux modifications de la base de données, permettra rapidement de se rendre compte des impacts et des intérêts de ce type de solution. Le fait que votre projet soit déjà commencé depuis des mois n'est pas une excuse valable pour ne pas essayer (dans la majorité des cas observés l'usine était arrivée en cours de projet).
Véritable pré-requis à la mise en place d’une approche agile, vraie garantie de la qualité de votre système et source de productivité par l’automatisation qu’elle apporte, l’usine de développement est aujourd’hui incontournable si vous souhaitez relever ces challenges.
L’investissement initial, comme nous l’avons observé sur plusieurs projets, a toujours été amplement remboursé au bout de quelques mois jusqu’à faire de l’usine de développement la pierre angulaire de ces projets.