Dessiner l’architecture logicielle

L’architecte doit-il communiquer ?

Dans la Tech, la communication est un aspect essentiel du métier d’architecte. Cette assertion est trop souvent oubliée et conduit généralement à des incompréhensions et des frustrations. L’architecte doit communique tous azimut, vers les équipes techniques comme les équipes non techniques.

La communication a plusieurs objectifs dont deux qui ont une vraie valeur ajoutée pour faire avancer les projets et le business de l’entreprise. Tout d’abord, la communication sert à convaincre le management de financer ou de sponsoriser des projets. Il ne suffit pas de demander un budget pour construire une cathédrale rutilante. Il faut savoir expliquer pourquoi la brillance de la cathédrale va apporter de la valeur à l’entreprise et donc, pourquoi le management a tout intérêt à ajouter une ligne budgétaire pour ce projet grandiose. 

Ensuite, la communication sert à convaincre les équipes de développement d’implémenter la solution préconisée ou les standards établis. Encore une fois, il ne suffit pas d’écrire une solution ou un standard dans un coin de la documentation pour qu’ils soient implémentés ou appliqués. La communication de l’architecte vers les équipes tout au long de la conception permet à chacun de s’informer, d’émettre des avis et ainsi de s’approprier le sujet. C’est l’appropriation du sujet par les équipes qui conduira à une implémentation motivée, et donc de qualité.

La communication par le dessin

La communication chez un architecte revêt deux formes complémentaires : le dessin lui-même que j’évoquerai ici, et sa présentation que je pourrais évoquer dans un autre billet.

L’architecte est amené à présenter différents points de vue de l’architecture en fonction du contexte et de l’audience. Il peut être amené à dessiner une vue de très haut niveau, par exemple pour une audience non-technique comme des équipes métiers. Il peut également être amené à dessiner une vue très détaillée qui va descendre dans le détail des composants logiciels, pour une audience de développeurs par exemple.

Néanmoins, il est nécessaire de toujours lier les vues entre elles pour que l’audience garde le fil du sujet. Par exemple on peut associer une vue détaillée à une vue plus globale en dessinant un effet de zoom. Garder une vision cohérente de l’ensemble des vues permet à l’audience de comprendre le périmètre des éléments présentés et de les situer dans un schéma plus global, ce qui élimine une source classique de confusion.

Comment dessiner l’architecture logicielle

Vous trouverez facilement des outils de diagrammes modernes très puissants et dotés de nombreuses fonctionnalités. C’est un piège dans lequel il ne faut pas tomber, surtout au début d’une phase de conception : il ne faut pas négliger les diagrammes réalisés avec des formes simples, par des outils simples, voire simplistes. C’est parfois dur à entendre pour un architecte mais, à l’heure de l’Agile, les diagrammes sont jetables. Le diagramme sert un objectif qui peut être éphémère, comme un atelier autour de la conception d’une fonctionnalité. D’autres diagrammes peuvent servir un objectif plus pérenne comme la capitalisation d’une connaissance relativement stable.

L’utilisation d’outils puissants risque d’amener plus facilement l’architecte dans un anti-pattern décrit par Neal Ford comme “Irrational Artifact Attachement”. Ce pattern survient lorsqu’un architecte s’attache trop à son artefact, parce qu’il est joli et qu’il y a passé beaucoup de temps. Cet attachement irrationnel au diagramme qu’il a produit de ses mains va biaiser sa réception des avis et critiques qui pourraient amener une modification, voire une suppression, de son travail. Les diagrammes low-tech permettent d’éviter cette situation.

L’outil de dessin low-tech le plus souvent utilisé par les architectes est le fameux tableau blanc. Il est grand, pratique, collaboratif, il a très peu de fonctionnalités et il est facilement effaçable. Mais on peut aussi utiliser une tablette branchée à un écran plutôt qu’un tableau blanc, ce qui a amène plusieurs avantages : les images sont directement numérisées, on peut copier/coller des formes, les modèles de base sont quasiment illimités et on peut facilement revenir dessus plus tard pour le modifier, ce qui est beaucoup moins le cas avec la photo d’un tableau blanc.

Si vous choisissez d’utiliser un outil numérique, celui-ci doit a minima posséder les fonctionnalités suivantes :

• une gestion des couches : on appelle “couches” ou layers des groupes d’objets qui sont visibles ou invisibles ensemble. Ils permettent de produire des diagrammes simples en cachant certaines complexités. Ils permettent également de construire des images incrémentales pour une présentation dans laquelle on découvrira le diagramme au fur et à mesure ;
• une gestion des bibliothèques : créer une bibliothèque d’icônes et de formes permet de garantir une vue cohérente des diagrammes dans l’entreprise et permet également de créer rapidement un nouveau diagramme ;
• une gestion des aimants : les aimants permettent de coller facilement les flèches aux formes ou d’aligner les formes entre elles.

En plus de ces fonctionnalités, l’outil doit proposer d’autres fonctionnalités de base : supporter les lignes, les couleurs, les artefacts visuels ainsi que les exports dans une grande variété de formats.

Les standards du dessin d’architecture logicielle

Différents standards de formats existent pour réaliser des diagrammes d’architecture logicielle. Nous en passerons quelques-uns en revue.

UML

UML, pour Unified Modelig Language, est un langage de modélisation standard qui permet de visualiser une architecture système. UML inclus un ensemble de technique de notations graphiques pour créer des représentations visuelles de système logiciels. UML est versatile et largement utilisé pour modéliser les structure et les comportements des systèmes logiciels, à travers différents types de diagrammes :

• le diagramme de classe, pour représenter la structure classique d’un système
• le diagramme de séquence, pour illustrer comment les objets interagissent dans un scenario spécifique d’un cas d’utilisation
• le diagramme de cas d’utilisations, pour représenter les interactions entre un système et ses entités externes
• le diagramme d’activités, pour représenter les flux d’activités et d’actions
• le diagramme d’états, pour afficher les états d’un système et les transitions entre ces états
• le diagramme de composants, pour indiquer comment un système est découpé en composants et les dépendances entre eux.

Bien qu’UML soit facilement compréhensible pour le développement logiciel, il peut être trop complexe ou trop détaillé pour représenter une architecture haut-niveau. Ainsi UML est toujours utilisé pour des diagrammes et classes ou de séquence, mais tombe en désuétude pour le reste.

C4

C4 est une technique de diagramme visant à moderniser UML.

La signification de C4 est la suivante :

• C pour contexte : le contexte du système, incluant les rôles utilisateurs et les dépendances externes
• C pour container : les limites physiques et logiques des contenants de l’architecture, ce qui représente un bon point de départs pour les architectes et les opérations
• C pour composant : la vue des composants du système, qui doit s’aligner avec la vue architecture
• C pour classe : diagramme UML de classe.

C4 est une bonne alternative pour standardiser les diagrammes, mais il est plus adapté à un style d’architecture monolithique dans lequel les conteneurs et les composants sont différents, contrairement aux microservices. Néanmoins, les deux premières couches restent très utile pour représenter une architecture microservices.

ArchiMate

ArchiMate est un langage de modélisation d’architecture d’entreprise open-source qui cherche à être le plus minimaliste possible et ne pas couvrir tous les cas limites. Il offre une approche structurée pour décrire l’architecture. Il est particulièrement pertinent dans la modélisation des relations entre différents domaines architecturaux. Les principales fonctionnalités sont les suivantes :

• la couche métier, qui se focalise sur les produits et services offerts aux clients
• la couche applicative, qui décrit comment les applications supporte le métier et comment ils sont liés aux couches inférieures d’infrastructure
• la couche technologie, qui se concentre sur l’infrastructure, incluant le matériel, le logiciel et les technologies de communication
• les éléments physiques, qui représentent le monde physique, comme les équipements ou les bâtiments
• les éléments d’implémentation et de migration, qui modélise la transition de l’architecture courante à l’architecture cible
• les éléments de motivation, qui fournissent la capacité de modéliser les parties prenantes, les éléments de changements, les objectifs métiers, les principes et les exigences. ArchiMate est un choix populaire parmi les architectes. Il offre un ensemble bien défini d’entités et de relations, facilitant l’illustration d’architectures complexes. Archimate est particulièrement utile dans l’architecture d’entreprise pour aligner les solutions technologiques avec les objectifs métiers.

Les éléments de base du dessin d’architecture

Titre

Tous les diagrammes doivent avoir un titre suffisamment parlant pour l’audience.

Lignes

Les lignes doivent être assez épaisses pour se voir et indiquer le sens du flux si besoin.
Les lignes peuvent être multiples mais cohérentes.
Un exemple de standard : ligne pleine = communication synchrone, ligne pointillée = communication asynchrone.

Formes

Les formes peuvent être standardisées, par exemple définir une forme 3D pour un élément déployable et un rectangle pour les conteneurs.

Etiquettes

Chaque élément du diagramme doit avoir une étiquette.

Couleur

Utiliser la couleur pour différencier les artefacts entre eux, mais pas pour différencier deux artefacts de même nature (par exemple, deux instances d’un même microservice).

Légende

Ajouter une légende si la signification des formes est ambigue. Un diagramme qui porte à confusion est pire qu’une absence de diagramme.

Conclusion

Le dessin efficace est une compétence fondamentale pour l’architecte. Il ne s’agit pas de créer une diagramme visuellement attractif mais plutôt de créer une réprésentation claire et pertinente d’un système complexe. Il s’agit également de choisir le bon outil adapté à la vue et à l’audience souhaitées. Le défi, en tant qu’architecte, est donc de trouver le bon équilibre entre justesse technique et simplicité.