Le DevOps peut aider à mettre les applications en production de manière rapide et soutenue, mais ce n’est pas ce qui fait le succès d’une telle collaboration. Le succès se traduit par la qualité des décisions prises, et pour atteindre cette qualité, les équipes IT doivent être libres d’agir de la manière la plus autonome possible.

C’est la position de Mark Schwartz, stratège entreprise chez Amazon Web Services, auteur de “A Seat at the Table : IT Lesadership in the Age of Agility“, et ancien DSI du gouvernement fédéral. Dans sa keynote lors du récent DevOps Enterprise Summit, il a fait remarquer que les meilleures initiatives de DevOps sont celles qui visent à atteindre des objectifs et non des exigences. Trop d’équipes IT sont contraintes de répondre aux exigences d’un cas d’usage métier, alors qu’elles devraient être libres de poursuivre des objectifs globaux.

Et si les exigences n’étaient pas les bonnes ?

C’est l’essence même de l’agilité et de la flexibilité. Des équipes travaillant sur le terrain avec les utilisateurs finaux des entreprises, sans être entravées par des décisions centralisées de l’entreprise. “Avec la façon traditionnelle de prendre des décisions d’investissement, vous traduiriez les objectifs en une série d’exigences, puis vous mettriez toutes ces exigences dans un cas d’usage business, et ensuite vous essaieriez de les exécuter” explique M. Schwartz.

“C’est un peu étrange si l’on y réfléchit, parce que l’ajout de ces exigences augmente en fait le risque pour le projet. Vous avez maintenant ajouté le risque que vos exigences ne soient pas les bonnes.”

En s’accrochant à ces exigences, “vous avez aussi lié les mains des personnes innovantes que vous voulez voir penser à de bonnes solutions” poursuit-il. Chez AWS, dit-il, “au lieu de créer des exigences, nous avons simplement pris ces objectifs et les avons transmis directement aux équipes. Ainsi, nous avons créé une équipe qui était une équipe interfonctionnelle – elle comprenait des développeurs, des responsables des opérations et de l’infrastructure, des testeurs, des responsables de la sécurité et des responsables opérationnels.”

En définitive, estime Schwartz, “l’important est de réaliser que la réduction de la durée des cycles n’est pas de faire les choses plus vite. Il ne s’agit pas de la rapidité, mais de la qualité des décisions. Quand vous mettez du DevOps dans une entreprise, il ne s’agit pas seulement de la rapidité avec laquelle vous pouvez mettre vos produits sur le marché – bien que ce soit important -, mais de savoir comment votre organisation centrale peut conserver un bon contrôle, et prendre de bonnes décisions quand tout va très vite dans le contexte commercial et dans le processus DevOps.”

Dans l’IT, assurer le fonctionnement ouvre la voie à l’innovation

Schwartz a également cherché à dissiper l’idée répandue selon laquelle il y aurait une différence entre dépenses IT de maintenance et dépenses d’innovation. “Le mythe selon lequel notre budget IT comporte deux types de coûts existe dans la communauté IT depuis un certain temps déjà.”

“Nous avons des coûts de maintien en condition opérationnelle et des coûts d’innovation, et nous disons tous que l’innovation est le domaine où nous voulons dépenser notre argent ; la maintenance n’est pas ce pour quoi nous voulons dépenser notre argent. Je ne suis pas d’accord. Je pense qu’une grande partie de ce que l’on appelle “maintenir les lumières allumées “, est en fait du travail d’innovation. En fait, c’est ce qui fait progresser l’entreprise ; c’est ce qui fait évoluer les systèmes IT pour qu’ils restent conformes aux besoins de l’entreprise.”

Le logiciel n’a pas besoin d’être entretenu “comme il faut entretenir une voiture pour qu’elle continue à fonctionner comme elle l’a toujours fait” considère Schwartz. “Le logiciel continue à faire exactement ce qu’il faisait quand vous l’avez acheté. Vous n’avez pas besoin d’y mettre de l’argent pour qu’il continue de le faire. Le problème, c’est que vous ne voulez jamais que le logiciel continue à faire ce qu’il faisait quand vous l’avez acheté. Vous voulez continuer à le changer à mesure que votre entreprise change. Ainsi, les dépenses de maintenance ou d’entretien sont en grande partie liées à la décision d’utiliser le bon logiciel et d’y apporter les modifications nécessaires.”

Article “DevOps should be about good decisions, not faster cycle times” traduit et adapté par ZDNet.fr

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.