Reprendre le contrôle de son patrimoine Cobol /migrer

 

ellipsys
 
 Reprendre le contrôle de son patrimoine Cobol /migrer  
 
Le Cobol, le symbole de  la "dette IT" 
 
 
Les équipes des "Cobolistes" se réduisent
La partie la plus ancienne des systèmes d’information ("legacy system"), est aux mains d’une population de spécialistes dont le nombre ne cesse de se resserrer.  C'est le cas des Cobolistes. Et ces équipes sont souvent submergées de demandes. 
 
Le décommissionnement de Cobol est sans cesse repoussé
Plutôt que d'avoir supprimé ou transformé des couches techniques les plus anciennes, typiquement la couche Cobol, les entreprises les ont empilées pour ne pas prendre de risque. Il est vrai aussi que le Cobol s'est bien acquitté de sa mission jusqu'à ce jour !
Ainsi dans beaucoup d'entreprises, on a contourné le problème au départ des technologies les plus récentes, pour adapter et gérer les formats de données anciens ("compatibilité ascendante"). Ce depuis très longtemps maintenant. 
 
Mais cet état de fait n'est pas irrémédiable
Il faudra commencer par "ouvrir" le système, et le porter à la connaissance de tous, c'est à dire le rendre intelligible par l'ensemble des équipes data. Puis il faudra sérieusement envisager de migrer, car il n'est jamais trop tard pour bien faire 😊. C'est notre proposition. 
 
 
 

 
 
Une cartographie dynamique des flux traités par Cobol (et d'autres langages) 
 

 
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.

Agrémenté d’un moteur de recherche, ce "data lineage" permet de définir pour chaque donnée, son origine, son devenir, et il permet d'accéder aux règles de gestion sous-jacentes. Les spécificités de Cobol sont traitées :  
  • Les Programmes (.cbl),
  • Les fichiers Structures (.cpy),
  • Et les fichiers de Paramètres (.jcl). 
 
 
 
Automatiser la migration de Cobol 
 
ellipsys
 
Une fois que le patrimoine est maîtrisé, la principale difficulté restera sa réécriture dans une technologie tierce, celle qui permettra à l'entreprise de se projeter. Si la réécriture des centaines de milliers / millions de lignes de code n'est pas advenue jusqu'alors, c'est que le "risque perdant" était trop fort. Ça n'est plus le cas avec {openAudit}.  
 
L'automatisation du process permet d'aller vite à la cible, en minimisant les régressions : 
  
  1. {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. 
  2. {openAudit} en déduit la cinématique d’ensemble, et l’intelligence, qui seront reconstruites dans un arbre algorithmique agnostique,
  3. Sur cette base, {openAudit} va produire du "SQL standard",
  4. Puis l’intelligence va être reconstruite a minima dans le SQL spécifique de la base de données cible, 
  5. Tous les traitements complexes non reproductibles en SQL simple, seront pilotés par un exécutable NodeJS, ou autre.
 
 
 
Conclusion 
 
Beaucoup d'entreprises sont légitimement inquiètes à l'idée de sortir de Cobol.
Le choix de l'automatisation, à la fois pour mettre à portée de tous la réalité concrète de ce que le Cobol construit comme flux, et à la fois pour envisager une migration, peut permettre de franchir ce pas de façon simple et efficace. 
 

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 ?