Histoire d'une architecture émergente - Emmanuel-Lin Toulemonde, Duck Conf 2021
La belle histoire que nous raconte Emmanuel-Lin, c’est celle d’un projet d'architecture émergente qui a permis de gagner des centaines de milliers d’euros dès la première journée de développement. C’est l’histoire d’un MVP vraiment minimaliste.
Dans tout projet d’informatique, un schéma, un plan ou une architecture est défini ; de nombreuses briques qu’il va falloir mettre en place et sur lesquelles reposera une application. Cette architecture peut souvent être lourde à mettre en place et, quand on débute le projet, on peut s’attendre à ce qu’elle ne soit pas fonctionnelle tout de suite.
À partir de ce moment-là, architecture pourrait rimer avec torture.. Surtout pour le DevOps !
Il était une fois… les raffineries de Total
Les raffineries consomment beaucoup de gaz et d’énergie : en France, cela représente à peu près 3% de la consommation de gaz et 0,5% de la consommation d’électricité, pour un coût de plusieurs centaines de millions d’euros par an. C’est le rôle de l’acheteur énergie que de négocier et opérer les contrats d’achat d’énergie. Pour cela :
- il fait des nominations à dire d’expert. S’il se trompe dans ses prédictions, il risque de payer un surcoût.
- il achète des capacités, c’est-à-dire un droit à consommer du gaz, dont les dépassements impliquent des pénalités onéreuses. Il peut cependant acheter des capacités supplémentaires, s’il parvient à anticiper ses besoins.
C’est pour répondre à cette double problématique que la Total Digital Factory a donné naissance au projet VADER (Valorisation des données énergétique du raffinage). L’objectif : nominer et prévenir les dépassement de capacité, en utilisant le données historiques jusqu’au quasi temps-réel pour alimenter un modèle de prévision.
Le plan vs la réalité
Le projet a donc débuté par deux semaines de “scoping”, durant lesquelles la squad a pu réfléchir à l’architecture qui collerait au mieux avec l’application à développer. Le plan a ensuite été challengé par une équipe d’architectes et suite à cette revue, la squad a commencé à douter. Douter de la difficulté de la première marche.
Alors, elle a décidé de mettre cette architecture de côté car la promesse faite à Marc, le PO et utilisateur de la solution, était d’apporter de la valeur immédiatement.
Marc a besoin de prédire la consommation en gaz et en électricité de ses raffineries. Il veut savoir s’il consomme trop, s’il risque des pénalités et combien ça peut lui coûter.
Prédire pour le lendemain, ses équipes et lui le font déjà, mais savoir si le jour-même il va trop consommer, ça non. C’est la première fonctionnalité que l’équipe à décidé de développer. Ensuite, elle a découpé les autres et les a priorisées.
Au lieu de mettre en place toute l’infrastructure imaginée, la squad a choisi de livrer de la valeur immédiatement. Et de le faire de la manière la plus simple possible.
“en production dès le jour 1”
La squad a établi un backlog de ce qu’il fallait développer et s’est retrouvée avec une todo list encore un peu trop longue.
Le backlog définit par la squad pour la première fonctionnalité
Après ce premier découpage, le temps de développement estimé était de 4 à 6 semaines. Alors elle a essayé de faire encore plus simple.
La manière la plus simple et la plus rapide de livrer de la valeur à l'utilisateur
Une architecture émergente
Les données étaient extraites manuellement par Marc. Une règle métier simple calculait les consommations. Ensuite chaque jour, une personne de la squad envoyait à Marc, dans un chat d’équipe, un screenshot des prédictions pour la journée en cours.
La première architecture de VADER, le 1er jour de développement à 11h
Finalement, la solution était en production dès le jour 1 et l’utilisateur prenait déjà ses décisions à partir des prédictions.
Par la suite, on a apporté de nouvelles fonctionnalités à notre PO (rendre les paramètres en dur configurables par l’utilisateur, calcul des pénalités projetées et celles réellement encourues, etc.). Les déploiements et les tâches ont alors été automatisés (extraction des données, envoi de mail, infrastructure, etc) et notre application est devenue plus robuste. Grâce à cette approche, tous les jours, nous étions capables de faire émerger une nouvelle architecture.
Chaque étape devenait un choix conscient de l’équipe, dicté par la réalité et non par les hypothèses faites en amont du projet. Marc a aussi beaucoup contribué au projet car son feedback a aussi amené certains choix.
« Une vision qui ne s'accompagne pas d'actions n'est qu'un rêve. Une action qui ne découle pas d'une vision c'est du temps perdu. Une vision suivie d'action peut changer le monde. » disait Nelson Mandela. D’ailleurs l’équipe n’a pas jamais complètement laissé de côté le schéma d’architecture. Il était simplement le reflet de leur vision. Et jour après jour, choix après choix, architecture après architecture, elle a convergé vers sa vision.
L'histoire complète racontée par Emmanuel-Lin est déjà disponible sur Youtube.
Take Away
Viser sans cesse la simplicité c’est fatiguant alors voici les choses importantes qui méritent d’être retenues :
- Faire simple pour éviter le sur engineering et atteindre vos objectifs organisationnels plus vite.
- Être agile est un état d’esprit, l**’architecture émergente est l’incarnation de l’agilité en architecture logicielle**.
- Le schéma d’architecture doit servir de vision.
- Commencer simple, puis faire des petites actions vers cette vision.
OCTO propose une formation architecture des données : stockage et accès. Au cours de cette formation, nos consultants mettent à disposition les connaissances issues de leurs retours d'expériences auprès de nos clients, et vous font découvrir les bases des architectures permettant de répondre à ces enjeux de stockage et d’accès.
