Qu’est-ce que l’architecture logicielle ?

Bienvenue dans le chapitre 1 : Qu’est-ce que l’architecture logicielle ? Le chapitre zéro vous a donné les briques de base. Ce chapitre prend du recul et se demande ce que signifie agencer ces briques de façon délibérée, qui le fait, et pourquoi cela en vaut la peine. Il vous donne le vocabulaire dont dépend le reste du cours, et une manière de penser applicable à n’importe quel système, d’une petite application de réservation à une plateforme nationale de paiement.

Tout système logiciel a une architecture, que quelqu’un l’ait conçue ou non. C’est l’ensemble des structures fondamentales qui composent le système, et des décisions importantes qui les ont produites. Ces structures déterminent bien plus de choses que la plupart des gens ne l’imaginent : la rapidité et la fiabilité du système, son coût d’exploitation, et le nombre d’équipes qui peuvent y travailler en même temps. Surtout, elles déterminent combien coûtera la modification du système l’an prochain. Les fonctionnalités sont ce que fait un système. L’architecture détermine en grande partie la qualité avec laquelle il le fait, et ce qu’il en coûte de faire autre chose.

Ce chapitre s’adresse aux développeurs qui évoluent vers des responsabilités d’architecture. Il s’adresse aussi à toute personne qui travaille avec des architectes et veut comprendre ce qu’ils font, et pourquoi. Il s’appuie sur les briques de base du chapitre zéro : composants, stockages de données, réseaux et API. Si elles vous sont familières, vous êtes prêt. Et il mène au chapitre 2, qui rend les objectifs d’une architecture précis et mesurables, sous forme d’attributs de qualité.

Le chapitre compte huit sections. La section un point un compare les définitions qui comptent, de la norme internationale et du Software Engineering Institute, ou SEI, jusqu’aux praticiens qui insistent sur la compréhension partagée et sur les décisions coûteuses à changer. La section un point deux s’attaque à la confusion la plus courante : où s’arrête l’architecture et où commence la conception. La réponse est qu’il n’y a pas de mur, seulement un continuum ordonné par l’importance. La section un point trois explique pourquoi s’en soucier, en s’appuyant sur trois cas réels : la perte de trading de Knight Capital en deux mille douze, le lancement chaotique de HealthCare point gov en deux mille treize, et un changement opéré en deux mille vingt-trois chez Amazon Prime Video.

Ce diagramme de la section un point un montre les idées que partagent les définitions, à l’aide d’un système de livraison de repas. La ligne en pointillés est la frontière du système. Les boîtes à l’intérieur sont des éléments : une application mobile, un service des commandes, une base de données des commandes, un service des livreurs et un module de paiement. Les flèches sont des relations. L’application appelle le service des commandes en HTTPS. Le service des commandes interroge la base de données en SQL, et envoie un événement au service des livreurs. De petites étiquettes indiquent des propriétés. Le service des commandes, par exemple, est sans état, et trois copies tournent en parallèle. Hors de la frontière se trouve l’environnement : les clients, les livreurs et les restaurants, et le prestataire de paiement par carte. Et l’environnement ne se limite pas aux autres systèmes. Il comprend aussi la loi, le budget, l’organisation et ses équipes, et la plateforme cloud. On ne peut pas comprendre une architecture sans eux.

La section un point quatre s’intéresse aux personnes : ce que font réellement les architectes, les différents types d’architectes, pourquoi l’architecture est un rôle avant d’être un intitulé de poste, et le débat de longue date sur la question de savoir si les architectes doivent encore écrire du code. La section un point cinq élargit l’angle aux parties prenantes, toutes les personnes qui ont un intérêt dans le système, des utilisateurs et développeurs jusqu’aux régulateurs. Elle montre comment les préoccupations contradictoires sont rendues explicites, plutôt que tranchées par celui qui crie le plus fort. La section un point six passe aux décisions et aux compromis : ce que contient une bonne décision, quelles décisions sont facilement réversibles et lesquelles ne le sont pas, et l’idée de décider au dernier moment responsable.

Les deux dernières sections portent sur le temps. La section un point sept explique la dette technique au sens où Ward Cunningham l’entendait à l’origine, ce qui la distingue d’un simple désordre, et comment les architectures s’érodent et dérivent de la forme voulue. La section un point huit situe l’architecture dans le cycle de livraison, entre la conception complète en amont et la conception purement émergente, et montre un juste milieu pragmatique : juste assez d’architecture, au bon moment, vérifiée en continu.

Ce diagramme de la section un point deux montre comment distinguer l’architecture de la conception. Plus une décision est à gauche, plus elle est architecturale ; plus elle est à droite, plus elle relève de la conception et du code. Le premier critère est le coût de l’annulation d’une décision : des mois de travail pour de nombreuses équipes à un bout, quelques minutes pour une seule personne à l’autre. Le deuxième est la portée de l’impact : tout le système ou toute l’organisation, ou une seule fonction ou classe. Le troisième est l’effet sur les qualités clés. Les points placent une décision réelle, le choix du format des messages, sur chaque ligne, et sur les trois elle penche vers l’extrémité architecturale.

Si vous ne retenez qu’une chose de ce chapitre, que ce soit celle-ci. L’architecture est l’ensemble des décisions sur lesquelles il est coûteux de se tromper. Le travail de l’architecte consiste à identifier ces décisions, à les prendre délibérément avec les bonnes personnes, à en consigner les raisons et à les réexaminer régulièrement, tout en rendant le plus grand nombre possible d’autres décisions peu coûteuses à changer. Le reste du cours applique cette idée.

Vous pouvez lire les sections dans l’ordre, ce qui est préférable si les idées sont nouvelles pour vous, ou piocher dans celles dont vous avez besoin. Le chapitre entier demande environ deux heures et demie de lecture. Chaque section se termine par quelques questions d’autoévaluation. Essayez d’y répondre de tête avant de regarder, pour voir ce que vous avez retenu. Quand vous serez prêt, un test du chapitre facultatif vous attend, avec vingt questions à choix multiples et deux réponses rédigées. Comptez environ quarante-cinq minutes. La note de réussite est de quatre-vingts pour cent, comme pour tous les tests de chapitre du cours.

Voilà la carte du chapitre 1. Commencez par la section un point un, où nous comparons les définitions de référence de l’architecture logicielle pour dégager ce qu’elles ont en commun. À très vite.