L'architecture faiblement couplée — Accelerate

Les pratiques de livraison continue (continuous delivery) améliorent la performance, la culture et le bien-être des équipes. Mais elles se heurtent souvent à un mur que la volonté seule ne suffit pas à franchir : l'architecture du logiciel et des services dont il dépend. Un système mal découpé peut transformer chaque déploiement en négociation collective, et faire de l'automatisation des tests un chantier si coûteux qu'on y renonce. Forsgren, Humble et Kim ont donc cherché à mesurer l'impact des décisions architecturales sur la performance de livraison — et à isoler ce qui distingue une architecture qui libère les équipes d'une architecture qui les entrave.

Leur résultat principal est à la fois libérateur et contre-intuitif. La haute performance est possible avec presque tous les types de systèmes — mainframe, embarqué, progiciel sur étagère, comme greenfield web — à condition que les systèmes, et les équipes qui les construisent et les exploitent, soient faiblement couplés (loosely coupled). Ce n'est pas le style d'architecture à la mode qui décide ; c'est une propriété précise : la capacité d'une équipe à tester et déployer son service indépendamment, sans coordination fine ni synchronisation permanente avec d'autres équipes.

Le type de système n'est (presque) pas le facteur décisif

L'intuition courante voudrait qu'on livre vite et bien sur un système d'engagement (system of engagement) tout neuf, et lentement sur un système d'enregistrement (system of record) critique, un progiciel ou de l'embarqué. Les auteurs ont testé cette hypothèse sur un large éventail de types de systèmes, examinés à la fois comme système principal en développement et comme service contre lequel on doit s'intégrer.

Type de système	Performance attendue (intuition)	Résultat de la recherche
Greenfield (jamais mis en production)	Élevée	Pas de corrélation significative
Système d'engagement (utilisé directement par l'utilisateur)	Élevée	Pas de corrélation significative
Système d'enregistrement (données critiques)	Faible	Pas de corrélation significative
Progiciel commercial sur étagère	Faible	Pas de corrélation significative
Logiciel embarqué (sur un appareil matériel)	Faible	Pas de corrélation significative
Logiciel sur mesure développé par un tiers	—	Plus fréquent chez les low performers
Systèmes mainframe	Faible	Plus fréquent chez les low performers
S'intégrer contre un mainframe	Faible	Pas de corrélation significative

Deux faits saillants. D'abord, pour la plupart des types de systèmes, aucune corrélation significative avec la performance de livraison : c'est surprenant, et cela contredit l'intuition. Ensuite, deux cas tirent les performances vers le bas. Les low performers étaient plus souvent en train de bâtir — ou de devoir interagir avec — du logiciel développé sur mesure par une autre entreprise (typiquement un partenaire d'externalisation), et plus souvent au travail sur des systèmes mainframe. Détail important : avoir à s'intégrer contre un mainframe n'était pas corrélé à une moindre performance.

Note

Ce résultat déplace le débat : il faut se concentrer sur les caractéristiques architecturales (détaillées ci-dessous), pas sur les détails d'implémentation. On peut atteindre ces caractéristiques même avec un progiciel ou un mainframe « legacy » ; à l'inverse, la dernière architecture microservices déployée sur conteneurs ne garantit rien si l'on ignore ces caractéristiques.

Le cas du logiciel sur mesure développé par un tiers porte aussi une leçon stratégique, déjà esquissée plus tôt dans le livre : puisque la performance de livraison influence la performance organisationnelle, il faut investir dans la capacité à créer et faire évoluer les produits logiciels stratégiques qui différencient l'entreprise — et donc rapatrier cette capacité en interne plutôt que de la sous-traiter.

Les deux caractéristiques décisives : testabilité et déployabilité

Si le type de système compte peu, deux caractéristiques architecturales comptent énormément. Les répondants d'accord avec les deux affirmations suivantes appartenaient bien plus souvent au groupe des hauts performants :

« Nous pouvons réaliser l'essentiel de nos tests sans environnement intégré (integrated environment). »
« Nous pouvons déployer ou livrer notre application indépendamment des autres applications et services dont elle dépend, et nous le faisons. »

Les auteurs nomment ces deux propriétés testabilité (testability) et déployabilité (deployability). Pour les atteindre, on conçoit des systèmes faiblement couplés : des systèmes qu'on peut modifier et valider indépendamment les uns des autres. En 2017, l'analyse a été élargie pour mesurer à quel point une architecture faiblement couplée et bien encapsulée détermine la performance informatique. Le verdict est net : c'est le plus gros contributeur à la livraison continue dans l'analyse 2017 — devant même l'automatisation des tests et des déploiements.

Concrètement, l'architecture est suffisamment découplée quand une équipe peut :

Capacité de l'équipe	Ce que le découplage permet
Modifier en profondeur la conception de son système	sans la permission de quelqu'un d'extérieur à l'équipe
Modifier en profondeur la conception de son système	sans dépendre d'autres équipes ni leur créer un travail significatif
Terminer son travail	sans communiquer ni se coordonner avec des personnes hors de l'équipe
Déployer et livrer son produit ou service à la demande	quels que soient les autres services dont il dépend
Réaliser l'essentiel de ses tests à la demande	sans environnement de test intégré
Déployer en heures ouvrées	avec un temps d'arrêt négligeable

Dans les équipes qui obtiennent un score élevé sur ces capacités architecturales, peu de communication est nécessaire entre équipes de livraison pour faire avancer le travail : l'architecture est conçue pour qu'on puisse tester, déployer et faire évoluer son système sans dépendances vers les autres équipes. Architecture et équipes sont faiblement couplées. Pour que cela fonctionne, il faut aussi des équipes pluridisciplinaires (cross-functional), réunissant en leur sein toutes les compétences nécessaires pour concevoir, développer, tester, déployer et exploiter le système.

À retenir

Le découplage prédit fortement le débit (throughput) et la stabilité (stability) à la fois. C'est sa singularité : la plupart des leviers font arbitrer entre vitesse et fiabilité, alors qu'une architecture testable et déployable indépendamment améliore les deux dimensions simultanément, tout en réduisant l'épuisement et la douleur du déploiement.

La loi de Conway et la manœuvre inverse

Le lien entre bande passante de communication et architecture des systèmes a été formulé dès 1968 par Melvin Conway : « les organisations qui conçoivent des systèmes [...] sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations. » Autrement dit, l'architecture d'un système tend à refléter l'organigramme de communication de l'entreprise. Une organisation cloisonnée produira un logiciel cloisonné ; des équipes qui doivent sans cesse se parler produiront des systèmes qui doivent sans cesse se coordonner.

Loi de Conway (sens habituel)
  Structure de communication  ──────►  Architecture du système
  de l'organisation                     produite

Manœuvre inverse de Conway (inverse Conway maneuver)
  Architecture cible          ◄──────  On fait ÉVOLUER d'abord
  (faiblement couplée)                 les équipes et la structure
                                       pour OBTENIR cette architecture

La recherche d'Accelerate appuie ce qu'on appelle la manœuvre inverse de Conway (inverse Conway maneuver) : plutôt que de subir la loi de Conway, on s'en sert. On fait évoluer délibérément la structure des équipes et de l'organisation pour obtenir l'architecture désirée. L'objectif : que l'architecture soutienne la capacité des équipes à faire leur travail de bout en bout — de la conception jusqu'au déploiement — sans nécessiter de communication à haute bande passante entre équipes.

Plusieurs approches concrètes servent cette stratégie : les contextes délimités (bounded contexts) et les API pour découper de grands domaines en unités plus petites et plus faiblement couplées ; les doublures de test (test doubles) et la virtualisation pour tester un service ou un composant en isolation, sans devoir lever l'ensemble du système.

Astuce

DevOps prône une meilleure collaboration entre équipes : il ne s'agit pas de les isoler. Le but d'une architecture faiblement couplée est d'éviter que la bande passante de communication ne soit saturée par des micro-décisions au niveau de l'implémentation, afin de réserver cette bande passante à ce qui compte vraiment : discuter des objectifs partagés de haut niveau et de la manière de les atteindre.

Les microservices ne sont pas une fin en soi

Les architectures orientées services (service-oriented architectures, SOA) — et toute « vraie » architecture microservices — sont censées produire ces résultats : test et déploiement indépendants. Mais le livre est explicite et prudent : il faut être très strict sur les résultats attendus quand on met en œuvre ce type d'architecture. Dans la vraie vie, beaucoup de prétendues SOA ne permettent pas de tester et déployer les services indépendamment les uns des autres — et n'apportent donc aucune amélioration de performance.

La leçon est essentielle pour ne pas se tromper de cible : ce qui compte est le découplage et l'autonomie, pas l'étiquette de l'architecture. On peut avoir des « microservices » fortement couplés (qui se déploient tous ensemble, dans un ordre imposé, après concertation entre dix équipes) — et ne récolter que la complexité distribuée, sans aucun des bénéfices. À l'inverse, un système plus classique correctement encapsulé peut très bien offrir testabilité et déployabilité.

	Architecture fortement couplée	Architecture faiblement couplée
Tests	Exigent un environnement intégré, tous les services levés ensemble	L'essentiel se fait en isolation, à la demande
Déploiement	Coordonné, par lots, dans un ordre imposé	Indépendant, à la demande, par chaque équipe
Communication inter-équipes	Permanente, à haute bande passante, sur l'implémentation	Faible, réservée aux objectifs partagés
Permission de changer la conception	Dépend d'équipes ou de personnes extérieures	Autonome au sein de l'équipe
Effet du passage à l'échelle	Productivité par personne qui s'effondre	Productivité maintenue, voire croissante
Effet sur débit ET stabilité	Les deux dégradés	Les deux améliorés

Le découplage est ce qui permet de passer à l'échelle

C'est sans doute le résultat le plus frappant du chapitre. Avec une architecture faiblement couplée et bien encapsulée, et une structure organisationnelle assortie, deux choses arrivent. D'abord, on obtient une meilleure performance de livraison — plus de tempo, plus de stabilité, moins d'épuisement et de douleur de déploiement. Ensuite, et c'est crucial, on peut accroître substantiellement la taille de l'organisation d'ingénierie tout en augmentant la productivité de façon linéaire — voire mieux que linéaire.

Pour le mesurer, les auteurs ont calculé une métrique précise : le nombre de déploiements par jour et par développeur. La vision orthodoxe du passage à l'échelle affirme qu'ajouter des développeurs augmente la productivité globale, mais fait baisser la productivité individuelle à cause des surcoûts de communication et d'intégration — c'est l'esprit de la loi de Brooks. Or, en observant les déploiements par développeur et par jour chez les répondants qui déploient au moins une fois par jour, le constat est tout autre.

À mesure que le nombre de développeurs augmente…	Fréquence de déploiement par développeur
Low performers	Diminue
Medium performers	Reste constante
High performers	Augmente significativement

Le couplage est donc le mécanisme caché du passage à l'échelle. Dans une architecture couplée, chaque développeur ajouté alourdit la coordination, et la productivité par personne s'effondre : ajouter du monde ralentit. Dans une architecture découplée, chaque équipe avance sur son service sans attendre les autres ; ajouter des personnes accélère l'organisation au lieu de la freiner. En se concentrant sur les facteurs qui prédisent la haute performance — une culture générative (generative culture) orientée objectifs, une architecture modulaire, des pratiques d'ingénierie qui rendent la livraison continue possible, et un leadership efficace — on fait croître les déploiements par développeur et par jour linéairement ou mieux.

Piège courant

Ne lisez pas ces chiffres comme une preuve de causalité mécanique. Le livre travaille avec des corrélations mises en évidence par des modèles statistiques rigoureux, et formule des hypothèses sur les mécanismes (la bande passante de communication saturée, par exemple). L'argument est solide et cohérent, mais il décrit ce qui prédit la performance, pas une recette garantissant un résultat dans un contexte donné. Évitez de sur-vendre : le découplage est un levier puissant, pas une formule magique.

Laisser les équipes choisir leurs outils

Dernier résultat de ce chapitre, qui prolonge la logique d'autonomie : les équipes qui peuvent choisir leurs propres outils performent mieux. Dans beaucoup d'organisations, les ingénieurs doivent puiser dans une liste d'outils approuvés. Cette centralisation poursuit des objectifs légitimes :

réduire la complexité de l'environnement technique ;
garantir les compétences pour gérer la technologie tout au long de son cycle de vie ;
augmenter le pouvoir de négociation avec les fournisseurs ;
s'assurer que toutes les technologies sont correctement licenciées.

Mais cette rigidité a un revers : elle empêche les équipes de choisir les technologies les mieux adaptées à leurs besoins, et d'expérimenter de nouvelles approches pour résoudre leurs problèmes. L'analyse montre que le choix des outils est une pièce importante du travail technique : quand les équipes décident des outils qu'elles emploient, cela contribue à la performance de livraison, et donc à la performance organisationnelle. Ce n'est pas surprenant — ce sont les professionnels qui font le travail et opèrent l'infrastructure qui sont les mieux placés pour décider, en fonction de ce qui sert au mieux leur tâche et leurs utilisateurs. D'autres études sur les professionnels techniques aboutissent au même constat : les bénéfices de déléguer le choix des outils aux équipes l'emportent souvent sur les inconvénients. Cela rejoint le principe DevOps bien connu du « you build it, you run it » : l'équipe qui construit et exploite le service en porte aussi les choix techniques.

Note

Cette délégation n'abolit pas toute standardisation. Il existe une place légitime pour standardiser, en particulier autour de l'architecture et de la configuration de l'infrastructure : une plateforme opérationnelle standardisée apporte de réels bénéfices. L'exemple d'Amazon passant à une SOA est éclairant — Steve Yegge note qu'il devient quasi impossible de déboguer le code d'autrui « sans une façon standard et universelle d'exécuter chaque service dans un bac à sable débogable ». La règle pragmatique : standardiser la plateforme et les contrats, laisser les équipes libres au-dessus.

À retenir

La haute performance est possible avec presque tous les types de systèmes (mainframe, embarqué, progiciel inclus) à une condition : que systèmes et équipes soient faiblement couplés. Le type de système n'est presque jamais le facteur décisif.
Les deux caractéristiques qui comptent vraiment sont la testabilité (tester l'essentiel sans environnement intégré) et la déployabilité (déployer et livrer à la demande, indépendamment des autres services). En 2017, le découplage est le plus gros contributeur à la livraison continue, devant l'automatisation des tests et des déploiements.
Le découplage prédit à la fois le débit et la stabilité, et surtout il passe à l'échelle : chez les hauts performants, les déploiements par développeur augmentent avec la taille de l'équipe, là où ils s'effondrent dans une architecture couplée.
La loi de Conway lie architecture et structure de communication ; la manœuvre inverse de Conway consiste à faire évoluer délibérément les équipes pour obtenir une architecture autonome, et à réserver la communication aux objectifs de haut niveau.
Les microservices ne sont pas une fin en soi : ce qui compte est le découplage et l'autonomie. Une SOA qui ne permet pas de tester et déployer indépendamment n'apporte aucun gain.
Laisser les équipes choisir leurs outils (« you build it, you run it ») est associé à de meilleures performances ; on standardise la plateforme et l'infrastructure, on laisse les équipes libres au-dessus.