À l’époque, la Harvard Business Review a rejeté son article original en se basant sur le fait qu’il n’avait pas prouvé son hypothèse. Néanmoins, cette observation est devenue connue sous le nom de loi de Conway, et les expériences collectives de mes collègues et de moi-même ont maintes fois renforcé la vérité de cette affirmation. Mais vous n’avez pas à nous croire sur parole !
Dans « Exploring the Duality between Product and Organizational Architectures », une étude de la Harvard Business School a effectué une analyse de différentes bases de code pour voir s’ils pouvaient prouver l’hypothèse originale de Conway appliquée aux systèmes logiciels. Dans cette étude, les chercheurs ont pris de multiples exemples de logiciels créés pour résoudre le même problème (par exemple, des logiciels de traitement de texte, de gestion financière et de base de données) et ont comparé les bases de code créées par des équipes open source faiblement couplées et celles créées par des équipes fortement couplées. Leur étude a révélé que les équipes de produits, souvent co-localisées et concentrées, créaient des logiciels qui tendaient davantage vers des bases de code monolithiques et étroitement couplées. Alors que les projets open source ont donné lieu à des bases de code plus modulaires et décomposées.
Les organisations ont depuis quelques années compris ce lien entre la structure organisationnelle et les logiciels qu’elles créent, et ont adopté de nouvelles structures afin d’obtenir le résultat qu’elles souhaitent. Netflix et Amazon par exemple se structurent autour de multiples petites équipes, chacune ayant la responsabilité d’une petite partie du système global. Ces équipes indépendantes peuvent s’approprier l’ensemble du cycle de vie des services qu’elles créent, ce qui leur confère un degré d’autonomie plus important que celui dont disposent les équipes plus importantes avec des bases de code plus monolithiques. Ces services, avec leurs préoccupations indépendantes, peuvent changer et évoluer séparément les uns des autres, ce qui permet de mettre les changements en production plus rapidement. Si ces organisations avaient adopté des équipes plus grandes, les systèmes monolithiques plus importants qui auraient émergé ne leur auraient pas donné la même capacité à expérimenter, à s’adapter et, en fin de compte, à garder leurs clients heureux.
Vous pouvez voir des tensions dans vos propres organisations où votre structure et vos logiciels ne sont pas alignés. Vous avez peut-être vu par exemple les défis impliqués lorsque des équipes distribuées essaient de travailler sur la même base de code monolithique. Dans ce cas, les voies de communication auxquelles Conway fait référence sont en contraste avec le code lui-même, où la base de code unique nécessite une communication à grain fin, mais où une équipe distribuée n’est capable que d’une communication à grain grossier. Lorsque de telles tensions émergent, la recherche d’opportunités pour diviser les systèmes monolithiques autour des frontières organisationnelles produira souvent des avantages significatifs.
Dans les Radars technologiques précédents, nous avons souligné la popularité croissante des Microservices, qui sont de plus en plus adoptés par les organisations qui cherchent à améliorer l’autonomie de leurs équipes et à augmenter la vitesse du changement. L’article de Martin Fowler et James Lewis approfondit le sujet, en soulignant le fait que ces architectures permettent aux organisations d’avoir beaucoup plus de flexibilité pour aligner l’architecture de leurs systèmes sur la structure de leurs équipes, afin de s’assurer que la loi de Conway fonctionne pour vous. Dans la prochaine édition du Tech Radar, nous aborderons le reflet de l’influence croissante des microservices, qu’il s’agisse de technologies d’infrastructure comme Packer ou Docker, de l’outil de découverte de services Consul, ou de micro-conteneurs comme le populaire DropWizard ou le tout nouveau SpringBoot. Nous aborderons également l’inverse – les organisations qui modifient la structure de leurs équipes pour s’adapter à leurs systèmes informatiques.
Nous nous attendons pleinement à voir émerger davantage de techniques et de technologies de soutien pour permettre les architectures Microservices, et nous en ferons le suivi au cours des prochains mois. En attendant, si vous voulez en savoir plus, inscrivez-vous au dernier Tech Radar, consultez l’article de Martin et James sur les microservices, ou mon livre chez O’Reilly, Building Microservices.