Ce qu’est l’architecture logicielle : les définitions de référence et leurs points communs

Pourquoi il faut définir le mot

Demandez à dix ingénieurs expérimentés ce qu’est l’architecture logicielle et vous entendrez dix réponses différentes : le diagramme de boîtes et de flèches affiché au mur, le choix du fournisseur de cloud, le schéma de la base de données, le découpage en services, les règles indiquant quel code peut appeler quel autre, ou simplement « les décisions difficiles ». Chaque réponse saisit quelque chose de réel, et chacune, prise isolément, passe à côté de quelque chose. Un cours qui entend enseigner l’architecture doit donc commencer par préciser de quoi il parle.

Cela compte pour des raisons pratiques. Si une équipe pense que l’architecture, c’est « le diagramme », elle cessera d’y prêter attention une fois le diagramme dessiné, alors même que le système continue de changer en dessous. Si elle pense que l’architecture, c’est « la pile technologique », elle débattra des frameworks en ignorant la façon dont les responsabilités sont réparties et dont circulent les données. Une bonne définition vous dit quoi regarder, quoi protéger et de quoi discuter avec les autres.

Les définitions ci-dessous proviennent d’une norme internationale, du Software Engineering Institute (SEI) de l’université Carnegie Mellon, et de praticiens. Elles ont été écrites dans des buts différents, mais elles s’accordent plus qu’elles ne divergent, et leurs points d’accord forment le cœur de la discipline.

La définition normative : ISO/IEC/IEEE 42010:2022

ISO/IEC/IEEE 42010 est la norme internationale de description des architectures. Son édition actuelle, publiée en novembre 2022, a remplacé l’édition de 2011. Elle définit l’architecture, en paraphrasant de près, comme les concepts ou propriétés fondamentaux d’une entité dans son environnement, ainsi que les principes qui régissent la réalisation et l’évolution de cette entité et ses processus de cycle de vie associés.

Trois caractéristiques de cette définition méritent l’attention. D’abord, elle parle d’une entité, et pas seulement d’un système logiciel. L’édition 2022 a délibérément élargi le champ pour que les mêmes idées s’appliquent aux logiciels, aux systèmes de systèmes, aux produits, aux lignes de produits et aux entreprises entières. Ensuite, elle place l’entité dans son environnement : on ne peut pas comprendre une architecture sans les utilisateurs, les autres systèmes, l’organisation, les lois et les budgets qui l’entourent. Enfin, elle inclut des principes directeurs sur la façon dont l’entité est construite et dont elle change. L’architecture n’est pas seulement un instantané de la structure ; elle comprend les règles qui maintiennent la cohérence de la structure à mesure que le système évolue, comme « chaque service possède ses propres données » ou « le code du domaine ne dépend jamais du framework web ».

La norme trace aussi une frontière nette entre une architecture et une description d’architecture. L’architecture est l’ensemble des propriétés fondamentales que le système possède réellement. La description est un produit de travail (documents, modèles, diagrammes, enregistrements de décisions) qui l’exprime. ISO/IEC/IEEE 42010 est avant tout une norme sur les descriptions : elle indique ce qu’une bonne description doit contenir, comme les parties prenantes identifiées, leurs préoccupations et les vues qui répondent à ces préoccupations. Elle ne vous dit pas comment concevoir une architecture. La section 1.5 revient sur les parties prenantes et les préoccupations, et le chapitre 4 traite des vues.

La définition du SEI : structures, éléments, relations et propriétés

La définition la plus enseignée vient de Software Architecture in Practice de Len Bass, Paul Clements et Rick Kazman (4e édition, Addison-Wesley, 2021), dont les auteurs ont travaillé au SEI. Selon eux, en paraphrasant : l’architecture logicielle d’un système est l’ensemble des structures nécessaires pour raisonner sur le système, et ces structures se composent d’éléments logiciels, des relations entre eux et des propriétés des uns et des autres.

Chaque partie de cette phrase a son utilité. Structures, au pluriel : un système possède plusieurs structures à la fois (ses modules de code, ses processus en cours d’exécution, son déploiement sur des machines) et aucune n’est à elle seule « l’architecture ». Nécessaires pour raisonner sur le système : pour savoir si quelque chose est architectural, on se demande si l’on en a besoin pour répondre à des questions importantes, comme « Cela résistera-t-il au pic de charge ? » ou « Deux équipes peuvent-elles y travailler indépendamment ? ». Les éléments sont les parties : modules, services, bases de données, files d’attente. Les relations sont la façon dont ils sont reliés : utilise, appelle, publie vers, est déployé sur. Les propriétés sont ce qui fait que les éléments et les relations se comportent comme ils le font : un service est sans état, un appel est synchrone avec un délai d’expiration de deux secondes, une base de données contient des données personnelles et doit rester dans l’UE.

La référence au raisonnement explique aussi ce qui n’est pas de l’architecture. Le nom d’une variable locale, l’algorithme interne d’une routine de tri ou la disposition d’un écran de paramètres n’aident généralement pas à raisonner sur le système dans son ensemble ; ils relèvent donc de la conception détaillée plutôt que de l’architecture. La section 1.2 examine où passe cette frontière.

Les définitions des praticiens : compréhension partagée, ce qui est important et décisions

Les praticiens ont proposé des définitions plus courtes qui mettent l’accent sur les personnes et les décisions plutôt que sur les structures. Martin Fowler en a popularisé deux, dues à Ralph Johnson (l’un des quatre auteurs du livre Design Patterns de 1994). La première veut que l’architecture soit la compréhension partagée qu’ont les développeurs experts de la façon dont le système est conçu. La seconde, issue de la même discussion, est délibérément ouverte : L’architecture, c’est ce qui est important. Quoi que ce soit. Johnson a aussi suggéré que l’architecture est l’ensemble des décisions que l’on aimerait réussir tôt dans un projet, non parce qu’on a plus de chances de les réussir tôt, mais parce qu’il est si coûteux de se tromper.

Grady Booch, l’un des créateurs d’UML, l’a formulé en termes économiques : l’architecture est constituée des décisions de conception importantes qui façonnent un système, leur importance se mesurant au coût du changement. Cela transforme une idée abstraite en critère utilisable. Le choix de la couleur d’un bouton est facile à annuler. Le choix entre une base de données relationnelle et une base orientée documents, ou entre une seule unité déployable et quarante, est coûteux à annuler une fois que les données, le code et les équipes se sont développés autour. Booch a aussi fait remarquer que toute architecture est conception, mais que toute conception n’est pas architecture.

Ces définitions ajoutent ce que les définitions structurelles laissent implicite. L’architecture vit en partie dans la tête des gens ; un système dont les ingénieurs seniors partagent une image claire de son fonctionnement a une architecture plus cohérente qu’un système où chacun a une image différente, même si aucun des deux n’a de diagramme. Et l’architecture est façonnée par des décisions, dont beaucoup impliquent un compromis : choisir une option, c’est renoncer aux avantages d’une autre. La section 1.6 examine en détail les décisions et les compromis.

Ce que les définitions ont en commun

Lues côte à côte, les définitions convergent vers sept idées, qui forment ensemble une définition de travail pour la suite de ce cours.

Trois types de structures

Les travaux du SEI sur la documentation, publiés sous le titre Documenting Software Architectures : Views and Beyond (Clements et ses collègues, 2e édition, 2010), regroupent les structures en trois types, et Software Architecture in Practice utilise le même regroupement. Connaître ces trois types vous protège de l’erreur la plus courante dans les discussions d’architecture : parler d’un type de structure alors que votre interlocuteur pense à un autre.

Les structures de modules montrent comment le code est découpé en unités d’implémentation, comme des paquets, des bibliothèques et des espaces de noms, et comment ces modules dépendent les uns des autres. Elles existent au moment du développement. Elles répondent à des questions comme : quelle équipe peut modifier quoi sans casser le travail des autres, et quel code peut être réutilisé ?

Les structures de composants et connecteurs montrent ce qui existe quand le système s’exécute : processus, services, clients, bases de données, et les connecteurs entre eux, comme les appels HTTP, les files de messages et les flux d’événements. Elles répondent à des questions d’exécution : quelle est la rapidité d’une requête, que se passe-t-il quand une partie tombe en panne, où les données sont-elles conservées ?

Les structures d’allocation font correspondre le logiciel à des choses extérieures au logiciel : au matériel et à l’infrastructure cloud (déploiement), aux équipes (affectation du travail), et aux fichiers et dépôts (implémentation). Elles répondent à des questions de coût, d’exploitation et d’organisation : où cela s’exécute-t-il, qui le construit, qui est réveillé la nuit quand il tombe en panne ?

Un même élément peut apparaître dans les trois. Une fonctionnalité de validation de commande est un paquet dans la structure de modules, un service en cours d’exécution dans la structure de composants et connecteurs, et un ensemble de conteneurs dans une région cloud dont l’équipe validation est propriétaire dans les structures d’allocation. La correspondance entre les structures n’est pas toujours biunivoque : un même module peut être déployé sous forme de plusieurs services, ou plusieurs modules peuvent s’exécuter dans un même processus. C’est précisément dans cet écart que se cachent bien des surprises.

Tout système a une architecture

Comme l’architecture est faite de structures et des propriétés qu’elles ont réellement, tout système logiciel a une architecture, que quelqu’un l’ait conçue volontairement ou non, et qu’elle soit écrite ou non. Une macro de tableur devenue un outil critique pour l’entreprise a une architecture. Le code d’une start-up écrit à la hâte par trois personnes aussi. La question n’est jamais de savoir si un système a une architecture, mais si cette architecture est adaptée à son usage, comprise par les personnes qui y travaillent et façonnée délibérément.

Cela conduit à une distinction utile. L’architecture voulue (ou prescriptive) est ce que l’équipe croit ou a décidé que la structure devrait être : le diagramme du wiki, les règles convenues. L’architecture réelle (ou descriptive) est ce que font vraiment le code et l’infrastructure. Les deux s’éloignent avec le temps à moins que quelqu’un ne les maintienne alignées, et cet écart est l’une des principales sources de dette technique, traitée à la section 1.7. Une architecture non documentée n’est pas absente ; elle est simplement plus difficile à voir, à analyser et à modifier sans risque.

Comment les professionnels utilisent les définitions

En pratique, les architectes expérimentés récitent rarement une définition, mais ils se servent de chacune comme d’une grille de lecture. La vision de l’ISO leur rappelle de regarder vers l’extérieur, vers l’environnement, et de distinguer ce que le système est de ce que les documents disent. La vision du SEI leur donne un vocabulaire de structures, d’éléments, de relations et de propriétés pour l’analyse, ainsi qu’un critère (« avons-nous besoin de cela pour raisonner sur le système ? »). La vision de Johnson leur rappelle qu’un modèle mental partagé par l’équipe est en soi un actif à entretenir. La vision de Booch leur indique où consacrer leur temps limité : aux décisions qu’il serait coûteux d’annuler.

Il en découle une règle empirique pratique. Quand vous ne savez pas si quelque chose est architectural, posez trois questions. Serait-ce coûteux ou risqué de le changer plus tard ? Cela touche-t-il plusieurs parties du système ou plusieurs équipes ? Cela détermine-t-il si le système atteint un objectif de qualité important, comme la rapidité, la disponibilité ou la sécurité ? Si la réponse à l’une de ces questions est oui, traitez-le comme de l’architecture : décidez-le délibérément, consignez les raisons, et assurez-vous que les personnes concernées le comprennent.