Pourquoi et comment créer cette « chaine de confiance continue » ?
Au cours des dernières années, l’arrivée d’une nouvelle vague d’acteurs du numérique a mis l’accent sur le rôle stratégique de la technologie et du SI comme catalyseurs de la croissance des métiers de l’entreprise. Face à ce nouveau contexte, les organisations ont lancé de nombreuses initiatives de transformation afin de positionner la DSI au centre des enjeux d’innovation et au cœur de leurs stratégies de leurs produits métiers.
La fonction SI n’est donc plus seulement perçue comme un moyen pour décliner la mise en œuvre des processus métiers. La DSI se retrouve désormais partenaire dans la création de valeur métier par sa capacité à dégager de l’information pertinente, à créer des nouvelles expériences pour les clients et à flexibiliser l’accès aux ressources informatiques.
Dans ce contexte de disruptions constantes, les entreprises cherchent par tous les moyens à gagner en agilité et à améliorer le time-to-market de leurs produits tout en maintenant la sécurité et la performance au cœur de leur stratégie produit. C’est là qu’on pense « naturellement » au DevOps ! Aujourd’hui, les entreprises sont sensibilisées aux bienfaits du DevOps comme mouvement visant à mieux travailler ensemble pour gagner en productivité et « réussir une dizaine de déploiements par jour ». Mais pour bénéficier au maximum des effets de leviers et aller vers le DevOps à grande échelle, il faut nous inspirer des pratiques des GAFA.
Dans cet article nous présenterons nos convictions pour une mise en place du DevOps réussie et en profondeur. Nous avons pour habitude de regrouper nos convictions en quatre piliers : Une approche produit au cœur de la transformation, un modèle opérationnel en adéquation avec les ambitions, un parcours d’accompagnement « chacun son rythme » et la mise en place des plateformes DevOps intégrées au cycle de vie des produits
Une approche produit au cœur de la transformation
Avec la prise de conscience de l’importance du Time-to-Market, les équipes commencent à mettre en service rapidement les premières versions en service et les améliorent au fur et à mesure. Mais alors qu’en sera -t-il de la deadline du projet ? Pour nous, le fameux triangle « Qualité – Coût – Délai » est remplacé par « UX – Valeur – Capacité à faire ».
En pratique, passer d’une approche projet à une approche produit nécessite une démarche profonde d’architecture et de changement de culture d’entreprise.
Afin d’accélérer cette phase, nous conseillons vivement de se baser sur un référentiel connu et de partager une définition commune d’un produit en illustrant avec des exemples connus de tous.
Prenons « SAFe » par exemple, un cadre de mise à l’échelle des pratiques AGILE, qui permet de partager une définition claire et précise avec des réussites dans la mise en place dans plusieurs entreprises.
Une fois une définition posée et partagée par tous, la démarche de « découpage » du SI en produit doit s’aligner sur la perception des utilisateurs et de leurs usages réels. Donc la mise en place de ce portefeuille de produit DSI doit obligatoire se faire avec les sachants métiers et SI. Voici deux exemples de démarche complètement différentes que nous pouvons partager avec vous :
- Approche Top-Down :
- On part de l’identification des fonctionnalités utilisateurs qu’on regroupe par produit logique en fonction des usages
- On définit les composants SI qui permettent de livrer le produit logique final
- En fonction des dépendances entre composants, de la taille des composants, de leurs stabilités et des responsabilités existantes, on définit les produits par équipe
- Approche Bottom-Up :
- On procède par équipe à des ateliers de « team proposition value » afin de construire leur référentiel de produits
- On consolide les informations et on partage de nouveau avec l’ensemble des parties prenantes et on met en avant les dépendances
- On travaille ensemble sur ces dépendances afin de les limiter au maximum
- Approche Top-Down :
Passer de l’approche projet à l’approche produit nécessite plus qu’un changement méthodologique. L’ensemble de l’organisation sera touché entrainant un changement d’état d’esprit de toutes les parties prenantes.
Un modèle opérationnel en adéquation avec les ambitions
Une transition vers DevOps sans le volet organisation n’est pas une transition vers le DevOps !
Le DevOps impose le passage du modèle cloisonné par projet et par domaine d’intervention (Conception, Build, Run) vers un modèle avec une approche par produit avec un responsable produit où l’équipe est responsable de l’ensemble du cycle de vie.
Attention à ne pas tomber dans une application trop dogmatique ou systématique qui pourrait être faite de cette définition.
Les modèles opérationnels ne sont principalement que des moyens pour atteindre des cibles définies. Ainsi ils seront amenés à évoluer en fonction d’elles et devenir un vecteur d’accélération du time-to-market de l’atteinte de la cible. En fonction de la maturité de l’organisation et de ses ambitions, il faut définir un point de départ et un point d’arrivée pour le modèle opérationnel. Les étapes de transition doivent se faire naturellement avec la montée en maturité de l’organisation et la montée en autonomie des équipes.
Si nous prenons en exemple cette synthèse ci-dessus, nous nous sommes accordés, au début de la transformation, sur le fait qu’une équipe DevOps était une équipe autonome sur l’intégralité du cycle de vie de son portefeuille de produit. Arrivés à un certain stade, nous avons estimé nécessaire de faire une « pause » à durée indéterminée afin de capitaliser sur les succès, partager les pratiques, s’approprier la nouvelle culture d’entreprise et construire une nouvelle roadmap de montée en maturité.
En synthèse, notre cible a été trop ambitieuse et le risque de « fatiguer » l’organisation se faisait de plus en plus ressentir.
Ainsi le changement d’organisation vers un modèle DevOps demande beaucoup d’efforts selon la maturité et les aspirations de chacun. L’accompagnement se doit d’être personnalisé pour que chacun avance à son rythme mais la mesure de la performance doit être globale afin de rassurer les parties prenantes sur les directions prises.
Un parcours d’accompagnement « chacun son rythme »
Certaines entreprises ont le changement plus facile que d’autres. Il faut réussir à identifier ces facteurs de différences et accorder une importance primordiale à la culture d’entreprise. C’est pour cela qu’une approche d’accompagnement par « petits pas » semble naturellement être une approche à privilégier. À chaque pas, il est important de valoriser les succès pour donner confiance et de mesurer la performance pour se donner une vue systémique de la transformation DevOps.
Pour ce faire, 3 piliers essentiels que nous avons constamment adoptés ou identifiés lors de nos interventions réussies :
- Avoir une approche systémique plutôt qu’une approche ciblée sur une équipe isolée en mobilisant des « champions » de tout bord.
- Permettre un feedback régulier afin d’améliorer la transition de manière continue.
- Créer une culture qui favorise l’expérimentation et la prise de risques
L’approche d’accompagnement au changement ci-dessous nous a permis de déployer un axe de la transformation chez un de nos clients. Ce cadre nous permet de regrouper 3 aspects primordiaux de l’accompagnement au changement DevOps : l’expérimentation, la valorisation du succès, le feedback.
Pour évaluer concrètement les bénéfices du DevOps et ainsi renforcer l’embarquement des derniers réfractaires, il faut prouver qu’on a eu raison d’adopter cette démarche. Ainsi il faut mesurer les bénéfices de la transformation et en faire ressortir le ROI ; nous pouvons voir ci-dessous quelques indicateurs qui permettront de rapidement mettre en place un premier système de mesure.
Il ne faut surtout pas avoir de réticence de voir ces indicateurs fluctuer au début de la transformation car tout est basé sur l’expérimentation qui doit être valorisée et les échecs acceptés. Il s’agit donc de mesurer l’impact de chaque action d’amélioration et de réajuster la trajectoire si besoin.
Ces indicateurs permettront ainsi d’identifier rapidement les principaux freins à la transformation qu’ils soient technologiques ou organisationnels. Dans les solutions qu’on s’empresse d’adopter, il y en a deux que nous rencontrons sur toutes nos interventions :
- La mise en place des plateformes DevOps afin d’accélérer le time-to-market tout en sécurisant le déploiement
- La modernisation des applications afin d’accélérer l’adoption du DevOps et ainsi bénéficier pleinement des apports du DevOps
La mise en place des plateformes DevOps intégrées au cycle de vie des produits
La mise en place d’une plateforme CI/CD (d’intégration et de déploiement continue) est la colonne vertébrale d’une approche DevOps. Communément appelée « pipeline de déploiement », elle compile, déploie, teste et livre l’application en continu jusqu’en production. Elle requiert d’automatiser la majeure partie des tests, la gestion de la configuration, les environnements… C’est un des enjeux principaux du DevOps.
Le degré d’automatisation visé dépend des besoins de réduction du cycle de fabrication et des contraintes de qualité, de sécurité et de règlementations propres aux produits. Plus le livrable est petit, meilleure est la maîtrise des potentielles erreurs et plus vite on se rassure de la viabilité de la pipeline de déploiement.
La notion de petite livraison est liée au mode de fonctionnement itératif de la méthode Agile :
- L’objectif est d’embarquer le code source d’une feature en cours de développement jusqu’au déploiement en production sans l’activer directement pour l’utilisateur
- Une fois la feature opérationnelle et disponible en production, l’activation et la désactivation en production sont « censées être » des opérations simples ne nécessitant ni geste technique ni déploiement
Attention néanmoins aux freins qui peuvent se présenter concernant l’adoption de cette approche :
- Mise en œuvre difficile dans un environnement non agile et/ou présentant une architecture applicative non orientée services
- Changement profond de culture du fait qu’une mise en production peut engendrer des erreurs (fail fast, learn fast)
Une autre difficulté qu’on identifie régulièrement au niveau de la pipeline est située au niveau des choix technologiques. D’après notre expérience, les solutions sont nombreuses et les bénéfices équivalents, alors comment choisir les solutions les plus adaptées aux problématiques de vos entreprise ?
Lors de nos interventions, on favorise toujours la culture de l’outillage au service du contexte et de l’optimisation des processus.
Faut-il mettre en place une plateforme partagée pour plusieurs produits ou bien une plateforme sur mesure pour un produit ? Au cours de nos interventions chez nos clients, nous avons constitué un premier pattern (à alimenter lors de nos prochaines interventions) afin d’aider au choix pour :
La modernisation des applications pour accélérer la transition DevOps
Une fois toutes les idées en place, on peut très rapidement se lancer en se disant que c’est facile de livrer des « petits packages » et limiter les dépendances… mais encore faut-il que l’architecture de votre SI vous le permette.
Souvent, lors des démarches de transformation, nous ne partons pas d’un « green field ». L’embarquement du legacy et sa transformation constituent un enjeu important pour ces organisations qui se lancent dans la transformation DevOps. Cela nécessite dès lors un découplement de leur travail pour plus d’efficacité et donc d’utiliser des architectures applicatives plus modulaires. On en revient ainsi à notre tout premier point : l’approche produit même au niveau de l’architecture du SI.
Pour faire simple et efficace, deux approches s’imposent pour nous :
- Les nouveaux produits sont tous conçu avec une approche « DevOps first » : la conception d’applications DevOps First nécessite de renforcer les tests réalisés et de prendre plus de risques pendant les mises en production. Cela signifie une évolution des méthodes de développement et l’introduction de nouvelles démarches comme le « Feature Flipping » ou le « Blue-Green Deployment » pour mettre en production, partiellement ou de façon ciblée, certaines fonctionnalités.
- Les produits existants sont sans exception évalués pour se fixer rapidement en termes d’ambition sur la modernisation technologique des produits. L’objectif de cette démarche est d’avoir un portefeuille de produits le plus modulaire possible afin de limiter les dépendances et d’améliorer le sentiment de responsabilité tout au long du cycle de vie au sein des équipes. Certaines applications seront modifiées afin d’avoir cette logique produit, d’autres seront simplement conservées en l’état. On sera forcément amené à piloter l’organisation comme flotte de bateaux où chacun bateau va à sa propre vitesse mais tous collaborent.
Attention à la culture de votre entreprise et de l’éligibilité des produits pour vos premières expérimentations afin d’éviter des échecs rapides et décourageants
S’il est aujourd’hui impératif pour les entreprises d’être plus agiles, de déployer plus vite et de manière plus sécurisée, les pratiques DevOps à mettre en œuvre n’en ont pas moins des impacts profonds sur les DSI.
Mais nous avons la conviction profonde que malgré les difficultés d’une telle transformation, la promesse faite par les pratiques DevOps justifie largement les moyens à mettre en œuvre. Attention tout de même à mettre les moyens de manière réfléchi afin de ne pas entrainer le désengagement et l’absence de sens au sein des équipes BizDevOps.
C’est pour cela qu’il faut vraiment faire attention au démarrage du programme de transformation. Investir dès le début sur les produits qui feront du programme un succès et entamer la naissance des premiers champions DevOps à travers des premières expérimentations réussies : il s’agit avant tout de légitimer la transformation, trouver les bons sponsors et enlever rapidement quelques épines du pied !
Il faut donc adopter les pratiques présentées dès maintenant mais progressivement, en « test & learn », en s’inspirant des pratiques des GAFA. Cela requiert un changement d’état d’esprit : il faut être orienté résultat et les mesurer en continue, penser produit et non plus projet et donc s’approprier la valeur produite, faire des pas plus petits mais en plus grand nombre pour éviter des changements de directions impossibles. C’est un changement profond qui se fera plus ou moins rapidement selon les organisations et leur capacité à se transformer.
