Quelles sont les caractéristiques ou étapes déterminant la différence entre la réussite et l’échec d’une migration hors mainframe ?
Après avoir suivi de tels projets de migration pendant 18 ans (et réalisé à plus de 10 000 consultations sur le thème) chez Gartner, j’ai été témoin de désastres. Chez LzLabs, nous avons développé une technologie qui, selon nous, atténue considérablement les risques.

Néanmoins, nous suggérons quelques éléments clés à prendre en compte dans le cadre d’un projet de migration du mainframe afin d’en garantir la réussite. Les migrations du mainframe sont confrontées à un nombre incroyable de technologies d’applications très variées intégrées au fil des dernières décennies alors que les portefeuilles d’applications croissaient organiquement durant cette période. Le manque de connaissances des règles ou processus métier ainsi que de la technologie d’implémentation peuvent engendrer des risques pour le processus de migration.

Dans un souci d’efficacité, LzLabs recommande 4 étapes déterminantes pour se préparer à la sortie du mainframe et atténuer les risques liés à la migration.

Comprendre le portefeuille informatique : déterminer où vous êtes et où vous allez

La modernisation informatique relève de la responsabilité du directeur informatique et nécessite une vision allant au-delà de la complexité et l’agitation que représentent la gestion des opérations informatiques quotidiennes. Les propriétaires d’applications ont la responsabilité de gérer un portefeuille historique pour les 5 à 10 prochaines années. Le déclin des compétences de gestion opérationnelle et de développement de la plateforme mainframe atteint son apogée, et l’idée commune selon laquelle « la Terre continuera de tourner » relève de la politique de l’autruche. Certains éléments ou peut-être l’intégralité de votre portefeuille d’applications peuvent s’exécuter en dehors du mainframe. La question est de savoir comment on y parvient ! Combien êtes-vous prêts à dépenser ? Combien de temps souhaitez-vous y consacrer ? Quels risques êtes-vous prêts à prendre ?

Bien souvent, l’aspiration la plus commune est d’avoir une application moderne entièrement réécrite en Java ou mise en œuvre via un package logiciel prêt à l’emploi. Il s’agit d’un objectif louable, mais qui coûte cher, pas facile ni même rapide à atteindre. En conséquence, les directeurs informatiques doivent décider quelles applications en valent la peine et lesquelles doivent être plutôt être transformées incrémentalement. Le réhébergement des applications « en l’état » dans un environnement d’infrastructure moderne offre l’avantage immédiat de ses coûts fortement réduits et constitue une base solide pour entamer un effort de modernisation itératif.

Le paradigme prédominant du développement d’applications sur le mainframe correspondait à un portefeuille d’applications développées sur-mesure ou personnalisées. Ce processus s’est poursuivi pendant des décennies auprès d’entreprises qui n’en comprenaient pas toujours les tenants et aboutissants. La relation « fragile » entre code source, documentation et programmes effectivement utilisés représente un problème qui persiste depuis plus de 50 ans. Et la difficulté à identifier précisément quel code source a été utilisé pour la création de certains aspects d’applications déployées de longue date est au cœur des défis que doivent relever certains de ces projets de réhébergement mainframe.

Le responsable informatique d’une grande entreprise se plaignait ainsi : « nous avons environ 100 millions de lignes de COBOL dans notre référentiel de code source, ce qui n’est pas en soi un problème, étant donné que seules 10 millions de lignes sont actives. Le problème, c’est que nous ne savons pas quels sont ces 10 millions. »
Envisager la recompilation ou la réécriture de telles applications afin de pouvoir les exécuter sur une nouvelle plateforme exige un travail dantesque et laborieux consistant à identifier correctement le code source, puis à le rendre disponible pour la migration.

Définir une architecture de référence pour votre avenir

Dans une récente enquête sur la modernisation du mainframe, réalisée par l’agence de recherche Vanson Bourne, nous avons découvert que nos prospects se tournent massivement vers des solutions open source dans leurs décisions de modernisation.
En déplaçant la charge de travail des applications vers un serveur moderne ou un environnement Linux basé sur le cloud, les entreprises peuvent entamer leur parcours sans courir de risques intrinsèques majeurs. La migration des applications pour les exécuter en dehors du mainframe est une bonne chose, mais les différences opérationnelles d’une infrastructure d’exécution moderne et du mainframe doivent être préalablement comprises.

L’objectif ne doit pas être de migrer la totalité de votre portefeuille créé dans le mainframe dans un environnement x86 moderne ou sur le cloud, en reproduisant les approches de pilotage des 50 dernières années. Il faut exploiter le potentiel des solutions open source si les perspectives de bénéfice en valent la peine, sans nécessiter une recompilation complète du code source d’origine.

Quelques conseils à mettre en œuvre :

  1. Tirer parti des solutions modernes de traitement des flux de travail plutôt que de répliquer les ordonnanceurs du mainframe.
  2. Créer des environnements DevOps modernes pour soutenir la maintenance/l’amélioration des applications réhébergées.
  3. Profiter de l’ouverture d’un sgbd moderne comme PostgreSQL pour exposer les données historiques (verrouillées jusqu’à lors) à toutes les possibilités de reporting ou d’analyse ainsi à dispostion.
  4. Mettre en œuvre des solutions modernes d’intégration de la charge de travail qui utilisent des conteneurs Docker, par exemple, dans un environnement de déploiement sur le cloud.

Les entreprises doivent définir une architecture de référence qui exploite tous les composants modernes et ouverts possibles pour remplacer leurs prédécesseurs propriétaires mainframe vieillissants, en fournissant une capacité équivalente voire supérieure sans la « taxe logicielle » de ces fournisseurs.

Initier le changement culturel et investir dans la formation aux nouvelles compétences

La migration des applications historiques mainframe est une chose. La migration « des mentalités » des équipes mainframe en est une autre ! Beaucoup de leurs membres sont sûrement sur le point de partir à la retraite, mais il est essentiel d’aider ceux qui restent à appréhender la valeur du nouvel environnement. L’un de nos principaux clients a identifié ses efforts de migration du mainframe comme un « projet de changement humain» et plusieurs exigences importantes furent requises pour sa réussite :

  • Pour mettre en place un tel projet, la direction générale doit pouvoir bénéficier du soutien d’un leader technique, généralement dans l’équipe mainframe, reconnu et en confiance dans son rôle d’éclaireur pour inspirer les équipes techniques à le suivre.
  • Les critères de succès de la migration doivent être définis avec l’équipe mainframe (et le niveau de leurs attentes ainsi que leur validité doivent être régulièrement examinées à mesure que le projet progresse).
  • Des programmes de formation dédiés, à la fois techniques et culturels, sont nécessaires pour soutenir le changement d’état d’esprit qui est impératif.
  • Le personnel informatique possédant des compétences sur Linux, le logiciel libre (« open source ») et le cloud doit être impliqué pour guider la transition vers une nouvelle plateforme.


Prévoir de tirer parti des anciennes données de nouvelles manières

Les bases de données pré-relationnelles avaient à l’époque un avantage de performances indéniable et reconnu. Mais, déplacer ces données vers un environnement moderne ouvre l’accès à ces données pour une vaste palette d’outils de reporting ou d’analyse. Lorsque vous migrez des applications mainframe historiques, déterminez où ces nouvelles solutions peuvent fournir des fonctions équivalentes sans avoir à utiliser certaines parties de l’application migrée. Éliminez les éléments de l’application qui dépendent de technologies mainframe historiques s’ils peuvent être remplacés par des alternatives modernes. N’essayez pas de déplacer chaque élément d’une application si ce n’est pas impératif. Par exemple, en utilisant le Software Defined Mainframe, le résultat originellement imprimé peut être plutôt importé directement dans Splunk où il devient immédiatement disponible pour une analyse informatisée. Les données relationnelles dans PostgreSQL sont également facilement accessibles à tous les outils modernes de reporting ou d’analyse.

Migrations du mainframe : une recette du succès

À mesure que le déclin des compétences mainframe s’accélère, la procrastination devient une option toujours moins viable. Prenez le temps de comprendre votre portefeuille applicatif existant pour tirer parti de la puissance des solutions open source afin de créer une architecture qui maximise la valeur de ces environnements pour le métier, tout en réduisant l’ampleur du changement nécessaire pour réhéberger votre portefeuille. Le changement n’est pas uniquement technique. Derrière chaque migration réussie se cache un leader ayant eu le courage d’assumer ses convictions. Aidez ceux qui sont prêts à apprendre et à se familiariser avec les nouvelles technologies de Linux et du cloud. Enfin, aidez votre entreprise à comprendre les avantages d’un accès aux données et d’une analyse de celles-ci beaucoup plus simples, ouverts et étendus. Les nouveaux outils peuvent être perçus comme significativement différents des applications historiques écrites il y a 20 ans ou davantage, mais leurs avantages l’emportent incontestablement sur le changement qu’ils induisent.

___________________

Par Dale Vecchio, CMO, LzLabs