Mel Conway a formulé sa célèbre loi en 1967 et c’était une réflexion sur la façon dont les grandes organisations fonctionnent et produisent des résultats. La « version officielle » (telle que publiée par Mel Conway lui-même) est la suivante :
« Toute organisation qui conçoit un système (défini au sens large) produira une conception dont la structure est une copie de la structure de communication de l’organisation. »
Une façon plus informelle de dire cela peut être de dire que « les voies de communication dans une organisation déterminent la structure du système qu’elle conçoit », ou encore de simplifier encore davantage que « la structure d’une organisation détermine la structure du système qu’elle conçoit. «
Quoi qu’il en soit, la loi de Conway nous dit que parce que la conception de systèmes complexes est une tâche complexe, il est inévitable que la façon dont ils sont conçus (en considérant le processus de conception comme une tâche collaborative) détermine la conception qui est produite.
Il y a eu des travaux pour tester cette hypothèse dans la nature, mais actuellement, il n’y a aucune « preuve scientifique » que cette loi détient. Cependant, beaucoup pensent qu’il a un certain mérite. Faute de preuves formelles, il appartient à chacun de décider par lui-même s’il pense que le bas tient. Mais à tout le moins, cela peut servir d’inspiration et nous permettre de réfléchir aux interdépendances entre les processus de conception et les résultats de conception.
Que signifie la loi de Conway pour les API
La loi de Conway parle généralement de processus de conception complexes, et il semble relativement simple de l’appliquer à l’espace API. Nous pouvons considérer les paysages d’API comme ce qui est en cours de conception, et les organisations sur leurs parcours d’API comme celles qui font la conception. Ce qui nous donne alors directement l’image d’une organisation complexe (et structurée) en tant que concepteur de système et du paysage API en tant que système conçu.
Dans un paysage plus classique d’équipes importantes et très enchevêtrées, nous avons obtenu, par conséquent, des monolithes avec de nombreuses dépendances internes, et ces monolithes ressemblent à la structure de l’état d’esprit et de l’organisation informatique qui les a produits.
Au lieu de délimiter clairement et proprement les composants de conception et de les développer en tant que produits encapsulés, il y avait beaucoup d’« éléments partagés » (comme tout le monde accédant directement aux bases de données) et, par conséquent, souvent, la base de code monolithique aurait des dépendances nombreuses et très complexes, ce qui rendait difficile le changement de pièces isolées sans affecter potentiellement beaucoup d’autres.
L’histoire du monolithe se traduit directement dans l’espace API. Les dépendances complexes et les abstractions manquantes étaient parfois directement traduites en API, résultant en des «API système» qui étaient simplement des API génériques d’accès à la base de données, couplant ainsi étroitement les détails de mise en œuvre d’un côté (le schéma de la base de données) aux consommateurs devant en connaître tous les détails.
Dans l’espace API, la meilleure approche est généralement de réfléchir aux raisons pour lesquelles l’accès à la base de données peut être nécessaire (« nous avons besoin d’accéder aux données des clients »), de réfléchir au type d’accès nécessaire (« voici les choses que nous voulons faire avec les données client »), puis de concevoir une API autour de cela (« voici une API qui vous permet de faire ce que vous voulez faire »).
Maintenant, nous avons des composants couplés plus lâchement, la gestion des clients peut être modifiée et améliorée sans affecter les consommateurs d’API, et les consommateurs d’API obtiennent des abstractions significatives avec lesquelles ils peuvent facilement travailler.
Si vous organiser d’une certaine manière prédétermine les résultats, alors obtenir ces API pas si bonnes est une conséquence inévitable des organisations traditionnellement structurées. Une conséquence intéressante de ceci est que si vous vous réorganisez structurellement, cela devrait signifier que ce que vous concevez maintenant commence à avoir l’air différent en raison de cette structure organisationnelle modifiée. Cette façon de penser nous amène à la deuxième façon d’utiliser la loi de Conway.
La « manœuvre de Conway inversée »
La « manœuvre inversée de Conway » tire son nom du fait qu’au lieu d’observer le résultat d’un processus de conception, vous essayez de changer le résultat attendu en modifiant la structure organisationnelle. Cependant, il convient de noter qu’il ne s’agit toujours que d’une application de la loi de Conway, c’est-à-dire qu’elle n’est pas inversée, et en fait, Mel Conway a déclaré qu’il n’était pas en faveur de cette étiquette spécifique.
De nombreuses organisations suivent aujourd’hui cette voie en adoptant des méthodes agiles et en se réorganisant en équipes plus petites et axées sur le domaine avec plus d’autonomie. Et dans une certaine mesure, on pourrait soutenir que ce que beaucoup de ces organisations recherchent, c’est exactement la loi de Conway : ils veulent un système mieux modulaire afin qu’il puisse être modifié plus facilement et plus rapidement.
D’une manière générale, il semble que cette manœuvre fonctionne le plus souvent. Et les API jouent un rôle crucial à cet égard, car idéalement, les équipes les utilisent comme principal mécanisme de collaboration, ce qui signifie que les chemins de communication des équipes sont désormais identiques à la structure du système conçu.
Mais cela signifie également que la structure de l’organisation devient absolument essentielle pour bien fonctionner, car si elle n’est pas bien structurée, cela se traduit par un système qui n’est pas non plus bien structuré.
Des méthodes telles que Cartographie des capacités commerciales (BCM) devenu encore plus important qu’avant. Dans l’ancien monde, il était plus facile de « pirater » les choses parce que le système monolithique signifiait qu’il n’y avait pas de barrières à l’intérieur. Dans le nouveau monde, lorsque les capacités ne sont pas modélisées en fonction des besoins de l’entreprise, les besoins de l’entreprise ne peuvent pas non plus être satisfaits facilement en utilisant l’API d’une capacité.
Ce que cela montre, c’est que l’utilisation de la loi de Conway peut être très puissante, car vos chances d’obtenir une conception bien structurée peuvent être « piratées » par des changements organisationnels. Mais cela montre également qu’il est essentiel de bien faire ces changements organisationnels.
Conclusion
En résumé, la loi de Conway nous enseigne deux leçons importantes : la première leçon est que peu importe vos efforts, vous ne pouvez pas concevoir un système complexe qui présente une certaine structure à moins d’aligner votre organisation en conséquence.
La deuxième leçon est que si vous vous réorganisez en une structure plus modulaire pour produire un meilleur résultat, il devient extrêmement important de vous assurer que la structure organisationnelle s’aligne sur la structure des objectifs du système que vous construisez.
Si vous êtes intéressé par plus de détails sur la loi de Conway et comment elle crée une relation directe entre la structure organisationnelle et une conception structurée, veuillez regarder la vidéo suivante.