Architecture : Voyager léger

Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un deuxième principe à appliquer afin d’atteindre ces objectifs. Alors que le premier, « Etre toujours impliqué », concernait l’architecte et son rôle, celui-ci à trait aux livrables d’architecture. Il s’intitule « Voyager léger ».
L’expression « Voyager léger » doit ici être prise au pied de la lettre. La question qui se pose est : Que doit avoir sur lui un architecte lorsqu’il fait le tour des parties prenantes d’un projet pour échanger avec chacune d’entre elles ? De quel support a-t-il besoin pour expliquer les besoins métier à l’équipe de réalisation, pour transmettre la vision du produit au métier, pour impliquer les opérations suffisamment tôt, etc. ?

Comme nous l’avons déjà vu, les dossiers d’architecture à rallonge sont un mal courant dans nos Direction Informatique. C’est le piège du « Big Design Up Front » (BDUF) ou du « Big Modeling Up Front » (BMUF). Les dossiers d’architecture épais comme des bottins ne sont d’aucune utilité parce qu’au final, quels que soient les efforts déployés pour les produire et quelle que soit la pertinence de leur contenu, ils ne sont pas lus. De tels documents ne sont pas lisibles facilement et demandent trop d’efforts et de temps pour appréhender et comprendre leur contenu. Résultat, tout le monde s’en détourne et toute la valeur qu’ils contiennent est perdue.

Comment voyager léger ?

Voyager léger impose de fournir une vision simple d’un système qui ne l’est pas nécessairement. Il faut donc trouver le bon niveau d’abstraction afin de résumer la vision d’une architecture en quelques lignes et quelques schémas.

• Réduire la documentation à ce qui est nécessaire et suffisant :
  Ne pas écrire 50 pages quand 5 suffisent ; Ne pas écrire 5 pages quand un diagramme suffit …
  Il suffit de maintenir quelques diagrammes de haut niveau permettant de naviguer dans l’architecture (voyager léger ne signifie pas que toute documentation disparaît). Ces diagrammes ne devraient pas faire l’objet d’une règle rigide. Leur type et leur formalisme dépendent du système et du contexte. Il faut savoir rester flexible.
• Favoriser la communication orale :
  Un architecte Lean est un membre actif des équipes de développement, et non un simple producteur de documents à destination des différentes parties prenantes. A ce titre, il se doit de se focaliser sur la collaboration plutôt que sur la documentation. Là encore, cela ne signifie pas qu’il ne faut pas documenter, mais la documentation doit être vue comme un effort secondaire. La priorité est le partage de la connaissance.
• Publier les modèles d’architecture :
  Les diagrammes de haut niveau et les modèles d’architecture doivent être publiés de façon à être accessibles aux membres des équipes et à tous ceux qui souhaitent les consulter. Quand on a réussi à synthétiser la vision de l’architecture à quelques diagrammes de haut niveau, le plus efficace reste de les placarder dans le bureau (à côté du Scrum board, par exemple).
• Obtenir du feedback et itérer :
  Une fois synthétisés, il faut s’efforcer d’échanger autour des diagrammes qui résument la vision de l’architecture avec l’ensemble des parties prenantes. L’architecte Lean sera très attentif à leurs feedbacks et itérera pour améliorer aussi bien le fond que la forme. Il s’assurera que la vision de l’architecture est compréhensible (et comprise) par le métier, les opérations et les équipes projet.

Il ne faut pas sous-estimer la difficulté à définir et capturer une vision qui est simplement compréhensible par toutes les parties prenantes d’un projet. Il est beaucoup plus facile de se noyer dans la complexité. Il est donc nécessaire de prendre du temps, en itérant avec l’ensemble des parties prenantes, pour identifier les éléments clés de l’architecture et les capturer au travers de quelques diagrammes et d’une description succincte.

La poursuite des 3 C

L’application de ce principe permet une plus forte Cohésion des solutions parce que l’ensemble des personnes impliquées comprend et supporte la vision de l’architecture dans son contexte. Et, puisqu’ils la comprennent et la supportent, ils peuvent et vont en appliquer les principes au sein des projets.

D’autre part, la Connexion aux objectifs de l’entreprise est améliorée puisque, en voyageant léger, les architectes Lean peuvent avoir des échanges constructifs avec l’ensemble des parties prenantes autour de la vision de l’architecture.

Enfin, l’accueil favorable du Changement est simplifié puisque, la vision de l’architecture se concentre sur ses éléments clés ce qui contribue à la définition d’architectures « simples ». Or, une architecture « simple », même si elle est plus difficile à définir, est plus facile à adapter quand les changements le nécessitent.

Traduction libre du billet « Lean Architecture Principle #2: Travel light » publié par Denis Koelewijn sur blog.xebia.com.