Une révolution organisationnelle majeure est en cours. Après le retour d’expérience de Pôle Emploi sur SAFe® dans le cadre de l’agilité à l’échelle, intéressons-nous de plus près au concept de la Révolution conwaylicienne inverse.
Un truc de geek ?
Le 20 mars 2018, un email1 de Satya Nadella à tous les employés de Microsoft fait passer la Loi de Conway du statut de "truc de geek" à celui de principe de sociologie des organisations. Il conclut l’annonce d’une réorganisation majeure de la société - dont la subite disparition du Département Windows ! – par la nécessité stratégique de dépasser cette fameuse loi.
Cinquante ans plus tôt, lors d’un congrès sur la programmation modulaire, Melvin Conway annonce : "les organisations qui conçoivent des systèmes sont contraintes de produire des architectures qui reflètent leurs propres structures de communication".
En clair, une organisation fortement hiérarchique ne peut concevoir que des produits hiérarchiquement organisés, un projet réparti sur quatre équipes proposera quatre modules distincts, etc. Depuis, plusieurs études sérieuses ont confirmé cette affirmation visionnaire.
Concevoir l’agilité
Aujourd’hui, les exigences d’agilité dans les organisations et les systèmes sont devenues stratégiques. Tout change tout le temps, mais pas toujours au même moment. Un système n’est donc agile que s’il est possible de le faire évoluer par morceau. Il est d’autant plus agile que les morceaux sont plus petits et qu’ils sont faiblement couplés entre eux.
Une lecture inversée de la Loi de Conway suggère que pour concevoir un système agile, il faut que les équipes soient elles-mêmes organisées en petites unités autonomes, focalisées sur leur périmètre, et qu’elles sachent collaborer ponctuellement avec d’autres équipes suivant des modalités définies.
On pensera alors aux directives2 imposées en 2002 par Jeff Bezos aux développeurs d’Amazon :
- Toutes les équipes exposeront leurs données et fonctionnalités sous forme de service
- Les équipes communiquent entre elles via ces services
- Aucune communication inter-processus n’est permise autre que les appels de service
- Les équipes utilisent les technologies qu’elles souhaitent
- Tous les services sans exceptions doivent être conçues pour être externalisables
- Toute personne qui n’applique pas ces règles sera renvoyée
- Merci et bonne journée !
Connaissant leur patron, aucun développeur d’Amazon n’a pris au sérieux le point 7. Pour le reste, ils ont appliqué scrupuleusement ces directives et ont aussi bâtît une des premières et des plus importantes entreprises "de plateforme" pour laquelle les perspectives de diversification et de croissance se sont révélées illimitées.
Faut-il recoller les morceaux ?!
L’adage suivant lequel "un système est plus que la somme de ses parties" signifie que la coopération des parties au sein du système fait émerger des propriétés qui n’existent dans aucune des parties mais qui sont quand même proposées par le système.
Dans l’univers du Besoin, l’architecte d’entreprise va identifier, organiser et prioriser les propriétés du système - les capacités, les fonctionnalités - que l’on souhaite voir émerger. Il va assister le représentant du Métier (le Product Owner) à la définition des objectifs et de la couverture fonctionnelle, à leurs inévitables évolutions au court du temps et donc à la gestion du backlog global.
Dans l’univers de la Solution, l’architecte d’entreprise va s’assurer que le périmètre de chaque équipe est bien défini ainsi que les points d’articulations afin que l’ensemble des équipes partage les mêmes objectifs et priorités. Ce noyau d’architecture (Minimum Viable Architecture) va s’enrichir pour qu’à chaque sprint le système livre les capacités et les fonctionnalités attendues.
Cette architecture intentionnelle évolue au fil des arbitrages avec les propositions des équipes (appelées l’architecture émergeante) pour former la Piste d’architecture.
Garant de l’intégrité du référentiel d’architecture (ou Solution Intent3 dans SAFe), l’architecte d’entreprise trace les décisions sur l’état du Besoin et de la Solution en fonction des priorités et de la criticité du système.
Avec l’agilité à l’échelle, l’architecte d’entreprise va devoir faire encore plus d’architecture, et de façon toujours plus dynamique et coopérative.
Toute révolution est un changement. Tout changement présente des risques et des opportunités. Les architectes d’entreprise qui choisiront de rester dans leur tour d’ivoire ne connaîtrons que les risques.
Les autres deviendront des architectes d’entreprise agiles. Cela sera passionnant mais pas toujours simple. Alors, aidons-les !
1 : Embracing our future: Intelligent Cloud and Intelligent Edge
https://news.microsoft.com/2018/03/29/satya-nadella-email-to-employees-embracing-our-future-intellig...
2 : The Secret to Amazons Success Internal APIs
https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
3 : SAFe, Solution Intent
https://www.scaledagileframework.com/solution-intent/
