Évaluation, prise de décision et gouvernance

Bienvenue dans le chapitre 11 : Évaluation, prise de décision et gouvernance. Les chapitres précédents vous ont montré comment décrire ce qu’un système doit accomplir, comment le structurer et comment le rendre rapide, fiable, sûr et économique. Ce chapitre porte sur le travail qui entoure ces décisions pendant toute la vie d’un système : les vérifier avant d’engager l’argent, les maintenir vraies alors que des centaines de changements arrivent chaque mois, et les justifier en termes économiques et éthiques.

Le chapitre s’adresse aux développeurs expérimentés, aux responsables techniques et aux architectes qui prennent ou orientent des décisions importantes. C’est là que le cours se rassemble ; il s’appuie donc sur tous les chapitres précédents. Il renvoie le plus souvent aux chapitres 1 à 4 : les compromis, la dette technique, les scénarios d’attributs de qualité, la loi de Conway et les enregistrements de décision. Les chapitres 5 à 10 aident, mais ne sont pas indispensables. Le niveau est avancé, mais chaque section commence par une courte explication pour les débutants. Et il mène au chapitre 12, qui applique toute la discipline aux systèmes construits autour de modèles d’intelligence artificielle.

L’exemple fil rouge est la plateforme de livraison de repas utilisée depuis le chapitre 2. Vous verrez son architecture évaluée, soumise au risk-storming, protégée par des fonctions d’aptitude, gouvernée, réorganisée autour des équipes et en partie modernisée. La section onze point un traite de l’évaluation formelle avec l’Architecture Tradeoff Analysis Method, ou ATAM : ses neuf étapes réparties sur deux réunions, qui y participe, et ses résultats, comme les risques, les points de sensibilité, les points de compromis et les thèmes de risque. La section onze point deux explique pourquoi les comités de revue mensuels échouent si souvent, et ce qui fonctionne à la place : le risk-storming, le pre-mortem, les katas d’architecture et les revues de conception écrites. La section onze point trois transforme une évaluation ponctuelle en protection continue. Une fonction d’aptitude est une vérification objective d’une caractéristique architecturale, idéalement automatisée, comme une règle de dépendance ou un test de charge avec des seuils de percentiles. La section onze point quatre se demande comment une organisation de nombreuses équipes autonomes garde une architecture cohérente, grâce aux principes, aux normes, aux garde-fous et aux points de validation, au processus de consultation et aux radars technologiques.

Ce diagramme de la section onze point quatre oppose deux façons de gouverner. Dans la gouvernance par points de validation, une équipe conçoit, puis attend pendant des semaines dans la file d’un comité de revue. Si la conception est rejetée, elle est reprise et attend de nouveau. Ce n’est qu’après l’approbation que l’équipe peut construire et mettre en production. Dans la gouvernance par garde-fous, l’équipe décide, et son changement passe par un pipeline doté de garde-fous : la politique en tant que code et des fonctions d’aptitude qui vérifient automatiquement des règles objectives. Il peut arriver en production en quelques minutes. En dessous se trouvent les appuis : le processus de consultation pour les décisions importantes, des principes et un radar technologique pour une direction commune, et un chemin balisé (paved road) de modèles et de plateforme. Les garde-fous laissent les personnes libres pour les décisions qui demandent du jugement. Et dans le processus de consultation, n’importe qui peut prendre une décision architecturale, après avoir demandé conseil aux personnes concernées et aux experts, et l’avoir consignée.

La section onze point cinq prend au sérieux la loi de Conway comme outil de conception. Elle présente Team Topologies : quatre types d’équipes, trois façons d’interagir pour les équipes, et les limites de la charge cognitive d’une équipe. La section onze point six traite des systèmes qui existent déjà : pourquoi les réécritures big bang échouent si souvent, et les techniques incrémentales qui fonctionnent. La section onze point sept couvre la dimension humaine du rôle : diriger sans autorité formelle, bâtir la confiance, faciliter les décisions, gérer les conflits et communiquer avec les dirigeants. Et la section onze point huit clôt le chapitre avec deux argumentaires qu’un architecte doit savoir bien construire : l’analyse de rentabilité, avec la valeur actuelle nette et le délai de récupération, et la justification éthique, y compris les préjudices prévisibles et la durabilité.

Ce diagramme de la section onze point six montre l’une de ces techniques, le strangler fig : remplacer un système hérité morceau par morceau pendant qu’il continue de fonctionner. D’abord, intercepter. Les clients appellent une façade de routage, qui envoie encore tout le trafic au monolithe hérité. Rien ne change encore dans le comportement. Ensuite, la première tranche. La façade envoie une fonctionnalité, le suivi des commandes, vers un petit service nouveau, avec une synchronisation temporaire des données entre l’ancien et le nouveau. Tranche après tranche, l’essentiel du trafic bascule, jusqu’à ce qu’il ne reste plus que la facturation dans l’ancien système. Enfin, tout le trafic va vers les nouveaux services, et le système hérité est éteint. La migration n’est terminée que lorsque l’ancien système et le code temporaire ont tous deux été supprimés.

L’architecture n’est pas terminée quand le diagramme est dessiné. Ses décisions doivent être mises à l’épreuve, protégées pendant que le système évolue, prises par les bonnes personnes, portées par des équipes dont la structure leur correspond, et justifiées auprès des commanditaires et de la société. Les architectes les plus efficaces rendent ce travail léger et continu, plutôt que lourd et ponctuel. De courtes revues des risques, au lieu d’audits annuels. Des garde-fous automatisés, au lieu de files d’approbation. Des conseils, au lieu d’autorisations. Et une migration incrémentale, au lieu de réécritures. La discipline qui relie le tout est celle par laquelle ce cours a commencé : nommer la qualité dont vous avez besoin, la rendre mesurable, décider délibérément, écrire pourquoi, et continuer à vérifier.

À la fin du chapitre, vous saurez expliquer quand évaluer une architecture, et mener soit l’ATAM, soit une revue légère comme le risk-storming, avec un registre des risques et des responsables. Vous saurez concevoir des fonctions d’aptitude qui transforment les scénarios d’attributs de qualité en vérifications automatisées. Vous saurez planifier une modernisation incrémentale, avec le strangler fig, le branch by abstraction et les exécutions en parallèle. Et vous saurez calculer la valeur actuelle nette et le délai de récupération pour une analyse de rentabilité, et examiner une architecture sous l’angle des préoccupations éthiques et de durabilité.

Vous pouvez lire le chapitre dans l’ordre, ou aller directement à la section dont vous avez besoin. Si une idée d’un chapitre précédent ne vous est pas familière, suivez le lien qui y renvoie. Comptez environ trois heures et demie pour lire tout le chapitre. À la fin de chaque section, vous trouverez des questions d’autoévaluation. Répondez-y de tête avant de regarder les réponses. Quand vous serez prêt, un test du chapitre facultatif vous attend ; il prend environ quarante-cinq minutes. Il comporte vingt questions à choix multiples et deux réponses rédigées. La note de réussite est de quatre-vingts pour cent.

Voilà comment le chapitre est construit. Commencez par la section onze point un, sur l’évaluation de l’architecture et l’ATAM. À très vite.