On a l’impression d’une ritournelle, d’une prédiction de Nostradamus qui ne se concrétise jamais… “Le mainframe est mort!”. Depuis environ trois décennies, la relégation aux oubliettes de ces “dinos” électroniques a souvent été annoncée. Souvenez-vous des prédictions en ce sens qui ont accompagné l’apparition des minis, celle ensuite des PC survitaminés et de leur promesse de démocratisation des infrastructures, et, enfin, l’avènement du cloud.

Et pourtant, les partisans du mainframe continuent d’y croire dur comme fer et de baser sur lui une partie non négligeable de leur stratégie et de leurs activités. NRB est parmi eux.

A en croire Henri Arnold, responsable de la division Mainframe Integrated Solutions chez NRB, de nouveaux éléments sont même venus renforcer leur conviction au cours des deux dernières années. Ils concernent aussi bien la sécurité des données (chiffrement), l’accélération des accès (pour une accélération des temps de réponses particulièrement utile dans des contextes de traitement analytique) qu’une sorte de dé-ringardisation des applications héritées du passé via de nouveaux processus de modernisation différenciée.

Plus question, dans ce dernier registre, de penser à réécrire les applications “legacy”, comme il en fut un temps question. La recette, désormais, est l’“APIsation” des applications mainframe. Autrement dit, explique Henri Arnold, la fragmentation des énormes codes mainframe existants, en leur appliquant de l’intelligence artificielle (IA) afin de les segmenter en blocs pertinents, sur base de leur signification et rôle par rapport à des requêtes et finalités.” De quoi les transformer en services API utiles et consommables.

“L’IA permet de relire et de passer au crible les codes source et de comprendre ces codes spaghetti dans lesquels il est difficile d’effectuer des changements.”

Le but est aussi de permettre aux responsables business de disposer des outils nécessaires pour développer ou gérer leurs propres besoins applicatifs. “Le but est de rendre les moteurs de règles directement exploitables par le business, de les “externaliser” en quelque sorte entre les mains du business”, sans plus devoir solliciter systématiquement l’intervention des équipes de techniciens hyper-pointus – et de plus en plus rares – capables d’agir sur le code mainframe. 

Le mainframe et l’air du temps

Aux yeux d’Henri Arnold, IBM a procédé, ces deux dernières années, à quelques inflexions stratégiques – au rayon mainframe – qui étaient nécessaires pour éviter leur obsolescence. La nouvelle réalité (informatique) étant ce qu’elle est, le mainframe se devait de jeter des passerelles et des fils de dialogue avec le monde des applis mobiles, des environnements hébergés sur des plates-formes cloud…

D’où quelques annonces essentielles, à ses yeux, tels que zOS Connect, “qui permet au mainframe de dialoguer avec le monde extérieur via échange de micro-services et d’API avec les solutions cloud.”

Henri Arnold (NRB): “Les clients, désormais, ne sont plus tentés par un scénario de réécriture des programmes mainframe ou par le remplacement du mainframe. Neuf fois sur dix, ce genre de projet n’allait d’ailleurs jamais jusqu’au bout…”

Le mainframe se plie par ailleurs davantage aux contraintes et à l’immédiateté du big data et des données IoT: “le dialogue et les échanges d’informations, pour alimenter les transactions, se font désormais en temps réel.” La capacité qu’a désormais le mainframe de rafraîchir les données en temps réel, et non plus via des mises à jour différées, lui sauve en quelque sorte la vie. “Cela permet de garder les applications et les données là où elles sont [depuis des lustres] et là où elles bénéficient des atouts historiques du mainframe, en termes de stabilité, de puissance “élastique” et de sécurité notamment, cette dernière ayant été renforcée par un regain de mécanismes de chiffrement.”

Nouveaux métiers

Le fait de disposer désormais de nouveaux outils et mécanismes rendant davantage exploitables l’héritage applicatif mainframe ne signifie toutefois pas que l’exploitation de ce “legacy” se fait d’un coup de baguette magique.

De nouvelles compétences deviennent nécessaires, souligne Henri Arnold. Plusieurs profils et métiers se font jour. Voici comment il les voit: “Des analystes programmeurs orientés API front end, capables de rendre les programmes existants “APIsables” et de concevoir une couche intermédiaire qui permettra d’activer les micro-services. Mais aussi des développeurs zOS Connect et ESB (pour la couche d’intégration). Et des développeurs d’applications Java.”

NRB compte d’ailleurs mettre en oeuvre, dans les trimestres à venir, une division et une activité proposant ce genre de profils: “Nous ne sommes plus dans l’outsourcing de mainframe pur et dur mais dans l’outsourcing du développement d’applications.”

La raison – et l’opportunité? “Les [grandes] entreprises [Ndlr: celles qui s’appuient encore sur des mainframes] ne disposent désormais plus, chez elles, ou ne veulent plus mobiliser en interne une équipe de 20 ou 40 développeurs, chargée de pérenniser leurs applications. Elles feront de plus en plus appel à des spécialistes externes…”

Le langage Java est considéré, par NRB, comme un autre élément essentiel de la “seconde jeunesse” du mainframe. “Les programmes en Cobol et en PL1 survivront encore sans doute en 2030” mais les compétences pour les entretenir et, à plus forte raison, pour en écrire de nouveaux se font toujours plus rares. Les nouveaux programmes sont donc écrits, d’emblée, en Java ou en JavaScript. “C’est là quelque chose qui n’était pas réellement possible voici deux ou trois ans, notamment pour des questions de coûts et de charge CPU. Mais, depuis lors, Java v.8 a fait son apparition, apportant nombre d’améliorations, avec un potentiel multi-threading et un embarquement sur un processeur dédié ZIP (Integrated Information Processor) qui réduit les coûts de consommation de programmes Java. Cela favorise les développements en Java ou JS…”

D’autant plus qu’IBM a imaginé une tarification différenciée – et avantageuse – pour de nouveaux développements, réduisant drastiquement le coût au MIPS dès l’instant où il est dédié à ce genre de nouveaux développements… Ce principe du “container pricing”, de la “conteneurisation”, a d’ailleurs été étendu à la facturation des nouvelles applications une fois mise en production.

Le tarif appliqué, négociable client par client, dépend essentiellement du nombre de transactions effectuées sur une période déterminée et non plus selon le principe du “pic” de MIPS consommés.