Plans de déploiement des services d'application influencés par la structure de l'équipe

Les développeurs sont vraiment différents. De par leurs rôles et responsabilités jusqu'à leur placement dans la structure organisationnelle, les développeurs sont souvent le « groupe à part ». Vous ne pouvez même pas nécessairement les inclure dans le terme « informatique », car les équipes de développement oscillent entre faire partie de l'informatique et faire partie de l'entreprise.

Même si DevOps commence à prendre racine en tant que changement culturel, la plupart des organisations restent fonctionnellement organisées dans ce que l’on appelle communément des silos informatiques. Dans notre étude sur l'état des services d'application 2019 , nous avons constaté que près de la moitié des répondants (46 %) étaient toujours organisés en « équipes à fonction unique » du type « Réseau », « Serveur », « Stockage » et « Sécurité ». Plus d’un tiers (37 %) travaillaient dans des équipes d’opérations combinées mieux adaptées à l’adoption et à l’application des principes et des approches DevOps en matière de livraison et de déploiement d’applications. Seuls 15 % travaillaient dans de petites équipes interfonctionnelles basées sur des unités commerciales ou des produits de l’entreprise.

La structure est importante, car elle définit en partie votre objectif et vos priorités. Cela détermine à son tour les paramètres par lesquels le succès est mesuré. Les organisations cloisonnées impliquent des mesures cloisonnées. Nous pouvons le constater dans notre enquête NetOps et DevOps de l’été dernier. Nous avons constaté des différences significatives dans la manière dont les équipes étaient mesurées en fonction de leur structure. Par exemple, les indicateurs les plus courants dans tous les types d’équipes et tous les rôles étaient les suivants :

1. Temps de disponibilité du réseau (60 %)
2. Temps de disponibilité des applications (56 %)
3. Optimisation des processus (40%)
4. Délai moyen de résolution (39 %)

Mais lorsque nous décomposons cela et examinons les mesures basées sur les types d'équipes, nous constatons que plus l'équipe est collaborative, c'est-à-dire plus elle est performante. De type DevOps, la structure d'une équipe évolue en fonction des priorités. 

Maintenant, comment les mesures par lesquelles vous êtes évalué sont-elles liées aux services d’application ? En fait, beaucoup.

Si votre objectif principal est la disponibilité du réseau, vous allez travailler dans ce sens et déployer des services qui répondent à cet objectif. Il en va de même pour la disponibilité des applications. Si c’est votre priorité, vous prendrez les services de disponibilité beaucoup plus au sérieux que les personnes évaluées en fonction de la fréquence de déploiement.

Nous pouvons constater l’impact d’une base de répondants composée en grande partie d’une « équipe à fonction unique » dans les plans de déploiement des services d’application dans notre recherche. Cela devient plus évident lorsque nous catégorisons les services d'application en fonction de ce qu'ils fournissent aux applications : sécurité, performances, identité/accès, disponibilité et mobilité. 

Ces résultats reflètent l’impact des mesures d’équipe à fonction unique. Les développeurs se préoccupent principalement de la disponibilité (qui inclut souvent des objectifs de performances spécifiques) et prévoient de déployer les services d’application qui prennent en charge à la fois la disponibilité et les performances. De même, les NetOps se concentrent sur les services d’application qui prennent en charge la disponibilité du réseau en optimisant, en mettant à l’échelle et en protégeant les protocoles réseau sur lesquels les applications s’appuient. 

La structure de l’équipe est importante. Non seulement en raison de la nécessité d’encourager une culture plus collaborative, mais aussi en raison de la manière dont elle impacte les décisions, y compris les choix technologiques. La diversité des objectifs peut conduire à des frictions et à des frustrations. C'est l'une des raisons pour lesquelles nous voyons des services d'application tels que l'équilibrage de charge, traditionnellement déployés et exploités par NetOps, être arrogés par DevOps et déployés dans le cadre de l'application. Parce que dans les organisations dotées de structures d’équipe à fonction unique, la disponibilité des applications est une priorité pour les développeurs, mais pas pour NetOps.

Pour vraiment capitaliser sur DevOps, les structures d’équipe – et les indicateurs par lesquels elles sont mesurées – doivent évoluer vers des modèles plus collaboratifs et s’éloigner des équipes traditionnelles à fonction unique.

Parce que les silos appartiennent aux fermes, pas à l’informatique.