Dwie organizacje z portfelami COBOL o podobnej wielkości podejmują różne decyzje modernizacyjne. Jedna z nich dokonuje replatformizacji: przenosi programy COBOL do infrastruktury chmurowej za pomocą AWS Mainframe Modernization lub warstwy emulacji COBOL, zachowując kod i eliminując fizyczny komputer mainframe. W ciągu osiemnastu miesięcy obniżają koszty infrastruktury o 40%, a program zostaje uznany za sukces. Druga organizacja próbuje tego samego podejścia, napotykając barierę po dwunastu miesiącach i przechodzi do rearchitektury, przebudowując najważniejsze programy jako mikrousługi Java. Koszt tej zmiany dwukrotnie przekracza pierwotny budżet i trwa kolejne trzy lata.
Ten sam punkt wyjścia. Radykalnie różne rezultaty. Różnica nie tkwiła w narzędziach, dostawcach ani zespołach. Chodziło o to, że druga organizacja zdecydowała się na replatformizację systemów, które miały ograniczenia architektoniczne, których nowa platforma nie była w stanie obsłużyć – zależności transakcyjne CICS, struktury plików VSAM oraz wymagania dotyczące czasu rzeczywistego, których replatformowany kod nie mógł spełnić bez gruntownej przebudowy. Decyzja została podjęta, zanim ktokolwiek zrozumiał systemy na tyle dobrze, aby móc ją poprawnie wdrożyć.
Znajdź blokery rearchitektury na wczesnym etapie
SMART TS XL automatycznie identyfikuje głębokość sprzężenia CICS, złożoność VSAM i martwy kod w całym portfolio COBOL.
Więcej informacjiCo właściwie oznacza każda ścieżka dla COBOL-a
Definicje ogólne są dobrze znane. Ważne jest, co każda ścieżka oznacza konkretnie dla programów COBOL, gdzie architektura, model wykonania i struktury danych różnią się od współczesnych aplikacji w sposób, który bezpośrednio wpływa na to, która ścieżka jest wykonalna.
Zmiana platformy COBOL
Zmiana platformy przenosi programy COBOL do nowego środowiska operacyjnego, zazwyczaj infrastruktury chmurowej, zachowując przy tym kod w dużej mierze niezmieniony. COBOL kompiluje się i działa na nowej platformie, natywnie (za pomocą kompilatora COBOL firmy IBM w systemie Linux) lub poprzez warstwę emulacji, która przechwytuje wywołania specyficzne dla komputerów mainframe (CICS, VSAM, JES) i tłumaczy je na natywne odpowiedniki chmurowe.
Co zostaje zachowane po zmianie platformy:
- Kod źródłowy COBOL
- Logika, obliczenia i reguły biznesowe programu
- Model wykonywania wsadowego (pętle PERFORM, sekwencyjne przetwarzanie plików)
- Struktury danych (układy rekordów, definicje kopii)
- Struktura zadań JCL (przepisana na potrzeby nowego harmonogramu, ale logicznie równoważna)
Jakie zmiany wprowadza zmiana platformy:
- Infrastruktura fizyczna (z/OS → Linux w chmurze)
- Podsystem wejścia/wyjścia (VSAM → zarządzana pamięć masowa plików lub baza danych, w zależności od narzędzia)
- Harmonogram zadań (JES2/JES3 → AWS Batch, Azure Logic Apps lub równoważny)
- Model kosztów (rozliczanie oparte na MIPS → rozliczanie w chmurze oparte na zużyciu)
Kluczowy wniosek: Replatforming jest właściwy, gdy problemem jest platforma, koszt uruchomienia systemu z/OS, zależność od infrastruktury, model rozliczeń MIPS. Jest to jednak błędna ścieżka, gdy problemem jest kod lub architektura.
Przebudowa COBOL-a
Rearchitektura zmienia fundamentalną konstrukcję systemu. Logika biznesowa zostaje zachowana lub zaczerpnięta ze źródła COBOL, ale jest implementowana w nowym języku, z nowym modelem wykonania i nową warstwą danych. Rezultatem jest system, który działa tak samo, jak COBOL, ale nie przypomina go strukturą.
Jakie zmiany wprowadza rearchitektura:
- Język programowania (COBOL → Java, Python, Go, C#)
- Model wykonywania (wsadowy → sterowany zdarzeniami, strumieniowy lub oparty na API)
- Warstwa danych (pliki VSAM → baza danych relacyjna, NoSQL, pamięć masowa w chmurze)
- Model transakcji (pseudokonwersacyjny CICS → bezstanowe usługi RESTful)
- Wzorzec integracji (współdzielone zbiory danych → kontrakty API, kolejki komunikatów)
Co należy zachować podczas przebudowy:
- Każda reguła biznesowa wdrażana przez COBOL, w tym nieudokumentowane przypadki brzegowe
- Każde obliczenie, w tym charakterystyka precyzji numerycznej arytmetyki dziesiętnej w systemie upakowanym
- Każda transformacja danych, w tym konwersje niejawne w poleceniach MOVE
- Każdy stan błędu, w tym określone kody STATUSU PLIKU i zachowania awaryjne, od których mogą zależeć systemy podrzędne
Uwaga: Najczęstszym błędem podczas rearchitektury jest odkrycie, że COBOL zawierał reguły biznesowe, które nigdy nie zostały nigdzie indziej zapisane. Nowy system zachowuje się inaczej niż stary w określonych przypadkach skrajnych, nie z powodu błędu implementacji, ale z powodu niekompletności specyfikacji. Logikę biznesową należy wyodrębnić i udokumentować ze źródła COBOL przed rozpoczęciem rearchitektury.
Czynniki specyficzne dla języka COBOL, które zmieniają tę decyzję
Ogólne ramy modernizacji traktują replatformę i rearchitekturę jako decyzje dotyczące przede wszystkim kosztów, harmonogramu i ryzyka. W przypadku języka COBOL kilka czynników technicznych, specyficznych dla języka i jego środowiska wykonawczego, silnie wpływa na decyzję.
Zależności transakcji CICS
CICS (Customer Information Control System) to oprogramowanie pośredniczące do przetwarzania transakcji, z którego korzysta wiele programów COBOL w przypadku obciążeń interaktywnych. Program COBOL, który wykonuje wywołania EXEC CICS, ma niejawną zależność od serwera transakcji CICS w zakresie zarządzania ekranami, komunikacji terminalowej, przydzielania zadań i sterowania programem.
Implikacja zmiany platformy: Narzędzia takie jak emulacja Micro Focus CICS, OpenFrame i niektóre funkcje modernizacji komputerów mainframe AWS emulują semantykę CICS. Jeśli użycie CICS jest standardowe i poprawne, emulacja może działać. Jeśli program opiera się na wewnętrznych mechanizmach CICS, manipulacji obszarami pamięci masowej, kontroli punktów synchronizacji i przechowywaniu danych na poziomie zadań, wierność emulacji ulega pogorszeniu.
Implikacja rearchitektury: Program CICS przekonwertowany na API REST musi mieć przeprojektowany pseudo-konwersacyjny model transakcji, uwzględniający interakcje bezstanowe. Jest to zmiana architektoniczna, a nie translacja kodu.
Sygnał wskazujący na konieczność przeprojektowania: Intensywne wykorzystanie CICS ze złożoną obsługą obszarów komunikacyjncyh, łańcuchowaniem transakcji zaplecza lub logiką punktów synchronizacji.
Architektura plików VSAM
VSAM (Virtual Storage Access Method) to indeksowany system plików używany w większości programów produkcyjnych COBOL. Pliki VSAM mają specyficzne wzorce dostępu, takie jak sekwencyjny klucz KSDS, sekwencyjny wpis ESDS czy względny rekord RRDS, które nie mają bezpośrednich odpowiedników w pamięci masowej natywnej dla chmury.
Implikacja replatformowa: Warstwy emulacji tłumaczą odczyty i zapisy VSAM na podstawowe operacje na plikach lub bazach danych. Działa to w przypadku prostego dostępu sekwencyjnego lub opartego na kluczach. W przypadku złożonego dostępu do klucza alternatywnego, klastrów VSAM współdzielonych przez wiele programów lub wzorców losowego dostępu wrażliwych na wydajność, emulacja zwiększa opóźnienie i złożoność.
Implikacja zmiany architektury: zastąpienie VSAM relacyjną bazą danych wymaga mapowania układów rekordów na schematy tabel, obsługi niejawnych konwersji typów danych i przepisania każdego dostępu do pliku, aby korzystał z języka SQL lub ORM.
Sygnał wskazujący na konieczność przeprojektowania: pliki VSAM współdzielone przez wiele programów, alternatywne wzorce dostępu do indeksów lub wymagania dotyczące wydajności w czasie rzeczywistym, których emulacja nie jest w stanie spełnić.
Wymagania wsadowe a wymagania w czasie rzeczywistym
Programy wsadowe w języku COBOL są zaprojektowane do sekwencyjnego przetwarzania dużych wolumenów rekordów w zaplanowanych oknach czasowych. Wiele systemów bankowych, ubezpieczeniowych i rządowych nadal uruchamia zadania wsadowe w trybie nocnym, przetwarzając miliony transakcji, generując raporty i aktualizując pliki główne.
Implikacja zmiany platformy: Semantyka przetwarzania wsadowego dobrze przekłada się na wykonywanie wsadowe w chmurze (AWS Batch, Azure Batch). Model przetwarzania sekwencyjnego przetrwa zmianę platformy. Jeśli potrzeba po prostu uruchomienia tego samego zadania wsadowego na tańszej infrastrukturze, zmiana platformy rozwiązuje ten problem bezpośrednio.
Implikacja rearchitektury: Jeśli wymagania biznesowe uległy zmianie, z przetwarzania wsadowego na nocny na przetwarzanie w czasie niemal rzeczywistym, z wymiany plików na integrację API, z monolitycznych uruchomień wsadowych na indywidualnie wyzwalane mikrousługi, replatformizacja nie może spełnić nowego wymagania. Architektura musi się zmienić.
Sygnał wskazujący na konieczność przeprojektowania: Wymagania interesariuszy dotyczące przetwarzania w czasie rzeczywistym, integracji opartej na interfejsie API, architektury sterowanej zdarzeniami lub czasów reakcji poniżej sekundy, których nie jest w stanie zapewnić semantyka wsadowa.
Wbudowana logika biznesowa bez specyfikacji zewnętrznej
To najbardziej niedoceniany czynnik specyficzny dla języka COBOL. Główne zagrożenia obejmują utratę krytycznych reguł biznesowych osadzonych w kodzie sprzed dziesięcioleci oraz niewystarczającą dokumentację zachowania systemu. Programy COBOL często zawierają jedyną zachowaną specyfikację reguły biznesowej. Przepis wymagający określonego obliczenia został opracowany w 1983 roku. Analityk biznesowy, który go rozumiał, przeszedł na emeryturę w 2001 roku. Kod COBOL to nie tylko implementacja, to także dokumentacja.
Implikacja replatformingu: Reguły biznesowe pozostają nienaruszone, ponieważ kod jest zachowany. To jeden z najmocniejszych argumentów za replatformingiem.
Implikacja rearchitektury: Reguły biznesowe muszą zostać wyodrębnione ze źródła COBOL przed ponowną implementacją. <cite index=”28-1″>Nieudokumentowany, ściśle powiązany kod zwiększa nakład pracy na każdym etapie.</cite> Jeśli ta ekstrakcja jest niekompletna, nowy system ma inną specyfikację niż stary, a te różnice ujawniają się w środowisku produkcyjnym.
Ramy decyzyjne: osiem pytań
Zanim wybierzesz ścieżkę, poniższa lista ośmiu pytań dostarczy Ci dowodów potrzebnych do podjęcia decyzji z pewnością, a nie na podstawie założeń.
1. Co jest główną przyczyną tej modernizacji?
- Koszt infrastruktury → wystarczy zmiana platformy
- Zależność platformy (z/OS) → wystarczy zmienić platformę
- Wymagania w czasie rzeczywistym → wymagana jest przebudowa
- Wymagania integracyjne (API) → prawdopodobnie konieczna będzie rearchitektura
- Utrzymywalność / dostępność talentów → przebudowa lub refaktoryzacja
2. Jaki jest poziom sprzężenia CICS? Wymień każde wywołanie EXEC CICS. Policz programy z ponad dwudziestoma różnymi poleceniami CICS. Programy z silnym sprzężeniem CICS są kiepskimi kandydatami do zmiany platformy, jeśli dokładność emulacji jest niepewna.
3. Jakie są wzorce dostępu VSAM? Zidentyfikuj programy uzyskujące dostęp do plików VSAM za pomocą kluczy alternatywnych, klastrów współdzielonych lub losowego dostępu zależnego od wydajności. Są to wskaźniki ryzyka zmiany platformy.
4. Czy logika biznesowa została udokumentowana zewnętrznie? Jeśli kod źródłowy COBOL jest jedyną wiarygodną specyfikacją, rearchitektura wymaga ekstrakcji logiki biznesowej jako kroku wstępnego, a nie równoległego obciążenia.
5. Jaka jest tolerancja okna wsadowego? Jeśli firma wymaga tego samego modelu przetwarzania wsadowego przy niższych kosztach, należy zmienić platformę. Jeśli firma wymaga, aby to samo przetwarzanie było dostępne w czasie rzeczywistym, należy zmienić architekturę.
6. Jaka jest złożoność zależności? Program z pięćdziesięcioma zależnościami podrzędnymi, zbiorami danych, zwanymi podprogramami, obiektami wywołującymi JCL, wiąże się z większym ryzykiem rearchitektury niż samodzielne narzędzie. Struktura zależności determinuje kolejność migracji i zakres testów.
7. Jaki procent kodu jest martwy? Martwy kod wykluczony z zakresu przed jakąkolwiek konwersją zmniejsza nakład pracy dla obu ścieżek. W przypadku programów rearchitektury, martwy kod, który nie został wykluczony, jest konwertowany po pełnym koszcie, a następnie odrzucany.
8. Jaki jest rozkład złożoności? Złożoność cyklomatyczna powyżej 50 na program lub ponad dwadzieścia dołączonych kopii wskazuje na programy, które są kosztowne w rearchitekturze i ryzykowne w przypadku zmiany platformy. Wymagają one indywidualnej uwagi, a nie zbiorczego przydzielania ścieżek.
Zastosowanie frameworka: cztery profile systemowe COBOL
| Profil | Charakterystyka | Zalecana ścieżka | racjonalne uzasadnienie |
|---|---|---|---|
| Stabilne narzędzie wsadowe | Sekwencyjne wejście/wyjście pliku, brak CICS, dobrze udokumentowana logika, niska złożoność | Replatform | Koszt platformy jest problemem, kod nie jest ograniczeniem |
| Transakcje online z dużym udziałem CICS | Duże wykorzystanie EXEC CICS, zależności od obszaru wymiany, model pseudo-konwersacyjny | Przeprojektuj | Ryzyko emulacji CICS jest wysokie; prawdopodobne są wymagania w czasie rzeczywistym |
| Główny procesor plików VSAM | Złożone wzorce dostępu VSAM, współdzielone przez wiele programów, duża objętość odczytu | Najpierw oceń wierność emulacji; jeśli emulacja się powiedzie, przeinstaluj platformę | Emulacja VSAM jest zmienną decyzyjną |
| Skarbiec logiki biznesowej | Nieudokumentowane zasady, brak specyfikacji zewnętrznej, duże znaczenie regulacyjne | Najpierw wyodrębnij logikę, a następnie wybierz | Ryzyko związane z rearchitekturą jest niedopuszczalne bez wcześniejszej ekstrakcji logiki biznesowej |
Podsumowanie: <cite index=”30-1″>W praktyce duże firmy łączą podejścia: zmieniają platformę stabilnych części, przebudowują kod, który jest trudny w utrzymaniu, przepisują kilka systemów wymagających nowych możliwości oraz wycofują te, które nie są już używane.</cite> Decyzja nie jest podejmowana na poziomie portfela, lecz na poziomie obciążenia pracą i jest stosowana indywidualnie do każdego programu lub grupy programów w oparciu o dowody.
Podejście hybrydowe: najpierw przebudowa platformy, przebudowa architektury tam, gdzie to konieczne
Praktyczna zasada: zmień hosting lub platformę, aby szybko zatrzymać wyciek, a następnie przebuduj lub przeprojektuj systemy, które naprawdę wyróżniają Cię na tle konkurencji.
W przypadku większości organizacji z dużymi portfelami COBOL praktyczna kolejność działań jest następująca:
Faza 1: Replatformowanie wybranych kandydatów. Programy bez CICS, z prostym sekwencyjnym wejściem/wyjściem, udokumentowaną logiką i niską złożonością mogą zostać przeniesione na platformę z przewidywalnym nakładem pracy i ryzykiem. Pozwala to na szybką redukcję kosztów infrastruktury i buduje zaufanie organizacji.
Faza 2: Ocena złożonych programów. Programy ze sprzężeniem CICS, złożonymi wzorcami VSAM lub nieudokumentowaną logiką biznesową wymagają indywidualnej analizy przed wyborem ścieżki. To właśnie na tym etapie ekstrakcja logiki biznesowej i analiza strukturalna decydują o konieczności rearchitektury i jej zakresie.
Faza 3: Rearchitektura programów z blokadami architektonicznymi. Programy, które nie spełniają wymagań biznesowych dotyczących infrastruktury na replatformie, wymagań w czasie rzeczywistym, integracji API i przetwarzania sterowanego zdarzeniami, są rearchitekturowane zgodnie ze wzorcem Strangler Fig: budowanie nowej usługi wraz z programem na replatformie, stopniowe kierowanie ruchu do nowej implementacji w miarę walidacji każdego komponentu i wycofywanie starego programu po migracji całego ruchu.
Faza 4: Wycofanie martwego kodu. Programy zidentyfikowane jako martwe podczas analizy strukturalnej są wykluczane z obu ścieżek i wycofywane z eksploatacji, co zmniejsza bieżące koszty utrzymania bez konieczności przeprowadzania konwersji.
Co analiza musi dać przed podjęciem jakiejkolwiek decyzji
Powyższy model decyzyjny daje lepsze odpowiedzi, gdy dane wejściowe są dowodami, a nie szacunkami. Analiza strukturalna, która dostarcza tych danych wejściowych, wymaga analizy rzeczywistego kodu źródłowego COBOL, a nie polegania na dokumentacji lub wiedzy programistów.
Co analiza musi ustalić dla każdego programu:
Kompletny inwentarz programów, w tym programy, których dokumentacja nie uwzględnia. W dużych środowiskach COBOL liczba nieudokumentowanych programów często przekracza 20% całkowitej liczby. Graf zależności pokazujący, które programy wywołują inne, które zestawy danych są współdzielone, które zadania JCL wywołują które programy. Inwentarz poleceń CICS dla każdego programu, liczba, typy i złożoność wywołań. Analiza wzorców dostępu VSAM, które metody dostępu, które pliki są współdzielone między programami, które pliki mają alternatywne indeksy. Cyklomatyczny rozkład złożoności, które programy są strukturalnie proste, a które są kandydatami wysokiego ryzyka w przypadku jakiejkolwiek konwersji. Identyfikacja martwego kodu, które programy i akapity nie mają ścieżek wykonywania przychodzącego. Ekstrakcja logiki biznesowej, reguły implementowane przez każdy program, w formie umożliwiającej walidację wyników obu ścieżek.
Bez tego inwentaryzacji decyzja o ścieżce jest podejmowana na podstawie niekompletnych informacji. Programy są przypisywane do replatformizacji na podstawie założeń, które okazują się błędne, gdy emulacja ujawnia ograniczenia architektoniczne, które nie były widoczne podczas planowania.
W jaki sposób SMART TS XL Tworzy dowody przed podjęciem decyzji
SMART TS XL'S modernizacja dziedziczna Analiza automatyzuje opisany powyżej inwentarz strukturalny, analizując jednocześnie każdy program COBOL, copybook, zadanie JCL i odniesienie do pliku VSAM w celu zbudowania ujednoliconego modelu zależności, który sprawia, że decyzja o ścieżce jest oparta na dowodach.
Mapowanie zależności aplikacji generuje graf wywołań międzyprogramowych i mapę udostępniania zestawu danych, która określa złożoność zależności, czyli czynnik, który najbardziej bezpośrednio wpływa zarówno na ryzyko emulacji zmiany platformy, jak i na zakres oraz kolejność zmian architektury.
Statyczna analiza kodu generuje metryki złożoności, inwentaryzację wywołań CICS oraz identyfikację martwego kodu dla każdego programu w portfolio. Programy przekraczające próg złożoności cyklomatycznej i mocno sprzężone z CICS są automatycznie identyfikowane jako kandydaci do rearchitektury lub oceny, a nie zbiorczo przypisywane do replatformizacji.
Rozszerzenie JCL rozwiązuje parametry symboliczne i buduje kompletny łańcuch zależności wykonywania wsadowego, określając, które zadania JCL wywołują które programy, w jakiej kolejności, z jakimi zestawami danych, dostarczając kontekst operacyjny, który określa, jak dane wyjściowe dowolnej ścieżki muszą się zachowywać, aby spełnić harmonogram wykonywania wsadowego.
Funkcja analizy wpływu konkretyzuje zakres każdej ścieżki przed rozpoczęciem programu: dla każdego programu wybranego do rearchitektury, analiza wpływu wymienia wszystkie programy zależne, które muszą zostać zaktualizowane, ponownie przetestowane lub skoordynowane z przebudowanym komponentem. W przypadku kandydatów do replatformy, ta sama analiza identyfikuje, które współdzielone zestawy danych i współdzielone podprogramy tworzą zależności międzyprogramowe, które muszą być obsługiwane spójnie.
Przeszukiwanie przedsiębiorstwa umożliwia przeszukiwanie całego inwentarza w całym programie: w ciągu kilku sekund można znaleźć każdy program korzystający ze specyficznego polecenia CICS, każdy program uzyskujący dostęp do specyficznego klastra VSAM, każdy copybook definiujący specyficzną strukturę danych, w milionach wierszy kodu COBOL.
Organizacje, które podejmują tę decyzję prawidłowo, opierają się na dowodach strukturalnych, a nie na założeniach planu projektu. Dowody strukturalne to… SMART TS XL produkuje.
