La course à la réactivité est une réalité aujourd’hui. Les entreprises cherchent à répondre non seulement le mieux possible, mais aussi le plus rapidement possible à divers signaux : évolutions du contexte économique, modifications des attentes des consommateurs, modifications du paysage concurrentiel… Il s’agit donc souvent de faire évoluer un produit et, en particulier dans le cas qui nous concerne, un produit logiciel, qu'il soit au service du business (par exemple une plateforme e-commerce) ou directement le produit final (par exemple un service en ligne).
Cet article présente un élément essentiel, aux implications multiples : l’organisation au sein de l’entreprise et ses conséquences sur l'évolution des produits logiciels, tel que le présente la loi de Conway.
La capacité à répondre à ce besoin de réactivité sera liée à la façon dont le produit a été réalisé. L’architecture, le cycle de production et de déploiement, etc. sont autant de facteurs qui auront un impact sur la latence qui séparera la validation d’une évolution et sa mise à disposition réelle pour l’utilisateur.
On peut s’étonner que certaines entreprises réussissent à relever ce défi avec une performance aussi élevée et parmi elles très souvent les leaders du Web. Par ailleurs, on peut aussi s’accorder sur l’apparente (et certainement réelle) complexité de leurs architectures techniques. On s’en étonnera d’autant qu’il est assez souvent constaté que le même exercice dans de plus petites structures, et donc souvent avec un niveau de complexité moindre, n’arrive pas à délivrer dans des délais tenables.
À quoi peut donc tenir cette capacité à délivrer rapidement ? Certes, ces entreprises comptent parmi leurs effectifs des profils experts. Mais ce n’est pas une exclusivité et fort heureusement, les talents se retrouvent aussi dans les entreprises plus conventionnelles. Certes, elles revendiquent des architectures modernes, qui semblent s'éloigner du legacy présent dans certains contextes… Pourtant certaines d’entre elles ont connu à leurs débuts des architectures moins modernes... Amazon ou Netflix par exemple, qui ont toutes deux dues transformer en profondeur leur architecture originelle pour ne pas se retrouver immobilisées.
Pour réussir ce challenge, de pouvoir faire évoluer rapidement un produit, et ce dans un contexte qui n’est plus celui d’une startup de quelques individus mais d’une société de plusieurs centaines ou milliers de salariés, certains choix communs semblent avoir porté leurs fruits. Parmi eux, un travail sur la granularité du produit : le passage d’un tout insécable à un ensemble de composants collaborants, si possible de la façon la plus souple possible.
Cette approche a par ailleurs d’autres bénéfices, qui ne sont pas couverts dans cet article, comme l’optimisation de l’empreinte globale en termes de ressources par rapport à un besoin et la capacité à adapter plus précisément les ressources nécessaires à une variation de l’utilisation.
Cette approche permet de concevoir des composants, au périmètre de responsabilités bien défini, interagissant avec d’autres composants au travers des protocoles de communication et des règles réduisant au minimum les besoins de synchronisation.
Il peut donc être tentant de s’inspirer de ces approches, d’autant que maintenant, les solutions techniques visant à simplifier la mise en oeuvre de ce type d’architecture rendent le défi plus acceptable. Pire, comme tout le monde en parle, les adeptes du culte du cargo pensent qu’il FAUT passer par là pour survivre à une concurrence qui n’attendra personne. Et puis il y a aussi l’effet de mode… Mais il serait trop simple de trouver dans un changement d’architecture seul une réponse au problème global de réactivité.
Qu’est ce que la loi de Conway ?
En effet, ces architectures ne viennent en général pas seules. Elles ont été introduites en même temps que des modifications structurantes dans l’organisation des sociétés concernées. De petites équipes ont été constituées pour cela. Ce choix d’organisation va dans le sens d’une constatation réalisée en 1967 et depuis connue sous le nom de Loi de Conway qui lie les caractéristiques d’une organisation ou équipe à celles du produit qu’elle développe. Dans les termes d’origine, cela donne :
"Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations."
Cette constatation a été faite dans un premier temps sur une petite équipe, par un certain Melvin Conway, aussi reconnu comme développeur émérite pour des travaux sur les compilateurs et en particulier des papiers sur les coroutines.
Bien qu’initialement refusée par le Harvard Business Review, cette loi a tout de même fait l’objet d’une étude par la Harvard Business School. L’étude s’est appuyée sur l’analyse d’applications d’un même type, réalisées par des équipes aux modes d’organisation différents : des équipes “distribuées”, typiquement retrouvées sur des projets open source où les contributeurs ou équipes de contribution ne sont pas colocalisés, ainsi que des équipes “denses”. La corrélation a été établie : les équipes “distribuées” produisent spontanément des architectures plus modulaires que les équipes “denses”, qui tendent à produire des architectures plus monolithiques. La nature des interactions entre les équipes, caractérisée par un couplage lâche dans le cas distribué et un couplage fort dans le cas dense, a donc pour conséquence la mise en oeuvre d’un design à l’image de l’organisation.
Il pourrait donc être tentant de voir dans l’adoption de plus en plus généralisée d’équipes de développement plus petites, souvent sous l’impulsion d’une volonté de faire entrer de nouveaux modes de pilotage des projets, plus “agiles”, une réponse sécurisante au problème évoqué en début d’article : savoir répondre plus rapidement au changement.
C’est probablement en partie vrai... Mais cela ne suffit pas.
La véritable production de valeur commence lorsque l’utilisateur peut tirer profit d’une évolution. L’équipe de développement joue donc un rôle limité dans la chaîne de valeur globale. Produire vite ne suffit pas, il faut aussi déployer vite.
Le schéma classique le plus répandu en entreprise repose sur une organisation axée sur des domaines fonctionnels. On va retrouver dans les services informatiques les départements en charge de responsabilités bien identifiées : réseau, DBA, exploitation, sécurité, etc., pire encore : maintenance et support. Ce mode d’organisation regroupe et concentre les expertises, mais ne favorise pas leur mise à disposition. En effet, le mode de communication entre ces services est plus ou moins naturel… Et d’ailleurs souvent moins que plus ! Il prend fréquemment la forme d’échanges indirects, par ouverture de tickets par exemple, ce qui ne présente pas les caractéristiques d’une communication fluide et rapide.
Il faut donc aussi se défaire de ces silos fonctionnels et tendre vers une organisation centrée sur un objectif commun : apporter de la valeur et non réduire les coûts. L’abandon de cette organisation fonctionnelle va donc faciliter la mise en oeuvre de nouvelles approches. Cet abandon s’accompagne d’une incitation à constituer des équipes autonomes, constituées de profils experts certes, mais ayant aussi comme caractéristique d’entretenir une certaine polyvalence. C’est dans cette veine que le concept Devops s’inscrit.
Les risques dans l'interprétation de la loi de Conway
Comprendre la loi de Conway comme une invitation à créer de petites équipes serait bien trop réducteur. S’il ne devait être retenu qu’un seul mot dans cette loi, ce serait communication. Vous souhaitez construire un produit logiciel constitué de composants granulaires plus rapides à développer (puis faire évoluer), dotez vous d’une organisation qui se calera sur cet objectif, en définissant des équipes dédiées aux composants, depuis leur création et jusqu’à leur maintien (au sens MCO). Vous souhaitez que ces composants interagissent et partagent des règles de communication communes, faites en sorte que les équipes partagent aussi un mode de communication du même type. Enfin, vous souhaitez que vos cycles produit soient raccourcis, faites en sorte que la communication sur toute la chaîne dans votre organisation s’y prête.
Ce constat maintenant vieux de près de 50 ans doit rappeler qu’en dépit de tous les efforts possibles en termes d’outillage, de langage, de patterns, etc., une clé essentielle dans la réussite d’un produit est de savoir dimensionner et organiser le dispositif humain en fonction des contraintes du produit et de veiller à ce que cette organisation reste efficiente tout au long de la réalisation.
