Každá organizace, která provozuje starší systémy, čelí stejnému základnímu napětí. Systémy jsou příliš cenné na to, aby se jich vzdalo, příliš drahé na údržbu v jejich současném stavu a příliš riskantní na jednorázovou výměnu. Sálové počítače COBOL zpracovávají 95 % transakcí bankomatů po celém světě. Osmdesát procent federálních IT rozpočtů USA jde na údržbu systémů, které měly být modernizovány už před lety. Starší systémy neselhávají, ale daří se jim, a právě proto je tak obtížné je změnit.
Cena za nečinnost se zvyšuje. Technický dluh roste každým rokem, kdy se modernizace odkládá. Bezpečnostní zranitelnosti se hromadí v kódových bázích, které již nedostávají záplaty. Integrace s moderními systémy se stává obtížnější, protože se zvětšuje propast mezi starší architekturou a cloudovými nativními vzory. A skupina vývojářů, kteří rozumí starším jazykům, se zmenšuje s tím, jak lidé, kteří je vytvořili, odcházejí do důchodu. Organizace, které v modernizaci uspějí, nejsou ty, které čekají, až bude tlak neúnosný. Jsou to ty, které metodicky plánují, volí správný přístup pro každý systém a provádějí postupně, místo aby vsadily celý program na jeden velký přechod.
Poznejte své portfolio Legacy v plném rozsahu
SMART TS XL identifikuje, co lze vyřadit před uzamčením rozsahu modernizace.
Více informacíCo je modernizace starších systémů?
Modernizace starších systémů je proces transformace zastaralých softwarových systémů, často monolitických, náročných na údržbu a obtížně integrovatelných, do moderních, agilních a škálovatelných architektur. Nejedná se nutně o nahrazení. Modernizace zahrnuje spektrum přístupů od přesunu stávajícího kódu do cloudové infrastruktury s minimálními změnami, přes inkrementální refaktoring, až po úplnou rearchitekturu nebo nahrazení moderními alternativami.
Rozdíl od jednoduché údržby: údržba udržuje systém v chodu tak, jak je. Modernizace mění jeho základní funkce, architekturu nebo operační prostředí, aby se prodloužila jeho životnost, snížily provozní náklady, umožnila integrace s moderními systémy nebo se organizace připravila na budoucí rozvoj schopností, včetně úloh umělé inteligence.
Proč starší systémy nemohou čekat donekonečna
Několik sbíhajících se sil způsobuje, že náklady na odklad budou v roce 2026 vyšší než před třemi lety:
Připravenost na AI. Generativní úlohy AI odhalují každou slabinu v podnikovém datovém majetku, fragmentované zdroje, nekonzistentní sémantiku, neřízený přístup, a to během několika týdnů od pilotního nasazení. Organizace nemohou provozovat smysluplné pracovní postupy AI na izolovaných, nedokumentovaných starších systémech. Modernizace je předpokladem pro éru AI.
Nedostatek talentů. Najít vývojáře pro COBOL, PL/I a patnáct let starou Javu se stává skutečně obtížným. Průměrný věk vývojářů COBOLu je nyní v polovině padesátých let. Každý rok, kdy je modernizace odložena, zkracuje časový rámec pro přenos znalostí, než institucionální znalosti odejdou do důchodu spolu s lidmi, kteří je vlastní.
Bezpečnostní ohrožení. Starší systémy, které již nedostávají bezpečnostní záplaty od dodavatelů, hromadí neřešené CVE. Čím déle systém v tomto stavu pracuje, tím větší je oblast známých zranitelností.
Složitost integrace. Moderní architektury řízené API, mikroslužby a cloudově nativní platformy předpokládají vzorce konektivity, které starší monolity nativně nepodporují. Každé nové řešení integrace zvyšuje technický dluh, který ztěžuje případnou modernizaci.
7 R: Základní rámec pro modernizační rozhodnutí
Rámec 7 R, odvozený z původních 5 R společnosti Gartner a rozšířený o praxi v oboru, poskytuje organizacím strukturovaný způsob, jak se rozhodnout, co dělat s každou aplikací ve svém portfoliu. Klíčovým principem je, že žádný jednotný přístup není vhodný pro všechny systémy. Program modernizace na úrovni portfolia aplikuje na různé systémy různé strategie na základě jejich složitosti, obchodní kritičnosti a strategické hodnoty.
| Strategie | Co to znamená | Kdy ji použít | Typická časová osa | Úroveň rizika |
|---|---|---|---|---|
| Odejít | Vyřazení z provozu, systém již není potřeba | Redundantní, nepoužívané nebo plně nahrazené systémy | Bezprostřední | Nízké |
| Udržet | Ponechat tak, jak je, s minimálními změnami | Systém funguje, náklady na modernizaci převyšují přínos | Pokračující | Nízké |
| Znovu hostit | Přenos do cloudu bez nutnosti změn kódu | Nekritické úlohy, rychlé výsledky, snížení nákladů na infrastrukturu | 1–3 měsíců | Nízké |
| Replatformovat | Přesun s cílenými změnami platformy (např. spravovaná databáze) | Mírné propojení, potřeba specifického výkonu nebo optimalizace nákladů | 2–6 měsíců | Střední |
| Refaktor | Restrukturalizujte kód bez změny vnějšího chování | Snížení technického dluhu, zlepšení udržovatelnosti, pokrytí testy | 3–12 měsíců | Střední |
| Rearchitekt | Redesign pro cloudově nativní, mikroslužby nebo novou architekturu | Významné požadavky na škálovatelnost, strategická změna platformy | 12–24 měsíců | Vysoký |
| Nahradit | Ukončete vlastní systém, začněte používat SaaS nebo jej vyměňte za moderní alternativu. | Funkčnost komodit lépe obsloužena stávajícími produkty | 6–18 měsíců | Středně vysoká |
Nejdůležitějším rozhodnutím v jakémkoli modernizačním programu je důsledné uplatňování tohoto rámce, spíše než držet se jedné strategie pro všechno. Organizace, které uplatňují metodu „lift-and-shift“ na všechno, skončí s účty za cloud vyššími, než byly náklady na jejich datová centra, a to bez flexibility, která by je ospravedlňovala. Organizace, které uplatňují rearchitect na všechno, skončí s několikaletými programy, které přinášejí hodnotu příliš pomalu, než aby si udržely podporu zúčastněných stran.
Osm modernizačních přístupů podrobně
1. Změna umístění (zvedání a posun)
Rehosting přesune aplikaci do cloudového nebo moderního infrastrukturního prostředí beze změn v kódu aplikace. Aplikace běží na jiné platformě, ale chová se identicky. Je to nejrychlejší cesta do cloudu, s nejnižším rizikem a s nejméně transformačními nároky.
Nejlepší pro: Nekritické aplikace, kde je primárním cílem snížení nákladů na infrastrukturu, konsolidace datových center nebo umístění pro budoucí modernizaci. Rehosting se často používá jako první fáze, systém se přenese na cloudovou infrastrukturu a poté se provede postupná refaktorizace.
Co neřeší: Technický dluh, problémy s údržbou, složitost integrace ani architektonická omezení. Systém běží v cloudu, ale architektonicky zůstává nezměněn. Monolit, jehož údržba v místní síti byla drahá, je i po rehostingu stále drahý.
2. Přechod na novou platformu
Replatforming provádí cílené úpravy platformy nebo běhového prostředí, aby se využily cloudové služby, aniž by se musela restrukturalizovat architektura aplikace. Typickými kroky při replatformingu je migrace ze samostatně spravované databáze na cloudově spravovanou databázovou službu nebo ze samostatně spravovaného aplikačního serveru na spravovanou kontejnerovou platformu.
Nejlepší pro: Aplikace, kde specifické komponenty mají jasné cloudové ekvivalenty, které snižují provozní režijní náklady, a kde náklady a riziko úplné rearchitektury nejsou ospravedlněny obchodním přínosem.
3. Refaktoring
Refaktoring restrukturalizuje stávající kód za účelem zlepšení jeho vnitřní kvality, aniž by se změnilo jeho vnější chování. Řeší technický dluh, zlepšuje testovatelnost, snižuje složitost a usnadňuje pochopení a rozšíření kódu. Nejedná se o migraci platformy, systém běží ve stejném prostředí před i po refaktoringu.
Refaktoring je nejvhodnějším přístupem, když: základní funkcionalita systému je v pořádku a stále potřebná, ale jeho vnitřní struktura zpomaluje a ztěžuje změny. Kandidátem na refaktoring je program v COBOLu s desítkami let nahromaděné podmíněné logiky, který správně provádí kritickou obchodní funkci, ale vyžaduje dny pečlivé analýzy před jakoukoli úpravou.
4. Rearchitektura
Rearchitektování přepracovává základní strukturu aplikace, rozkládá monolit na mikroslužby, přechází od synchronní k událostmi řízené komunikaci a implementuje CQRS neboli vzory pro získávání událostí. Je to strategie s nejvyšším úsilím a nejvyšší návratností, pokud je provedena dobře, a strategie s nejvyšším rizikem, pokud je provedena špatně.
Hlavním způsobem selhání, který je třeba sledovat, je „distribuovaný monolitní antivzor“, tedy týmy, které implementují nové služby, ale nedokážou oddělit datovou vrstvu, čímž vytvářejí provozní složitost mikroslužeb s těsným propojením monolitu. Tento vzorec funguje, když jsou hranice dat jasně definovány před extrakcí služeb.
Nejlepší pro: Systémy, u kterých nelze v rámci stávající struktury splnit požadavky na škálovatelnost, odolnost nebo architektonickou flexibilitu a u kterých má organizace technickou vyspělost pro provoz distribuovaných systémů.
5. Vzor škrtiče
Vzor Strangler Fig je modernizační přístup, při kterém jsou stávající funkce staršího systému postupně nahrazovány novými aplikacemi a službami, dokud nový systém nakonec nenahradí všechny staré nebo klíčové části staršího systému.
Místo jednorázové náhrady staršího systému se vedle starého systému buduje nová funkcionalita, která jej postupně nahrazuje, jakmile jej převezmou moderní komponenty. Proxy neboli fasádní vrstva směruje požadavky, zpočátku vše odesílá do staršího systému a postupně směruje další požadavky na nové komponenty, jakmile jsou ověřovány. Starší systém je postupně „škrten“, dokud jej nelze bezpečně vyřadit z provozu.
Nejrizikovější cesta: Migrace velkým třeskem. Vytvoření kompletní náhrady izolovaně a následné najednou přerušení provozu má zdokumentovanou vysokou míru selhání v podnikovém měřítku.
Proč je Strangler Fig nyní výchozím doporučením pro kritické systémy: Eliminuje největší možný způsob selhání starší modernizace, tzv. „velký třesk“. Každá nová komponenta je ověřena v produkčním prostředí před extrakcí další. Vrácení předchozích verzí je vždy možné, protože starší systém nadále běží. Kontinuita podnikání je zachována po celou dobu.
Reálná aplikace: Finanční instituce, která nahrazuje svůj základní bankovní systém, extrahuje funkci dotazování na účet jako první novou službu. Nová služba zpracovává provoz dotazů, zatímco starší systém se stará o vše ostatní. Jakmile je služba stabilní, extrahuje se další funkce, iniciování transakcí. Toto pokračuje, dokud není starší jádro vyřazeno z provozu, s nulovými prostoji a průběžným ověřováním v každém kroku.
6. Zapouzdření API
Obalení API vytváří moderní vrstvu API kolem staršího systému bez změny interního kódu systému. Externí uživatelé interagují s moderním API; API překládá požadavky do nativního rozhraní staršího systému a transformuje odpovědi do moderních formátů. Starší systém se stává interním implementačním detailem skrytým za čistým rozhraním.
Nejlepší pro: Systémy, které musí zůstat zavedeny na dobu neurčitou (kvůli regulačním požadavkům, nákladům nebo složitosti), ale musí se účastnit moderních integračních vzorců. API obalování je způsob, jakým mnoho organizací zpřístupňuje programy v COBOLu moderním webovým a mobilním aplikacím, aniž by se musely dotýkat kódu v COBOLu.
Omezení: Nejsou řešena omezení základního systému, jako je výkon, škálovatelnost a udržovatelnost. Obalení API zlepšuje integraci, aniž by vylepšovalo systém, který obaluje.
7. Obnova od nuly
Přestavba zahodí stávající implementaci a od základů napíše náhradu, zaměřenou na moderní architekturu, jazyk a platformu. Je vhodná, když je stávající systém skutečně neekonomický a když jsou obchodní požadavky dostatečně pochopeny, aby bylo možné s jistotou specifikovat náhradu.
Riziko: Každá organizace, která se pokusila o velkou přestavbu kritického systému, zjistila, že stávající systém obsahoval nezdokumentovanou obchodní logiku, kterou nový systém nereplikoval. Migrace IT systémů britské banky TSB v roce 2018 způsobila, že 1.9 milionu zákazníků bylo na týdny zablokováno k jejich účtům. Projekt FBI s názvem Virtuální spis případů byl po vývoji v hodnotě 170 milionů dolarů opuštěn. Výměna mzdového systému v Queensland Health vedla k tomu, že 35 000 nemocničních zaměstnanců bylo po celé měsíce nedopláceno nebo přepláceno. V každém případě složitost stávajícího systému, jeho zabudovaná obchodní pravidla, jeho okrajové případy a jeho provozní chování za podmínek, které nebyly nikdy explicitně specifikovány, překračovaly to, co náhradní tým chápal před zahájením projektu.
8. Modernizace s pomocí umělé inteligence
Modernizace s pomocí umělé inteligence využívá rozsáhlé jazykové modely a specializované nástroje umělé inteligence k urychlení nejnáročnějších fází modernizace starších systémů: porozumění kódu, generování dokumentace, překlad kódu a generování testů.
Nástroje pro překlad z COBOLu do Javy používají LLM vyladěné v obou jazycích k vytvoření počátečních překladů programů v COBOLu, které pak lidští inženýři kontrolují a vylepšují. Překlad eliminuje většinu mechanického převodního úsilí, ale neodstraňuje potřebu lidského pochopení toho, co by měl přeložený kód dělat.
Automatizované generování dokumentace analyzuje starší kód a vytváří strukturovanou dokumentaci o tom, co každý program dělá, jaká obchodní pravidla implementuje, jaká data čte a zapisuje a za jakých podmínek se větví. Tato dokumentace je předpokladem pro to, aby lidští inženýři mohli validovat přeložený kód a aby si organizace uchovala znalosti i po odchodu expertů na COBOL do důchodu.
Generování testů využívá umělou inteligenci k vytváření jednotkových testů pro starší programy na základě analýzy jejich vstupně/výstupního chování, čímž vytváří pokrytí testů, které nebylo nikdy napsáno během původního vývoje a které je nutné před bezpečným provedením jakéhokoli refaktoringu.
Kritické omezení modernizace s pomocí umělé inteligence: Nástroje umělé inteligence urychlují konverzi kódu. Neodstraňují však potřebu porozumět obchodní logice, kterou kód implementuje. Správně přeložený program je stále neúspěšný, pokud je překlad správný a obchodní pravidla byla špatně pochopena. Nástroje umělé inteligence snižují náklady na mechanickou práci, nikoli náklady na porozumění.
Výběr správného přístupu: Rámec pro rozhodování
Správný přístup k modernizaci jakéhokoli systému závisí na čtyřech faktorech posuzovaných společně: obchodní kritičnost, technická složitost, strategická hodnota a dostupný rozpočet a časový harmonogram.
| Profil systému | Doporučený přístup |
|---|---|
| Nízká obchodní kritickost, nízká složitost | Odejít do důchodu nebo znovu hostit |
| Vysoká obchodní kritickost, nízká složitost, faktor ovlivňující náklady na infrastrukturu | Znovu hostovat nebo změnit platformu |
| Vysoká kritičnost, střední složitost, technický dluh jako primární problém | Inkrementální refaktoring |
| Vysoká kritičnost, vysoká složitost, kritické pro daný úkol, nulové požadavky na prostoje | Vzorek Strangler Fig |
| Systém úzce propojený se zastaralou platformou | Replatform nebo Rearchitect |
| Funkce komodit dostupná jako SaaS | Nahradit |
| Kromě ekonomické opravy i dobře pochopených požadavků | Přestavba (s maximální opatrností) |
| Rozsáhlé portfolio jazyků COBOL nebo starších jazyků | Překlad s pomocí umělé inteligence + ověření lidskou silou |
Nejčastější chyba: použití stejného přístupu na každý systém v portfoliu, protože je to jednodušší vysvětlit zainteresovaným stranám. Modernizační program, který replatformuje vše bez ohledu na charakteristiky systému, povede k výsledkům od vhodných (u některých systémů) přes zbytečné náklady (u systémů, které měly být vyřazeny) až po nebezpečné zjednodušení (u systémů, které skutečně potřebovaly rearchitekturu).
Výzvy modernizace starších systémů: Co programy narušuje
Pochopení selhání modernizačních programů je stejně důležité jako pochopení dostupných přístupů. Selhání jsou konzistentní:
Nedokumentovaná obchodní logika. Starší systémy obsahují obchodní pravidla, která neexistují nikde jinde než v chování kódu. Program v COBOLu, který dvanáct vývojářů modifikovalo během třiceti let, kóduje rozhodnutí, která nikdy nebyla zdokumentována a kterým žádný žijící člen týmu plně nerozumí. Jakýkoli modernizační přístup, který tuto logiku před změnou systému neextrahuje a nedokumentuje, riskuje vytvoření nového systému, který se chová jinak než ten starý způsobem, který se objeví až tehdy, když dojde k obchodním důsledkům.
Pokusy o velkolepou modernizaci. Organizace, které při modernizaci selhávají nejvýrazněji, jsou ty, které se pokoušejí nahradit celý systém najednou a provést modernizaci k určitému datu. Každý dobře zdokumentovaný velký neúspěch modernizace, TSB Bank, FBI VCF, Queensland Health, sdílí tento vzorec. Postupná modernizace s průběžným ověřováním v každém kroku je přístup, který vede k úspěchu.
Rozšíření rozsahu a objevování během realizace. Modernizační tým odhaluje složitost, která nebyla během plánování viditelná. Systém, který se jevil jako omezená aplikace, se ukázalo jako sdílení dat s dvaceti dalšími systémy prostřednictvím nedokumentovaných rozhraní souborů. Funkce, která se zdála být přímočará, implementovala obchodní pravidlo, jehož zavedení trvalo tři měsíce regulačních vyjednávání a které není nikde zdokumentováno. Lékem je strukturální analýza před plánováním, ne plánování bez strukturální analýzy.
Riziko koncentrace znalostí. Lidé, kteří nejlépe rozumí staršímu systému, jsou často ti, kteří jsou nejblíže odchodu do důchodu. Pokud odejdou dříve, než jsou jejich znalosti převedeny a zdokumentovány, modernizační tým pracuje s neúplným pochopením toho, co systém dělá.
Měření špatných věcí. Týmy, které měří úspěšnost modernizace procentem migrace kódu nebo dodržováním časového harmonogramu, spíše než obchodními výsledky, snížením nákladů, spolehlivostí služeb nebo dobou dodání funkcí, optimalizují spíše pro aktivitu než pro výsledky.
Posouzení, které musí předcházet jakémukoli rozhodnutí o přístupu
Nejdůležitější věcí, kterou může každá organizace udělat před volbou modernizačního přístupu, je pochopit, s čím pracuje. Hodnocení, které zahrnuje kontrolu dokumentace a pohovory s vývojáři, je nedostatečné ze dvou důvodů: dokumentace je neúplná a zastaralá a znalosti vývojářů jsou rozptýlené, nekonzistentní a soustředěné u lidí, kteří jsou často nedostupní nebo se blíží důchodu.
Strukturální posouzení, analýza skutečného zdrojového kódu každé aplikace v rozsahu a vytvoření modelu závislostí z toho, co kód skutečně dělá, vytváří důkazní základnu pro každé následné rozhodnutí:
Inventář programů. Kolik programů skutečně existuje, včetně těch, které nejsou uvedeny v dokumentaci. Ve velkých starších prostředích skutečný počet obvykle překračuje zdokumentovaný počet o 20–30 %.
Mapování závislostí. Které programy volají které ostatní, které sdílejí data prostřednictvím souborů nebo databází, které úlohy JCL volají které programy v jakém pořadí. Struktura závislostí určuje pořadí migrace, komponenty s vysokým počtem přímých vstupů, na kterých je mnoho dalších závislých, migrují jako poslední.
Identifikace mrtvého kódu. Programy, které nejsou nikdy volány žádnou produkční cestou, lze z rozsahu modernizace zcela vyloučit. V typických starších portfoliích představuje mrtvý kód 10–25 % celkového inventáře, což je ve fázi hodnocení dosažitelné významné snížení rozsahu.
Klasifikace složitosti. Které programy mají nejvyšší cyklomatickou složitost, nejvíce závislostí na sešitech, nejvíce volajících programů a nejvíce interakcí s databází? Toto jsou programy, které vyžadují největší úsilí a nesou největší riziko, a měly by být osloveny až jako poslední, poté, co tým získá zkušenosti s méně složitými komponentami.
Extrakce obchodní logiky. Jaká rozhodnutí každý program implementuje, na jaké podmínky se větví, jaké výpočty provádí. Tato dokumentace je specifikací, podle které musí být modernizovaný systém validován.
Jak SMART TS XL Podporuje modernizaci starších systémů
Výše popsané strukturální posouzení je přesně to, co SMART TS XL automatizuje. Současným rozborem každého programu v COBOLu, toku úloh JCL, sešitu úloh, modulu PL/I, programu RPG, schématu SQL a související komponenty vytváří kompletní model závislostí, díky kterému je plánování modernizace založeno na důkazech, nikoli na předpokladech.
Analýza modernizace starších programů vytváří kompletní inventář programů, včetně programů, které v dokumentaci chyběly, s předběžným hodnocením složitosti pro každou komponentu. Mapování závislostí aplikací vytváří graf závislostí mezi jazyky, který určuje pořadí migrace: které komponenty lze modernizovat v raných vlnách, protože na nich nic nezávisí, a které musí počkat, dokud nebudou jejich závislé komponenty připraveny.
Díky analýze dopadů je každá navrhovaná změna před provedením vědoma rizik: když tým navrhne modernizaci COBOLu, který je součástí 300 programů, analýza dopadů vyjmenuje každý z těchto 300 programů, vymezí rozsah validačního úsilí a odhalí závislosti s nejvyšším rizikem před provedením změny.
Funkce statické analýzy kódu identifikuje nefunkční kód, programy a odstavce bez vstupních odkazů z jakékoli produkční cesty, což umožňuje jejich vyloučení z rozsahu modernizace před zahájením jakýchkoli konverzních prací. Pro organizace migrující do cloudu je nemigrace nefunkčního kódu jedním z nejpřímějších zdrojů snížení nákladů, kterého lze dosáhnout během fáze hodnocení.
Díky funkci podnikového vyhledávání lze strukturální model dotazovat v průběhu víceletého modernizačního programu: během několika sekund lze najít každý program, který čte z určité datové sady, každý sešit, který definuje určité pole, každou úlohu JCL, která volá konkrétní program, napříč miliony řádků kódu v libovolné kombinaci jazyků.
SMART TS XLJe vizualizace kódu vytváří diagramy závislostí a vývojové diagramy programu, které činí nedokumentovanou strukturu systému srozumitelnou pro celý modernizační tým, včetně inženýrů, kteří nikdy neviděli COBOL a potřebují pochopit, co programy, které nahrazují, skutečně dělají.
Postupná modernizace: Princip každého úspěšného programu
Nejkonzistentnějším zjištěním napříč úspěšnými i neúspěšnými modernizačními programy je role inkrementalismu. Nejlepší postup: Inkrementální modernizace s využitím vzoru „strangler“ nebo komponovatelných plánů snižuje riziko migrací úloh po jednotlivých doménách nebo funkcích.
Inkrementalismus není bázlivost. Je to uznání, že porozumění komplexnímu starému systému roste v průběhu modernizačního procesu a že program strukturovaný tak, aby toto rostoucí porozumění zahrnoval v každé fázi, bude přijímat lepší rozhodnutí než program, který všechna rozhodnutí předem zařazuje do fáze plánování, jež nutně předchází plnému porozumění.
Modernizační programy, které přinášejí předpokládanou návratnost investic, definují úspěch na úrovni vlny, kdy každá vlna dodává ověřené a produkčně připravené komponenty, spíše než na úrovni programu, kde je úspěch definován až v konečném bodě. Každá vlna buduje organizační sebevědomí, odhaluje složitosti integrace dříve, než se stanou překážkami, a ukazuje, že zvolený přístup funguje ve specifickém kontextu systémů a omezení dané organizace.
