News - Projects

Modernisation : que faire des milliards de lignes de code legacy ?

19.02.2016



Le COBOL représente encore 70 % des traitements transactionnels.
Alors que les auteurs de ces programmes partent à la retraite, que faire de ces 200 milliards de lignes de code historique ?


 

Lancé en 1959, le COBOL est un des plus vieux langages encore en activité. Des programmes conçus il y a plus de 50 ans continuent encore de tourner. C’est également le langage le plus utilisé en entreprise, il fait tourner 70 % des systèmes transactionnels,

Le paysage informatique a bien changé depuis : les mobiles sont aujourd’hui plus puissants que les mainframes des années 50. Le cloud permet de disposer d’une capacité de traitement et de stockage à la demande, virtuellement sans limite.

[Source : Micro Focus ]

Côté environnement logiciel, c’est l’ère du temps réel, des évènements asynchrones, des flux Big Data, des architectures de services distribuées, des agents intelligents…

Comment le COBOL peut-il survivre dans ce nouveau millénaire ? D’autant que les compétences se font de plus en plus rares. Les derniers programmeurs partent à la retraite et le langage historique n’attire pas les nouvelles générations nourries à internet et au mobile.

"Legacy software is fine, it’s just old software that still works."

Pourtant, ces programmes tournent encore. C’est en tout cas ce que soutient IBM qui s’enorgueillit de pourvoir faire tourner des applications critiques écrites il y a une cinquantaine d’années sur leurs mainframes IBM z et i.

Le problème c’est que ces programmes vieillissent. On estime que 90 % du code COBOL en circulation datent des années 70’s à 90’s. Au fil des années ce code a été optimisé et réglé au petit poil pour s’adapter aux évolutions des mainframes, et maintenu à la main, Or plus personne n’est capable de comprendre comment ce code fonctionne, pourquoi tel algorithme est utilisé, pourquoi l’exécution prend tel chemin et pas un autre.  

La modernisation de ces programmes historiques devient une nécessité urgente pour diverses raisons :

  • La difficulté d’intégration avec les environnements existants
  • Le business aujourd’hui réclame de l’agilité et de la flexibilité
  • Une pénurie de compétences
  • Le coût de maintenance devient supérieur à celui de la modernisation
  • La difficulté à exploiter les technologies modernes : mobile, cloud, big data, social…
  • Le support des éditeurs qui disparaît

Dans un récent rapport du Gartner, il apparaît que 45 % des entreprises placent la modernisation des applications dans le top 5 des priorités pour les projets à venir dans le cadre de la transformation numérique.

Les approches de modernisation

La modernisation des applications - COBOL en particulier et historiques en général - est un sujet très complexe et qui nourrit tout un écosystème d’éditeurs d’outils et de prestataires.

Différentes approches entrent en concurrence et définissent des stratégies de modernisation.


[ Coût / risque / avantage compétitif des principales approches de modernisation, source Morphis Insights ]

Le package

C’est une des options extrêmes. Ici, on remplace toutes les applications historiques par des progiciels. Le coût peut être très élevé car on va payer pour un logiciel sur étagère avec des fonctionnalités dont on n’a pas besoin.

On peut également se tourner vers des offres SaaS qui proposent des fonctionnalités à la demande. Mais dans ce cas-là, on utilise les mêmes fonctionnalités que ses concurrents, l’avantage compétitif devient nul.

Le revamping

Le revamping consiste rénover l’interface utilisateur (en général un écran 5250) en utilisant les standards du web : HTML, CSS. On bénéficie ainsi d’une interface graphique plus moderne à base de menus, de boutons, de liens hypertextes…

Le wrapping

Cette méthode ancienne consiste à encapsuler le programme historique dans un service de type Web Service afin de pouvoir l’exposer dans une architecture orientée services. Cela permet d’ouvrir l’application à d’autres environnements, mais ne modernise pas le code.

La migration

Encore appelé « Lift ans Shift » ou re-hosting, la migration consiste déplacer l’application d’un environnement à un autre. Typiquement, on va virtualiser et héberger l’application dans le cloud. C’est la solution la plus rapide et la moins coûteuse. Pas besoin de ré-architecturer ou de modifier l’application, le coût se réduit à la migration et aux tests dans le cloud. Si l’on gagne en extensibilité, l’application reste monolithique et mono-plateforme, donc peu évolutive.

La partition

C’est une variante du List and Shift adaptée au cloud hybride. On va séparer les traitements à l’intérieur d’une application pour pouvoir les répartir en couches entre un cloud public et un cloud privé. Par exemple il peut être plus économique de faire tourner la couche transactionnelle d’une application dans un cloud public, et plus sécurisé de gérer la couche de données dans un cloud privé. Le coût est supérieur à l’approche Lift ans Shift, mais l’approche peut être intéressante si l’économie réalisée grâce à la répartition dans le cloud hybride est supérieure au coût de modification de l’application.

Modernisation du code

Lorsque l’on s’attaque à la modification du code, on trouve ici plusieurs approches.

La réécriture du code

Appelée aussi re-engineering, l’approche la plus basique consiste à réécrire entièrement le code. On prend des programmeurs maîtrisant COBOL et Java (ou C#), qui vont analyser le code historique, faire du rétro-engineering quand le code devient incompréhensible, puis recoder en Java en appliquant autant que peut se faire le paradigme objet.

Autant dire que trouver de tels programmeurs relève du défi. Sans compter qu’un tel procédé va prendre un temps imprévisible, et donc un coût astronomique.

La modernisation du langage

Une méthode plus outillée consiste à prendre un programme écrit en vieux COBOL-85 par exemple ; à le passer dans une moulinette de traduction de code. Le langage généré peut être une version plus moderne du COBOL, comme un COBOL orienté objet ISO 2002 voire 2014. Dans l’environnement IBM i (AS/400), on passera du RPG à du RPG free-form.

Les avantages sont que la traduction est moins douloureuse et qu’on ouvre l’application aux environnements modernes. En revanche, on risque une pénurie de compétences pour maintenir ces programmes.

La traduction de code

Le langage généré peut être également un nouveau langage tel que Java, C/C ou C#.

Le problème c’est que cela ne marche pas vraiment. On obtient le même programme écrit certes en Java, mais ressemble et qui se comporte comme un programme COBOL, Le programme est difficilement maintenable et évolutif, et souffre de problèmes de performance. Les aspects évènementiels, concurrents ne sont pas exploités.

Modernisation du portfolio

Modélisation et transformation

Pour passer au palier supérieur, on va prendre en compte l’ensemble du système d’information, modéliser les processus métier et les structures de données. L’utilisation d’un gestionnaire de portfolio d’applications capable de cartographier et documenter l’ensemble des applications devient indispensable. Dans certains cas, la logique métier peut être modélisée dans un métalangage orienté objet tel que UML, La transformation en code moderne peut alors se faire grâce à des générateurs de code.

C’est une démarche complexe qui nécessite encore beaucoup d’intervention humaine. Une des difficultés est que les processus métier sont parfois codés en dur, et fortement couplés avec d’autres aspects du code historique comme des fichiers de configuration ou des commandes batch qui sortent du scope de la modélisation. De fait, l’outil de modernisation s’accompagne généralement d’une offre de services.

La marché florissant de la modernisation

Dans son rapport « IDC MarketScape: Worldwide Application Modernization Services for Digital Transformation 2015 Vendor Assessment », IDC identifie 16 acteurs principaux qui sont pour la plupart des éditeurs-sociétés de services avec une présence mondiale tels que IBM, Accenture, PwC, HCL, Capgemini, HP Entreprise, Atos, Fujitsu…

 


[Source : IDC]

Le marché de la modernisation des applications est un secteur en pleine croissance, estimé entre 50 et 100 milliards de dollars selon Gartner et Forrester

Extraction d’algorithme

Dans une recherche constante d’efficacité et de réduction des coûts, on cherche à automatiser un maximum de tâches dans le processus de modernisation. Dernière avancée en date, l’extraction d’algorithme telle qu’on la trouve chez CodeCase Software.

Ici l’outil va analyser non seulement le code source des applications, mais également tout ce qui s’apparente à du code source : requêtes base de données, fichiers de configuration, dépendances vers des frameworks, des API, etc. L’outil va modéliser la logique globale de l’application et peut alors extraire les algorithmes sous forme d’un métalangage universel. Contrairement à UML qui est orienté objet, ce métalangage est multi-paradigmes. L’algorithme est ensuite transformé en code cible. Il est donc possible de moderniser non seulement du COBOL mais aussi de et vers la plupart des  langages : C#, Delphi, Java, VBA, VB, C , Fortran, C, VB6, etc.

Le processus de modernisation nécessite toujours une intervention d’humaine, mais à un niveau plutôt architecture, puisque les tâches de compréhension de la logique et de génération de code sont davantage automatisées.

Cette approche permet de capitaliser sur le vrai trésor de l’entreprise, ses algorithmes, indépendamment des langages et des plateformes. Et de préparer l’entreprise à l’économie des algorithmes telle que la prédit Gartner.


Article rédigé par Pierre Tran

© 2014 Codecase, all right reserved
Credits - Legal notices

X

Let's meet !