Reprendre le contrôle de son patrimoine Cobol /migrer

 

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

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 :     {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 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.