Les 10 principales erreurs à éviter lors de l’adoption du DevOps

Un directeur des systèmes d’information décide qu’il est temps pour son organisation d’adopter le DevOps. Ils embauchent une équipe de licornes numériques, adoptent une gamme d’outils de pointe et sont déçus lorsque les résultats ne sont pas au rendez-vous. Tous les projets, idées, produits et équipes présentés sont freinés par des normes culturelles, des processus, des infrastructures et des compétences de plus en plus obsolètes. Rien n’est aligné avec les nouveaux modèles opérationnels et technologies introduits, et les licornes numériques–ainsi que leur potentiel–sont prises en otage derrière un barrage. L’organisation est incapable de livrer ses logiciels avec l’agilité et la vitesse nécessaires pour innover et fait alors naufrage.

En cours de route, l’organisation a commis plusieurs erreurs qui se sont avérées fatales à l’adoption du DevOps. 

1. Ne pas avoir obtenu l’adhésion des parties prenantes commerciales, techniques ou de gestion

Le DevOps nécessite un changement complet au sein d’une organisation, et ce changement peut impliquer une réaffectation du pouvoir et de l’influence, le déracinement d’outils de longue date et le retrait d’anciens processus. Un manque d’adhésion de la part de toute partie prenante peut mettre des bâtons dans les roues pendant toute l’opération. L’opposition peut venir du département des finances qui ne comprend peut-être pas le DevOps et sa nécessité, elle peut venir des VP techniques qui sont devenus trop habitués à gérer leur département d’une certaine manière, ou elle peut venir d’ingénieurs qui ne veulent pas apprendre à utiliser de nouveaux outils et processus. La résistance peut provenir de n’importe où, et l’ignorer peut être l’une des plus graves erreurs que les organisations commettent lorsqu’elles essaient d’adopter le DevOps.

2. Ne pas mettre la culture au premier plan 

L’adoption du DevOps est à 80% culturelle; la culture doit donc toujours être traitée en premier. Alors que des outils et des processus avancés peuvent accélérer les pipelines de livraison, les pipelines eux-mêmes sont activés par la générativité culturelle. Le modèle Westrum est souvent utilisé pour évaluer la force d’une culture d’entreprise au sein de trois classifications. Les cultures génératives sont axées sur la performance et se caractérisent par des niveaux élevés de coopération et de confiance. Les cultures bureaucratiques sont axées sur les règles et se préoccupent des règles et des responsabilités. Les cultures pathologiques sont axées sur le pouvoir, basées sur la peur et peu coopératives. La transformation culturelle est un précurseur nécessaire à l’adoption réussie des outils et pratiques DevOps.

3. Formuler ses pratiques DevOps autour d’une pile technologique plutôt que faire l’inverse

Les organisations pensent parfois prendre un raccourci en choisissant des piles technologiques que d’autres ont construites et des outils sur lesquels d’autres ont écrit. Leurs méthodologies sont alors orientées vers ce que leur pile technologique peut faire, et elles finissent par insérer leurs exigences commerciales dans leurs fonctionnalités. En revanche, les organisations qui évaluent et formulent leurs pratiques avant de choisir leurs outils ont la possibilité de réfléchir aux problèmes particuliers qui doivent être résolus. Elles sont capables d’intégrer la veille stratégique dans leurs méthodologies, ce qui signifie que leurs fonctionnalités répondent aux besoins de l’entreprise. Les piles technologiques devraient tourner autour de la culture et des processus plutôt que l’inverse.

4. Décider d’adopter DevOps sans savoir pourquoi

Le DevOps est un voyage, non une destination, mais savoir ce que vous espérez accomplir en adoptant le DevOps simplifiera votre voyage et vous aidera à canaliser vos efforts. Espérez-vous réduire les coûts en augmentant l’efficacité, empêcher une violation de données en améliorant la sécurité avec le DevSecOps ou publier des fonctionnalités plus rapidement? Le DevOps peut aider votre entreprise de différentes manières, mais aligner toutes vos initiatives informatiques autour d’un objectif commun vous aidera à devenir un centre infonuagique d’excellence.

5. Embaucher une licorne DevOps ou une équipe DevOps pour tout faire

Le DevOps n’est pas un rôle qui peut être rempli par une seule personne ou une seule équipe. Cela nécessite de changer les outils, les processus et la culture utilisés par toutes les équipes et tous les individus. Concentrez-vous sur la mise à niveau et la formation des équipes existantes pour qu’elles adoptent les outils et processus DevOps à travers l’organisation au lieu d’isoler les DevOps au sein d’équipes nouvellement créées.

6. Lancer des projets «Agiles» avec trop de paperasserie administrative et de travail en retard

Vos équipes ne peuvent pas être agiles ou innovantes si elles ont trop de paperasse à gérer. Elles ne peuvent pas fournir une valeur commerciale de bout en bout en cycles courts si les tâches de base nécessitent de passer par des cadres réglementaires, tels que l’obtention d’une approbation écrite de la sécurité, du service juridique, des finances ou de tout autre service, avant de tester les hypothèses. Donnez à vos équipes la liberté de pivoter rapidement en cas de besoin en leur permettant d’être auto-organisées et autonomes.

7. Ne pas favoriser une bonne communication entre les équipes commerciales et techniques

Assurez-vous que les équipes techniques ne choisissent pas les outils qu’elles trouvent techniquement intéressants, mais qui ne correspondent pas aux exigences de l’entreprise, et assurez-vous que les parties prenantes commerciales ne choisissent pas des outils qui manquent de viabilité technique à long terme. Le BizDevOps consiste à intégrer les commentaires venant du côté commercial d’une organisation dans ses cycles de livraison de logiciels. Il aligne les cycles DevOps plus étroitement avec les objectifs commerciaux et peut éviter les problèmes de communication entre les équipes.

8. Ne pas tenir compte des dépendances tierces

Les grandes organisations qui ont externalisé des fonctions informatiques de base peuvent avoir du mal à passer à un modèle piloté par API. Les tiers peuvent trouver qu’aider les clients à passer aux architectures infonuagiques natives va à l’encontre de leurs intérêts, car les clients peuvent dépenser moins d’argent et réduire leur dépendance. Lors de l’évaluation de vos pipelines, tenez compte du fait que les dépendances tierces peuvent créer des goulots d’étranglement.

9. Ne pas envisager une feuille de route technologique à long terme

Comme les projets en logiciel libre sont susceptibles de survivre à l’ascension et la chute de divers fournisseurs, ils peuvent soutenir la croissance et l’innovation à long terme nécessaires pour créer des services infonuagiques à l’échelle qui sont fiables, résilients, rentables et sécurisés. Cependant, leur conception, leur test, leur gestion et leur mise à niveau peuvent être complexes. Savoir où vous voulez que votre organisation soit technologiquement dans cinq, voire dix ans vous aidera à choisir des outils en logiciel libre ou commerciaux qui correspondent à votre cas d’utilisation.

10. Ne pas tenir compte de l’impact sur les structures existantes

Bien que les opérations soient traditionnellement responsables de l’infrastructure et les développeurs responsables des applications, le DevOps nécessite l’introduction d’une nouvelle couche de plateforme applicative qui implique un tout nouveau domaine de responsabilité entre l’infrastructure et l’application. Les grandes entreprises avec des structures rigides peuvent trouver cela difficile, surtout si elles doivent contourner les obstacles existants (et parfois douloureusement évidents) et les mauvaises pratiques. Lors de l’architecture d’une plateforme applicative, tenez compte de son impact possible sur les structures existantes. 

Nous sommes en 2020, et le DevOps est une nécessité et non un luxe. Lorsque vous instaurez l’adoption du DevOps dans votre organisation, veillez à ne pas commettre l’une de ces erreurs courantes.

Pour en savoir plus, téléchargez notre livre blanc intitulé «Accélérer la transformation DevOps en effectuant une évaluation de la culture et des procédés».