Ce modèle de Dossier d’Architecture (DA) est applicable à la plupart des projets d’informatique de gestion, indépendamment de l’architecture générale retenue (monolithe, SOA, microservices, n-tiers, …). Il a déjà été utilisé sur plusieurs projets importants y compris au sein de grandes organisations. Il s’enrichit régulièrement.

Autres langues : Anglais.

Nous avons découpé l’architecture en cinq vues (applicative, sécurité, dimensionnement, infrastructure et développement), chaque vue étant auto-porteuse.

L’idée est de proposer un ensemble de vues d’architecture alignées sur les rôles que l’on trouve le plus fréquemment dans les organisations et sur leurs préoccupations respectives. Par exemple, un architecte d’infrastructure ou un ingénieur DevOps a rarement besoin de connaître le détail de l’architecture logicielle (le détail des frameworks utilisés ou la façon de gérer les erreurs). De même, un PO ou un architecte d’entreprise va s’intéresser à la vision macroscopique des modules applicatifs et de leurs interactions principales ("le batch B appelle le service S") mais rarement du détail de l’infrastructure sous-jacente (choix de la base de donnée du service, dimensionnement des machines, …).

Un dossier suivant ce modèle sera ainsi constitué :

• d’une vue applicative présentant le contexte général et l’architecture applicative ;

• d’une vue développement présentant l’architecture logicielle et son environnement ;

• d’une vue dimensionnement présentant les aspects liés aux performances et au dimensionnement de l’infrastructure ;

• d’une vue infrastructure présentant les serveurs, les middlewares, l’exploitation, etc. ;

• d’une vue sécurité ;

Dans chaque vue, on retrouvera le triptyque :

• Contraintes (juridiques, budgétaires, technologiques, normatives…) applicables au projet;

• Exigences non fonctionnelles (ENF) exprimées par les porteurs du projet dans la limite des contraintes ;

• Solution (description de l’architecture retenue et répondant aux ENF).

Le dossier comprend également un exemple de glossaire pouvant servir de support à l’Ubiquitous Language, élément fondamental d’une architecture.

Pour en savoir plus, voir ce papier publié dans Applied Computing and Informatics.

• A partir de quelle taille de projet ce modèle est-il éligible ? Ce modèle a été utilisé avec succès sur un court projet d’une seule personne comme sur plusieurs grands projets faisant intervenir des équipes importantes sur plusieurs années. Un grand projet/produit détaillera probablement plus de rubriques mais la plupart de ces dernières sont applicables quelque soit la taille du projet. Par exemple, les questions de disponibilité ou d’internationalisation ne sont pas liées à la taille d’un projet nous semble-il.

• Ce modèle peut-t-il servir de base à un référentiel d’architecture ? Même si de nombreuses idées peuvent être reprises, non, ce n’est pas l’objet de ce modèle.

• Ce modèle convient-il à un programme complet ? Nous préconisons pour un programme complet une approche type TOGAF avec les livrables associés. En revanche, les phases C et D pourront être documentées par un DA au sein de chaque projet de ce programme.

• Comment documenter les trajectoires d’architecture ? Nous préconisons de décrire la trajectoire générale (sans entrer dans trop de détails) dans la section "Architecture générale" de la vue applicative et d’en décrire l’architecture des futurs modules dans les sections habituelles des différents vues mais en spécifiant clairement de quelle étape il s’agit (par exemple, préfixer le titre d’un module ou d’un flux qui n’apparaît qu’en étape 2 avec [Etape 2]). Attention néanmoins à faire en sorte d’éviter trop de refactoring documentaire quand cette partie du projet sera implémentée (liens cassés par exemple).

  • Traiter les étapes futures dans les mêmes sections que les éléments à implémenter immédiatement afin de les traiter suivant la même logique que le reste.

  • Plus l’étape décrite est lointaine dans le temps, moins son architecture doit être détaillée (c’est un bon principe agile d’architecture 'Just In Time' qui évitera de réécrire de nombreuses fois ces sections).

  • Plus l’étape décrite est proche de l’architecture physique, moins elle doit être détaillée. Par exemple, il peut être pertinent de documenter dans la vue applicative l’architecture générale de modules qui devraient être implémentés dans un an mais attendre le plus possible pour documenter leur dimensionnement précis dans la vue dimensionnement. De même, vous pouvez documenter des flux applicatifs lointains mais attendez avant de décrire les flux techniques précis dans la vue infrastructure.

• Pourquoi 'DA' et pas 'DAT' (dossier d’architecture technique) ou termes similaires ? Chaque organisation possède sa terminologie propre mais le terme 'technique' (comme 'fonctionnel' d’ailleurs) est équivoque (qu’est ce qui n’est pas "technique" dans l’IT ?).

• Copyright (c) 2017-2023 Bertrand Florat et contributeurs

• Ce modèle est en licence CC BY-SA 4.0 : Creative Commons Attribution - Partage à l’identique V4.0

• Vous pouvez créer votre propre modèle à condition qu’il conserve la licence CC BY-SA 4.0 et qu’il contienne donc ces trois éléments:

  • Le nom du créateur (Bertrand Florat) ;

  • Un lien vers https://creativecommons.org/licenses/by-sa/4.0/ ;

  • Une notice de non-responsabilité et un lien vers https://github.com/bflorat/modele-da.

• Les dossiers d’architecture issus de ce modèle n’ont pas à appliquer cette licence. Il est néanmoins recommandé d’y inclure un lien vers https://github.com/bflorat/modele-da.

• Contributrices/eurs, siwon (RACI)

• Retours : Antoine Parra Del Pozo, Pascal Bousquet, Philippe Mayjonade, Nicolas Chahwekilian, Steven Morvan, Dr. Christophe Gaie

• Tous les diagrammes de ce modèle ont été générés avec l’excellent outil PlantUML Les diagrammes C4 utilisent la personnalisation C4 de plantuml.

• Site Reliability Engineering - Google

• Living documentation - Cyril Martraire

• Clean Code - Robert Martin

• Performance des architectures IT - 2e ed. - Pascal Grojean

• Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides (GOF)

• Le projet d’Urbanisation du SI - Christophe Longépé

• Sécurité de la dématérialisation - Dimitri Mouton