Attributs de qualité et exigences architecturalement significatives

Bienvenue dans le chapitre 2 : Attributs de qualité et exigences architecturalement significatives. L’architecture existe pour apporter des qualités : la rapidité sous la charge, le maintien en service quand des parties tombent en panne, la possibilité de modifier sans risque, la confidentialité des données. Ce chapitre montre comment transformer des souhaits vagues, comme rapide, fiable et sécurisé, en exigences précises et testables, capables d’orienter les décisions de conception.

Demandez à n’importe quel groupe de parties prenantes ce qu’un système doit faire, et vous obtiendrez une liste de fonctionnalités : rechercher un vol, payer un panier, prendre un rendez-vous. Demandez-leur à quel point il doit bien le faire, et les réponses sont plus vagues : il doit être rapide, il ne doit pas tomber en panne, il doit être sécurisé. Ces secondes réponses sont des attributs de qualité, et c’est surtout d’eux que traite l’architecture. Une exigence qui a un effet mesurable sur la structure d’un système s’appelle une exigence architecturalement significative. La plupart d’entre elles s’avèrent être des attributs de qualité ou des contraintes, plutôt que des fonctions.

Ce schéma de la section deux point un le montre bien. Deux systèmes de billetterie ont des fonctionnalités identiques : parcourir les événements, bloquer des places et payer. L’un vend des billets pour une salle des fêtes de trois cents places. Son moment le plus chargé apporte quelques requêtes par seconde, donc une seule application web avec une seule base de données est la bonne réponse : bon marché, simple et facile à modifier. L’autre vend une tournée dans des stades de soixante mille places. Il doit absorber un afflux des milliers de fois plus important, et ne jamais vendre deux fois la même place. Il lui faut donc un cache de pages, une salle d’attente virtuelle, un inventaire des places soigneusement conçu, un stockage partitionné et une file d’attente des paiements. Mêmes fonctions, architectures complètement différentes. La différence vient entièrement des attributs de qualité et des contraintes.

Ce chapitre s’adresse aux développeurs qui s’orientent vers l’architecture. Il s’adresse aussi à toute personne qui rédige ou relit des exigences. Il vous faudra une certaine aisance avec l’arithmétique simple : pourcentages, multiplications et divisions. Il s’appuie sur l’idée, vue au chapitre 1, que l’architecture existe pour répondre aux préoccupations des parties prenantes au moyen de compromis. Ce chapitre rend ces préoccupations précises. Et il mène au chapitre 3, qui présente les principes de conception que les architectes utilisent pour atteindre ces qualités.

Il comporte huit sections. La section deux point un distingue exigences fonctionnelles, attributs de qualité et contraintes, et étudie un système de billetterie de concerts le jour où une grande tournée est mise en vente. La section deux point deux présente la norme internationale sur la qualité des produits, avec ses neuf caractéristiques, et montre comment l’utiliser comme aide-mémoire plutôt que comme formulaire à remplir. La section deux point trois enseigne la technique la plus utile du chapitre : le scénario d’attribut de qualité en six parties, qui transforme doit être rapide en un énoncé que vous pouvez tester.

Voici sa forme. Un scénario raconte une courte histoire, de gauche à droite. Une source, quelqu’un ou quelque chose, produit un stimulus : un événement auquel le système doit répondre, comme un afflux de requêtes ou la panne d’un serveur. Le stimulus atteint un artefact, le système entier ou l’une de ses parties, dans un environnement : fonctionnement normal, pic de charge, mode dégradé ou attaque. L’artefact répond, et la réponse est jugée par une mesure de la réponse : le chiffre. Le stimulus et la mesure de la réponse sont les deux parties que l’on omet le plus souvent, et les deux qui comptent le plus. L’exemple en dessous rassemble le tout : cinq cents acheteurs par seconde arrivent à l’étape de paiement le jour du Black Friday, et les commandes sont confirmées en une seconde et demie au plus au quatre-vingt-dix-neuvième percentile, sans aucune commande perdue.

Les sections deux point quatre à deux point sept passent en revue les qualités qui façonnent le plus souvent les architectures. La section deux point quatre traite des performances et de la scalabilité, avec de vrais calculs : latence et débit, percentiles, files d’attente et limites de l’ajout de processeurs. La section deux point cinq fait de même pour la disponibilité et la fiabilité : les neuf, le temps entre défaillances et le temps de réparation, et la façon dont les composants se combinent en série et en parallèle. La section deux point six couvre les qualités liées au changement : modifiabilité, testabilité et déployabilité. La section deux point sept rassemble la sécurité, l’utilisabilité et l’accessibilité, l’interopérabilité, le coût, l’efficacité énergétique, la sûreté et les qualités réglementaires.

C’est le chapitre où le cours commence à calculer. Vous verrez pourquoi une requête adressée à un serveur occupé à quatre-vingt-dix pour cent prend, en moyenne, dix fois son temps de service. Aucune de ces mathématiques n’est plus difficile que l’arithmétique de l’école. Les chiffres dissipent aussi les fausses certitudes. Un temps de réponse moyen de cent vingt millisecondes peut masquer le fait qu’une requête sur cinquante prend plus d’une seconde. C’est pourquoi les professionnels spécifient des percentiles. La section deux point huit boucle la boucle. Aucun système ne peut être à la fois rapide, disponible, sécurisé, bon marché et facile à modifier. Elle montre comment un atelier et un arbre d’utilité transforment une foule d’opinions en une liste classée, et quelles qualités entrent en conflit.

Si vous ne retenez qu’une chose de ce chapitre, que ce soit celle-ci : une qualité n’est pas une exigence tant qu’elle n’a pas de stimulus, de contexte et de mesure. L’étape de paiement doit être rapide : c’est un souhait. Lorsque deux mille clients par minute passent commande pendant le pic du vendredi soir, quatre-vingt-dix-neuf pour cent des paiements aboutissent en une seconde et demie au plus : voilà une exigence. On peut concevoir en fonction d’elle, la tester, la superviser et en débattre preuves à l’appui.

Il vaut mieux lire les sections deux point un à deux point trois dans l’ordre, car le reste du chapitre utilise leur vocabulaire. Ensuite, vous pouvez piocher dans les qualités dont vous avez besoin. La lecture du chapitre entier prend environ trois heures. Quand une section fait des calculs, refaites-les vous-même. C’est ainsi que les chiffres deviennent des outils utilisables dans une vraie conversation. Chaque section se termine par quelques questions d’autoévaluation. Répondez-y de tête avant de regarder. Quand vous êtes prêt, passez le test facultatif du chapitre : vingt questions à choix multiples et deux réponses rédigées, en quarante-cinq minutes environ. La note de réussite est de quatre-vingts pour cent.

Voilà la carte du chapitre 2. Commencez par la section deux point un, où nous distinguerons exigences fonctionnelles, attributs de qualité et contraintes, et découvrirons un système de billetterie le jour de sa plus forte affluence. À très vite.