Évaluation de l’architecture et ATAM

Pourquoi évaluer une architecture

Toute architecture est un pari. Quand une équipe choisit un courtier d’événements, une base de données par service ou une seule région cloud, elle prédit que ces décisions apporteront les performances, la disponibilité, la sécurité et le coût dont le métier a besoin. La section 1.3 a montré pourquoi de tels paris comptent : le coût de changement d’une décision structurelle augmente avec tout ce qui est construit par-dessus, et certaines des défaillances les plus coûteuses du logiciel tenaient à l’agencement plutôt qu’à des lignes de code isolées. L’évaluation de l’architecture est l’acte délibéré de vérifier le pari avant que l’argent soit dépensé, ou pendant qu’il l’est.

Une évaluation pose une question étroite et pratique : compte tenu de ce que ce système doit accomplir, lesquelles de ses décisions architecturales mettent ces objectifs en danger ? Ce n’est ni une revue de code, ni un concours de beauté entre styles, ni un audit de la qualité de la documentation. Elle porte sur les décisions et leurs conséquences pour les attributs de qualité ; elle peut donc être menée bien avant qu’il existe du code, sur une conception au tableau blanc ou un ensemble d’enregistrements de décision, et elle peut être répétée sur un système qui fonctionne depuis des années.

L’évaluation a aussi des bénéfices au-delà de ses constats. Des parties prenantes qui se rencontrent rarement (responsables produit, exploitation, sécurité, finance, développeurs) doivent s’accorder sur ce qui compte le plus, ce qui met souvent au jour des hypothèses contradictoires. L’architecte doit expliquer la conception assez clairement pour que des personnes extérieures puissent l’examiner, ce qui améliore la documentation. Et l’organisation obtient une trace des risques connus qu’elle a choisi d’accepter, ce qui est très différent de risques que personne n’a remarqués.

Quand évaluer

Le meilleur moment pour évaluer est celui où suffisamment de choses ont été décidées pour que l’évaluation ait de quoi examiner, mais avant que ces décisions deviennent coûteuses à défaire. En pratique, il existe plusieurs moments naturels, et les organisations matures utilisent pour chacun une évaluation plus ou moins lourde.

Évaluer trop tôt gaspille des efforts sur des décisions qui ne sont pas encore réelles ; évaluer trop tard transforme les constats en regrets. Une règle utile du modèle piloté par les risques de Fairbanks (section 1.8) s’applique ici aussi : investissez dans l’évaluation en proportion du risque. Un outil interne utilisé par deux équipes n’a pas besoin d’un atelier de deux jours ; une plateforme nationale de paiements, si.

L’ATAM : origines, objectif et participants

L’Architecture Tradeoff Analysis Method (ATAM) est la méthode d’évaluation la plus connue. Rick Kazman, Mark Klein et Paul Clements, du Software Engineering Institute (SEI) de l’université Carnegie Mellon, l’ont décrite dans le rapport technique ATAM: Method for Architecture Evaluation (CMU/SEI-2000-TR-004, août 2000). Elle est issue de la Software Architecture Analysis Method (SAAM), plus ancienne, que Kazman et ses collègues ont publiée en 1994 et qui portait surtout sur la modifiabilité. L’ATAM est aussi décrite dans Software Architecture in Practice de Bass, Clements et Kazman, aujourd’hui dans sa quatrième édition (2021).

Son objectif est souvent mal compris. L’ATAM ne donne pas de note à une architecture ni de note de réussite, et elle ne prouve pas qu’un système satisfera ses exigences. Elle identifie les endroits où les décisions architecturales mettent en danger les objectifs métier et ceux où elles imposent des compromis entre qualités, afin que les personnes responsables puissent décider quoi faire. Le nom de la méthode met l’accent sur les compromis, car la plupart des risques intéressants se trouvent là où une qualité est obtenue aux dépens d’une autre.

Trois groupes y participent. L’équipe d’évaluation, en général trois à cinq personnes extérieures au projet, conduit la méthode : un chef d’équipe, un responsable de l’évaluation qui anime, des secrétaires qui consignent les scénarios et les débats, et des questionneurs experts de certaines qualités. Les décideurs du projet sont l’architecte, le chef de projet ou le responsable produit, et le commanditaire ou le client qui peut agir sur les constats. Les parties prenantes de l’architecture sont toutes les autres personnes concernées : développeurs, testeurs, exploitation, sécurité, intégrateurs, support et représentants des utilisateurs. L’indépendance compte : des évaluateurs qui ont conçu le système, ou qui rendent compte à l’architecte, trouvent moins de risques.

Le vocabulaire de l’analyse

Le cœur de la méthode, ce sont les étapes 6 et 8. Pour chaque scénario important, les évaluateurs demandent à l’architecte de dérouler la façon dont l’architecture y répond, et ils creusent avec des questions tirées de chaque qualité : combien d’appels synchrones se trouvent sur ce chemin, qu’arrive-t-il aux requêtes en cours quand ce nœud tombe en panne, où ce secret d’authentification est-il stocké, qu’est-ce qui limite la file d’attente ? Chaque réponse est classée à l’aide de cinq notions devenues un vocabulaire standard bien au-delà de l’ATAM elle-même.

Les non-risques méritent plus d’attention qu’ils n’en reçoivent d’habitude. Consigner qu’une décision est solide en raison d’une hypothèse précise (trois réplicas, un temps de réponse contractuel d’un fournisseur, un trafic sous un certain niveau) transforme une vague assurance en quelque chose que l’on pourra vérifier plus tard. Quand l’hypothèse change, le non-risque devient un risque potentiel. Les points de sensibilité et de compromis sont tout aussi précieux après l’évaluation : ils indiquent aux futurs mainteneurs quels paramètres modifier avec précaution, et ce sont des emplacements naturels pour les vérifications automatisées décrites à la section 11.3.

L’arbre d’utilité revisité

La section 2.8 a présenté l’arbre d’utilité comme un outil pour hiérarchiser les exigences de qualité. Il est né dans l’ATAM, et au sein de la méthode il joue deux rôles distincts. À l’étape 5, les décideurs construisent l’arbre de haut en bas : l’utilité, puis les attributs de qualité, puis les raffinements, puis des scénarios concrets cotés (importance métier, difficulté technique). Les feuilles (H,H) deviennent l’ordre du jour de l’étape 6, car elles comptent le plus et sont les plus difficiles à atteindre : c’est donc là que les risques ont le plus de chances de se cacher.

À l’étape 7, le groupe élargi des parties prenantes propose des scénarios de bas en haut et vote sur eux, à peu près comme dans un Quality Attribute Workshop. Comparer les deux visions est l’un des moments les plus révélateurs d’une évaluation. Si les scénarios préférés des parties prenantes figurent déjà dans l’arbre, les décideurs comprennent la raison d’être de leur système. Si un scénario qui reçoit beaucoup de voix est absent, par exemple un scénario d’exploitation sur des tablettes de restaurant qui passent hors ligne, les décideurs ont un angle mort, et l’architecture en a peut-être un aussi. Ces scénarios sont ajoutés à l’arbre et analysés à l’étape 8.

La CBAM : mettre l’argent sur la table

L’ATAM vous dit où sont les risques ; elle ne vous dit pas quelles corrections valent la peine d’être payées. La Cost Benefit Analysis Method (CBAM), mise au point au SEI par Rick Kazman, Jai Asundi et Mark Klein (publiée pour la première fois en 2001), s’appuie sur les scénarios d’une ATAM pour construire cet argumentaire économique.

Dans les grandes lignes, les parties prenantes prennent les scénarios priorisés et attribuent une utilité (sur une échelle de 0 à 100) à plusieurs niveaux de réponse pour chacun : pire cas, situation actuelle, niveau souhaité et meilleur cas. Les architectes proposent des stratégies architecturales et estiment la réponse que chacune obtiendrait. L’utilité gagnée par chaque stratégie se lit sur la courbe utilité-réponse du scénario et est pondérée par la priorité du scénario ; additionnée sur l’ensemble des scénarios, elle constitue le bénéfice de la stratégie. Diviser le bénéfice par le coût donne un rapport valeur-coût (VFC), et les stratégies sont retenues par ordre de VFC dans la limite du budget disponible, puis confrontées à l’intuition et aux contraintes.

La stratégie B apporte plus de bénéfice par livre sterling, mais elle ne respecte pas le temps de reprise de 15 minutes qu’exigent les contrats avec les restaurants. Les chiffres éclairent la décision ; ils ne la prennent pas. La vraie valeur de la CBAM est d’obliger à faire des estimations explicites et comparables du bénéfice et du coût, et de montrer quand c’est une contrainte, et non un ratio, qui doit trancher. Sa faiblesse est que les utilités et les coûts sont des jugements ; les équipes devraient les faire varier et voir si le classement change, exactement comme la section 1.6 le recommande pour les matrices de décision pondérées. La section 11.8 montre comment transformer de telles estimations en analyse de rentabilité.

Coûts et aspects pratiques

Une ATAM complète coûte cher en temps de travail. À titre d’illustration approximative : une équipe d’évaluation de quatre personnes qui consacre chacune deux jours à la préparation (8 jours-personnes), une phase 1 d’une journée avec trois décideurs (7), une phase 2 de deux jours avec dix parties prenantes en plus (34) et une semaine de suivi par deux personnes (10) totalisent environ 60 jours-personnes, avant que quiconque ait corrigé quoi que ce soit. Pour un système dont la défaillance coûterait des millions, ou qui fonctionnera pendant dix ans, c’est une assurance bon marché. Pour une petite équipe produit, c’est disproportionné.

Plusieurs pratiques font que les évaluations en valent la peine. Adaptez la méthode : Bass, Clements et Kazman décrivent une évaluation d’architecture allégée, une ATAM réduite pour les équipes internes qui peut se faire en une journée ou moins, et certaines organisations ne mènent que les étapes 2 à 6 avec une poignée de personnes. Préparez-vous bien : l’essentiel du coût d’une mauvaise évaluation est dépensé à découvrir, en séance, que personne ne sait décrire l’architecture. Gardez des évaluateurs indépendants mais informés. Convenez à l’avance de qui est responsable des constats et de la façon dont ils seront suivis, idéalement sous forme d’enregistrements de décision et d’éléments de backlog dotés de responsables. Et recommencez : les constats sont un instantané, et les risques changent à mesure que le système et le métier évoluent.

Les praticiens ne s’accordent pas sur la place de la méthode aujourd’hui. Ses détracteurs y voient un vestige lourd des grands projets conçus en amont, mal adapté aux équipes qui déploient de nombreuses fois par jour. Ses défenseurs répondent que ses notions (scénarios, points de sensibilité et de compromis, thèmes de risque) sont exactement ce qui manque aux équipes agiles quand elles sautent l’évaluation, et que la méthode peut être allégée. Les deux camps ont en partie raison : le cérémonial complet convient aux systèmes à forts enjeux et à longue durée de vie et aux engagements majeurs, tandis que le vocabulaire et l’habitude d’un questionnement guidé par les scénarios ont leur place partout. La section 11.2 traite de l’extrémité la plus légère.