Note : 5 ; Il aurait été vraiment bien s’il avait été moins abstrait

On trouve de la littérature sur l’architecture agile. Pas beaucoup, mais on en trouve. Mais quand il est question du rôle de l’architecte, il en va autrement. Les approches agiles, centrées sur l’auto-organisation renâclent à en admettre l’existence, et seuls les ouvrages faisant état d’un architecte plus ou moins seul maître à bord (le chef de projet faisant la paperasse indigne de l’Architecte) apparaissent dans les rayonnages.

Le livre de Michael Keeling se positionne ici : une vue agile du rôle de l’architecte. A cet égard, il positionne l’architecte d’avantage comme un facilitateur que comme un directeur (voir un dictateur, le plus souvent). Pour nous convaincre de tout cela, le volume compte pas moins de 310 pages (hors annexes), ce qui semble plutôt conséquent. L’ensemble est structuré en 3 parties totalisant 17 chapitres. La première d’entre-elle, Introducing Software Architecture va compter 2 chapitres et se satisfaire de 25 pages en tout. La douzaine de pages du premier chapitre trace les grandes lignes des missions de l’architecte. C’est concis mais un peu abstrait, sans exemples pour étayer la chose. A ce stade on est confiant, le « Project Lionheart » illustrera cela. On a tort, ce premier chapitre donne un avant-goût du reste.

Design Thinking fundamentals ne parle pas de « Design Thinking » au sens classique du terme. En fait, il est question ici de l’approche globale que propose l’auteur, du travail de l’architecte selon 4 axes :

• Understand : Ou comment aller rechercher des informations auprès des parties prenantes pour mieux comprendre le contexte et les contraintes.
• Explore : Construire des solutions ou des combinaisons de structures en vue d’adresser le besoin.
• Make : Créer des modèles, des plans ou des prototypes.
• Evaluate : Vérifier l’adéquation de ce que l’on a imaginé et construit avec la réalité.

Les chapitres qui suivent habillent ces quatre axes. La seconde partie « Architecture Design Fundamentals » est dédiée à cela. Elle compte 11 chapitres sur près de 165 pages, c’est donc la partie principale du livre. Elle débute par un chapitre assez général sur la stratégie de conception orientée réduction du risque. Il n’apporte pas grand-chose.

Les chapitres 4 et 5 sont consacrés à l’axe « understand », pour aller recueillir les besoins des parties prenantes d’une part (chapitre 4) et relever les exigences clés par rapport à l’architecture d’autre part (chapitre 5). Le chapitre 4 est assez réussi avec le Stakeholder Map, alors que le suivant propose d’établir un « ASR workbook » pour les « architecturally significant requirements ». C’est peu convaincant.

Ce sont deux chapitres aussi pour la partie « explore ». Le chapitre 6 « Choose an Architecture » nous propose de construire une matrice de décision pour sélectionner une architecture. Bof. Cela devrait marcher en théorie, mais dans la pratique… Le chapitre 7 me régale plus car il parle patterns architecturaux (oui, ceux du POSA book) et en parle bien !

Un seul chapitre sur la partie « make » dédié à l’élaboration de modèles. C’est assez confus et peu exploitable pour moi. L’architecture design studio abordé au chapitre 9 semble intéressant. Toutefois, comme trop souvent, l’auteur en fait une description trop abstraite et pauvrement illustrée avec l’étude de cas qui ne me permet vraiment pas de me rendre compte.

Toujours dans le « make », le chapitre 10 nous invite à visualiser l’architecture selon différentes perspectives, pour en voir la structure, les patterns ou la métaphore. Intéressant mais peu convaincant. Plus abstrait encore, le chapitre 11 évoque les différents niveaux de description de l’architecture. Passons.

Les deux derniers chapitres de cette partie sont consacrés à l’axe « Evaluate ». Une mention pour le chapitre 12 proposant plusieurs options et niveaux d’évaluation en fonction de la rapidité de la boucle de feedback et la profondeur d’analyse.

La troisième partie compte 120 pages sur 4 chapitres, un pour chacun des axes évoqués précédemment. Il s’agit d’un catalogue d’activités décrits façon « patterns ». On y trouve pas mal de matériel intéressant, même si les descriptions souffrent une fois encore d’un niveau d’abstraction trop élevé. Toutes les activités n’ont pas le même niveau d’intérêt, mais ce catalogue sauve un peu le reste du livre.

Ce volume n’est pas ce que j’espérais. On parvient à saisir une approche de la mission de l’architecte qui sort des carcans habituels, mais l’auteur échoue à rendre son propos captivant avec un style et un niveau d’abstraction qui ne font pas le boulot. Dommage. Il reste le catalogue qui fourmille de bonnes idées même si lui-même aurait pu être plus concret.

Référence complète : Design It ! – Michael Keeling – Pragmatic Bookshelf 2017 – ISBN: 978 1 68050 209 1