Comment faire évoluer ses mainframes pour répondre aux nouveaux besoins en agilité

Des projets de modernisation impactants et complexes au niveau technologique et humain

Les projets de gestion d’obsolescence des anciens programmes de développement (PowerBuilder, Natural encore Pacbase) sont une réalité très impactante pour les grandes organisations au niveau fonctionnel et technique, mais aussi en termes de coûts.

Pacbase par exemple, atelier de génie logiciel mainframe qui intègre un générateur de Cobol, est largement répandu dans les grands comptes. Il est souvent plébiscité pour l’efficacité importante qu’il apporte aux équipes de développement. Cependant, sa problématique est que le Cobol généré est très peu lisible, donc peu maintenable.

Autre enjeu : les applications héritées sont constituées de milliers voire de millions de lignes de code. Elles sont complexes, car elles résultent d’années de développement et de maintenance pour se conformer aux nouvelles règles métier ou à des mises à niveau techniques. Et elles sont aussi composites impliquant à la fois un patrimoine mainframe et distribué.

À l’obsolescence des outils – couplée à la nécessité de pouvoir explorer, comprendre et transformer ces millions de lignes de code – s’ajoute la question de la fédération des équipes de développement tous départements confondus.

Les développeurs cobol expérimentés ont besoin d’un fort accompagnement au changement. Quant aux « jeunes », ils souhaitent utiliser des outils modernes pilotés par des outils de pipeline familiers.

Le passage d’un langage distribué – avec des fonctionnalités déjà données et des mots clés – à un langage low level comme Cobol peut s’avérer complexe. Face à la désinfection des collaborateurs, aux manques d’expertises internes ou aux départs à la retraite, les entreprises ont pour volonté de former ou de reconvertir leurs collaborateurs à l’open ou au mainframe, et de sortir de leurs anciens programmes en se tournant par exemple vers Eclipse ou IBM Developer for z/OS (IDz), basé sur DevOps.

Évoluer vers l’open legacy et le rehosting

Héberger ou basculer les structures des anciennes applications mainframe vers le monde open – plus précisément moderniser les anciennes versions de Cobol vers Cobol V6 et les technologies ZCX, le monde des ZLINUX (Open SHIFT, REDHAT, GH) et les APIs (Open LEGACY) – nécessite de faire du rehosting.

Cette étape de basculement des applications permet de conserver les habitudes de travail tout en évoluant vers des plateformes plus modernes.

Il est possible également de faire évoluer son SI partiellement, en ne migrant uniquement qu’une ou quelques applications.

Les solutions de modernisation préservent l’investissement et le patrimoine applicatif tout en offrant le bénéfice d’utiliser des plateformes distribuées qui offrent des facilités transparentes d’intégration avec les nouvelles technologies.

Quatre points à considérer dans la démarche de transformation mainframe

• L’agile doit s’aligner avec les enjeux de Time To Market. Cela suggère de faire évoluer la gestion des livraisons logicielles habituellement de type « composant par composant » en une gestion des livraisons par configuration applicative, avec utilisation d’outils comme GIT.
• Automatisation de tests sur mainframe (tests unitaires et de non-régression). Les tests automatisés constituent le chaînon manquant des mainframes pour atteindre le niveau d’agilité et d’adaptation DevOps attendu. Pour cela il est nécessaire d’automatiser la conception, l’itération et l’exécution des tests unitaires, d’intégration et de non-régression avec une approche « shift left » et des outils qui étendent les capacités d’automatisation et de gestion de données de tests sur mainframe. Le prérequis à ces tests automatisés sera la mise en place d’un « ZDevops » avec l’utilisation de GIT Lab ou de Jenkins pour construire une chaîne CI/CD. Des outils de RPA peuvent aussi être utilisés pour automatiser des tests d’intégration ou des tests fonctionnels.
• Appliquer de l’IA générative, du chiffrement et de la cryptologie pour protéger les activités notamment contre les fraudes. L’accélérateur présent sur le processeur Telum du nouveau Z16 IBM utilise un modèle d’inférence d’IA effectuée sur le processeur qui analyse en détail les processus massifs de transaction se déroulant au sein du mainframe. z16 est équipé d’une carte Crypto Express 8S (CEX8S) qui chiffre les données en mémoire dès le démarrage de la machine empêchant de facto toute infiltration de malware.
• IBM Watson : impact sur le mainframe et sur l’analyse du patrimoine applicatif. Avec IBM Watson Machine Learning for z/OS, il est possible de déployer des modèles au sein de z/OS pour analyser le code source des applications existantes et ainsi aider à comprendre et à évaluer le patrimoine applicatif. Watsonx Code Assistant for Z permettra en plus de suggérer et de convertir du code des applications COBOL vers du Java s’exécutant sur z/OS.

Conclusion

La transformation mainframe est en marche. Son objectif est d’arriver à concilier les mondes open et mainframe. Les organisations appliquent aujourd’hui de nouvelles stratégies et de nouvelles pratiques qui visent à redynamiser l’environnement de développement, à supprimer toute technologie obsolète, à automatiser les tests tout en intégrant de l’Intelligence artificielle. Car oui, il est possible, in fine, de transformer le mainframe en une plateforme DevOps moderne et agile.