Par Philippe Magne
Sommaire
Le secteur des BFSI (Banking, Financial services, Insurance) repose massivement sur l’utilisation des plateformes dites « legacy » (Mainframe et IBM i) pour leurs applications critiques. Bon nombre d’utilisateurs ont tout simplement « oublié » ces systèmes back-end du fait de front-end mobile ou web en tout genre, mais ils sont bel et bien toujours là pour faire fonctionner les missions régaliennes de ces entreprises.
L’essence même de toutes ces entreprises, c’est la maîtrise du risque. C’est probablement la première raison pour laquelle ces systèmes font toujours partie intégrante du paysage informatique, et ce, même si ceux qui font leur business de leur remplacement n’hésitent pas à les qualifier de ringards. Mais comment peut-on encore imaginer aujourd’hui les remplacer par d’autres plus « performants » ou plus « modernes » en maîtrisant parfaitement les risques de migration ? Le nombre d’entreprises qui vont oser encore prendre un tel risque se réduit de jour en jour.
Ne rien changer de l’organisation existante serait cependant tout aussi risqué pour une seule et unique raison : la pyramide des âges. Dans les 5 à 10 ans à venir, c’est 75% des ressources existantes qui seront parties à la retraite.
La plupart des directions générales ont parfaitement compris l’enjeu et l’urgence de réussir leur « transition générationnelle ». Il y a un réel consensus pour s’accorder à dire que cela passe par une transformation DevOps. C’est au travers d’une nouvelle organisation des développements plus agile, plus moderne et plus outillée que l’on peut attirer et conserver de jeunes talents.
De la direction à la mise en œuvre, il y a cependant un gap important, tant les clés du succès sont nombreuses. Vous trouverez dans cet article quelques conseils pour assurer votre transformation DevOps en mettant toutes les chances de votre côté. Elles sont le fruit de notre expérience acquise sur le terrain depuis plus de cinq ans maintenant et dans les entreprises du monde entier.
Voici les 5 étapes clés :
1. Définir la cible
Cela peut paraître basique comme premier conseil, mais trop de gens partent avec des cibles relativement peu claires, tout simplement parce que DevOps se décline à trois niveaux : stratégique, managérial et technique. Cela vaut donc le coup de prendre un peu de temps pour définir les jalons d’une transformation qui, de toute façon, durera plusieurs années et dont les enjeux sont vitaux. Une roadmap claire intégrant tous les jalons du changement et avec des échéances précises donnera une orientation pour l’ensemble des acteurs, du développeur au management, en passant par les équipes sécurité et exploitation. Le but est de faire de ces systèmes legacy une technologie comme une autre, banalisée et surtout, complètement démystifiée par les jeunes générations. Car au final, on s’aperçoit vite que la barrière est surtout faite d’idées préconçues que l’on peut faire tomber.
2. Engager rapidement les aspects « tooling »
Contrairement à des projets applicatifs où l’on peut passer du temps à établir un « cahier des charges » pour s’assurer que l’on couvre bien les besoins de tous les utilisateurs, il est quasi impossible de procéder ainsi dans une stratégie DevOps, du fait de la profusion de technologies dans le monde distribué, en complet décalage avec la rareté des choix possibles dans le monde legacy.
Ce mouvement se nourrit de « good stories » qui se développent de manière virale à travers le réseau et favorisent l’émergence rapide d’authentiques standards. C’est ainsi que le gestionnaire de sources Git est devenu en seulement quelques années un standard de facto dans le monde distribué et, de fait, un incontournable également pour le code Legacy. De même, Jenkins en tant qu’orchestrateur des tâches d’intégration s’impose naturellement. Est-ce la meilleure technologie sur le marché ? Là n’est déjà plus la question. C’est un standard. Citons enfin Jira qui s’est imposé comme référence dans la gestion de projets.
Le tout consiste ensuite à bâtir une chaine DevOps cohérente et efficace. Soit vos propres équipes ont les compétences (et le temps) de faire l’intégration par elles-mêmes, soit vous vous appuyez sur un acteur qui vous propose une chaîne globale et déjà intégrée. C’est la proposition de valeur d’Arcad Software.
Les outils ne font pas le changement, mais, contrairement à des projets applicatifs, ils en sont de puissants moteurs.
3. Adopter une politique de « quick wins »
Il s’agit d’emporter l’adhésion en apportant la preuve par l’exemple. Basculer l’ensemble des équipes dans une stack DevOps multi-plateformes est beaucoup trop ambitieux. Choisissez plutôt une première application combinant de multiples technologies. Tâchez, par contre, de couvrir l’ensemble de la chaîne DevOps afin d’être capable de montrer le maximum de valeur dans la chaîne et de ne pas avoir l’effet naturel de comparaison avec ce qui existait auparavant. La politique des « petits pas » s’entend donc moins ici sous les aspects découpage par phases que découpage par domaines applicatifs.
4. Communiquer tout azimut
Le challenge de la transformation DevOps, c’est de faire en sorte que les générations existantes et futures puissent collaborer ensemble dans le même intérêt : celui de l’entreprise et de la continuité de son business. Des générations que tout oppose sur le papier : différentes technologies, différentes plateformes, différents langages, différentes motivations. A priori, dit comme ça, cela a tout d’une mission impossible. Une clé majeure pour la réussite de ce projet, c’est de mettre en place une communication interne par de nombreux canaux différents : cela passe par des affiches, des vidéos, des témoignages, etc. L’un de nos clients a réalisé en collaboration avec ses fournisseurs des mini « salons » baptisés « Techfest » pour faciliter le partage d’information, non seulement entre les collaborateurs, mais aussi avec le monde externe. Cette communication favorise le sentiment d’appartenance et impulse le mouvement.
5. Rendre l’upper management partie prenante
« DevOps for legacy » n’est pas une stratégie comme une autre dans le sens où elle est juste vitale. Les entreprises qui s’y seront prises trop tard et auront laissé leurs ressources critiques partir à la retraite sans réagir vont se trouver en grande difficulté et n’auront d’autre avenir que de se faire racheter par leurs concurrents. C’est la raison pour laquelle on voit de plus de leaders DevOps être directement rattachés à la direction générale.
Si ça n’est pas encore le cas chez vous, rien ne vous empêche d’utiliser cet article pour tirer la sonnette d’alarme. Si vous avez déjà entamé votre stratégie DevOps mais que vous n’avez pas encore eu de résultats tangibles, revenez auprès de votre direction pour demander plus de moyens. C’est souvent la mauvaise maîtrise des enjeux stratégiques, sur un sujet relativement technique, qui peut mettre mal à l’aise une direction.
En conclusion
Nous vivons une époque passionnante. Une époque où les anciennes et les nouvelles générations doivent collaborer dans l’intérêt de l’entreprise. Une époque où il ne s’agit plus de s’opposer car chacun a sa pierre à poser dans l’édifice. Seules les règles ont changé et la réussite passe obligatoirement par un changement radical d’état d’esprit.
Philippe Magne
Président Directeur Général, ARCAD Software
Philippe Magne est le PDG et le Fondateur du groupe ARCAD Software, un éditeur de logiciels international spécialisé dans les solutions multi-plateformes pour DevOps, la modernisation d’applications, l’automatisation des tests et le masquage des données. Il dirige l’entreprise pour produire une gamme de solutions complètes et intégrées, distribuées par IBM dans le monde entier. Philippe est un expert de la modernisation et est un conférencier reconnu dans les événements IBM.
