Comment les entreprises se séparent de Cobol

Voilà 61 ans que le langage de programmation Cobol est utilisé, sous une forme ou une autre. Dans un certain nombre d’organisations, il devient de plus en plus difficile de trouver des personnes qui peuvent maintenir correctement les applications Cobol basées sur les mainframes, d’autant plus que la plupart des cursus informatiques ne l’enseignent plus.

L’importance et la fragilité de ces systèmes ont été démontrées en avril 2020, lorsque, au plus fort de la pandémie COVID-19, plusieurs administrations américaines (dont les états du New Jersey et du Kansas) ont commencé à lancer des appels désespérés aux programmeurs Cobol pour qu'ils se portent volontaires (retraités y compris) pour les aider à faire fonctionner leurs systèmes de gestion du chômage face à une recrudescence de demandes sans précédent. L’âge n’y fait rien. Cobol est toujours utilisé par de nombreuses grandes banques, compagnies d’assurance et administrations pour gérer leurs processus transactionnels de base tels que le paiement des allocations chômage ou les distributeurs automatiques de billets.

Cobol fait le travail mais il est difficile à maintenir et à intégrer

« Ce sont des applications vieilles de 20 à 30 ans qui ont bien servi l’entreprise, mais elles accumulent une dette technique et sont très spécifiques à l’activité », explique Tim Jones, managing director, responsable de la modernisation applicative chez le fournisseur de services Advanced. Cobol est « fonctionnellement riche mais il se trouve qu’il s’exécute sur une plateforme contraignante et ne joue pas avec les autres systèmes modernes ». Pour Tim Jones, la crise des compétences à la fois sur Cobol et les mainframes, la prise en considération des coûts associées et la nécessité de maintenir un avantage compétitif à travers les innovations technologiques sont des éléments moteurs dans la décision des organisations d’abandonner Cobol aujourd’hui. En particulier les applications qui résident toujours sur un mainframe.

« Ce n’est pas seulement un problème de compétences Cobol, c’est un problème plus large de modernisation des systèmes existants, au sein desquels Cobol n’est qu’une composante », estime Tim Jones. « Il est vraiment difficile d’intégrer les systèmes modernes, mobiles et clouds au mainframe. Lorsque vous pensez à votre avantage concurrentiel, si vous êtes sur mainframe, vous prendrez du retard. Si vous avez engagé une transformation numérique, vous devrez à un moment donné faire face au sujet tabou de ce système qui héberge 70% de vos applications métiers ».

« Tant que ces charges de travail se trouvent sur le mainframe, il faut un argument commercial pour s’éloigner de Cobol », selon Markus Zahn, responsable du cluster pour les nouveaux mainframes à la Commerzbank. « Cela pourrait être la pénurie de ressources causée par les effets démographiques ou des changements dans les attentes des clients en termes de disponibilité des données en temps voulu ».

Comment moderniser les applications Cobol

Pour les charges de travail sur lesquelles l'analyse de rentabilité s’est révélée probante, il y a plusieurs façons de se libérer des contraintes de l’existant. On peut essayer de trouver un logiciel commercial similaire, effectuer un transfert direct de l'application vers une infrastructure moins chère ou réécrire entièrement l'application dans un langage moderne comme Java ou C#. Mais toutes ces solutions comportent des risques. Le transfert direct de l’application (désigné en anglais par l’expression lift and shift) consiste à la porter vers une plateforme plus moderne, sans la réécrire ni modifier la façon dont elle a été conçue. Cela nécessite souvent de recourir à un émulateur sur la plateforme cible pour permettre à l’application de continuer à fonctionner comme avant.

Toutefois, cette option peut ne pas apporter la valeur à long terme recherchée par de nombreuses entreprises. « Lift and shift était une stratégie populaire il y a dix ans, mais aujourd’hui les organisations veulent en général obtenir plus de valeur d’un projet de modernisation », expose Tim Jones. « Elles ne veulent pas seulement réduire le coût des opérations, elles ont besoin d’accroître leur agilité pour répondre aux demandes du marché, de disposer de technologies prêtes pour les évolutions futures, d'adopter le cloud et des pratiques de développement modernes et de stimuler l’innovation informatique pour soutenir l’activité ».

Réécriture complète ou code refactoring

Vient ensuite l’option de la réécriture totale qui consiste à décomposer l’application et à la réécrire dans un langage plus moderne. « Le défi avec une réécriture, c’est que quels que soient les besoins métiers que vous abordez, ces systèmes ont 30 ans et disposent d’une documentation limitée. Personne ne les comprend de bout en bout, cela prend donc beaucoup de temps », pointe M. Jones. « Si vous le faites bien, vous obtenez quelque choses d’entièrement natif cloud, mais au moment où vous l’aurez terminé, vous serez peut-être déjà distancé ».

De ce fait, de nombreuses organisations optent pour une sorte d’option intermédiaire sûre, connue sous le nom de réusinage de code (code refactoring). Cela implique une certaine restructuration du code, souvent par le biais de logiciels permettant de l’automatiser, fournis par des spécialistes du domaine. Cette technique conserve la logique métier existante mais permet d’améliorer les performances et la portabilité, sans modifier radicalement la fonctionnalité de base. « C’est la voie qui semble avoir le plus de succès », constate Mark Cresswell, chairman exécutif de LzLabs, un fournisseur de services spécialisé dans la modernisation des applications mainframes.

Voici deux exemples d’organisations qui se sont libérées du Cobol basé sur mainframe en utilisant toutes les deux des techniques de réusinage de code et des logiciels d’automatisation du refactoring pour moderniser leurs applications.

Conversion à l'identique pour le ministère britannique du Travail

Le UK Department for Work and Pensions (DWP), ministère britannique du Travail et des Retraites, gère différents systèmes pour assurer le paiement des pensions, aides sociales et allocations familiales à 20 millions de personnes par an. Il a opté pour une conversion automatisée prudente « à l’identique » de ses applications Cobol, sans émulation mainframe de type lift and shift. En 2015, un grand nombre de ses systèmes de paiement - incluant les pensions de guerre et les allocations de chômage aux demandeurs d’emploi - étaient toujours écrites en Cobol, résidant sur les mainframes ICL hébergés par Hewlett-Packard. « Comme vous pouvez l’imaginer, c’est une plateforme vraiment coûteuse à supporter et à maintenir », a exposé Andy Jones, ingénieur responsable de l’infrastructure au DWP, dans une interview vidéo l’an dernier.

Le coût de la maintenance de l'infrastructure existante sur laquelle reposent ces systèmes, ainsi que les difficultés croissantes du ministère à trouver et à conserver des personnes capables de maintenir les applications Cobol sur mainframe, ont mis en évidence la nécessité de faire évoluer ces 25 millions de lignes de code, et ce avant que le support du système d'exploitation mainframe VME n’expire, en décembre 2020. « Il s'agissait surtout de l'infrastructure ICL qui supporte le code Cobol », a expliqué à InfoWorld Mark Bell, responsable du programme de remplacement VME au DWP.

Ce n’était pas la première fois que l’équipe d’ingénieurs IT du ministère essayait de se défaire de ces systèmes hérités. Au moins quatre projets de modernisation avaient jusque-là été engagés dont une tentative assez longue de réécriture du code Cobol en Java. Mais tous avaient échoué. Maintenant que la plate-forme arrivait vraiment en fin de vie, une stratégie simplifiée a été mise en place et les experts du spécialiste de la modernisation Advanced ont été appelés à la rescousse.

Visual Cobol et Red Hat Linux

Cette stratégie impliquait de porter le code Cobol vers le langage orienté object Visual Cobol de Micro Focus, plus moderne, et de passer du système d’exploitation VME à Red Hat Linux, hébergé sur des serveurs en cloud privé par Crown Hosting Data Centres, une co-entreprise entre l’agence gouvernementale britannique Cabinet Office et l’entreprise privée Ark Data Centres. Dans le cadre de ce projet, plus de 10 milliards de lignes de données seront également transférées de la base de données IDMSX, fermée et hiérarchique, vers des bases de données relationnelles Oracle.

Visual Cobol est une mise en oeuvre plus moderne du langage Cobol, dans le but de l’ouvrir aux environnements et concepts de développement modernes. « Il prend surtout en charge plusieurs langages, ce qui signifie que l’on peut faire appel à des développeurs Java et C# qui pourront écrire de nouveaux programmes s’intégrant parfaitement aux programmes Cobol existants, le tout à partir du même environnement de développement », souligne Tim Jones, d’Advanced. Le projet a démarré sur le plus petit système, qui gère le paiement de 1,5 milliards de livres sterling d’allocations de logement une fois par mois, par lots, auprès d’environ 360 instances locales. Le nouveau code a été converti puis testé en parallèle par rapport à l’original pendant une période de quatre semaines. Une fois que tout le monde s’est assuré qu’aucune perturbation ne se produirait, le passage au nouveau système a été effectué en février 2018.

Des gains déjà significatifs

A partir de là, les équipes informatiques du DWP et les spécialistes d’Advanced ont procédé système par système, en engageant en particulier la conversion du plus important service du ministère assurant la gestion du versement des allocations aux demandeurs d’emploi. Cela s’est déroulé au moment de Pâques en 2020, juste au moment où la pandémie de Covid-19 s’emparait du Royaume-Uni. « C’était une période intense pour réaliser la migration d’une application dans un service de prestations qui commençait à voir une avalanche de demandes suite à la façon dont l’épidémie frappait le pays », témoigne Mark Bell, responsable du programme de remplacement VME au DWP. Il restait ensuite trois systèmes plus petits à déplacer. En janvier 2021, le ministère n’avait plus aucune application Cobol basée sur VME.

Les économies et les gains en performance sont déjà significatifs pour l’organisme public. « Ce modèle de fonctionnement nous permet de [réduire] les ressources et le support », constate M. Bell. Du côté des performances, alors que les allocations pour les demandeurs d’emploi étaient traitées en plusieurs lots de quatre heures, l’opération est maintenant effectuée en une heure environ. En restant basé sur une version de Cobol, le choix de Visual Cobol dans le cloud peut donner l’impression que l’on repousse le problème à plus tard. Mais elle permet à l’ensemble de l’organisation d’être plus réactive et moderne dans son approche du logiciel. Alors que les mises à jour des anciens systèmes Cobol monolithiques ne pouvaient être déployées qu'une ou deux fois par an, les nouveaux systèmes orientés objet permettent aux développeurs d'apporter des changements plus petits et plus réguliers. L’équipe de développement peut également commencer à expérimenter dans un environnement de test sur Amazon Web Services, créer un ensemble d’API réutilisables pour exposer des sources de données clés, et appliquer les modifications à travers un pipeline CI/CD. Le passage à Visual Cobol de Micro Focus ouvre même la voie vers une réécriture plus radicale à l’avenir, par exemple en Java ou en C#.

Code refactoring et conversion à Java pour le New York Times

En 2015, le New York Times devait de son côté mettre à jour l’application Cobol utilisée pour son service de livraison quotidienne à domicile. Celle-ci avait 35 ans et fonctionnait sur un mainframe Z d’IBM. La société d’édition du journal souhaitait convertir l’application en Java et l’exécuter dans le cloud d’AWS car elle devenait coûteuse à maintenir et ne s’intégrait pas bien avec les autres systèmes plus modernes. Entre 2006 et 2009, une tentative de réécriture manuelle du logiciel avait déjà échoué. Elle avait laissé l’application largement intacte jusqu’en 2015, date à laquelle elle exécutait 600 tâches en batch avec 3 500 fichiers envoyés chaque jour aux systèmes qui les exploitaient en aval, consommant environ 3 To de données et stockant 20 To de données de sauvegarde.

Cette année-là, l’équipe informatique de la publication a décidé d’adopter une stratégie de migration du code et des données en recourant à la technique du réusinage de code. Pour le faire, elle s’est appuyée sur le logiciel de refactoring automatisé du spécialiste Modern Systems, racheté par la suite par Advanced. Le code a été converti en Java et les données ont été transférées des fichiers indexés vers une base de données relationnelle Oracle. Ce processus a pris deux ans et, après avoir fonctionné pendant moins d’un an dans un datacenter privé, la nouvelle application baptisée Aristo a été migrée vers le cloud public d’AWS en mars 2018, après huit mois de travail supplémentaires.

« Si le New York Times avait déjà mis en place sa stratégie cloud avant de commencer sa migration mainframe, l’entreprise aurait choisi de migrer directement vers AWS, en s’évitant ainsi d’avoir à concevoir et mettre en oeuvre le déploiement d’Aristo on-premise », signale un billet de blog d’AWS sur le projet. Désormais, le système de distribution du journal a été intégré dans la plateforme d’abonnement numérique plus moderne, qui est gérée, bâtie et maintenue par la même activité de gestion des abonnements au New York Times. Cela a permis de réduire de 70% par an le coût total de possession de l’application Aristo.