Petit pense-bête pour une transformation DevOps réussie
Si on peut reconnaitre au cloud computing d'avoir été un outil central consacrant la démarche DevOps de nombreuses organisations, beaucoup hésitent encore à franchir le pas en se bornant à l'utilisation de certains outils sans engager une démarche en profondeur, c'est à dire organisationnelle et culturelle. Et c'est pourtant là que se situe la clé d'une transformation réussie.
Des outils vers la culture
Tout a commencé un beau matin devant la machine à café, lorsque le directeur financier à croisé le chemin du DSI. "Elles nous coûtent cher vos machines, n'y aurait-il pas un moyen de rationnaliser un peu notre parc ?". C'est souvent comme ça qu'une société s'oriente vers le cloud. Si l'argument est pertinent et sérieux, il ne doit cependant pas rester le seul dans la balance. Une migration vers un cloud public implique des contraintes opérationnelles et organisationnelles que tout bon DSI se doit d'avoir en tête. L'utilisation d'outils modernes implique tôt ou tard à l'organisation d'adapter ses pratiques, sa manière de communiquer, sa manière de livrer du code, sa manière d'itérer un projet, sa manière de livrer le client final, sa manière de mesurer sa performance... le tout en assurant une continuité de l'activité. Si vous vous êtes posés ces questions, bravo, vous venez d'initier la mutation DevOps de votre organisation.
L'adoption de nouveaux outils, de nouveaux processus métier se fait souvent dans la douleur. La conduite du changement doit être maîtrisée, expliquée, et l'entreprise doit en tirer un bénéfice compris de tous. Le principal intérêt d'engager une démarche devops est de fluidifier son organisation en systématisant et donc en engageant une démarche qualité de bout en bout, sur l'ensemble du workflow.
Repenser ses processus métiers
Repenser son architecture est une chose, repenser ses processus métiers en est une autre et c'est pourtant tôt ou tard inéluctable pour gagner en efficacité et tirer le meilleur profit possible d'une architecture moderne. Il faut dans un premier temps bien comprendre d'où l'on part. Par exemple, si on est une banque dont le métier repose sur une architecture mainframe avec des process très rigides, il est impératif de comprendre que les efforts à fournir vont être colossaux pour tendre à plus d'agilité, pouvant mener à une organisation collaborative plus adaptée à une architecture moderne. La culture devient alors indissociable des processus et des outils. Et comme un chauffeur de bus ne devient pas pilote de formule 1 en un jour, l'organisation, toute aussi bien rôdée soit-elle par des décennies de procédures très cadrées et très rigides, subira des échecs. Ce sont ces échecs et sa manière d'y répondre qui conditionneront le succès sa mutation DevOps.
Les bases
Il existe quelques points clés qui vous guideront vers le succès, une transformation DevOps doit être envisagée comme utile, c'est à dire qu'elle vise à faire mieux fonctionner votre organisation :
connaissez vos contraintes les plus importantes ; ayez pour objectif de supprimer ces contraintes les plus importantes (en terme de gain de temps et de coûts par exemple) ; gardez en tête que la création de valeur c'est le code produit ; analysez chaque flux nécessaire à la production de cette valeur ; plus votre organisation est importante en terme de taille et le nombre d'intervenants important, plus vous vous heurterez à des obstacles pour avoir une vision claire et décloisonnée de toute la chaîne de production de valeur.
Coexistence, pérénisation, transformation
La dimension technique ne peut éluder les questions commerciales, aussi il faudra aborder sa transformation de manière pragmatique en ne perdant pas de vue que c'est aussi la valeur (le code et ses processus de livraison) du "passé" qui fait vivre l'organisation pendant sa mutation. L'objectif d'une mutation DevOps est de créer de la valeur et non d'en détruire. Un utilisateur final n'a pas à être impacté par une refonte d'architecture et une transformation des processus métiers.
Demandez-vous si une transformation DevOps peut absorber de nouveaux outils, de nouveaux processus, de nouveaux cycles de livraison tout en coexistant avec les anciens ; Il est impératif que les expérimentations technologiques ne remettent pas en cause les processus et architectures existantes sans avoir mis à l'épreuve leur robustesse opérationnelle. Ce point est particulièrement important dans la mesure où les équipes ne travaillent pas toujours au même rythme et que la capacité de chacun à absorber de nouvelle technologies ou procédures peut grandement varier. Ayez à l'esprit qu'il n'est ici pas question de mettre un point d'arrêt à vos anciennes architectures et technologies pour en expérimenter de nouvelles comme les containers et les microservices. Il existera toujours un moment de flottement dans votre transformation ou le "nouveau" et l'"ancien" monde devront cohabiter pour que l'entreprise maintienne son activité ; Ce sont les nouveaux outils qui seront intégrés en toute sécurité dans votre modèle organisationnel afin qu'ils coexistent avec le modèle en place, vous devrez donc pour un temps, fonctionner sur un modèle hybride... DevOps, ne se borne pas à mettre une application mainframe dans un container que l'on pousse sur un cloud public.
Dernier point et non des moindres, ayez conscience que le rythme accru de la production de la valeur qu'induit une transformation DevOps, modifiera les rôles et les exigences de chacun bien au-delà des équipes de développement et d'exploitation. Il vous faudra fédérer, et donc associer bien d'autres services de votre organisation (RH, helpdesk, juridique, commercial, financier...) pour que le succès soit compris de tous et que chacun soit un maillon de cette transformation qui crée plus de valeur.
L'un des principaux avantages vite perceptible c'est la simplicité pour une nouvelle équipe de développement de rentrer dans un projet ou de passer à un autre projet puis de le reprendre plus tard. On ne subit plus le rythme du développement, on l'organise en épousant les concepts d'intégration continue et de déploiement continue
Tendre vers une culture d'adaptabilité et d'apprentissage
Chaque transformation se heurte à des réticences. L'automatisation est typiquement une problématique complexe à surmonter culturellement. Quand le rythme des livraisons s'accélère, il devient par exemple compliqué de tester le code à chaque livraison. Il faut donc passer d'une culture d'exécution des tests à celle de l'automatisation des tests. On se rend compte dans cet exemple que sans adhésion et sans une capacité d'adptation des équipes en charge du contrôle qualité, de simples procédures de test peuvent devenir un goulet d'étranglement. Chaque équipe passera par une phase d'apprentissage qu'il convient de planifier et de faciliter.
Si la pile logicielle largement adoptée dans les pratiques DevOps d'aujourd'hui constitue une fantastique trousse à outils, c'est une fois de plus vers l'humain qu'il faut se tourner pour qu'il s'adapte non pas aux seuls outils, mais qu'il adhère à une nouvelle culture devenue nécessité pour fluidifier l'avancement d'un projet.
Une transformation DevOps réussie peut enfin souvent se mesurer au nombre de gens qui se parlent dans l'organisation alors que leurs activités étaient jusque là cloisonnées. Si on livre plus vite, c'est que l'on échange mieux, plus efficacement, en livrant de la valeur plus rapidement, en livrant mieux puisque votre démarche qualité est maintenant systématisée.
Un fois la démarche DevOps devenue réalité, la communication entre les équipes se fait à l'essentiel. Elles arrivent à avoir une discussion sur la base d'une zone commune d'échange (comme un tableau de bord) ce qui permet aux acteurs d'échanger sans pour autant avoir la même compréhension technique d'un même projet.
À terme, tous les maillons de la chaine, jusqu'au client final, qui tirent un bénéfice de cette démarche.
