Se libérer de ses Mainframe IBM, rapidement. Deuxième partie
31/08/2016
Dans la première partie de cette analyse, j’ai présenté la solution de la société LzLabs qui permet de migrer une infrastructure Mainframe IBM, serveur Z sous z/OS, vers une plateforme x86/Linux.
Dans cette deuxième partie, je souhaite vous aider à trouver des solutions innovantes pour migrer les usages, les applications Mainframe IBM.
Le point de départ
La migration réussie d’une infrastructure Mainframe IBM vers une plateforme ouverte et plus économique est une étape majeure pour une entreprise. Elle peut décider de s’arrêter là, au moins pendant quelques mois ou années.
L’entreprise peut aussi, de manière complémentaire et indépendante, se poser la question du remplacement de ces applications historiques.
Les chiffres publiés par MicroFocus sur le poids actuel des applications Cobol sont impressionnants et préoccupants.
J’en ai extrait trois éléments :
- 85 % des transactions financières professionnelles sont réalisées en Cobol.
- 95% des opérations des distributeurs de billets sont gérés en Cobol.
- 5 milliards de nouvelles lignes de code Cobol sont développées chaque année. Oui, vous avez bien lu, on parle de «nouvelles» lignes de Cobol.
Ceci est confirmé par les résultats de l’enquête réalisée par MicroFocus et que j’ai déjà citée dans la première partie de cette analyse : 80 % des entreprises prévoient d’avoir un parc d’applications Cobol stable ou en croissance !
Cette situation n’est pas nouvelle : cela fait des années que les entreprises souhaiteraient pouvoir abandonner leurs applications historiques ; cela fait des années que l’usage de ces applications historiques... augmente.
Une autre enquête, réalisée par Vanson Bourne en 2014 et citée par LzLabs confirme ce paradoxe, comme le montre ce graphique.
Peut-on sortir de ce cul-de-sac ou faut-il accepter de rester prisonnier de ses applications historiques pendant encore des années ?
Ma réponse ? Oui, il est possible de se libérer de cet énorme fardeau.
Migration des applications Mainframe IBM : mode d’emploi
Commençons par éliminer la démarche qui vous conduira certainement à l’échec : la tentation de migrer 100 % des applications Mainframe IBM existantes, à l’identique, vers une nouvelle plateforme.
Ce serait une très mauvaise idée, un chantier pharaonique et la garantie d’une catastrophe financière et organisationnelle.
Le pragmatisme et une approche modulaire sont à la base d’une migration réussie.
Première étape : réaliser un inventaire des applications Mainframe IBM existantes et les classer en trois familles :
- Celles qui correspondent à des fonctions support, transverses, universelles : gestion RH, budgets, trésorerie, CRM...
- Les fonctions cœur métier, vraiment spécifiques de l’activité de l’entreprise, qu’elle soit dans le secteur financier, industriel ou de services.
- Les fonctions de gestion administratives back-office, telles que la paye ou la comptabilité.
Cet inventaire peut se réaliser très rapidement, en allant à l’essentiel. Les pourcentages d’applications dans chaque famille seront très différents d’une entreprise à l’autre, mais l’important est que toutes les applications soient placées dans l’une de ces trois catégories.
Deuxième étape : réduire au maximum le nombre d’applications Mainframe IBM à migrer.
Ce schéma présente les différentes pistes permettant de réduire l’empreinte des applications Mainframe IBM dans votre Système d’Information. Il servira de base à toute ce billet.
Usages Support : j’ai publié un billet sur la démarche DUS, Démarche Usages Support. L’hypothèse de travail est très simple : il existe de remarquables solutions SaaS, opérationnelles, qui répondent à 99 % des besoins correspondant aux fonctions support.
Les fonctions Mainframe Support ne seront jamais migrées ; elles seront éliminées, remplacées par des outils SaaS. Ceci a un double avantage :
- On supprime une grande partie du parc applicatif Mainframe IBM.
- On propose un meilleur service aux clients internes de l’entreprise en remplaçant des applications à l’ergonomie archaïque par des applications modernes, accessibles depuis tout objet disposant d’un navigateur.
Usages Cœur Métier (B - Business sur le schéma) : dans le même texte où je parle de la démarche DUS, je propose une autre démarche, DUM, pour les usages métiers. C’est le moment ou jamais pour l’entreprise et les équipes internes de développement de se poser la question : et si on en profitait pour repenser, dans une logique de reengineering de processus, ces applications essentielles ? Les outils modernes de développement, PaaS, Platform as a Service, disponibles sur les grands clouds publics, permettent de construire des applications beaucoup plus performantes, ergonomiques et innovantes. Il faut pour cela que l’entreprise accepte de recréer en interne des équipes d’ingénieurs logiciels, proches des métiers.
Usages Back-Office : Il reste maintenant toute une série d’applications Mainframe IBM qui ne seront pas remplacées par des solutions SaaS ou des développements sur mesure en PaaS. Pour l’essentiel, ce seront des applications de type Back-Office. Ce stock résiduel d’application est un candidat raisonnable pour une migration vers des architectures logicielles plus modernes.
J’ai maintenant une deuxième bonne nouvelle pour les responsables informatiques. J’ai présenté LzLabs pour la migration des infrastructures ; il existe une autre société suisse, basée à Lausanne, Eranea, qui propose des outils de migration des applications Cobol vers des solutions Java/Web.
Ce que fait Eranea est très complexe, et ils ont plusieurs années d’expérience dans ces activités de migration. Une présentation détaillée de leur solution est disponible sur SlideShare.
Les sociétés LzLabs et Eranea se connaissent bien ; Eranea était à Zurich lors de la présentation de LzLabs. Je ne serai pas surpris qu’elles annoncent rapidement des accords de collaboration tant leurs solutions sont complémentaires.
En résumé, il est nécessaire d’utiliser trois démarches différentes pour se libérer, progressivement, de ses applications Mainframe IBM :
- Basculement vers des solutions SaaS des fonctions Support.
- Développement sur mesure pour les usages cœur métier.
- Migration les applications résiduelles avec la solution proposée par Eranea.
Modèle B I S et Mainframe : une stratégie gagnante
Je ne pensais vraiment pas, quand j’ai développé le modèle B I S, Business, Infrastructures, Support, qu’il me rendrait service pour imaginer les démarches et solutions permettant d’envisager, pour la première fois, l’élimination des infrastructures et usages Mainframe IBM dans les grandes entreprises.
Il est très encourageant pour moi de constater que les solutions innovantes qui arrivent sur le marché, comme les offres LzLabs ou Eranea, confortent les visions stratégiques du SI que je présente dans ce blog. Les offres du Cloud Public, IaaS, SaaS et PaaS alliées au modèle B I S permettent, pour la première fois, de proposer des pistes de migration innovantes pour des solutions informatiques, Mainframe IBM, qui sont là depuis 1/2 siècle !
Calendrier réaliste
Combien de temps faudra-t-il pour que cette migration des applications Mainframe IBM soit terminée ?
Les réponses seront très différentes d’une entreprise à l’autre, c’est une évidence. Je vais quand même vous donner une fourchette de temps que j’estime réaliste : entre 3 et 7 années !
Dans quel ordre peut-on mener ce grand et passionnant chantier ?
- Etape 1 : migration des infrastructures Mainframe vers x86/Linux avec LzLabs.
- Etape 2 : recherche des solutions SaaS qui permettent de remplacer les applications Mainframe Support. L’étape 2 peut être menée en parallèle avec l’étape 1.
- Etape 3 : développement sur mesure des usages cœur métiers, en PaaS.
- Etape 4 : migration des applications qui restent avec Eranea.
J’espère croiser, dans les années qui viennent, de nombreux DSI de grandes entreprises qui me diront : «Merci, nous avons réussi à moderniser notre SI en nous libérant de nos Mainframe IBM. Nous avons suivi les pistes que vous avez défrichées pour nous.»