Note : 6 ; De bons moments mais des considérations bien trop générales la plupart du temps.

Je suis en grand fan d’architecture émergentes. Je n’avais pas de doute sur le fait que ce texte allait alimenter mon enthousiasme. Finalement, le livre refermé, le sentiment est mitigé. Nous allons voir pourquoi.

L’ouvrage est un format court, il ne compte que 164 pages sur 8 chapitres. Le premier chapitre compte une quinzaine de pages et couvre surtout des généralités. D’une part on y évoque les « ilités » et de l’autre la question de la conception émergente et pourquoi les auteurs préfèrent le terme « évolutionnaire ». Bref, il s’agit surtout de généralités. Le second chapitre aborde une notion très conceptuelle, celle de « fitness function », une notion que l’on retrouvera au fil des pages. L’idée est intéressante, à savoir établir une formule combinant les différentes propriétés attendues de l’architecture dans des proportions correspondant à nos attentes. La pratique est beaucoup plus floue, avec des concepts tels que « holistique » versus « atomique » …

Le chapitre 3 est bien plus conséquent, car il compte une vingtaine de pages pour évoquer la question des changements incrémentaux. Le cas d’utilisation choisi « penultimate widget » est bien abstrait, je n’ai pas compris ce que cela faisait (apparemment, ce n’est pas le sujet). Évidemment, il est question ici de pratiques devops et de déploiement continu, mais pas seulement. On évoque aussi la testabilité et de nouveau les fameuses fitness functions. Ce n’est pas mon chapitre préféré. On arrive aux choses sérieuses avec le chapitre 4 traite de « couplage architectural ». D’ailleurs le chapitre compte 35 pages. Tout d’abord la notion de « quanta architectural » définit la plus petite unité déployable indépendamment. Autant dire qu’il est gros pour le monolithe dont les auteurs se moquent à loisir. Le « monolithe modulaire » abordé ensuite (et rarement évoqué) mérite nettement moins de risées. Suivent : Micro-kernel, EDA, SOA, Microservice et serverless !

Bref, un tour d’horizon plutôt exhaustif des styles architecturaux principaux. J’aime bien, même si l’aspect « architecture évolutionnaire » n’est guère visible ici.
Place au chapitre 5 et à la « data évolutionnaire ». Un bien court chapitre d’à peine douze pages co-écrit avec l’auteur de « databases refactoring ». Dans un sens, c’est un bon ratio volume/information, mais c’est finalement un traitement très superficiel du sujet. Le co-auteur a peut-être cherché à ne pas trop marcher sur les plates-bandes de son propre ouvrage. Jusqu’ici le livre n’a pratiquement pas évoqué le volet « évolutionnaire » de l’architecture. C’est justement le sujet de ce chapitre 6 fort d’un peu plus de 25 pages. Cela part un peu dans tous les sens, sans grande cohérence. Le greenfield project a droit à un paragraphe bouche-trou, tandis que les applications legacy ont droit à bien plus sans que les considérations soient autres que générales : diviser en petits morceaux, définir les étapes de migration… La seconde partie du chapitre liste quelques tactiques applicables et est plus intéressante. Mais le chapitre est quand même décevant.

Le chapitre 7 adresse les pièges et anti patterns de l’architecture évolutive. C’est le chapitre que j’ai préféré. Bien sûr, on peut se régaler à lister de très nombreux anti patterns, mais les auteurs ont eu l’intelligence de réduire ceux-ci aux anti-patterns clé. Ils ne concernent pas seulement l’architecture en tant que telle, on y trouve des anti-patterns ayant un impact sur celle-ci, tel le « resumé-driven development ». Le livre se referme sur le chapitre 8 « putting evolutionary architecture into practice ». On y trouve essentiellement des considérations d’ordre organisationnelles. Ce n’est pas inintéressant, mais pas non plus indispensable au propos. Je passe.

Comme je l’ai dit au début, je suis un grand fan de l’architecture évolutive (personnellement j’aime bien « émergente »). Je pensais apprendre quelque chose, avoir de quoi réfléchir. J’espérais un texte construisant brique par brique cette approche pour me donner l’image globale. A la place, je termine sur l’impression d’un patchwork. L’élément central, la « fitness function » tient peu la route et n’est pas soutenue par le texte. L’étude de cas « penultimate widget » n’illustre pas le propos et encombre le texte. Enfin je perçois peu de liens entre les thèmes et ceux-ci sont traités la plupart du temps à trop haut niveau. Mon « 6 » est bien payé.

Référence complète : Building Evolutionary Architecture – Neal Ford, Rebecca Parsons & Patrick Kua – O’Reilly 2017 – ISBN : 978 1 491 98636 3