Architecture, conception et code : importance, portée et niveaux

Un continuum, pas un mur

Si l’architecture est l’ensemble des décisions et des structures importantes (section 1.1), alors la conception est tout le reste : les nombreuses décisions plus modestes sur le fonctionnement interne de chaque partie. La difficulté est qu’il n’existe pas de frontière nette entre les deux. Choisir de découper une plateforme de livraison de repas en un système de commandes et un système de livreurs est clairement architectural. Nommer une variable ne l’est clairement pas. Entre ces extrêmes s’étend une vaste zone intermédiaire de décisions (le format d’erreur d’une API, une règle de cache, le découpage d’un module en paquets) dont le statut dépend du contexte.

Grady Booch l’a joliment résumé : toute architecture est conception, mais toute conception n’est pas architecture. L’architecture et la conception détaillée sont des points d’un même continuum de décisions de conception, ordonnées selon leur importance. C’est pourquoi la question la plus utile n’est pas, dans l’absolu, « est-ce de l’architecture ou de la conception ? », mais « quelle est l’importance de cette décision ici, et quel soin mérite-t-elle ? ».

Une deuxième façon répandue de tracer la frontière est le niveau d’abstraction : l’architecture serait la vue de haut niveau (« des boîtes et des flèches »), la conception la vue de bas niveau (« des classes et des méthodes »). C’est une première approximation raisonnable, mais elle échoue dans les deux sens. Un détail de bas niveau peut être architectural : le format d’un identifiant partagé par vingt services, ou le choix d’une convention de fuseau horaire pour les dates stockées, peut coûter des mois à changer. Et une boîte de haut niveau peut être anodine : qu’un outil d’administration interne soit ou non un service séparé peut n’avoir aucune importance.

Ce qui rend une décision architecturalement significative

Une décision est architecturalement significative lorsqu’elle présente une ou plusieurs des caractéristiques suivantes. Ce ne sont pas des règles formelles issues d’une norme unique ; elles résument ce que disent, en d’autres termes, le SEI, Martin Fowler, Mark Richards et Neal Ford, entre autres.

Mark Richards et Neal Ford, dans Fundamentals of Software Architecture, décrivent le spectre architecture/conception en des termes semblables : une décision penche d’autant plus vers l’architecture qu’elle est stratégique (long terme, nombreuses personnes impliquées), qu’elle demanderait d’efforts pour être changée et que ses compromis sont importants. Martin Fowler en propose une version condensée : l’architecture, c’est ce qui est difficile à changer, ce qui signifie aussi que l’un des objectifs d’un architecte est de rendre davantage de choses faciles à changer. Rendre une décision peu coûteuse à annuler, par exemple en la plaçant derrière une interface, la fait de fait glisser de l’architecture vers la conception. Cette idée, la réversibilité, est approfondie à la section 1.6.

Décisions stratégiques et tactiques

Une distinction voisine oppose décisions stratégiques et décisions tactiques. Les décisions stratégiques fixent une direction pour longtemps et pour de nombreuses personnes : adopter un fournisseur de cloud, choisir entre un monolithe et des services distribués, décider que les données clients auront un système maître unique. Elles demandent généralement l’avis de plusieurs parties prenantes et méritent d’être consignées avec leurs raisons. Les décisions tactiques résolvent un problème immédiat dans un périmètre circonscrit : quelle bibliothèque utiliser pour analyser les dates dans un service, comment structurer une requête de base de données particulière, comment nommer les endpoints d’une API interne.

Stratégique ne veut pas dire lent. Beaucoup de décisions stratégiques peuvent et doivent être prises rapidement une fois les options claires, et certaines sont réversibles si elles sont bien structurées. Tactique ne veut pas dire sans importance : une mauvaise décision tactique répétée à cinquante endroits (par exemple, chaque service qui écrit sa propre logique de nouvelle tentative sans backoff) peut finir par constituer un problème architectural. Les architectes surveillent les décisions tactiques qui sont sur le point de devenir stratégiques à force de répétition, et les transforment en principe commun ou en capacité de plateforme.

Les niveaux d’architecture

Le mot architecture s’emploie aussi à plusieurs niveaux de portée, et les intitulés de poste suivent ces niveaux. Les confondre provoque bien des malentendus : un architecte d’entreprise et un architecte logiciel peuvent tous deux être « l’architecte », alors que leurs travaux se recoupent à peine.

L’architecture d’entreprise porte sur toute une organisation : ses capacités métier (ce qu’elle doit être capable de faire, comme « instruire les sinistres » ou « intégrer de nouveaux clients »), les informations qu’elle détient, son portefeuille d’applications et ses plateformes technologiques, et la façon dont tout cela doit évoluer pour servir la stratégie. Les livrables typiques sont des cartes de capacités, des feuilles de route vers l’état cible, des normes technologiques et des décisions sur les systèmes à retirer. Le cadre le plus utilisé dans ce domaine est TOGAF, publié par The Open Group, dont la version actuelle est le TOGAF Standard, 10e édition (2022). Il fournit une méthode (l’Architecture Development Method) et un ensemble de contenus pour planifier et gouverner les transformations de l’entreprise. Les organisations l’utilisent à des degrés divers ; beaucoup en adoptent certaines parties et d’autres le trouvent lourd, et ce cours ne le décrit que pour que vous puissiez le reconnaître.

L’architecture de solution traite un problème métier ou un programme, qui s’étend généralement sur plusieurs applications, équipes et fournisseurs : par exemple, un hôpital qui met en place la prise de rendez-vous en ligne et doit relier un nouveau frontend web, le système existant de gestion administrative des patients, un prestataire de SMS et le service d’identité. L’architecte de solution fait en sorte que les pièces s’emboîtent, souvent sous des contraintes commerciales et contractuelles.

L’architecture logicielle ou applicative, sujet principal de ce cours, concerne les structures et les qualités d’un seul système : sa décomposition, ses interactions à l’exécution, son déploiement, ses données et son évolution.

Trois spécialités traversent tous ces niveaux. L’architecture des données porte sur la façon dont les données sont modélisées, possédées, stockées, déplacées, gouvernées et utilisées pour l’analytique (chapitre 7). L’architecture de sécurité porte sur l’identité, l’accès, la protection des données, les modèles de menaces et le placement des contrôles de sécurité (chapitre 8). L’architecture d’infrastructure (souvent appelée aujourd’hui architecture cloud ou de plateforme) porte sur le calcul, les réseaux, le stockage, les environnements et les plateformes de déploiement (chapitre 10).

Qui prend quelles décisions

Dans une organisation saine, les décisions sont prises au niveau le plus bas qui dispose d’assez de contexte et qui répond des conséquences. L’architecture n’est pas la chasse gardée des personnes dont l’intitulé de poste contient le mot « architecte ». Une répartition par défaut raisonnable ressemble à ceci, même si chaque organisation l’ajuste.

Deux signaux d’alerte montrent que la répartition est mauvaise. Si les architectes décident des structures de classes internes, ils deviennent un goulot d’étranglement et l’équipe cesse de réfléchir. Si les équipes prennent chacune de leur côté des décisions qui ont des effets sur tout le système (chacune choisissant son propre courtier de messages, par exemple), l’organisation paie plus tard le prix de l’incohérence. La façon de consigner quelles décisions exigent une consultation plus large, et de faciliter leur enregistrement, est traitée dans décisions et compromis et, en profondeur, dans la partie du chapitre 4 consacrée aux enregistrements de décision d’architecture (ADR).

Comment les professionnels appliquent la distinction

Les équipes expérimentées transforment le continuum en une routine légère. Elles conviennent d’une courte liste des types de décisions qui exigent une trace écrite et une consultation plus large, par exemple tout ce qui modifie une API publique, introduit un nouveau stockage de données ou une nouvelle technologie, franchit les frontières entre équipes ou affecte un objectif de qualité déclaré. Tout le reste est décidé par les personnes qui font le travail, au travers de la revue de code habituelle. Elles revoient la liste quand quelque chose passe entre les mailles du filet ou quand les revues ressemblent à de la bureaucratie.

Elles cherchent aussi activement des moyens de réduire l’ensemble des décisions architecturales, car chaque décision qui devient peu coûteuse à annuler est une décision de moins à réussir du premier coup. Masquer un fournisseur derrière une interface, rendre une base de données privée à un seul service, utiliser des feature flags pour les comportements risqués et déployer par petits incréments déplacent tous des décisions de l’extrémité architecturale du continuum vers l’extrémité conception.