Contrôler / moderniser son Mainframe

 

Contrôler / moderniser son Mainframe

Avec la montée en puissance des technologies efficaces, en particulier dans le Cloud, la modernisation des environnements Mainframe est devenue une priorité stratégique pour de nombreuses entreprises. 

Mais moderniser des systèmes dont on n'a pas forcément une grande maîtrise n'est pas toujours simple. L'automaticité est une vraie option.   

 

Le Mainframe est encore bien en vie !

Le mainframe, avec plus de 60 ans d'existence, doit sa survie à sa sécurité, caractéristique clé. Comme il héberge des données stratégiques, il se distingue par sa fiabilité, sa tolérance aux pannes et ses systèmes de chiffrement avancés, essentiels pour certains secteurs. 

 
 

2 stratégies principales

sont mises en œuvre ici et là

1- Sortie du Mainframe 

La stratégie adoptée ces dernières années a souvent consisté à en sortir purement et simplement, en conservant les applications telles quelles, ou en les modernisant. Cette approche est désormais moins en vogue. 

 

2- Modernisation du Mainframe 

De plus en plus d'entreprises se tournent vers une modernisation des applications directement sur le Mainframe, en les rationalisant, en les migrant vers des langages plus « actuels », ou en exploitant des technologies tierces, ce qui est désormais possible sur le Mainframe.

Dans tous les cas, bien que le Mainframe reste une plateforme clé pour 89 % des grandes entreprises, il tend à s'alléger progressivement ou à devenir hybride en bifurquant vers le Cloud. C'est ce que dit une étude récente de l'ESN Kyndryl conduite par le cabinet Coleman Parkes.

Mais sortir ou moderniser le Mainframe, pas simple... 

Les compétences sont rares : les jeunes ingénieurs sont rarement formés à ces technologies, considérées comme datées. De l’autre côté de la pyramide des âges, si on doit évoquer le Cobol qui est le langage emblématique du Mainframe, les cobolistes sont souvent à la retraite ou s'en approchent... .

Quant aux  traitements gérés dans les Mainframes, ils sont sensibles, massifs, et il ne saurait y avoir la moindre interruption de service ou régression.

 

2 stratégies

pour changer les choses en douceur

1- Une cartographie continue du système avec le data lineage 

Notre parti pris est de faire du "reverse engineering" dynamique du code Cobol avec {openAudit}, et de présenter les flux graphiquement, sous forme de "cartes" reposant sur le data lineage. Ces cartes dynamiques peuvent être ultra granulaires, ou plus ensemblistes.

Les spécificités de Cobol sont traitées :  

  • Les Programmes (.cbl),
  • Les fichiers Structures (.cpy).


Agrémenté d’un moteur de recherche, ce data lineage permet de définir pour chaque donnée, son origine et son devenir.  Et il permet d'accéder aux règles de gestion sous-jacentes. Les usages de l'information peuvent être inclus dans l'analyse. 

Ce data lineage repose sur une base de données continuellement rafraîchie, ouverte et documentée, qui permet d'opérer d'innombrables analyses. 

 

Ainsi, la plateforme n'a plus de secret pour personne, cobolistes ou non cobolistes. Elle peut être maintenue aisément, optimisée, partiellement décommissionnée, etc. 

Ce data lineage peut être étendu à un large scope de technologies pour épouser le Système d'Information au complet (y compris la couche de data visualisation). C'est en particulier le cas avec DB2 qui est souvent associé au Cobol dans le Mainframe.

 

2- Catalyser les  migrations en SQL standard, en automatisant le process

  • {openAudit} va "parser" le Cobol, il va décomposer toute la complexité du code grâce à une grammaire permettant des analyses exhaustives et ultra granulaires. Toutes les subtilités du Cobol vont être prises en considération. 
  • {openAudit} en déduit la cinématique d’ensemble et l’intelligence, qui seront reconstruites dans un arbre algorithmique agnostique,
  • Sur cette base, {openAudit} va produire du "SQL standard",
  • Puis l’intelligence va être reconstruite a minima dans le SQL spécifique de la base de données cible, 
  • Tous les traitements complexes, non reproductibles en SQL simple, seront traités par un langage tiers. 

 

La migration peut donc s'opérer efficacement, qualitativement. 

 

Conclusion 

Si de nombreuses entreprises hésitent encore à moderniser leurs systèmes Mainframe et Cobol, la combinaison de la cartographie dynamique des flux via le data lineage et l’automatisation de la migration avec {openAudit} offre une solution claire et efficace pour franchir ce pas. La modernisation peut avancer à grand pas, les yeux ouverts.

 

Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Le data lineage, l’arme idéale pour la Data Loss Prevention ?