La relation entre l'organisation des équipes et l'architecture applicative

Cette relation est connue sous le nom de loi de Conway, énoncée par Melvin Conway en 1967 : « Les organisations qui conçoivent des systèmes […] sont limitées à produire des conceptions qui sont des copies des structures de communication de ces organisations. »

La communication au sein de l’équipe est fréquente et fluide, avec des réunions de planification régulières, des dailies, des rétrospectives et des démos. Cela permet à l’équipe d’avoir un haut niveau d’alignement et une coordination agile, ce qui est fondamental pour le développement d’un composant. Si vous décidez soudainement de diviser cette équipe en 2 équipes, il y a une rupture dans la communication. La communication avec les autres équipes est beaucoup moins fréquente, car l’une des idées des équipes est de les isoler des facteurs externes afin qu’elles puissent se concentrer sur leur périmètre. Cette réduction de la communication entre les équipes rend la tâche de maintenir un seul composant plus complexe. Dans ces cas, il y a deux options : 1) Diviser le composant en 2, un par équipe, ce qui permet aux équipes de se découpler et de travailler de manière plus autonome. 2) Maintenir un seul composant, ce qui implique la mise en place d’une série de mécanismes de coordination et de réunions entre les équipes, avec la surcharge que cela entraîne. De plus, les équipes sont interdépendantes, ce qui réduit la vitesse et l’autonomie et affecte la productivité (puisqu’elles doivent travailler si étroitement ensemble, on pourrait presque dire que, pour des raisons pratiques, il n’y a toujours qu’une seule équipe).

Traditionnellement, la réorganisation des équipes est souvent faite par le haut, et pas toujours par des personnes ayant une connaissance approfondie de l’architecture applicative. À maintes reprises, j’ai vu des équipes être réorganisées autour des clients, de sorte que lorsqu’un nouveau client arrivait, une nouvelle équipe était créée. Et dans certains cas, nous finissions par forker le code comme solution pour que la nouvelle équipe soit indépendante et agile. Avec tout ce que cela implique : dupliquer le code, avec tous ses bugs et sa dette technique ;

Afin de réaliser une réorganisation plus sensible à l’architecture qui n’impacte pas négativement l’application, il existe ce qu’on appelle la manoeuvre inverse de Conway. Celle-ci consiste à organiser l’équipe de manière à ce qu’elle imite l’architecture de l’application à atteindre. Pour concevoir ce type de réorganisation, il est essentiel de compter sur la collaboration des architectes logiciels, qui aideront à la concevoir en utilisant les principes de l’architecture logicielle. Les équipes peuvent être vues comme un système, avec différents composants ayant leurs responsabilités et dont la communication se fait à travers des interfaces bien définies.

Si ce sujet vous intéresse davantage, je recommande le livre Team Topologies, de Matthew Skelton et Manuel Pais. Et si vous avez besoin d’aide ou de conseils pour aborder une réorganisation, vous pouvez me contacter ici.