Sommaire

Rôles

1. Les équipes de composants et de fonctionnalités

En 1968, Melvin Conway publie dans le magazine Datamation un article qui montre comment une organisation se met en place et comment elle vient calquer sa structure avec celle du système qu’elle produit [Conway 1968] ; cet article est à l’origine de ce qui est appelé la "loi de Conway" :

« Les organisations qui conçoivent des systèmes […] sont contraintes de produire des designs qui sont des copies de la structure de communication de leur organisation. »

Les raisons de la présence de ces équipes de composants sont dues à des barrières telles que [Leffingwell 2018] :

  • la connaissance technologique - tel module est écrit en COBOL, Fortran…

  • des informations liées à la sécurité - tel autre module permet d’accéder à des informations confidentielles et seule cette équipe peut être habilitée,

  • des contraintes de réutilisation - un module donné est tellement utilisé que si n’importe qui vient le modifier sans en mesurer les impacts, il peut planter toute l’organisation,

  • la complexité sous-jacente d’un composant - les algorithmes utilisés ou la dette technique accumulée ont rendu le code particulièrement illisible, sauf pour les développeurs historiques.

Voici quelques problèmes liés à une organisation basée ...