Deux organisations disposant de portefeuilles COBOL de taille similaire optent pour des stratégies de modernisation différentes. L'une choisit une migration de plateforme : elle transfère ses programmes COBOL vers une infrastructure cloud via AWS Mainframe Modernization ou une couche d'émulation COBOL, préservant ainsi le code tout en éliminant le mainframe physique. En dix-huit mois, elle réduit ses coûts d'infrastructure de 40 % et le programme est considéré comme une réussite. L'autre organisation tente la même approche, se heurte à un obstacle après douze mois et se réoriente vers une refonte de son architecture, en reconstruisant les programmes les plus critiques sous forme de microservices Java. Ce changement de cap double le budget initial et prend trois années supplémentaires.
Même point de départ. Résultats radicalement différents. La différence ne résidait ni dans les outils, ni dans les fournisseurs, ni dans les équipes. Elle tenait au fait que la seconde organisation a opté pour une migration de plateforme pour des systèmes dont l'architecture était incompatible avec la nouvelle plateforme : dépendances transactionnelles CICS, structures de fichiers VSAM et exigences temps réel que le code migré ne pouvait satisfaire sans une refonte complète. Cette décision a été prise avant même que quiconque comprenne suffisamment les systèmes pour la mener à bien.
Identifiez rapidement les obstacles à la réarchitecture
SMART TS XL Identifie automatiquement la profondeur de couplage CICS, la complexité VSAM et le code mort dans l'ensemble de votre portefeuille COBOL.
En savoir plusCe que chaque chemin signifie concrètement pour COBOL
Les définitions génériques sont bien connues. Ce qui importe, c'est la signification spécifique de chaque chemin pour les programmes COBOL, dont l'architecture, le modèle d'exécution et les structures de données diffèrent des applications modernes, influençant directement la viabilité de chaque chemin.
Migration de COBOL
La migration de programmes COBOL vers un nouvel environnement d'exploitation, généralement une infrastructure cloud, préserve en grande partie le code. Le code COBOL est compilé et exécuté sur la nouvelle plateforme, soit nativement (à l'aide du compilateur COBOL d'IBM sous Linux), soit via une couche d'émulation qui intercepte les appels spécifiques au mainframe (CICS, VSAM, JES) et les traduit en équivalents natifs du cloud.
Ce que la replatformisation conserve :
- Le code source COBOL
- La logique, les calculs et les règles métier du programme
- Le modèle d'exécution par lots (boucles PERFORM, traitement séquentiel des fichiers)
- Les structures de données (organisation des enregistrements, définitions des copies)
- La structure de tâche JCL (réécrite pour le nouveau planificateur, mais logiquement équivalente)
Quels changements liés à la refonte de la plateforme :
- L'infrastructure physique (z/OS → Linux sur le cloud)
- Le sous-système d'E/S (VSAM → stockage de fichiers géré ou base de données, selon l'outil)
- Le planificateur de tâches (JES2/JES3 → AWS Batch, Azure Logic Apps ou équivalent)
- Le modèle de coûts (facturation basée sur les MIPS → facturation cloud basée sur la consommation)
À retenir : La migration vers une nouvelle plateforme est la solution appropriée lorsque le problème provient de la plateforme elle-même, du coût d’exécution de z/OS, de la dépendance à l’infrastructure ou du modèle de facturation MIPS. En revanche, elle est inappropriée lorsque le problème réside dans le code ou l’architecture.
Réarchitecture de COBOL
La réarchitecture modifie fondamentalement la conception du système. La logique métier est conservée, ou ré-dérivée du code source COBOL, mais elle est implémentée dans un nouveau langage, avec un nouveau modèle d'exécution, sur une nouvelle couche de données. Il en résulte un système qui remplit les mêmes fonctions que le COBOL, mais dont la structure est totalement différente.
Quels changements architecturaux :
- Le langage de programmation (COBOL → Java, Python, Go, C#)
- Le modèle d'exécution (traitement par lots → événementiel, en flux continu ou basé sur une API)
- La couche de données (fichiers VSAM → base de données relationnelle, NoSQL, stockage natif du cloud)
- Le modèle transactionnel (CICS pseudo-conversationnel → services RESTful sans état)
- Le modèle d'intégration (jeux de données partagés → contrats d'API, files d'attente de messages)
Ce que la réarchitecture doit préserver :
- Chaque règle métier implémentée par COBOL, y compris les cas limites non documentés
- Chaque calcul, y compris les caractéristiques de précision numérique de l'arithmétique décimale compactée
- Chaque transformation de données, y compris les conversions implicites dans les instructions MOVE
- Chaque condition d'erreur, y compris les codes d'état de fichier spécifiques et les comportements d'arrêt anormal dont les systèmes en aval peuvent dépendre
Attention : l’erreur la plus fréquente lors d’une refonte d’architecture est de découvrir que le code COBOL contenait des règles métier jamais documentées. Le nouveau système se comporte alors différemment de l’ancien dans certains cas particuliers, non pas à cause d’une erreur d’implémentation, mais parce que la spécification était incomplète. Il est donc impératif d’extraire et de documenter la logique métier du code source COBOL avant toute refonte.
Les facteurs spécifiques à COBOL qui modifient cette décision
Les cadres de modernisation génériques considèrent la refonte de la plateforme et la réarchitecture comme des décisions reposant principalement sur le coût, le calendrier et le risque. Dans le cas du COBOL, plusieurs facteurs techniques propres au langage et à son environnement d'exécution orientent fortement la décision dans un sens ou dans l'autre.
Dépendances des transactions CICS
CICS (Customer Information Control System) est le middleware de traitement transactionnel utilisé par de nombreux programmes COBOL pour les charges de travail interactives. Un programme COBOL effectuant des appels EXEC CICS dépend implicitement du serveur de transactions CICS pour la gestion des écrans, la communication avec les terminaux, la répartition des tâches et le contrôle du programme.
Conséquences d'une migration de plateforme : des outils comme l'émulation CICS de Micro Focus, OpenFrame et certaines fonctionnalités de modernisation des mainframes AWS émulent la sémantique CICS. Si l'utilisation de CICS est standard et conforme aux bonnes pratiques, l'émulation peut fonctionner. En revanche, si le programme repose sur des éléments internes de CICS (manipulation de zones de communication, contrôle des points de synchronisation, stockage au niveau des tâches), la fidélité de l'émulation se dégrade.
Conséquences de la refonte architecturale : Un programme CICS converti en API REST doit voir son modèle transactionnel pseudo-conversationnel repensé pour fonctionner avec des interactions sans état. Il s’agit d’une modification architecturale, et non d’une simple traduction de code.
Signes incitant à une réarchitecture : utilisation intensive de CICS avec une gestion complexe des zones de communication, un chaînage de transactions back-end ou une logique de points de synchronisation.
Architecture des fichiers VSAM
VSAM (Virtual Storage Access Method) est le système de fichiers indexé utilisé par la plupart des programmes de production COBOL. Les fichiers VSAM possèdent des modèles d'accès spécifiques (KSDS séquentiel par clé, ESDS par séquence d'entrée, RRDS relatif) qui n'ont pas d'équivalents directs dans le stockage natif du cloud.
Conséquences de la migration : les couches d’émulation traduisent les opérations de lecture et d’écriture VSAM en opérations sur les fichiers ou bases de données sous-jacentes. Pour un accès séquentiel ou par clé simple, cela fonctionne. En revanche, pour un accès complexe par clés alternatives, des clusters VSAM partagés entre plusieurs programmes ou des accès aléatoires critiques en termes de performances, l’émulation engendre une latence et une complexité accrues.
Conséquences de la réarchitecture : le remplacement de VSAM par une base de données relationnelle nécessite de mapper les structures d’enregistrement aux schémas de table, de gérer les conversions implicites de types de données et de réécrire chaque accès aux fichiers pour utiliser SQL ou un ORM.
Signes incitant à une refonte architecturale : fichiers VSAM partagés entre de nombreux programmes, modèles d’accès aux index alternatifs ou exigences de performances en temps réel que l’émulation ne peut satisfaire.
Exigences de traitement par lots par rapport aux exigences en temps réel
Les programmes batch COBOL sont conçus pour traiter de grands volumes d'enregistrements de manière séquentielle, selon des fenêtres de traitement planifiées. De nombreux systèmes bancaires, d'assurance et gouvernementaux exécutent encore des traitements batch nocturnes qui traitent des millions de transactions, génèrent des rapports et mettent à jour les fichiers maîtres.
Conséquences d'une migration de plateforme : la sémantique des traitements par lots s'adapte parfaitement à l'exécution par lots dans le cloud (AWS Batch, Azure Batch). Le modèle de traitement séquentiel est conservé malgré le changement de plateforme. Si le besoin est simplement d'exécuter le même traitement par lots sur une infrastructure moins coûteuse, une migration de plateforme y répond directement.
Conséquences d'une refonte architecturale : si les besoins métier ont évolué (traitement par lots nocturne vers traitement quasi temps réel, échange de fichiers vers intégration API, exécutions par lots monolithiques vers microservices déclenchés individuellement), une simple migration de plateforme ne suffira pas. L'architecture doit être repensée.
Signes incitant à une refonte architecturale : exigences des parties prenantes en matière de traitement en temps réel, d’intégration basée sur les API, d’architecture événementielle ou de temps de réponse inférieurs à la seconde que la sémantique par lots ne peut pas fournir.
Logique métier intégrée sans spécification externe
Il s'agit du facteur spécifique au COBOL le plus sous-estimé. Les principaux risques incluent la perte de règles métier critiques intégrées à du code vieux de plusieurs décennies et une documentation insuffisante du comportement du système. Les programmes COBOL contiennent souvent la seule spécification subsistante d'une règle métier. La réglementation exigeant un calcul précis a été rédigée en 1983. L'analyste métier qui la maîtrisait a pris sa retraite en 2001. Le code COBOL n'est pas seulement une implémentation, il en est la documentation.
Conséquences de la migration de plateforme : les règles métier sont préservées car le code est conservé. C’est l’un des arguments les plus convaincants en faveur de la migration de plateforme.
Conséquences de la réarchitecture : les règles métier doivent être extraites du code source COBOL avant d’être réimplémentées. <cite index=”28-1″>Un code non documenté et fortement couplé multiplie les efforts à chaque étape.</cite> Si cette extraction est incomplète, le nouveau système aura une spécification différente de l’ancien, et ces différences apparaîtront en production.
Un cadre de décision : huit questions
Avant de choisir une voie, ces huit questions permettent de recueillir les éléments nécessaires pour prendre une décision en toute confiance plutôt que par supposition.
1. Quel est le principal moteur de cette modernisation ?
- Coût de l'infrastructure → une refonte de la plateforme est suffisante
- Dépendance à la plateforme (z/OS) → une replatformisation est suffisante
- Exigences en temps réel → une refonte architecturale est nécessaire
- Exigences d'intégration (API) → une refonte architecturale est probablement nécessaire
- Maintenabilité / disponibilité des talents → réarchitecturer ou refactoriser
2. Quel est le niveau de couplage CICS ? Énumérez chaque appel EXEC CICS. Comptez les programmes comportant plus de vingt commandes CICS distinctes. Les programmes fortement couplés à CICS sont de mauvais candidats à la migration si la fidélité de l’émulation est incertaine.
3. Quels sont les schémas d'accès aux fichiers VSAM ? Identifiez les programmes accédant aux fichiers VSAM avec des clés alternatives, des clusters partagés ou des accès aléatoires sensibles aux performances. Ce sont des indicateurs de risque de migration.
4. La logique métier a-t-elle été documentée en externe ? Si le code source COBOL est la seule spécification faisant autorité, la réarchitecture nécessite l’extraction de la logique métier comme étape préalable, et non comme tâche parallèle.
5. Quelle est la tolérance de la fenêtre de traitement par lots ? Si l’entreprise a besoin du même modèle de traitement par lots à moindre coût, il convient de changer de plateforme. Si elle a besoin que le même traitement soit disponible en temps réel, il est nécessaire de repenser l’architecture.
6. Quelle est la complexité des dépendances ? Un programme comportant cinquante dépendances en aval (ensembles de données, sous-programmes, appelants JCL) présente un risque de réarchitecture plus élevé qu’un utilitaire autonome. La structure des dépendances détermine la séquence de migration et le périmètre des tests.
7. Quel est le pourcentage de code mort ? Exclure le code mort du périmètre avant toute conversion réduit l’effort pour les deux approches. Dans le cadre des programmes de réarchitecture, le code mort non exclu est converti à plein coût, puis supprimé.
8. Quelle est la distribution de la complexité ? Une complexité cyclomatique supérieure à 50 par programme, ou plus de vingt copybooks inclus, indique des programmes dont la réarchitecture est coûteuse et le changement de plateforme risqué. Ces programmes nécessitent une attention individuelle plutôt qu’une attribution de chemins d’exécution en masse.
Application du cadre de référence : Quatre profils de système COBOL
| profil | Caractéristiques | Chemin recommandé | Raisonnement |
|---|---|---|---|
| Utilitaire de traitement par lots stable | Entrées/sorties de fichiers séquentielles, sans CICS, logique bien documentée, faible complexité | Replateforme | Le coût de la plateforme est le problème ; le code n'est pas la contrainte. |
| transaction en ligne fortement axée sur CICS | Utilisation intensive d'EXEC CICS, dépendances de zones de virgules, modèle pseudo-conversationnel | Réarchitecte | Le risque lié à l'émulation CICS est élevé ; les exigences en temps réel sont susceptibles de se produire. |
| Processeur de fichiers maîtres VSAM | Modèles d'accès VSAM complexes, partagés par de nombreux programmes, volume de lecture élevé | Évaluer d'abord la fidélité de l'émulation ; changer de plateforme si l'émulation est satisfaisante. | L'émulation VSAM est la variable de décision |
| Trésorerie de la logique métier | Règles non documentées, absence de spécifications externes, importance réglementaire élevée | Extraire d'abord la logique, puis choisir | Le risque de réarchitecture est inacceptable sans extraction préalable de la logique métier. |
Point clé : <cite index=”30-1″>En pratique, les grands parcs informatiques combinent différentes approches : migration des composants stables, refactorisation du code difficile à maintenir, réécriture des quelques systèmes nécessitant de nouvelles fonctionnalités et mise hors service des systèmes obsolètes.</cite> La décision n’est pas prise au niveau du portefeuille, mais au niveau de la charge de travail, et est appliquée individuellement à chaque programme ou groupe de programmes en fonction des éléments de preuve.
L’approche hybride : d’abord une refonte de la plateforme, puis une réarchitecture si nécessaire.
Une règle pratique : réhéberger ou replatformiser pour stopper rapidement l’hémorragie, puis remanier ou réarchitecturer les systèmes qui constituent de véritables atouts concurrentiels.
Pour la plupart des organisations possédant d'importants portefeuilles COBOL, la séquence pratique est la suivante :
Phase 1 : Migration des applications clairement identifiées. Les programmes sans CICS, avec des E/S séquentielles simples, une logique documentée et une faible complexité, peuvent être migrés avec un effort et un risque prévisibles. Cela permet de réduire rapidement les coûts d’infrastructure et de renforcer la confiance au sein de l’organisation.
Phase 2 : Évaluation des programmes complexes. Les programmes intégrant CICS, des modèles VSAM complexes ou une logique métier non documentée nécessitent une analyse individuelle avant tout choix de solution. C’est à ce stade que l’extraction de la logique métier et l’analyse structurelle déterminent la nécessité d’une refonte et son étendue.
Phase 3 : Réarchitecture des programmes présentant des blocages architecturaux. Les programmes qui ne peuvent satisfaire aux exigences métier sur l’infrastructure migrée (exigences temps réel, intégration API, traitement événementiel) sont réarchitecturés selon le modèle « Strangler Fig » : le nouveau service est développé en parallèle du programme migré, le trafic est progressivement acheminé vers la nouvelle implémentation à mesure que chaque composant est validé, et l’ancien programme est mis hors service une fois tout le trafic migré.
Phase 4 : Mise hors service des programmes obsolètes. Les programmes identifiés comme obsolètes lors de l’analyse structurelle sont exclus des deux voies de développement et mis hors service, ce qui réduit les coûts de maintenance sans nécessiter de conversion.
Résultats que l'analyse doit produire avant toute décision
Le cadre de décision présenté ci-dessus donne de meilleurs résultats lorsque les données d'entrée sont des preuves plutôt que des estimations. L'analyse structurelle qui fournit ces données d'entrée nécessite l'analyse du code source COBOL lui-même, plutôt que de s'appuyer sur la documentation ou les connaissances des développeurs.
Ce que l'analyse doit établir pour chaque programme :
Un inventaire complet des programmes, incluant ceux non documentés. Dans les grands environnements COBOL, le nombre de programmes non documentés dépasse souvent 20 % du total. Un graphe de dépendances indiquant quels programmes s'appellent entre eux, quels jeux de données sont partagés et quels travaux JCL invoquent quels programmes. Un inventaire des commandes CICS pour chaque programme, précisant leur nombre, leurs types et leur complexité. Une analyse des modèles d'accès VSAM : méthodes d'accès, fichiers partagés et fichiers possédant des index alternatifs. Une distribution de la complexité cyclomatique : programmes structurellement simples et candidats à haut risque de conversion. Identification du code mort : programmes et paragraphes sans chemin d'exécution entrant. Extraction de la logique métier : règles implémentées par chaque programme, sous une forme permettant de valider la sortie de chaque chemin d'exécution.
Sans cet inventaire, la décision concernant la migration est prise sur la base d'informations incomplètes. Les programmes sont affectés à une nouvelle plateforme en se basant sur des hypothèses qui s'avèrent erronées lorsque l'émulation révèle des contraintes architecturales invisibles lors de la planification.
Comment SMART TS XL Produit les éléments de preuve préalables à la décision
SMART TS XL's modernisation de l'héritage L'analyse automatise l'inventaire structurel décrit ci-dessus, en analysant simultanément chaque programme COBOL, copybook, tâche JCL et référence de fichier VSAM pour construire le modèle de dépendance unifié qui rend la décision de chemin fondée sur des preuves.
La cartographie des dépendances de l'application produit le graphe d'appels inter-programmes et la carte de partage des ensembles de données qui déterminent la complexité des dépendances, le facteur qui affecte le plus directement à la fois le risque d'émulation de replatformage et la portée et le séquencement de la réarchitecture.
L' analyse statique du code génère des indicateurs de complexité, des inventaires d'appels CICS et identifie le code mort pour chaque programme du portefeuille. Les programmes dépassant le seuil de complexité cyclomatique et présentant un fort couplage CICS sont automatiquement identifiés comme candidats à une réarchitecture ou à une évaluation, plutôt que d'être massivement affectés à une migration de plateforme.
L' expansion JCL résout les paramètres symboliques et construit la chaîne complète de dépendances d'exécution par lots, indiquant quels travaux JCL invoquent quels programmes, dans quelle séquence, avec quels ensembles de données, fournissant ainsi le contexte opérationnel qui détermine comment la sortie de chaque chemin doit se comporter pour satisfaire la planification par lots.
L' analyse d'impact permet de définir précisément le périmètre de chaque projet avant même son lancement : pour tout programme sélectionné pour une réarchitecture, elle recense tous les programmes dépendants qui doivent être mis à jour, testés à nouveau ou coordonnés avec le composant réarchitecturé. Pour les programmes candidats à une migration de plateforme, cette même analyse identifie les ensembles de données et les sous-programmes partagés qui créent des dépendances inter-programmes nécessitant une gestion cohérente.
La recherche d'entreprise permet d'interroger l'inventaire complet dans tout le programme : trouvez en quelques secondes tous les programmes qui utilisent une commande CICS spécifique, tous les programmes qui accèdent à un cluster VSAM spécifique, tous les copybooks qui définissent une structure de données spécifique, sur des millions de lignes de COBOL.
Les organisations qui prennent cette décision correctement sont celles qui se basent sur des données structurelles plutôt que sur des hypothèses de plan de projet. Les données structurelles sont ce qui SMART TS XL produit.
