Ce que vos pipelines disent de votre structure organisationnelle

L’une des « lois » associées à DevOps appartient à un programmeur nommé Melvin Conway. Sa loi a été introduite en 1967 et stipule simplement que « les organisations qui conçoivent des systèmes… sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations ».

J'ai souligné le mot « systèmes » car trop souvent la loi de Conway s'applique uniquement aux applications. Aux systèmes logiciels. Mais la réalité est que les « systèmes » englobent tout, depuis les applications jusqu’aux pipelines intégrés qui les fournissent et les déploient. Vos canalisations.

Lorsque nous parlons d'adopter les méthodologies DevOps du côté du déploiement (c'est-à-dire de la production), nous devons également être conscients des principes associés comme la loi de Conway. Parce que cette loi s’applique à la conception des pipelines de déploiement tout comme aux applications qu’elle met sur le marché.

Vous vous souvenez peut-être de deux questions posées dans notre rapport sur l’état des services application de 2019. La première question concernait la structure organisationnelle de l'informatique : opérations combinées, fonction unique ou équipes interfonctionnelles. Nous avons constaté que près de la moitié (46 %) des plus de 2 000 répondants étaient organisés en équipes à fonction unique. Les opérations combinées arrivent en deuxième position avec 37 %. Les équipes interfonctionnelles sont moins courantes, avec seulement 15 % des répondants opérant dans de telles structures.

C’est désormais important alors que nous examinons l’état de l’automatisation du pipeline de déploiement. Car les résultats sont bien le reflet de la domination des équipes monofonctionnelles.

Les données présentées ici montrent un effort d’automatisation incohérent qui ne va pas aider à atteindre l’objectif de près de la moitié (48 %) des répondants en matière de transformation numérique , à savoir déployer des applications plus rapidement et plus fréquemment. La disparité entre ces domaines établis au sein de l’informatique est la preuve existentielle que la loi de Conway s’applique à n’importe quel système, n’importe où.

En creusant plus profondément, nous constatons qu'un peu plus d'une personne sur dix (11 %) n'a automatisé qu'un seul de ces domaines. Une personne sur quatre (25 %) a réussi à automatiser deux ou trois domaines. Et un peu plus d’un sur cinq (21 %) a automatisé les quatre domaines principaux nécessaires pour réaliser un pipeline de déploiement automatisé .

Un pourcentage significatif - 42 % - n'a automatisé exactement ZÉRO de ces domaines.

L’inégalité de l’automatisation dans le pipeline de déploiement est un élément important du puzzle du délai de rentabilisation, car chaque fois que vous rencontrez un processus manuel dans le pipeline, vous subissez un retard. Ce délai ralentit le délai de valorisation (ou le délai de mise sur le marché, si vous préférez). Les différences de taux montrent l’impact des organisations restant dans une « structure d’équipe à fonction unique » parce que nous voyons des « silos » individuels automatisés avec peu ou pas d’attention à la façon dont ils interagissent avec le reste du pipeline.

C’est pourquoi les opérations combinées ou les structures d’équipe interfonctionnelles sont privilégiées. Parce que les canaux de communication entre les domaines informatiques deviennent un processus homologue qui facilite davantage la conception d'un système couvrant plusieurs préoccupations. Lorsqu'un pipeline (système) est conçu par une équipe, celle-ci est en mesure de prendre en considération le pipeline dans son ensemble plutôt que comme ses éléments composites.

Le travail d’automatisation lui-même pourrait être (et devrait probablement être) géré par des experts du domaine. Mais la conception globale et les méthodes d'intégration (API) doivent être conçues au sein d'une équipe ouverte et collaborative. Sinon, nous nous retrouvons avec des silos d'automatisation qui peuvent ou non servir l'objectif commercial d'arriver sur le marché plus rapidement et plus fréquemment.

Donc, si vous rencontrez des retards ou des détours dans vos tentatives d'automatisation des pipelines de production, prenez du recul et considérez les structures organisationnelles en place et leur impact sur la conception de ce pipeline. Vous constaterez peut-être qu’avant de pouvoir automatiser efficacement quoi que ce soit, vous devez faire pression pour mettre en place des structures organisationnelles plus efficaces pour soutenir l’effort.