Modernisation mainframe : un continuum !

Fluidement et constamment, le matériel et le logiciel qui constituent les systèmes informatiques critiques des entreprises doivent évoluer pour éviter la sanction de la sélection darwinienne.

Les grandes entreprises, bien établies, pourraient se bercer de l’illusion que, pour conserver leur prospérité, voire simplement subsister dans un marché digital et global, où la concurrence est toujours plus acérée et où l’évolution technologique est plus rapide, il leur suffit de garder leur processus «cœur de métier» en état de marche pour s’affranchir d’une participation à cette course folle et incessante aux dernières innovations.

Mais, le véritable challenge se situe au niveau supérieurd’exigence : il s’agit réellement de développer puis maintenir une capacité permanente à transformer son métier par la modernisation fluide et permanente de ses systèmes informatiques pour conserver sa place sur le marché. La simple capacité à faire demain comme aujourd’hui va s’avérer largement insuffisante à très court terme !

L’adaptation sans répit du métier et des systèmes sous-jacents est le défi à affronter pour les grandes entreprises si elles veulent pérenniser leur rôle et leur position de leader sur le marché digital. Celles qui vont se cantonner au statu quo technologique pour leurs processus essentiels vont s’interdire tout levier, lucratif pour leurs affaires, sur les nouvelles plateformes qui délivrent à très haute fréquence leur lot d’innovations.

Le mainframe a été créé pour offrir une plateforme informatique puissante et solide sur laquelle les grandes sociétés de l’époque pouvaient asseoir à grande échelle leurs processus opérationnels. Elles pouvaient ainsi répondre à la forte demande d’une économie en expansion. En un demi-siècle, le mainframe est clairement devenu un pilier industriel et économique. Aujourd’hui encore plus de 70% des transactions financières mondiales sont traitées par une application fonctionnant sur mainframe.

Le débat autour de la viabilité du mainframe en tant que plateforme pour supporter des exigences du métier toujours croissantes dans un paysage concurrentiel moderne toujours plus affûté n’est bien sûr pas clos. Le présent article y contribue en démontrant que le ré-hébergement en l’état («AS-IS») vers des environnements modernes n’est pas une vue de l’esprit, voire une utopie. Il est concrètement possible et se pose en alternative parfaitement viable aux solutions habituelles de réécriture complète ou de recompilation sur cible. Celles-ci apportent le plus souvent, quand le chemin d’adoption de ces nouveaux systèmes et plateformes modernes comme cibles est trop radical, leur lot de frustrations et de tensions à l’émergence de résultats métier différents, parfois sensiblement.

Les motivations pour moderniser les systèmes informatiques de type mainframe sur une base continue sont pleinement fondées. Notre préambule atteste de la nécessité d’une évolution permanente. La réflexion doit donc alors porter plus sur la méthode (le COMMENT) plutôt que sur les justifications (le POURQUOI).

Le ré-hébergement («re-hosting») initial en l’état d’une application vers un nouvel environnement est une solution classique de migration à but de modernisation incrémentale. Elle comporte cependant de multiples variantes aux subtilités parfois peu palpables dans une réflexion initiale, mais dont la pertinence dans un contexte particulier peut s’avérer déterminante pour le succès du projet de transformation.

La plus récente de ces variantes permet de déplacer les applications sous leur forme binaire, sans recompilation ni adaptation du code source. Elle n’apparaissait jusqu’à présent que comme une vue de l’esprit tant les plateformes source (mainframe) et cible (x86/Linux) sont fondamentalement différentes.

Mais, elle est désormais effective et permet une transition très rapide et dénuée de risques, puisque n’entraînant pas de changements. En effet, dans les alternatives classiques de recompilatiom, les modifications impératives de code source induisent le plus souvent une très forte complexité additionnelle, souvent imprévue au lancement du projet: les résultats des tests initiaux produisent des résultats parfois considérablement différents par rapport au système initial et il peut s’avérer très difficile, voire impossible, de converger vers des résultats identiques. Cette complexité non anticipée peut conduire à l’avortement prématuré du projet.

Le principe opératoire du ré-hébergement binaire se décompose essentiellement en 3 étapes simples :

1. Rassemblement et packaging de l’ensemble des composants de l’application (en format binaire pour les programmes) sur la plateforme source.
2. Transfert de ceux-ci vers la plateforme cible.
3. Mise en place sur la plateforme cible pour exécution immédiate possible.

Pour atteindre cette fluidité, il faut que les services fournis par les différents sous-systèmes de départ aient été nativement réécrits pour Linux. En particulier, doivent être inclus les activités transactionnelle et batch ainsi que les accès aux données indexées, hiérarchiques ou relationnelles. Pour paraphraser l’astrophysicien Carl Sagan et sa célèbre citation métaphorique de la tarte aux pommes, on pourrait dire, que «pour recréer à partir de rien l’environnement d’exécution d’une application mainframe sur un système moderne et ouvert, il faut d’abord recréer l’univers», en tout cas celui du mainframe.

En particulier, un traducteur doit être en place : il permet la translation (au sens mathématique) des instructions binaire et concepts technique de l’architecture mainframe vers leur équivalent sur l’architecture x86, en particulier Xeon, afin de permettre une exécution sur Linux. Ce processus est appelé «Traduction Dynamique d’Architecture et de Jeu d’Instructions» (“Dynamic Instruction Set Architecture Translation.”). Les binaires ainsi transformés sont ensuite capables de fonctionner dans le conteneur applicatif qui leur fournit les APIs systèmes mainframe auxquelles ils font appel.

Il y a des bénéfices nombreux et très tangibles à une telle approche :

• Pas de négociations ou polémiques avec les utilisateurs finaux sur l’acceptabilité d’éventuelles discrépances dans les résultats dues aux modifications ou à la réécriture totale. Elles n’existent pas dans le ré-hébergement binaire. Ces écarts, même modestes, sont souvent dommageables car ils altèrent d’entrée la confiance placée dans le nouveau système par ses utilisateurs.
• Pas de pertes de productivité ni de besoin de formation pour ces mêmes utilisateurs: tout est parfaitement identique de leur point de vue. Les interactions avec leurs applications habituelles restent strictement identiques. Aucune perturbation sur les processus métier bien en place.
• La validation de la migration est extrêmement directe: les résultats doivent être strictement identiques. L’approche ne laisse aucune place à l’éventuelle validation subjective et condescendante par les participants au projet: la mesure du résultat est totalement quantifiée et donc parfaitement objective.
• La recherche de cette égalité stricte permet une approche très automatisée, donc extrêmement efficace de l’acceptation du nouveau système.
• Une large partie de la problématique de modernisation est résolue rapidement: les applications critiques fonctionnent désormais sur une plateforme, fondée sur des composants standards, dont la pérennité est indéniable. Elle peut ainsi être gérée par des ingénieurs système Linux, dont l’abondance sur le marché est sans commune mesure avec celle des profils similaires pour le mainframe. La problématique du recrutement difficile par raréfaction des compétences disparaît ainsi.
• Les économies massives possibles avec les plateformes modernes sont obtenues très rapidement, avant même que la modernisation effective n’ait à démarrer. Un retour sur investissement fortement positif à très brève échéance !

Après le ré-hébergement en l’état, la modernisation des applications peut débuter pour concrétiser le potentiel d’innovation énorme apporté par le nouvel environnement conforme à l’état de l’art: interface web, restructuration du monolithe en microservices «conteneurisés», intégration de services tiers, migration vers le cloud, etc. La cure de jouvence peut être complète mais réalisée de manière graduelle sur une base continue de réduction des risques dus aux changements.

Une transformation d’applications mainframe apparaît souvent comme une genèse, avec toute la durée et les efforts qu’elle telle démarche ex-nihilo peut suggérer. Le ré-hébergement en mode binaire marque une rupture fondamentale: les applications peuvent être déplacées en l’état, donc à très court terme et efficacement avant que le potentiel d’innovation pour le métier de la nouvelle plateforme d’accueil ne soit effectivement concrétisé de manière graduelle, dans des itérations successives de modernisation qui sont d’ailleurs souvent financées par les économies réalisées lors de la transition.