Éliciter, hiérarchiser et arbitrer les attributs de qualité

D’où viennent les exigences de qualité

Les exigences fonctionnelles arrivent généralement dans un backlog. Les exigences de qualité, rarement : les parties prenantes les tiennent pour acquises (« bien sûr que ce doit être rapide et sécurisé ») ou ne savent pas qu’elles doivent les énoncer. Les architectes doivent donc les éliciter activement, à partir de plusieurs sources.

Les parties prenantes. Chaque groupe a des préoccupations différentes : les clients tiennent à la rapidité et à la facilité d’utilisation, l’exploitation à la supervision et au rétablissement, la finance au coût d’exploitation, le support au diagnostic des problèmes, la conformité aux pistes d’audit. La cartographie des parties prenantes du chapitre 1 est le point de départ. Les objectifs métier. « S’implanter dans trois nouveaux pays l’an prochain » implique la localisation, la résidence des données et la scalabilité ; « réduire de 20 % les coûts du support client » implique l’utilisabilité et le libre-service. La réglementation et les contrats. La protection des données, le droit de l’accessibilité, les règles sectorielles et les SLA clients créent des contraintes non négociables. Les incidents. Chaque panne, violation ou journée de lenteur passée révèle une qualité qui était sous-spécifiée ; les revues post-incident sont une source précieuse. Les concurrents et le marché. Si les concurrents chargent en une seconde, deux secondes sont un problème de qualité. Le système existant. Son comportement mesuré aujourd’hui (charge réelle, percentiles de latence réels, délai réel de mise en œuvre des changements) fournit une base de référence qui transforme « plus rapide » en chiffre.

Les entretiens et les questionnaires fonctionnent, mais les attributs de qualité émergent mieux lorsque les parties prenantes s’écoutent les unes les autres. Un product owner qui apprend du responsable de l’exploitation ce que coûte une heure d’indisponibilité le vendredi à l’heure du dîner établira d’autres priorités. C’est l’idée qui sous-tend les ateliers structurés.

Le Quality Attribute Workshop

Le Quality Attribute Workshop (QAW), mis au point au Software Engineering Institute (Barbacci et ses collègues ; la troisième édition du rapport de méthode est parue en 2003), est une séance animée, qui dure généralement une journée, organisée tôt, avant que l’architecture soit figée. Il réunit de 5 à 30 parties prenantes pour produire des scénarios d’attributs de qualité affinés et hiérarchisés. Il comporte huit étapes.

Les équipes qui ne peuvent pas y consacrer une journée entière organisent souvent un « mini-QAW » plus court, une variante plus légère décrite par des praticiens comme Michael Keeling, Will Chaparro et Thijmen de Gooijer, qui utilise une taxonomie des attributs de qualité comme support et quelques heures avec un groupe plus restreint. L’essentiel demeure : les parties prenantes réunies, des scénarios plutôt que des adjectifs, un vote explicite et l’affinage des scénarios retenus.

L’arbre d’utilité

Un arbre d’utilité est un moyen d’organiser et de hiérarchiser les exigences de qualité, introduit dans le cadre de l’Architecture Tradeoff Analysis Method (ATAM), que Rick Kazman, Mark Klein et Paul Clements ont mise au point au SEI ; la méthode d’évaluation elle-même est traitée au chapitre 11. La racine est l’utilité, la qualité globale du système. Le deuxième niveau contient les attributs de qualité (performances, disponibilité, etc.). Le troisième niveau décompose chacun d’eux en préoccupations plus précises (pour les performances : latence des commandes, fraîcheur du suivi). Les feuilles sont des scénarios concrets et mesurables.

Chaque feuille est notée par une paire : l’importance métier (à quel point le scénario compte pour l’entreprise : élevée (H), moyenne (M) ou faible (L)) et la difficulté technique ou le risque (à quel point il est difficile à atteindre avec l’architecture : élevée, moyenne ou faible). La paire s’écrit (B,T), par exemple (H,M). Les scénarios notés (H,H) sont les priorités absolues de l’architecture : ce sont les plus importants et les plus difficiles, ils méritent donc un effort de conception précoce, des prototypes et des analyses. Les scénarios (H,L) comptent mais sont faciles, donc une approche standard suffira ; les scénarios (L,H) sont candidats à l’abandon ou au report, car ils sont difficiles mais ne valent pas grand-chose.

L’arbre est utile même en dehors d’une évaluation formelle. Il rend les compromis visibles sur une seule page, montre les lacunes (une qualité sans scénario) et empêche la partie prenante la plus bruyante de fixer seule les priorités.

Hiérarchiser quand tout est « critique »

Chaque partie prenante notera sa propre préoccupation comme élevée. Les techniques qui obligent à faire de vrais choix sont utiles. Un nombre de voix fixe (comme dans le QAW) oblige chacun à dépenser des voix rares. La comparaison par paires (« si vous ne pouviez en avoir qu’une, une recherche en moins d’une seconde ou aucune perte de données lors d’un basculement ? ») révèle le véritable ordre. Placer un montant ou un délai à côté de chaque cible (« quatre neuf coûteront 9000 £ de plus par mois et deux mois de travail ») fait changer bien des avis. Enfin, distinguer les contraintes (exigences légales d’accessibilité, résidence des données) des préférences évite que des éléments non négociables soient sacrifiés par accident.

Les priorités ne sont pas figées. Une start-up qui cherche ses premiers clients place à juste titre le délai de mise sur le marché et la modifiabilité au-dessus d’une disponibilité à cinq neuf ; le même produit, trois ans plus tard, avec des clients grands comptes et des SLA contractuels, doit revoir son classement. Revisitez l’arbre d’utilité quand l’activité change.

Les conflits entre qualités

Les qualités interagissent. Certaines se renforcent mutuellement : la modularité aide la testabilité, qui aide la déployabilité. Beaucoup entrent en conflit, parce que la tactique qui favorise une qualité en pénalise une autre. L’ATAM, décrite par Bass, Clements et Kazman, appelle points de compromis les points où une décision d’architecture affecte plusieurs qualités. Connaître les conflits habituels vous permet de les soulever avant qu’ils ne surprennent qui que ce soit.

La bonne résolution dépend toujours du contexte. « La sécurité prime sur les performances » est un slogan, pas une décision : 2 ms de plus de négociation TLS sur un site web public sont sans importance, alors que des contrôles antifraude synchrones à chaque passage de carte dans un stade bondé peuvent poser un vrai problème qui mérite une réponse architecturale (un modèle « approuver d’abord, vérifier ensuite » avec des plafonds). Demandez-vous : quel objectif métier chaque camp sert-il, combien coûte chaque option, et qui doit donner son accord ?

Consigner les décisions et suivre les qualités

Un compromis qui n’est pas consigné par écrit sera de nouveau débattu, souvent par des personnes qui n’étaient pas dans la salle. Consignez les compromis importants sous forme d’enregistrements de décision d’architecture (chapitre 4) : le contexte, les qualités en tension, les options envisagées, la décision et ses conséquences, y compris ce à quoi vous avez sciemment renoncé.

Rendez ensuite chaque cible de qualité mesurable et visible. Le Planguage de Tom Gilb propose un format rigoureux : une échelle (ce qui est mesuré, dans quelle unité), un instrument de mesure (comment c’est mesuré), et des niveaux comme échec (le seuil en deçà duquel l’exigence n’est pas satisfaite), objectif (la cible) et cible ambitieuse ou souhait (des niveaux plus ambitieux). Appliqué au scénario de latence des commandes : échelle, secondes entre l’envoi et la confirmation au 95e percentile ; instrument de mesure, supervision des utilisateurs réels pendant le pic du vendredi ; échec au-delà de 3 s ; objectif 1,5 s ; cible ambitieuse 1 s.

Enfin, suivez les mesures dans le temps sur un tableau de bord visible par les parties prenantes, à côté des SLO (chapitre 9), et revoyez-les chaque fois que l’activité, la charge ou l’équipe change.

Des scénarios aux fonctions d’aptitude

Le moyen le plus sûr de garantir qu’une exigence de qualité reste satisfaite est de la vérifier automatiquement, à chaque modification du système. Neal Ford, Rebecca Parsons et Patrick Kua, dans Building Evolutionary Architectures (2017 ; deuxième édition avec Pramod Sadalage, 2022), appellent une telle vérification une fonction d’aptitude architecturale : une évaluation objective de la mesure dans laquelle le système satisfait une caractéristique d’architecture. Un test de charge dans le pipeline qui fait échouer le build si la latence p95 des commandes dépasse 1,5 s à 100 commandes par seconde est une fonction d’aptitude. Il en va de même d’un test qui échoue si un module extérieur à payments importe la bibliothèque du prestataire de paiement (ce qui protège le scénario de modifiabilité), d’un exercice de basculement planifié qui mesure le délai de rétablissement, ou d’une analyse des dépendances qui bloque les bibliothèques vulnérables connues.

Les fonctions d’aptitude sont l’aboutissement naturel du travail de ce chapitre : un souhait vague devient un scénario (section 2.3), le scénario reçoit une priorité dans l’arbre d’utilité, et la mesure de la réponse du scénario devient une vérification automatisée. Toutes les qualités ne peuvent pas être automatisées à peu de frais (l’utilisabilité a toujours besoin de personnes), mais chacune de celles que vous automatisez cesse de s’éroder en silence. Le chapitre 11 traite en profondeur de leur conception : fonctions d’aptitude et architecture évolutive.