Lourd, complexe et peu agile : le mainframe est paré depuis longtemps de beaucoup d’inconvénients. Il est toutefois possible de le rendre plus agile : l’exemple de la Société générale.
«Le déploiement en continu impose la modernisation des applications, des plus anciennes aux plus récentes », assure Stefan Van Der Zijden, analyste chez Gartner. Pour ce dernier, les portefeuilles applicatifs souffrent d’un mal universel : avec le temps, trois composantes prennent de l’importance, tandis que trois autres se dégradent.
Hélas, ce n’est jamais dans le bon sens. Les trois composantes qui prennent de l’importance sont les coûts, qui augmentent, la complexité, qui s’accroît, et la maîtrise des risques, qui devient de plus en plus difficile. En parallèle, les trois composantes qui se dégradent sont l’alignement de l’application avec les besoins métiers, la valeur et l’agilité.
Dans un monde idéal, cela devrait être l’inverse : moins de coûts, de complexité et de risques, davantage d’agilité, de création de valeur et de proximité avec les métiers. Généralement, les courbes se croisent au bout de cinq ans, point au-delà duquel les coûts, la complexité et les risques l’emportent.
Moderniser pour réduire la dette technique
D’où un impératif de modernisation des applications. Celui-ci est dicté par les demandes des métiers, la nécessité de changements de plus en plus rapides, le poids grandissant de la dette technique, la difficulté de support compétitif des plateformes, l’obsolescence technologique ou la pénurie de compétences. Comment les DSI peuvent-ils justifier la transformation des applications et obtenir le budget nécessaire ?
Selon une étude de Teknowlogy Group, quatre arguments peuvent être utilisés pour agir au lieu de ne rien faire :
- Le risque est élevé : lorsque les anciennes applications sont mal connues, il devient difficile de les maintenir ou de les modifier. Cela entraîne inévitablement des risques accrus.
- Le choix est restreint et les coûts d’infrastructure sont plus élevés : les applications plus anciennes sont généralement étroitement liées à l’infrastructure sur laquelle elles fonctionnent. Ces dernières deviennent, au fil du temps, de moins en moins fiables, plus coûteuses et inefficaces.
- Les compétences sont limitées : cela pose un vrai problème dans le cas du code écrit pour les anciens mainframes, mais cela vaut aussi pour un large éventail d’anciens codes.
- Expériences utilisateur et client ne sont pas optimales : les consommateurs attendent des applications à l’état de l’art, mais les applications plus anciennes sont bien en-deçà de ces critères.
La Société générale, pour sa banque de détail, a conduit cette approche de modernisation, avec une démarche de transformation DevOps et de Continuous Delivery, dans le cadre de son projet IDEM-zDevOps (Integrated Development Environment for Mainframe). Pour Chris O’Malley, CEO de Compuware, « DevOps est particulièrement adapté pour les 20 % d’éléments qui génèrent 80 % des problèmes. »
Ainsi, la DSI de la Société générale a intégré son infrastructure mainframe au sein de sa stratégie IT, avec plusieurs objectifs : redynamiser l’environnement de développement mainframe, supprimer toute technologie mainframe obsolète et le transformer en une plateforme DevOps. Pour Chris O’Malley, « Toutes les banques conservent leurs mainframes, pour plusieurs raisons : la densité de transactions que l’on peut effectuer, la sécurité et le coût à la transaction, d’autant que les volumes ont explosé avec la banque sur mobile et le digital. En revanche, le mainframe se révèle moins agile, il faut donc l’adapter au monde non-mainframe pour favoriser cette agilité, afin de gagner du temps, par exemple avec une approche DevOps. Et plus une banque est grande, plus elle a besoin d’aller vite. »
« Le mainframe occupera toujours une place importante : plus de la moitié des lignes de codes sont maintenues dans le mainframe et la quasi-totalité des applications et des nouvelles initiatives métier sont composites, impliquant à la fois un patrimoine mainframe et distribué », explique Gatien Dupré, responsable du projet IDEM -zDevOps au sein de la DSI de la Banque de détail du groupe Société générale en France.
« Notre enjeu était clairement de fédérer les équipes autour d’un projet zDevOps », poursuit-il. « Pour moderniser les pratiques de développement, générer des gains de productivité et attirer de nouvelles générations de développeurs, le mainframe devait donc se transformer en une plateforme DevOps agile, tournée vers l’innovation. Autre enjeu stratégique de cette modernisation : gagner en productivité sur cette filière souvent délaissée. Enfin, et c’est la raison la plus importante, on redonne de l’attractivité pour les jeunes développeurs qui travaillent sur le mainframe », assure Gatien Dupré.
La chasse aux bugs est ouverte
Pour accompagner cette transformation DevOps mainframe et rallier les collaborateurs à ce changement important, la Société générale a mis en place un concours disruptif et humoristique, proposant aux équipes de traquer les bugs et les non-conformités. « Cela nous a permis de renforcer la cohésion autour du mainframe et de démontrer aux équipes que la culture mainframe pouvait très facilement intégrer les standards les plus innovants de l’IT et offrir une expérience de développement identique à d’autres technologies, telles que Java », explique Gatien Dupré.
Les équipes ont utilisé l’outil Topaz de Compuware pour traquer ces bugs et non-conformités. L’organisation d’une chasse aux bugs a été le résultat d’une réflexion sur la nécessité d’homologuer l’ensemble des développements. « Les dix meilleurs chasseurs de bugs ont été récompensés, les membres du Comex se sont pris au jeu et ont assisté à la remise des trophées », se souvient Gatien Dupré.
Résultat : « En moins de deux ans, plus de 90 % de nos collaborateurs sont engagés aujourd’hui dans le DevOps mainframe ! Pendant 35 ans, nous avons travaillé en cycle en V, modèle pour lequel le mainframe s’est adapté. En changeant de paradigme, le mainframe s’est de nouveau adapté pour s’inscrire dans cette démarche d’innovation agile et pérenne. Le mainframe est une puissante technologie, adaptable et évolutive sur laquelle nous nous appuyons pour co-créer de la valeur avec les métiers. », conclut Gatien Dupré.
Pour Chris O’Malley, CEO de Compuware, « avant, les développeurs étaient comme des esclaves dans une galère romaine, on leur demandait d’aller toujours plus vite, désormais, dans un monde DevOps, ils doivent être considérés comme des « high performers » pour la qualité et l’efficience. »
| Le projet Idem en bref | |||
| Pourquoi ? | Comment ? | Avec quoi ? | Pour quels résultats ? |
|
nement de dévelop-pement (Integrated Development Environment) |
|
|
Équipes DevOps : quels KPIs pour mesurer la performance ?
Dix KPIs sont principalement utilisés par les entreprises pour mesurer la performance des équipes en charge de l’approche DevOps (par ordre d’importance), selon IDC France :
- La robustesse en matière de sécurité.
- La satisfaction client.
- La disponibilité/fiabilité du service.
- Le Time to Market.
- Le rythme des déploiements.
- Les bénéfices pour l’entreprise (revenus, clients, image…).
- Les baisse de coûts techniques.
- Le travail collaboratif et la responsabilisation des équipes.
- Les délais.
- Le taux d’erreurs dans le code.
Dette technique et faillite du SI
Selon Computer Economics, une entreprise sur cinq présente un risque de faillite technologique, en raison de l’ancienneté de son ERP et, surtout, de la date de l’installation des derniers upgrades. Une perspective qui s’applique également aux environnements mainframes. La dette technique a des conséquences en termes d’augmentation des coûts, de performance des applications, de scalabilité, d’allongement des délais de mise à disposition des utilisateurs et de dégradation de l’expérience utilisateur. « La réduction de la dette technique liée aux applications mainframe est essentielle pour toute entreprise cherchant à intégrer des applications mainframe dans ses pipelines CI/CD (Continuous Integration/Continuous Delivrery) », déclare Jason Bloomberg, président du cabinet d’analyses sectorielles Intellyx. Malheureusement, ce poids de la dette technique est encore trop souvent sous-estimé. « Un développeur ne se réveille pas le matin en se disant : « Je vais me lever pour réduire la dette technique », il préfère travailler sur de nouvelles fonctionnalités. La dette technique est un problème très souvent ignoré, mais, avec le temps, elle devient comme une araignée géante : elle fait peur ! », rappelle Chris O’Malley, CEO de Compuware. Comment prendre conscience du problème ? L’une des approches consiste à identifier si quatre affirmations des développeurs sont récurrentes dès lors que l’on souhaite moderniser une application :
- « Le code de mon prédécesseur est tellement compliqué qu’il me faudra deux fois plus de temps que prévu pour implémenter cette nouvelle fonctionnalité. »
- « Si je touche à cette partie du code pour améliorer l’application A, cela risque de provoquer des dysfonctionnements dans l’application B. »
- « J’ai du mal à identifier ce bogue, il y a trop d’imbrications de « if », je ne comprends plus la logique métier de ce code… »
- « Pour améliorer les performances de ce système, on doit le réécrire complètement. »