Introduction

Parmi les conférenciers et conférencières écoutées lors de NewCrafts et FlowCon, Andrew est, avec Torn et Jessica, sûrement les personnes qui m’ont le plus marqués (bon, et Woody, et Kent aussi, etc.) Et par hasard j’ai eu son livre dans les mains, puis dans mon sac, et j’ai décidé de le lire, alors que je suis très mauvais lecteurs de livres techniques (on reviendra peut-être dessus plus tard).

Mais ayant du temps (note : je cherche des missions), j’ai commencé à feuilleter l’introduction, puis cherchant à remplir mon temps-libre (je cherche des missions), à poster sur LinkedIn les promesses que je voyais dans l’introduction, ce qui m’a valu d’accepter un challenge de la part de Damien : le lire en cinq semaines et lui faire un résumé, en échange d’un déjeuner. Résumé que vous êtes donc en train de lire. Voilà pour le contexte, le début de l’histoire (et certaines personnes savent que j’apprécie toujours donner le contexte historique, avec un petit h, quand je partage quelque chose, mais je ne reviendrai pas là-dessus, j’ai écris dessus ici : Raconte moi une histoire).

Ce livre n’est pas une liste mais un arbre.

Il est très facile de parcourir le livre à la recherche d’un sujet particulier.

  • Il y a quatre grandes parties, et une introduction.
  • Chaque partie contient entre 3 et 5 chapitres, et est introduite par un mini chapitre supplémentaire d’une page qui résumera la partie précédente, l’objectif de cette nouvelle partie et le contenu de chacun de ses chapitres.
  • Chaque chapitre contient toujours une introduction, et surtout une conclusion.

Par conséquent, pour chercher une réponse particulière : lire les chapitres introductifs de chaque partie, pour identifier la partie qui parle de notre problème, et, dans la foulée, identifier le chapitre précis. Ensuite, lire la conclusion du chapitre pour identifier si une solution proposée convient, et alors identifier alors le paragraphe concerné. Enfin, lire ce paragraphe, qui explique le détail d’implémentation de la solution. Et c’est fait.

J’oserai même faire le schéma suivant :

Introduction de Parties Conclusion des chapitre Paragraphe
Pourquoi ? Quoi ? Comment ?
Est-ce mon problème. Si oui -> Est-ce une solution qui me parait valide ? si oui -> Détail de l’implémentation

Attentes rationalistes

Dès les éloges j’avais envie de connaître la fin. J’en partage deux qui m’avaient déjà donné dès la première page envie de lire le livre. Kevin Henry qui explique que contrairement aux architectes BTP, l’architecture logicielle est écrite par les mêmes personnes qui vont y habiter (en cohabitation avec les utilisateur·ices), et pour longtemps, et Jacqui Read qui énonce que l’architecture est la représentation des décisions prises pour la construire. L’avant-propos de Sarah Wells spoile le livre en nous racontant la fin, ce qui dans le cas d’un livre technique est parfait : elle annonce qu’Andrew a trouvé la solution très concrète - l’architecture advice process - pour résoudre la tension entre, d’une part, la volonté de laisser les décisions d’architectures au niveau local, induisant alors de trop grandes divergences, un manque d’efficacité jusqu’à de potentiel problème de sécurité ; et, d’autre part, la volonté de centraliser les décisions d’architecture, dans un monde où il n’y a plus de solutions “one size fits all”, où chaque équipe doit pouvoir apprendre et donc expérimenter, sans parler du goulot d’étranglement que cela crée.

En cherchant à répondre aux deux questions classiques “pourquoi j’ai écrit ce livre” et “pour qui je l’ai écrit”, l’auteur commence de manière élégante à construire le double argumentaire qui sera largement déployé dans le premier chapitre : d’abord en avançant le constat qu’il y a des équipes qui arrivent à produire de bonnes architectures et d’autres non ; ensuite en ébauchant une probable cause de ce constat : l’appétit de contrôle dont les organisations centralisées sont les meilleures représentantes. Pourquoi : parce qu’il a d’abord été le témoin privilégié, puis acteur en expérimentant ces pratiques. Pour qui : pour les actuel.les ou futur.e.s “architectes en ingénierie logicielle”, ce qui lui permet d’essayer de sous-catégoriser cette catégorie, et de faire émerger rien que par une tentative définitionnelle le concept de révolution et de redistribution du pouvoir. D’ailleurs, si un jour vous devez donner une formation en architecture, commencez par donner les différentes définitions qui ont pu être données par les grands architectes, ça marche toujours.

Néanmoins, il y a dans ses propos liminaire deux angles morts : les conséquences sociales de la promotion de l’autonomisation des équipes d’une part, et le fait que cela forme un système régulateur et auto-régulé, et potentiellement oppresseur notamment s’il est implicite. La comoditisation des pratiques et des activités induisent l’établissement de normes, souvent techniques, et Andrew propose dans son livre de les formaliser, mais aussi de normes sociétales. Et ces normes sociétales, si elles sont implicites, ont tendance à renforcer les mécanismes de domination, et, de ce que j’ai compris, pour les déconstruire, on doit se forcer à faire le chemin inverse, construire des groupes plus grands, plus forts, pouvant porter des revendications ; promouvoir des mécanismes de centralisation des discussions des décisions (démocraties libérales et état associé) ; permettre la construction formelle de groupes d’intérêt, notamment économiques pour atteindre une masse d’investissement critique (les syndicats, mais aussi le capital risk / VC, mais ce n’est pas la seule manière de le faire). Pour moi, la promotion de l’éclatement des organisation en petites équipes autonomes sans méta-structure explicite ne permet pas la survie des faibles. Le chaos est-il vraiment ontologique ou juste une justification du libéralisme ? Il y aurait même une contradiction (superficielle) entre une comoditisation des pratiques induisant une forme de normalisation et la volonté d’autonomiser les pratiques dans les équipes.

Il y a quelques années, à une conférence NewCrafts à Paris, au moment de la sortie d’Accelerate, on répétait en boucle qu’il fallait plus d’équipes plus petites et plus autonomes, le lien entre l’un l’autre étant parfois dans un sens, parfois dans l’autre, et chaque fois je rentrais la tête dans les épaules : je ne pouvais m’empêcher de projeter un discours ultra-libertarien, réfutant l’intérêt d’avoir une partie des responsabilités centralisées dans une organisation, alors que pour moi c’est nécessaire, d’abord parce que la sommes de optimums locaux fait rarement un optimum gloabal, mais aussi, et surtout, pour confisquer l’usage de la force dans des rapports explicites et ainsi protéger les plus faibles, permettant de réduire les risque de prises de pouvoir locales (en d’autres termes, s’assurer que la RH détient le monopole de la violence, de manière encadrée, et que cette violence ne peut pas être exercée localement, de manière insidieuse). Eviter de diviser pour mieux régner, et permettre l’égalité des chances.

Certaines personnes proposaient déjà à ce moment des solutions, comme Emily Bache avec le concept de Servent Architect, et c’est bien dans cette direction que pousse Andrew : comment réduire la décentralisation pour permettre l’autonomie (et donc la capacité à réagir au plus près du terrain), sans pour autant jeter les contraintes globales d’efficacité et de vitalité (comme la sécurité par exemple !). Il propose quelque chose qui ressemble à du mob programming, sauf que c’est pour des décisions d’architecture. Même si je pense qu’Andrew aurait pu insister encore plus sur ce qu’il essaye de sauver dans la centralisation, il est assez explicite sur sa démarche.

De même, Andrew propose de mettre en œuvre des mécanismes de synchronisation et d’explicitation des contraintes entre les différents groupes autonomes ; il différencie même décentralisation et distribution, la seconde, contrairement à la première, ne s’assurant pas de l’autonomie des parties. Je dis juste que cela aurait pu être une motivation explicite de sa démarche, s’il cherche à la légitimer, comme il le fait dans le premier chapitre. Premier chapitre qui me laisse sur la faim - non pas sur le constat, avec lequel je suis d’accord - mais sur le raisonnement qu’il soutient. Alors qu’il montrera par la suite une approche holistique, systémique, organique, la chapitre est très mécaniste. Enfin, une des raisons pour lesquelles Andrew a voulu écrire ce livre est, je l’ai dit plus haut, qu’il souhaitait regrouper les apprentissages qu’il avait pu faire au contact des bonnes et mauvaises équipes et les concepts qui en avait émerger. Alors, pourquoi une volonté idéaliste, historiciste, alors que son approche aurait le mérite d’être simplement constructiviste ?

Une forme de post rationalisation de son expérience, qu’il nomme révolution et qu’il va même séquencer en cinq étapes, alors que pour moi ce sont cinq facettes de la même co-évolution (activité + pratiques), celle que décrit Simon Wardley : la commoditisation du calcul et l’évolution alors nécessaire des pratiques associées, cette “new physics” dans le sens qu’elle n’est plus newtonienne, certaines, mais basé sur une forme d’incertitude.

Les pratiques proposées

A partir de là, l’approche d’Andrew pourrait se résumer en : faites de l’architecture comme vous faites du code de qualité. Je dirai : craft architecture as you craft your code. En utilisant les pratiques XP. Sauf qu’on ne produit pas du code mais des décisions d’architecture, formalisées sous forme d’ADR (Architectural Decision Record). Et qu’on n’écrit pas des tests d’acceptance mais des CFR (cross-functional requirements, un nouveau terme pour parler des quality attributes ou des non functional requirements - j’aurais préféré qu’il garde les anciens, mais il l’explique pourquoi cf. p. 34).

Deux petits points intéressants :

  • la portée d’une décision architecturale ne dépend ni de qui la prend ni du temps qu’il a fallu pour la prendre ;
  • le métier fait partie des inputs, mais aussi l’organisation de l’organisation…

Alors, il faut l’assumer et essayer que les décisions prises par le métier ou la SG en termes de RH, orga etc. qui ont un impact architecturales doivent être considérées comme des décisions d’architecture et idéalement suivre le même process : celui proposé dans le livre.

Car c’est bien sur cela que se concentre la suite du livre : définir un processus de décisions qui peut scaler tout en assurant les deux propriétés nécessaires : accueillir l’incertitude d’une part et permettre l’émergence d’autre part, et donc rester décentralisé (cf plus haut), sans pour autant perdre en rapidité (on a tendance à dire que la recherche du consensus est long, à l’opposé de la décision autocratique). C’est l’Architecture Advice Process et sa règle unique : tout le monde peut prendre des décision d’architecture à condition de prendre l’avis un de toutes les personnes impactées et deux de toutes les personnes expertes du domaine dans lequel la décision doit être prise.

À partir de là, le livre s’attache à déplier ce processus, notamment :

  • Comment reconnaître quand c’est nécessaire
  • Comment identifier ses parties
  • Comment formaliser le contenu des décisions avec leurs inputs, options, décisions prises, outputs
  • Comment le déployer
  • Comment l’exécuter (simplement, ou via l’intermédiaire d’une Architecture Advice Forum dont il explicite les fonctionnements en détail et que je ne reprendrai pas ici, vu que c’est peut-être le cœur pratique de l’ouvrage)

Sachant que la personne qui conseille ne sera pas responsable, mais celle qui prendre la décision, oui. Être conscient des niveaux de confiance entre les individus est donc centrale, avec cette bascule des responsabilités. Il est fondamental de construire la confiance, et une culture de l’apprentissage - et Andrew détaille comment le faire dans ce cadre spécifique (par exemple : ça dépend de la taille, ça se nourrit, ça se protège) mais aussi ce qui reste compatible avec (ex : TOGAF).

C’est comme du code, ici les ADR (pour le coup, je ne rapellerai pas ce qu’Andrew appelle un bon ADR, ça se trouve facilement), qu’on chercherait à produire en mob programming (métier compris), ici le Advice Process, qui peut se concrétiser, à l’échelle, sous la forme d’un Advice Forum, avec donc des CFR testables comme critère d’acceptance, distribuables, transverses, et permettant de traduire et de construire une stratégie tech autour de laquelle aligner les équipes, ce qui est fondamental. Et concrètement, Andrew propose comment en interne sourcer collectivement ces CFR, ces principes architecturaux (et son workshop), mais aussi en externe sous la forme de radar (dont il détaille précisément les composants). Ces trois artefacts (CFR, principes architecturaux, et radar) sont les concepts fondamentaux permettant de scaler, comme on le verra à la fin.

Comme les sessions de mob, sans confiance ni envie d’apprendre, ça ne marche pas trop (même si le mob aide à les construire, si au bout d’un moment elles ne sont pas là, l’intérêt va chuter), d’où toute une partie sur les mécaniques de dynamiques sociales et de groupe, ainsi que sur les enjeu de décentraliser la confiance.

Décider c’est naviguer

Les troisième et quatrième parties, plus courtes, prolongent les propositions précédentes encore plus sur le côté social, en prenant plus de recul sur ce que sont des décisions. D’abord en insistant sur les composantes humaines “irrationnelles” qui motivent les décisions que sont la manière de cadrer (son point de vue, les espaces que l’on inclue ou exclue volontairement dans l’analyse), les biais, les peurs, et ses compétences créatives.

Ensuite en montrant que les décisions font systèmes et que c’est la manière dont elle font système qui permet de s’assurer d’être, ou pas, résilient à la variabilité (aux “unknown unknown”. Si l’on accepte qu’une décision n’est jamais isolée, déjà, on aura peut-être spontanément l’idée qu’elle fait partie d’une série causale, mais Andrew propose d’autres topologies : un arbre qui s’étend (hiérarchie inversée), des groupes atomiques (des décisions qui forme un ensemble insécable, que l’on peut identifier par exemple avec des spikes, spikes qui aident à leur tour à réduire - pas à ignorer - la part émotionnelle des décisions, part qui a elle tendance à augmenter la variabilité) ; et il insiste sur le fait que deux décisions séparées dans le temps peuvent former des conversations bidirectionnelles, la passée influençant évidement la future, souvent bien après qu’elle a été prise, ses conséquences émergeant petit à petit, mais le future éclairant, sélectionnant la passée (une espèce de biais de la survivante - comme si l’histoire était écrite par les vainqueurs). Cela lui permet d’introduire d’autres considérations sur cette résilience à la variabilité, cette variabilité difficile à prévoir où elle apparaîtra mais pourtant au cœur du logiciel : prendre, et tester, ses décisions le plus rapidement possible, sans essayer de savoir si elles sont critiques ou pas (si elle ne le sont pas elles seront validées d’autant plus rapidement), mais surtout en limitant le contexte fonctionnel (ce que j’appelle le “domaine de définition”). Cela se fait à l’aide de walking skeletons, mais surtout… en essayant de découper les grosses décisions en de plus petites décisions. Comme les features, les décisions se slicent ! Ca peut être des découpages fonctionnels, mais aussi temporel, en fonction des composants techniques, et enfin organisationnel : commencer à prendre les décisions qui permettront ensuite chaque équipe de prendre leur propre décision en interne. Une fois cela dit, c’est un cercle vertueux : les bonnes décisions permettent de définir une architecture - et une organisation (socio-technique) - permettant de prendre rapidement de petites décisions :).

Partage du pouvoir et Leadership

Alors, le livre approfondira les sous jacents de la transformation qu’il propose. D’abord sur les déplacement de pouvoir et de responsabilités, en donnant des indices comment y arriver autant d’un côté (lacher prise) que de l’autre (accepter de nouvelles responsabilités) et que les deux ne sont pas évidents (ça parle transparence, confiance, sécurité, délégation…). Puis sur le leadership, qui reste présent absolument nécessaire, mais pour qu’il se développe aux bons endroits, ne doit pas être considéré comme inné, hiérarchique, unidirectionnel ni réduit au “management”, et liste quelques approches qui vont dans ce sens : les 14 points de Deming, le servant leadership (Greenleaf), l’adaptive leadership (Linsly-Heifetz), et surtout le Leader-Leader Leadership (Marquet), qui lui permet d’établir quelques nouveau challenges pour les architectes / décisionnaires qui veulent aller dans ce sens : lâcher le contrôle (vraiment), être inclusif (vraiment - je répète vraiment car c’est très facile de faire semblant, et Andrew donne des exemples concrets là-dessus), apprendre à chacun à exprimer ses intuitions comme des intentions (et non des décisions), et avoir confiance (vraiment aussi : ne vérifier que si c’est nécessaire), pour finalement insister sur le côté moral d’un leader - c’est plus en proposant un environnement sain, sécurisé, inclusif, qu’un leader augmentera l’efficacité d’une structure, qu’en prenant les bonnes décisions. Sachant que le rôle de leader n’est pas associé à un poste, et doit tourner, quitte à le forcer.

Conclusion : comment conduire le changement

Enfin, toujours dans cet idée d’approfondir les sous-jacents de la transformation qu’il propose, le dernier chapitre du livre prend du recul sur la manière d’intégrer cette transformation dans une organisation existante naturellement verticale : l’idée n’est pas de changer l’organisation de l’équipe commerciale par exemple. Il faut assumer que l’équipe tech ou produit aura une sous-culture spécifique, parce que les modèle mentaux de créativité sont différents, que le rythme des changements est beaucoup plus élevé qu’ailleurs, que les points de contacts entre cette équipe et le reste de l’organisation ne sont pas si nombreux que ça, et enfin… que c’est déjà accepté et assumé qu’on est différent :-) ! Et pour cela propose l’image de bulles qui si l’on ne cherche pas à comprendre - ou influencer - comment elle fonctionne, ne changera rien en dehors de la bulle, et pourra rassurer le reste de l’organisation.

Partant de cette image finalement très riche, le livre listera donc pour finir les différents attendus pour que cette bulle puisse persister dans un environnement hétérogène - et il y en a un certain nombre. Le premier est qu’il faut laisser la bulle s’auto-organiser - on ne peut s’auto-gérer que si on peut s’auto-organiser (et dans ce cas, on doit s’auto-organiser), mais aussi la liste des attendus de l’extérieur, implicite (comme savoir gérer les risques, être aligner et contribuer à la vision de l’organisation, être financièrement efficient) comme moins évidents (comme publier un organigramme alors que les relation de leadership dans la bulle sont variables, que tout le monde soit efficace, reconnu pour des expertises précises, alors que l’Advice Forum promeut plutôt des expertises partagées, en construction, ou valoriser les grandes réussites, alors que la bulle préfère valoriser les personnes qui apprennent de leurs échecs. Et enfin, peut-être le plus compliqué : suivre des process pas du tout adaptés comme les évaluations annuelles de performance, les primes individuelles).

Cela se traduit finalement par une sorte d’API entre la bulle et le monde extérieur (il est d’autant plus important que la bulle ne fuite pas vers l’extérieur : ne cherchez pas à propager par exemple les pratiques comme les décalage de pouvoir en dehors d’elle), API qui ne dépend pas de l’implémentation (pour pouvoir continuer d’évoluer) - ce qui veut dire qu’il y a une espèce de couche d’adaptation, d’ACL, qu’il faut surtout expliciter (elle consomme des ressources, et souvent n’est pas très agréable).

Les toutes dernières pages parlent de dynamiques : en l’occurrence, commencer petits, sur une équipe ; et quand la bulle est trop grosses, la séparer. Quand ? Quand la confiance décroit alors que les durées de prise de décision s’allongent. Comment ? A priori suivant les domaines ou les stream, et y a aucune raison que ce soit en deux parties égales (au contraire, partir d’une excroissance sera plus facile). Quoi ? Les ADR : on les partage ; les Forum : chacun le sien ; les CFR et les principes d’architecture : on les copie ! Et on garde le même radar - il est impossible de savoir quelle équipe sera influencée par une innovation extérieure.

Ce qui est intéressant alors, c’est que ce mécanisme permet de suivre les propriétés fondamentales par lesquelles on a commencé : accueillir l’incertitude d’une part et permettre l’émergence d’autre part, en formant des petites équipes autonomes, puisque les seules choses qu’elles partagent sont les CFR. Cela suffit à garantir l’alignement.