Replatformovat nebo rearchitektovat? Jak zvolit správnou cestu modernizace pro starší COBOL

Dvě organizace s portfoliem COBOL podobné velikosti se přijímají různá rozhodnutí o modernizaci. Jedna provádí replatformu: přesouvá programy COBOL do cloudové infrastruktury pomocí AWS Mainframe Modernization nebo emulační vrstvy COBOL, přičemž zachovává kód a zároveň eliminuje fyzický mainframe. Během osmnácti měsíců sníží náklady na infrastrukturu o 40 % a program je považován za úspěšný. Druhá organizace se pokusí o stejný přístup, po dvanácti měsících narazí na zdí a přejde k rearchitektuře, přičemž nejdůležitější programy znovu vytvoří jako mikroslužby Java. Přechod na novou platformu stojí dvojnásobek původního rozpočtu a trvá další tři roky.

Stejný výchozí bod. Radikálně odlišné výsledky. Rozdíl nebyl v nástrojích, dodavatelích ani týmech. Rozdíl spočíval v tom, že druhá organizace zvolila replatforming pro systémy, které měly architektonická omezení, jež nová platforma nemohla zvládnout, závislosti na transakcích CICS, struktury souborů VSAM a požadavky na reálný čas, které replatformovaný kód nemohl splnit bez zásadního redesignu. Rozhodnutí bylo učiněno dříve, než kdokoli systémům dostatečně dobře porozuměl, aby ho učinil správně.

Co každá cesta vlastně znamená pro COBOL

Obecné definice jsou dobře známé. Důležité je, co každá cesta znamená konkrétně pro programy v COBOLu, kde se architektura, model provádění a datové struktury liší od moderních aplikací způsoby, které přímo ovlivňují, která cesta je životaschopná.

Replatformování COBOLu

Replatforming přesouvá programy v COBOLu do nového operačního prostředí, obvykle cloudové infrastruktury, přičemž kód zůstává z velké části nezměněn. COBOL se kompiluje a běží na nové platformě, buď nativně (pomocí kompilátoru COBOL od IBM v Linuxu), nebo prostřednictvím emulační vrstvy, která zachycuje volání specifická pro mainframy (CICS, VSAM, JES) a překládá je do cloudově nativních ekvivalentů.

Co si replatforming zachovává:

• Zdrojový kód COBOLu
• Logika, výpočty a obchodní pravidla programu
• Model dávkového provádění (smyčky PERFORM, sekvenční zpracování souborů)
• Datové struktury (rozvržení záznamů, definice sešitů)
• Struktura úloh JCL (přepsaná pro nový plánovač, ale logicky ekvivalentní)

Co se změní při replatformingu:

• Fyzická infrastruktura (z/OS → Linux v cloudu)
• I/O subsystém (VSAM → spravované úložiště souborů nebo databáze, v závislosti na nástroji)
• Plánovač úloh (JES2/JES3 → AWS Batch, Azure Logic Apps nebo ekvivalent)
• Nákladový model (fakturace založená na MIPS → cloudová fakturace založená na spotřebě)

Klíčové ponaučení: Replatforming je správný, pokud je problémem platforma, náklady na provoz z/OS, závislost na infrastruktuře nebo fakturační model MIPS. Je to špatná cesta, pokud je problémem kód nebo architektura.

Rearchitektura COBOLu

Rearchitektura mění základní design systému. Obchodní logika je zachována nebo znovu odvozena ze zdrojového kódu COBOLu, ale je implementována v novém jazyce, s novým modelem provádění a na nové datové vrstvě. Výsledkem je systém, který dělá to, co COBOL, ale strukturou se mu nepodobá.

Co se mění při rearchitektuře:

• Programovací jazyk (COBOL → Java, Python, Go, C#)
• Model provádění (dávkový → řízený událostmi, streamovaný nebo založený na API)
• Datová vrstva (soubory VSAM → relační databáze, NoSQL, cloudové úložiště)
• Transakční model (pseudokonverzační CICS → RESTful bezstavové služby)
• Integrační vzorec (sdílené datové sady → API smlouvy, fronty zpráv)

Co musí rearchitektura zachovat:

• Každé obchodní pravidlo implementované v COBOLu, včetně nedokumentovaných okrajových případů
• Každý výpočet, včetně charakteristik numerické přesnosti sbalené desítkové aritmetiky
• Každá transformace dat, včetně implicitních konverzí v příkazech MOVE
• Každý chybový stav, včetně specifických kódů STAVU SOUBORU a chování při ukončení, na kterém mohou záviset následné systémy.

Pozor: Nejčastějším selháním při rearchitektování je zjištění, že COBOL obsahuje obchodní pravidla, která nikdy nebyla nikde jinde zapsána. Nový systém se v určitých hraničních případech chová jinak než ten starý, nikoli kvůli implementační chybě, ale proto, že specifikace byla neúplná. Před zahájením rearchitektování musí být obchodní logika extrahována a zdokumentována ze zdrojového kódu COBOLu.

Faktory specifické pro COBOL, které mění toto rozhodnutí

Generické modernizační frameworky považují změnu platformy a rearchitektování za rozhodnutí primárně týkající se nákladů, časového harmonogramu a rizika. V případě COBOLu několik technických faktorů specifických pro jazyk a jeho běhové prostředí silně ovlivňuje rozhodnutí jedním nebo druhým směrem.

Závislosti transakcí CICS

CICS (Customer Information Control System) je middleware pro zpracování transakcí, který mnoho programů v COBOLu používá pro interaktivní úlohy. Program v COBOLu, který provádí volání EXEC CICS, má implicitní závislost na transakčním serveru CICS pro správu obrazovky, terminálovou komunikaci, dispečing úloh a řízení programu.

Důsledky pro změnu platformy: Nástroje jako emulace CICS od Micro Focus, OpenFrame a některé funkce modernizace mainframeů AWS emulují sémantiku CICS. Pokud je používání CICS standardní a správně fungující, emulace může fungovat. Pokud se program spoléhá na interní funkce CICS, manipulaci s čárkovou oblastí, řízení synchronizačních bodů a úložiště na úrovni úloh, dochází ke snížení věrnosti emulace.

Důsledky rearchitektury: Program CICS převedený na REST API musí mít svůj pseudokonverzační transakční model přepracovaný na bezstavové interakce. Jedná se o architektonickou změnu, nikoli o překlad kódu.

Signál tlačí na rearchitect: Intenzivní využití CICS se složitou manipulací s čárkovou oblastí, řetězením transakcí na back-endu nebo logikou synchronizačních bodů.

Architektura souborů VSAM

VSAM (Virtual Storage Access Method) je indexovaný souborový systém používaný většinou produkčních programů v COBOLu. Soubory VSAM mají specifické přístupové vzory, klíčovaný sekvenční přístup KSDS, záznamový postup ESDS a relativní záznam RRDS, které nemají žádné přímé ekvivalenty v cloudovém úložišti.

Důsledky replatformace: Emulační vrstvy převádějí čtení a zápisy VSAM do podkladových operací se soubory nebo databází. Pro jednoduchý sekvenční nebo klíčový přístup to funguje. Pro komplexní přístup s alternativními klíči, clustery VSAM sdílené mezi více programy nebo výkonově citlivé vzory náhodného přístupu emulace zvyšuje latenci a složitost.

Důsledky pro rearchitektování: Nahrazení VSAM relační databází vyžaduje mapování rozvržení záznamů na schémata tabulek, zpracování implicitních konverzí datových typů a přepsání každého přístupu k souborům pro použití SQL nebo ORM.

Signál tlačící k rearchitektování: Soubory VSAM sdílené mezi mnoha programy, alternativní vzory přístupu k indexům nebo požadavky na výkon v reálném čase, které emulace nedokáže splnit.

Požadavky na dávkové vs. požadavky na práci v reálném čase

Dávkové programy v COBOLu jsou navrženy tak, aby sekvenčně zpracovávaly velké objemy záznamů v plánovaných okenních intervalech. Mnoho bankovních, pojišťovacích a vládních systémů stále spouští dávkové úlohy přes noc, které zpracovávají miliony transakcí, vytvářejí sestavy a aktualizují hlavní soubory.

Důsledky změny platformy: Sémantika dávkového zpracování se dobře promítá do cloudového dávkového spouštění (AWS Batch, Azure Batch). Model sekvenčního zpracování přežívá změnu platformy. Pokud je požadavkem jednoduše spustit stejnou dávkovou úlohu na levnější infrastruktuře, změna platformy to řeší přímo.

Důsledky rearchitektování: Pokud se obchodní požadavky změnily, z nočních dávkových operací na zpracování téměř v reálném čase, z výměny dat založené na souborech na integraci API, z monolitických dávkových běhů na individuálně spouštěné mikroslužby, replatformování nemůže nové požadavky splnit. Architektura se musí změnit.

Signál tlačící k rearchitektování: Požadavky zúčastněných stran na zpracování v reálném čase, integraci založenou na API, architekturu řízenou událostmi nebo doby odezvy kratší než sekunda, které dávková sémantika nedokáže poskytnout.

Vestavěná obchodní logika bez externí specifikace

Toto je nejvíce podceňovaný faktor specifický pro COBOL. Mezi hlavní rizika patří ztráta kritických obchodních pravidel zabudovaných v desítky let starém kódu a nedostatečná dokumentace chování systému. Programy v COBOLu často obsahují jedinou dochovanou specifikaci obchodního pravidla. Předpis, který vyžadoval specifický výpočet, byl napsán v roce 1983. Obchodní analytik, který mu rozuměl, odešel do důchodu v roce 2001. Kód v COBOLu není jen implementace, je to dokumentace.

Důsledky replatformování: Obchodní pravidla přetrvávají beze změny, protože je zachován kód. Toto je jeden z nejsilnějších argumentů replatformování.

Důsledky rearchitektury: Obchodní pravidla musí být před opětovnou implementací extrahována ze zdrojového kódu COBOL. <cite index=”28-1″>Nedokumentovaný, úzce propojený kód znásobuje úsilí v každé fázi.</cite> Pokud je tato extrakce neúplná, nový systém má jinou specifikaci než ten starý a tyto rozdíly se projeví v produkčním prostředí.

Rozhodovací rámec: Osm otázek

Než si vyberete cestu, těchto osm otázek poskytne důkazy potřebné k tomu, abyste se mohli rozhodnout s jistotou, nikoli na základě předpokladů.

1. Co je hlavní hnací silou této modernizace?

• Náklady na infrastrukturu → přeprogramování je dostatečné
• Platformová závislost (z/OS) → přeplatformování je dostatečné
• Požadavky v reálném čase → je vyžadován rearchitekt
• Integrační požadavky (API) → pravděpodobně bude nutný nový architekt
• Udržovatelnost / dostupnost talentů → přepracování architektury nebo refaktoring

2. Jaká je úroveň propojení CICS? Vyjmenujte všechna volání EXEC CICS. Spočítejte programy s více než dvaceti různými příkazy CICS. Programy se silným propojením CICS jsou špatnými kandidáty na přeplatformování, pokud je nejistá věrnost emulace.

3. Jaké jsou vzorce přístupu k VSAM? Identifikujte programy, které přistupují k souborům VSAM pomocí alternativních klíčů, sdílených clusterů nebo náhodného přístupu citlivého na výkon. Toto jsou indikátory rizika změny platformy.

4. Byla obchodní logika zdokumentována externě? Pokud je zdrojový kód COBOL jedinou směrodatnou specifikací, vyžaduje rearchitektura extrakci obchodní logiky jako nezbytný krok, nikoli paralelní pracovní zátěž.

5. Jaká je tolerance dávkového okna? Pokud firma vyžaduje stejný model dávkového zpracování za nižší cenu, proveďte změnu platformy. Pokud firma vyžaduje, aby stejné zpracování bylo k dispozici v reálném čase, proveďte změnu architektury.

6. Jaká je složitost závislostí? Program s padesáti následnými závislostmi, datovými sadami, nazývanými podprogramy nebo volajícími JCL, nese vyšší riziko rearchitektování než samostatný nástroj. Struktura závislostí určuje pořadí migrace a rozsah testování.

7. Jaké procento kódu je mrtvého? Mrtvé kódy vyloučené z rozsahu před jakoukoli konverzí snižují úsilí pro obě cesty. U programů pro rearchitektování je mrtvý kód, který není vyloučen, převeden za plnou cenu a poté zahozen.

8. Jaké je rozdělení složitosti? Cyklomatická složitost nad 50 na program nebo více než dvacet zahrnutých sešitů značí programy, které jsou náročné na rearchitektování a rizikové z hlediska replatformy. Tyto programy si zaslouží spíše individuální pozornost než hromadné přiřazování cest.

Aplikace rámce: Čtyři profily systému COBOL

Změna hesla	charakteristika	Doporučená cesta	zdůvodnění
Stabilní dávkový nástroj	Sekvenční souborový I/O, žádný CICS, dobře zdokumentovaná logika, nízká složitost	Replatformovat	Problém je v ceně platformy, kód není omezením
Online transakce s vysokou mírou využití CICS	Nadměrné využití EXEC CICS, závislosti na commarea, pseudokonverzační model	Rearchitekt	Riziko emulace CICS je vysoké; pravděpodobně požadavky v reálném čase
Hlavní souborový procesor VSAM	Složité přístupové vzorce VSAM, sdílené mezi mnoha programy, vysoký objem čtení	Nejprve zhodnoťte věrnost emulace; pokud emulace funguje, přepněte platformu.	Emulace VSAM je rozhodovací proměnnou
Pokladna obchodní logiky	Nedokumentovaná pravidla, žádná externí specifikace, vysoký regulační význam	Nejdříve extrahujte logiku a pak vyberte	Riziko rearchitektury je bez předchozí extrakce obchodní logiky nepřijatelné.

Klíčové ponaučení: <cite index=”30-1″>V praxi velké společnosti kombinují různé přístupy: přepracují stabilní části, refaktorují kód, který je obtížné udržovat, přepíší hrstku systémů, které potřebují nové funkce, a vyřadí to, co se již nepoužívá.</cite> Rozhodnutí není na úrovni portfolia, ale na úrovni pracovní zátěže a uplatňuje se individuálně na každý program nebo skupinu programů na základě důkazů.

Hybridní přístup: Nejprve přepracujte platformu, poté přepracujte architekturu tam, kde je to nutné

Praktické pravidlo: přehostujte nebo přeplatformujte, abyste rychle zastavili krvácení, a poté refaktorujte nebo přepracujte architekturu systémů, které jsou skutečnými konkurenčními rozdíly.

Pro většinu organizací s velkými portfolii COBOLu je praktická postupnost následující:

Fáze 1, Replatformace jasných kandidátů. Programy bez CICS, s přímočarým sekvenčním I/O, zdokumentovanou logikou a nízkou složitostí lze replatformovat s předvídatelným úsilím a rizikem. To vede k rychlému snížení nákladů na infrastrukturu a budování důvěry organizace.

Fáze 2, Posouzení složitých programů. Programy s propojením CICS, složitými vzory VSAM nebo nedokumentovanou obchodní logikou vyžadují individuální analýzu před zvolením cesty. V této fázi extrakce obchodní logiky a strukturální analýza určují, zda je nutná rearchitektizace a jaký by byl její rozsah.

Fáze 3, Přepracování architektonických prvků programů s architektonickými blokátory. Programy, které nemohou splňovat obchodní požadavky na přepracovanou infrastrukturu, požadavky na práci v reálném čase, integraci API a zpracování řízené událostmi, jsou přepracovány pomocí vzoru Strangler Fig: vytvoření nové služby vedle přepracovaného programu, postupné směrování provozu do nové implementace, jakmile je každá komponenta ověřena, a vyřazení starého programu z provozu po migraci veškerého provozu.

Fáze 4, Vyřazení nefunkčního kódu. Programy identifikované jako nefunkční během strukturální analýzy jsou vyloučeny z obou cest a vyřazeny z provozu, což snižuje průběžné náklady na údržbu bez nutnosti konverze.

---

Co musí analýza přinést před jakýmkoli rozhodnutím

Výše uvedený rozhodovací rámec poskytuje lepší odpovědi, když vstupy jsou důkazy spíše než odhady. Strukturální analýza, která tyto vstupy poskytuje, vyžaduje analýzu skutečného zdrojového kódu COBOLu, spíše než spoléhání se na dokumentaci nebo znalosti vývojářů.

Co musí analýza pro každý program zjistit:

Kompletní inventář programů včetně programů, které dokumentace nezohledňuje. Ve velkých prostředích COBOL počet nezdokumentovaných programů často přesahuje 20 % z celkového počtu. Graf závislostí znázorňující, které programy volají které další, které datové sady jsou sdíleny, které úlohy JCL volají které programy. Inventář příkazů CICS pro každý program, počet, typy a složitost volání. Analýza vzorů přístupu VSAM, které metody přístupu, které soubory jsou sdíleny mezi programy, které soubory mají alternativní indexy. Cyklomatické rozdělení složitosti, které programy jsou strukturálně jednoduché a které jsou vysoce rizikovými kandidáty pro jakoukoli konverzi. Identifikace mrtvého kódu, které programy a odstavce nemají žádné příchozí cesty spuštění. Extrakce obchodní logiky, jaká pravidla každý program implementuje, ve formě, kterou lze použít k ověření výstupu obou cest.

Bez tohoto inventáře se rozhodnutí o cestě provádí na základě neúplných informací. Programy jsou přiřazovány k replatformování na základě předpokladů, které se ukážou jako chybné, když emulace odhalí architektonická omezení, která nebyla během plánování viditelná.

Jak SMART TS XL Vytváří důkazy před rozhodnutím

SMART TS XLJe starší modernizace Analýza automatizuje výše popsaný strukturální inventář a současně analyzuje každý program v COBOLu, sešit, úlohu JCL a odkaz na soubor VSAM, aby vytvořila jednotný model závislostí, díky kterému je rozhodování o cestě založeno na důkazech.

Mapování závislostí aplikace vytváří graf volání napříč programy a mapu sdílení datových sad, která určuje složitost závislostí, což je faktor, který nejvíce přímo ovlivňuje jak riziko emulace změny platformy, tak rozsah a pořadí změny architektury.

Statická analýza kódu vytváří metriky složitosti, inventáře volání CICS a identifikaci mrtvého kódu pro každý program v portfoliu. Programy nad prahovou hodnotou cyklomatické složitosti a se silným propojením CICS jsou automaticky označeny jako kandidáti na rearchitect-or-assess, spíše než aby byly hromadně přiřazeny k replatformě.

Rozšíření JCL řeší symbolické parametry a vytváří kompletní řetězec závislostí dávkového provádění, který určuje, které úlohy JCL volají které programy, v jakém pořadí a s jakými datovými sadami, a poskytuje tak operační kontext, který určuje, jak se musí výstup obou cest chovat, aby splňoval dávkový plán.

Díky analýze dopadů je rozsah každé cesty konkretizován ještě před zahájením programu: u každého programu vybraného pro rearchitektování analýza dopadů vyjmenovává všechny závislé programy, které je nutné aktualizovat, znovu otestovat nebo koordinovat s rearchitektovanou komponentou. U kandidátů na replatformování stejná analýza identifikuje, které sdílené datové sady a sdílené podprogramy vytvářejí závislosti mezi programy, které je nutné zpracovávat konzistentně.

Podnikové vyhledávání umožňuje dotazování celého inventáře v celém programu: vyhledá každý program, který používá specifický příkaz CICS, každý program, který přistupuje ke specifickému clusteru VSAM, každý sešit, který definuje specifickou datovou strukturu, během několika sekund a napříč miliony řádků jazyka COBOL.

Organizace, které toto rozhodnutí učiní správně, jsou ty, které jej činí na základě strukturálních důkazů, nikoli na základě předpokladů projektového plánu. Strukturální důkazy jsou to, co SMART TS XL vyrábí.