Peut on finalement rester pragmatique dans notre approche tout en ayant l’innovation que tout le monde veut à notre époque ?
L’architecture d’un projet est complexe, même le projet le plus simple peut être architecturé de nombreuses façons. A cela peut s’ajouter un manque de clarté sur le projet, qui n’est pas encore totalement défini, une pression pour utiliser telle ou telle technologie, une date de mise en production rapide mais aussi les compétences techniques de l’équipe… Faut-il réinventer la roue pour trouver la solution d’architecture adéquate pour le projet ou repartir d’une page vierge obligatoirement ?
Pourquoi la recherche de solutions est un défi ?
Les attentes variées des parties prenantes
Les clients veulent souvent une solution innovante, évolutive, rapide à mettre en œuvre, etc. Bref, une solution qui répondra à toutes les évolutions possibles et qui puisse aussi faire le café si l’on veut. Tout cela avec un budget qui lui aussi peut évoluer au fil du temps. J’exagère volontairement, mais pas tant que cela.
Le management du projet va, quant à lui, vouloir une solution totalement maîtrisée, pas de surprises en cours de route, il faut savoir à la minute prêt ce que l’on doit faire. Je vous invite à regarder la loi de Hofstadter : https://fr.wikipedia.org/wiki/Loi_de_Hofstadter. Celle ci décrit rapidement que quoi que l’on fasse, ce ne sera pas possible.
Les développeurs vont souvent vouloir évoluer et pouvoir s’amuser, il faut du nouveau. Cela nous mène à se former et à plonger dans l’incertitude.
Le piège des tendances
Il y aura toujours dans les comités de préparation, au moins une personne qui a lu ou entendu parler d’une solution magique, en général toute nouvelle, qui répond à tous les besoins du projet et qui va faire du lobbying autour de cette technologie.
Les contraintes invisibles
Budget, performances, compatibilité, délai sont autant de contraintes sur l’architecture qui n’ont pourtant pour certaines aucun chapitre dans le dossier d’architecture, tout juste une ligne dans le tableau des contraintes. J’ai connu des projets qui avaient une date de mise en production déjà définie avant d’avoir des spécifications écrites, des performances fantaisistes.
Ces aspects font peur mais il existe des solutions. Je n’ai pas connu de clients qui n’écoutaient pas des explications claires sur le décalage d’une mise en production ou d’une redéfinition du périmètre par exemple.
L’évolution constante des technologies
La rapidité avec laquelle les technologies évoluent rend difficile la mise à jour des connaissances et des choix techniques.
Les étapes clés pour rechercher une solution d’architecture efficace
Comprendre le problème
La première étape est de se faire expliquer la problématique afin de faire une analyse fonctionnelle et technique. Pour cela, il faut faire des réunions régulières, insister, poser des questions, bref : impliquer les parties prenantes pour clarifier les besoins. Il faut savoir exactement à qui demander, le décideur n’est pas forcément celui qui connait le mieux la problématique. Il faut aussi croiser les informations, car il y aura des contradictions, des hors sujets. Une question que je pose souvent est tout simplement : « Pourquoi ? ».
Cette question surprend mais ce qui est évident pour l’un mérite d’être expliqué pour l’autre. Expliquer n’est pas facile et si l’on ne sait pas répondre à cette simple question, on peut se questionner sur le caractère essentiel de ce qui est demandé.
La préparation des ateliers est essentielle, on ne peut pas aller à une réunion en attendant de prendre des notes. Il faut avoir préparé un plan et, pour ma part, j’ai très souvent une esquisse de solution qui permet d’avoir une base pour discuter.
Explorer l’existant
Une solution d’architecture n’est pour moi valable que si un ensemble de paramètres est pris en compte, dont les logiciels déjà existants, l’équipe qui écrira le logiciel et la maintenance. En effet, je pense qu’il est inutile de mettre en place une architecture avec trop d’inconnues pour les équipes si nous n’avons pas quelques spécialistes sous la main.
Evaluer les options
Il n’y a pas une seule solution, le métier de l’architecte est de voir les solutions possibles et de les présenter en identifiant les forces et les faiblesses des options disponibles.
Il est important de capitaliser sur les solutions précédentes ou des patterns éprouvés, ce n’est pas parce que l’on a déjà fait qu’il faut obligatoirement innover, il ne faut pas ignorer ce qui fonctionne.
Il faut aussi rechercher des cas similaires, des retours d’expérience, des benchmarks. Je prends ici l’exemple de l’accès aux bases de données avec le Framework Hibernate, selon la DB, les performances ne sont pas du tout les mêmes.
Pour cela, une matrice est une base, mais l’on peut aussi donner un score à chaque solution avec des ratios différents selon ce qui est important ou moins important.
Prototyper et tester
Il est crucial de tester ses hypothèses afin de valider certaines options, c’est pour moi indispensable sur la sélection de Framework et de COTS ou de code custom. C’est une méthode rapide pour valider la faisabilité technique ou fonctionnelle.
Les erreurs fréquentes à éviter
Je ne suis pas certain qu’une liste exhaustive puisse être établie… Cependant, voici quelques points importants:
- La solution à la mode : Choisir une solution car on en parle dans beaucoup d’articles, à la radio, etc.
- Sous estimer les risques: Sécurité, compatibilité, ou surcharge technique.
- La solution trop complexe: « Over-engineering » pour répondre à des besoins futurs incertains et pour pouvoir tout faire
- Ignorer l’équipe: Une solution non adaptée à leur expertise ou préférences.
- Le manque de documentation: Laisser un flou sur le pourquoi et le comment.
Comment tirer parti de l’expérience (et des échecs) ?
Un projet, qu’il se soit bien passé ou non, est une expérience utile. Il est plus facile de trouver les raisons d’un échec que d’une réussite.
- Apprendre des projets passés : Faire un post-mortem des solutions précédentes. Lister ce qui s’est bien passé et ce qui s’est mal passé. Ne pas oublier de lister ce que l’on a aimé ou pas.
- Mettre en place une base de connaissances : Centraliser les patterns, outils et retours d’expérience. C’est vrai que pour moi, c’est surtout mon cerveau… Ce qui n’est pas une bonne solution
- Encourager une culture de collaboration : Échanger avec d’autres architectes ou développeurs pour enrichir sa vision.
Conclusion
Je pense que la clef est de bien structurer la recherche, impliquer les parties prenantes, prototyper et documenter. Mes points forts sont la recherche, le prototypage et la documentation. J’ai plus de mal pour impliquer les parties prenantes, les interactions humaines ne sont pas mon fort, c’est pourquoi je planifie des réunions hebdomadaires dès le départ, pour me forcer à communiquer.
Le métier d’architecte est assez solitaire, et c’est assez paradoxal. Je ne comprends pas cette solitude. J’ai du mal à faire appliquer mes méthodes, cependant, je trouve qu’il serait beaucoup plus simple de ne pas être si seul. Je travaille dans des services complexes, avec de très nombreux projets. A chaque nouvelle architecture, je réfléchis à une solution que je présente à un comité de décideurs, architectes fonctionnels et techniques. Ce comité questionne la solution. J’ai du mal à comprendre pourquoi cette réunion arrive tardivement, lorsque j’ai bien réfléchi et étudié de nombreuses pistes. Pour moi, une réunion de présentation aux architectes devrait être organisée et les idées lancées, avec un ou deux ateliers qui présentent ensuite les conclusions de ces pistes pour ne pas remettre en cause la solution en fin de recherche. Quelle que soit la solution, il faut respecter la règle du KISS:
« Keep it simple stupid »
Il n’existe pas de solution parfaite, mais une méthodologie rigoureuse et une culture de collaboration peuvent faire toute la différence.
La recherche d’une solution d’architecture est un exercice d’équilibre, une quête perpétuelle de la simplicité et de l’efficacité.
Et vous, comment faites vous ? Quelle a été votre plus grande difficulté dans la recherche d’une solution d’architecture ?
