Jak na modernizaci legacy systémů

Nemožnost jejich jednoduchého opuštění vyplývá z potřeby zachování funkcí, které podnikům tyto systémy poskytují. Většina legacy systémů je stabilních, bezpečných, robustních a během doby provozu se jejich kód stal velmi dobře odladěným. Díky tomu většina společností na tyto systémy velmi spoléhá. Považuje je za nezbytné pro svoje fungování, a proto se zdráhá je jakkoli měnit. Vzhledem k tomu, že řada těchto systémů má takřka „historické kořeny, trpívají nedostatkem modularity, špatnou abstrakcí dat a neadekvátními možnostmi modelování dat, protože business procesy jsou zobrazeny jen v kódu. S tím je spojen i problém, že řada osob spojených s vývojem těchto systémů odešla do důchodu nebo se tomuto věku rychle blíží a společnostem začínají enormně růst náklady na provoz.

Problémy s legacy systémy

Vztah business-IT

Společnosti dnes potřebují rychle přidávat nové funkčnosti k jejich IT produktům, propojovat infrastruktury zpracovávající data a prezentovat data novými způsoby. Těmto nárokům nejsou legacy systémy schopny jednoduše dostát a jsou jednou z příčin zpožďování uvádění produktů na trh.

Náklady

Střední mainframe používaný pro provozování legacy systémů stojí kolem 4mil. $ a roční náklady na licence a provoz se také šplhají do milionů. Společnosti proto zvažují, zda se jim jejich provoz skutečně vyplatí.

Nedostatek znalostí

Během let procedurální jazyky používané před lety na mainframech ztratily svůj význam ve vývoji aplikací ve prospěch objektově orientovaných jazyků a přestaly být vyučovány. Dnes je proto pociťován nedostatek odborníků s potřebnou úrovní znalostí legacy systémů.

Databáze

Tehdy používané hierarchické databáze nevyhovují potřebám dneška, jak z hlediska komplexnosti péče tak způsobu použití.

Dokumentace a procesy

Dokumentace k systémům navrženým před 15, 20 nebo více lety, není na takové úrovni jako u dnešních systémů. Business logika je obvykle známa jen expertům, kteří byli součástí vývoje a často k ní chybí dokumentace. Legacy systémy obvykle implementují velmi komplexní funkce, k nimž chybí dokumentace popisující vazby v systému. Proto je velmi obtížné plánovat jejich migraci.

Jaké jsou možnosti modernizace?

V principu jsou možnosti dvě – buď úplná náhrada novým systémem, nebo částečná modernizace – viz obr 1.

Úplná náhrada legacy systému může být realizována buď výměnou za „standardní“ software pokud legacy systém poskytuje obvyklé funkce jako je ERP, CRM nebo HR (SAP, Siebel…), a nebo přepsáním kódu, a to buď automatizovaně nebo ručně. Přepsání pak umožňuje zároveň migrovat databázi a zvolit modernější jazyk.

Částečná modernizace pak dovoluje modernizovat jen část architektury systému – např. změnit databázi z hierarchické na relační nebo modernizovat uživatelské rozhraní. Možností je také přenést systém na hostingovou platformu která dovolí zachovat kód aplikace (tzv. rehosting), – např. rekompilovat na Wintel nebo Unix, kde jsou k dispozici stejné databáze jako na původní platformě a odpovídající softwarový stack.

Metoda úplné náhrady legacy systému nezachovává původní kód a znamená úplnou migraci (jazyk, databáze, platforma) a je proto nejkomplexnější a má nejvyšší riziko vzniku chyb. Náhrada business logiky vybudované za roky a to většinou lidmi, kteří nepracovali na původním projektu, vede na vysoké náklady a dlouhou dobu migrace. Navíc replikace business logiky obvykle není 1:1, ale je zatížena kompromisy nebo při snaze o její zachování extenzivním využitím konzultačních služeb na přizpůsobení „standardních“ balíků. Díky tomu je návratnost investice obvykle v nedohlednu.

Proto i firmy, které jsou rozhodnuty opustit původní kód, začínají rehostingem, který nezabere tolik času, má nižší náklady a nižší rizika. Výhodu je zvýšení efektivity stávajících vývojářů na platformě s lepšími nástroji na debugging a analýzu. Rehosting ovšem neřeší problém nedostatku vývojářů, protože stále zůstává potřeba znalostí původních jazyků a databází.

Automatizovaná konverze kódu často vede na kód, který je komplikovaný, špatně pochopitelný a obtížně se v něm proto dělají změny. Cílem automatické konverze je proto spíše rychle získat bezchybně zkompilovaný nový kód a menší péče je věnována přesnému zachování business funkcionality nebo její modernizaci. Je tedy řešením tam, kde je nezbytné opustit stávající platformu. Automatizovaná konverze není samozřejmě 100%, a často bývá nezbytné některé kusy kódu přepsat ručně. Manuální přepis kódu má naopak nepopiratelnou výhodu v tom, že přepsaný kód zachovává lépe business funkcionality, je lépe udržovatelný a rozšiřitelný. Další výhodou je snížení závislosti na legacy vývojářích, kterých je nedostatek.

Vzhledem ke komplexnosti problematiky vyvinula společnost T-Systems metodiku pro řízení projektů modernizace legacy systémů. V pěti fázích je nejprve prozkoumáno prostředí a vyhodnoceny závislosti a komplexita každé aplikace, následně je připraven návrh architektury a mapa, business case a projektový plán na řízení samotného procesu modernizace, který je finální fází a končí dodáním dokumentace a uvedením modernizovaného systému do provozu.

Zdeněk Lejsek, T-Systems Czech Republic