Stratégies pour garder Cobol et moderniser ses mainframes
Au cœur d’une économie façonnée par la vélocité de la mise sur le marché de nouvelles applications toujours plus performantes sur des plateformes multimodales, la modernisation des mainframes est un impératif. Un expert de HN Services explique comment mener ces projets.
par
John Modeste, Directeur Marketing et Solutions HN Services
Publié le: 04 juil. 2023
On le sait, Cobol est toujours le support des plus grands volumes transactionnels dans les secteurs public et privé du monde entier. Loin d’être obsolète, il est considéré comme une technologie stratégique pour 92 % des entreprises à travers le monde, le patrimoine mondial s’élevant à 850 milliards de lignes de code selon un rapport Micro Focus 2022.
Ce ne sont pas les limites technologiques du mainframe qui sont un frein à l’innovation et à la digitalisation des entreprises – IBM investit toujours et de manière continue dans ses systèmes Z – mais bel et bien les pratiques rigides et les idées reçues autour de cette plateforme.
On peut citer aussi les enjeux de maintenance des applications existantes (tournant pour certaines depuis de très nombreuses années), la complexité de la migration vers le cloud, la modernisation de l’environnement de développement ou encore des freins provenant des développeurs eux-mêmes.
« Il est indispensable d’accompagner les devs dans des expériences de développement logiciel optimisées via des IDE adaptés et des outils modernes intégrant le mainframe dans la chaîne d’outils DevOps. »
John ModesteHN Services
Car pour les dévs, coder en Cobol nécessite de changer de perspective sur la manière d’appréhender un problème.
Un langage ancien low level et monolithique à l’instar de Cobol offre moins de place pour créer des valeurs, retenir des informations et possède des structures de contrôle complexes.
Il nécessite aussi de pallier le manque d’instructions. En effet, au-delà d’être volumineuses et compliquées, les applications mainframe sont faiblement documentées et donc dépendantes des connaissances de collaborateurs bien souvent aux portes de la retraite.
Enfin, la plupart des outils de développement modernes ne sont pas disponibles pour Cobol.
Il est donc indispensable dans un premier temps d’accompagner les dev dans des expériences de développement logiciel optimisées via des IDE adaptés et des outils modernes intégrant le mainframe dans la chaîne globale d’outils DevOps.
Autre exemple, en utilisant SonarQube pour Cobol, il sera possible de normaliser le code et donc de le rendre plus qualitatif tout en apportant au développeur des indicateurs de performance clés et une meilleure visualisation, optimisant ainsi ses futures interventions et éventuelles rétro-documentations sur le programme.
Au-delà des outils, une organisation ad hoc aidera à faire travailler ensemble des équipes sillotées, en synergie, au même rythme et de manière agile, pour faciliter le déploiement de manière itérative d’un code de qualité orienté métiers.
Doit-on sortir du Cobol à tout prix ? La prudence est de mise.
Avec le développement du cloud, se pose alors la question de comment moderniser ou faire évoluer les applications mainframe existantes, pour faire face à la compétitivité intense de technologies modernes qui, elles, favorisent des cycles d’innovation rapides et des coûts réduits.
Et plus précisément, comment restructurer un code cobol afin de le rendre plus modulaire et simplifié ?
Si la potentialité d’une sortie du Cobol est motivée par l’aspect économique (IBM coûte cher), par le déficit de compétences en interne, ou encore par les difficultés à faire évoluer les applications, plusieurs scénarios sont envisageables pour moderniser/transformer les applications mainframe à travers de nouvelles technologies et plateformes (API, containeurs, mobiles, cloud…) dans une logique DevOps.
Le défi est d’abord de décider du périmètre – c’est-à-dire quelles applications moderniser –, de déterminer les moyens et d'exécuter des pratiques agiles pour soutenir l’exécution opérationnelle, la qualité, le déploiement et la sécurité au sein d’une véritable démarche de gestion du changement.
1. Replatforming
Le replatforming est le processus par lequel une application est transférée d’une plateforme technologique (ici mainframe) vers une autre (de type Windows ou cloud), sans la réécrire ni la modifier.
Dans certains cas, le processus peut être compliqué, car il doit se faire sans rupture opérationnelle et nécessite souvent de recourir à un émulateur sur la plateforme cible, afin de permettre à l’application de continuer à fonctionner comme avant. Il sera également nécessaire de modifier le Cobol pour le faire fonctionner avec l’émulateur cible.
2. Rehébergement/émulation
Pour les entreprises, notamment des secteurs de la finance, qui souhaitent continuer à s’appuyer sur la fiabilité et la puissance de calcul de leurs serveurs de données « hérités » (legacy), une option consiste à réhéberger leurs applications mainframe sur des plateformes de déploiement moins coûteuses – par exemple déplacer une application existante sur un émulateur basé sur le cloud, ou recompiler le code COBOL et l’exécuter dans des conteneurs Linux.
Ce processus implique généralement la migration des bases de données in situ vers le cloud et n’est pas vraiment une solution de modernisation à long terme.
3. Réécriture totale du code
La troisième option est la réécriture complète du code. Elle consiste à décomposer l’application dans de nouveaux langages modernes de type Java.
Le choix du langage de programmation est primordial, car il doit offrir la plus grande flexibilité et faire fonctionner l’application aussi bien sur un cloud public/privé que sur un serveur ou un mainframe.
Cependant, comme le code cobol est sous documenté, cette option est un processus long-terme et non adapté aux besoins en agilité et vélocité des entreprises modernes.
4. Refactoring
Contrairement à une réécriture totale, le refactoring du code révise le code d’origine, mais uniquement certains composants de l’application, souvent via des logiciels d’automatisation. On parle de clean code.
Cette technique conserve la logique métier existante, mais permet d’améliorer les performances et la portabilité en ouvrant la porte à des technologies innovantes telles que les conteneurs et les microservices.
Le refactoring est préférable à la réécriture, car c’est une option moins risquée.
Conclusion
Il n’existe pas d’approche unique de la modernisation mainframe.
Le système est complexe surtout pour de grandes organisations dotées d’architectures colossales qui ne veulent pas faire l’impasse sur le legacy, mais tout simplement augmenter leur évolutivité et leur agilité en se basant sur de nouvelles technologies.
La solution, en tout cas, n’est pas de faire cavalier seul. Il est indispensable de s’appuyer sur un écosystème expérimenté qui aide à limiter au minimum les modifications du patrimoine applicatif et à choisir les architectures. Sans oublier la montée en compétence des collaborateurs en interne via des outils et des processus adéquats, au travers de méthodologies agiles, ainsi que l’appui des communautés open source.
