Tudom, ez furcsán hangzik egy olyan cégtől, amelyik legacy modernizációból él.
De éppen ezért mondhatom el hitelesen: a legacy modernizáció nem mindig a helyes döntés. Sőt - tapasztalatom szerint az összes "modernizáljunk mindent" projekt legalább harmada olyan rendszert érint, amelyet valójában nem kellett volna megérinteni. Legalábbis nem akkor, nem úgy, és nem azért.
Az európai vállalatok 55%-a még mindig olyan kritikus rendszereket használ, amelyek legalább 10 évesek. Ez nem feltétlenül baj. Néha ez bölcsesség.
Mi az a legacy rendszer - és miért nem feltétlenül probléma?
Mielőtt belevágnánk, tisztázzuk a fogalmat. A "legacy" szó az IT-ban idővel pejoratívvá vált - mintha azt jelentené: elavult, rossz, szégyellnivaló.
Valójában a legacy rendszer egyszerűen annyit jelent: olyan rendszer, amely már régóta működik, üzleti logikát hordoz, és amelynek köré épültek az üzleti folyamatok. Ez nem baj. Ez érték.
A legtöbb pénzügyi szektorbeli legacy rendszer azért fut még 15-20 év után is, mert megbízhatóan csinálja amit csinál. A biztosítói core rendszer nem azért "legacy", mert rossz - hanem azért, mert 1998-ban írták, és azóta tízezer üzleti szabályt töltöttek bele, amelyek mindegyike egy valós üzleti igényt tükröz.
Ez az üzleti logika az igazi érték. Nem a technológia - az valóban elavult. De a benne kódolt tudás: az nem.
Mikor ne modernizáld a legacy rendszeredet? - 4 helyzet
1. Ha nem tudod pontosan mit csinál
Ez a leggyakoribb és legveszélyesebb helyzet.
A rendszer fut. Mindenki használja. De senki nem tudja pontosan hogyan számítja ki az X értéket, miért van kivételes kezelés a Z szerződéstípusnál, és mi az a különös logika a Q modulban, ami miatt "ne nyúlj hozzá, mert szétesik."
Ha nincs dokumentáció, és az eredeti fejlesztők már régen máshol dolgoznak - a modernizáció előtt nem refaktorálni kell, hanem megérteni. Egy discovery fázis, amely feltérképezi és dokumentálja a meglévő üzleti logikát, fontosabb és értékesebb mint maga a modernizáció. Ezt ritkán mondják el a modernizációt eladó cégek.
Mi mindig megmondjuk. Mert tapasztalatból tudjuk: ami dokumentálatlanul kerül át az új rendszerbe, az dokumentálatlanul fog hibázni - csak drágább technológián.
2. Ha a modernizáció valójában IT divat - nem üzleti igény
Előfordul - és szebb szóval nehéz megnevezni - hogy a modernizációs projekt mögött nem üzleti igény, hanem technológiai kíváncsiság vagy külső nyomás áll.
"Mikroszolgáltatásokra kellene átállni." "Mindenki cloudban van már." "A fejlesztők unják a Java 8-at."
Ezek lehetnek érvényes szempontok - de nem elegendő indokok egy működő, kritikus rendszer megérintéséhez. Ha a modernizáció elsődleges mozgatórugója nem egy konkrét, mérhető üzleti probléma, hanem az, hogy "modern legyen" - akkor nagyon óvatosan kell eljárni.
Egy biztosítói core rendszert nem azért kell modernizálni, mert a Spring Boot 3 már kijött. Azért kell modernizálni, mert a jelenlegi rendszer nem tudja kiszolgálni az új termékek bevezetési sebességét, vagy mert a compliance elvárások már nem teljesíthetők a jelenlegi architektúrában.
Ha nincs ilyen konkrét üzleti indok - várj.
3. Ha nincs meg a belső tudás az átálláshoz
A legacy rendszer modernizációja nem ér véget a szállítással. Az új rendszert valakinek üzemeltetni, fejleszteni és karbantartani kell. Ha a szervezetben nincs meg a kompetencia az új technológia kezeléséhez - a modernizáció egy új függőséget teremt, nem megszüntet egyet.
Láttam ezt közelről. Egy pénzügyi szektorbeli szervezet modernizált egy 15 éves Java rendszert - microservice architektúrára, Kubernetes-re, cloud natív megközelítéssel. A projekt technikailag sikerült. Utána az üzemeltetési csapat, amely korábban egy monolitot kezelt, hirtelen egy elosztott rendszert kapott, amelyet nem értett.
Az eredmény: az üzemeltetési költség megduplázódott, a hibakeresési idő megháromszorozódott, és fél évvel a go-live után külső segítséget kellett bevonni. Ez nem a modernizáció hibája volt - ez a felkészítés hiányának hibája volt.
4. Ha a határidő sürgeti a döntést
"Meg kell csinálni mert lejár a support." "Jövőre compliance audit lesz." "A vezérigazgató azt mondta Q3-ra legyen kész."
A sürgetés rossz tanácsadó legacy modernizációban. A tapasztalat egyértelmű: a határidő-vezérelt modernizációs projektek hajlamosak elhagyni azt az előkészítő munkát - dokumentálás, üzleti logika feltárás, fokozatos megközelítés tervezése - amelyek a sikert biztosítják.
A végeredmény: gyorsan megcsinált modernizáció, amely az éles bevezetés után hónapokig instabil, és amelynek üzemeltetése többe kerül mint a régi rendszeré.
Ha a support tényleg lejár - az nem feltétlenül jelenti, hogy a rendszer leáll. Jelenti, hogy a gyártó nem ad ki új security patch-et. Ez kockázat, amelyet kezelni kell - de nem feltétlenül teljes újraírással.
Mikor kell mégis modernizálni a legacy rendszert? - 4 egyértelmű jel
Az objektivitás kedvéért: négy helyzet van, amikor a legacy modernizáció nem opcionális, hanem stratégiai szükségszerűség.
Az integráció már nem lehetséges. Ha az új üzleti igények - mobilalkalmazás, API-alapú partnerkapcsolatok, real-time adatszolgáltatás- nem valósíthatók meg a meglévő rendszer technológiai korlátai miatt, és az API réteg már nem elegendő megoldás, akkor a modernizáció szükséges.
A karbantartási költség meghaladja az értéket. Ha a rendszer módosítása aránytalanul drága, ha minden változtatás regressziós hibák lavináját indítja el, és ha már nem találhatók fejlesztők, akik értik a technológiát - a fenntartás költsége exponenciálisan nő. Ilyenkor a legacy modernizáció hosszú távon olcsóbb.
A compliance elvárások már nem teljesíthetők. Pénzügyi szektorbeli szabályozói elvárások - DORA, MNB előírások, GDPR - néha olyan rendszerkövetelményeket támasztanak, amelyek a meglévő architektúrában egyszerűen nem implementálhatók. Ez egyértelmű jelzés.
Az üzleti fejlődés blokkolva van. Ha az IT rendszer nem képes követni az üzleti változásokat - új termékek, új csatornák, új partnerek - és ez valós bevételkiesést vagy piaci hátrányt okoz, a modernizáció megtérül.
Legacy modernizáció: fokozatos fejlesztés vagy teljes újraírás?
Ha a négy jel valamelyike teljesül, a kérdés már nem az, hogy kell-e modernizálni. A kérdés az, hogy mit modernizáljunk és hogyan.
Két alapvető megközelítés létezik:
Fokozatos modernizáció (strangler fig pattern) - a legacy rendszer köré fokozatosan épülnek az új komponensek, amelyek modulonként veszik át a funkciókat. A legacy rendszer addig fut, amíg az utolsó modul is átállt. Ez lassabb, de biztonságosabb - és pénzügyi szektorbeli kritikus rendszereknél szinte mindig ez a helyes út.
Teljes újraírás - nulláról új rendszer épül, amely átveszi a legacy helyét. Ez gyorsabbnak tűnik, valójában általában lassabb és kockázatosabb. Tapasztalat szerint 10-ből 9 sikeres legacy modernizáció inkrementális refaktorálás, nem rewrite. A teljes újraírás fő problémája a láthatatlan üzleti logika - az a tízezer apró szabály, amelyet az évek során a legacy rendszerbe égettek, és amelyet senki nem dokumentált teljesen.
Hogyan közelítjük meg a legacy modernizációt a FrontX-nél
Mielőtt bármilyen legacy modernizációs javaslatot teszünk, elvégzünk egy discovery fázist. Feltérképezzük a meglévő rendszer üzleti logikáját, azonosítjuk a valódi fájdalompontokat, és megvizsgáljuk az alternatívákat.
Néha az eredmény az, hogy nem javasoljuk a modernizációt - legalábbis nem most, nem így. Ez kellemetlennek tűnhet egy IT tanácsadótól. Valójában ez a legértékesebb szolgáltatás, amelyet nyújthatunk.
Mert egy rosszul időzített vagy rosszul megtervezett legacy modernizációs projekt drágább, mint a meglévő rendszer fenntartása. És ezt az ügyfélnek el kell mondani.
Ha legacy rendszerrel kapcsolatos döntés előtt állsz és szeretnéd, hogy valaki megnézze kívülről - szívesen konzultálunk: frontx.hu/kapcsolat
Kérdés hozzád
Találkoztál már olyan legacy modernizációs projekttel, amelyet visszamenőleg nem kellett volna elindítani? Mi volt az a jel, amelyet előre lehetett volna látni?
Gyakran ismételt kérdések
Mikor nem érdemes modernizálni a legacy rendszert?
Négy helyzetben érdemes elhalasztani: ha a rendszer üzleti logikája nincs dokumentálva, ha a modernizáció mögött nem konkrét üzleti probléma hanem technológiai divat áll, ha a szervezetben nincs meg a kompetencia az új rendszer üzemeltetéséhez, és ha a projekt határidő-vezérelt és kihagyja az előkészítő fázist.
Mi a különbség a fokozatos legacy modernizáció és a teljes újraírás között?
A fokozatos modernizáció (strangler fig pattern) a legacy rendszer köré modulonként épít új komponenseket - a legacy addig fut, amíg az utolsó modul is átállt. A teljes újraírás nulláról épít új rendszert. A fokozatos megközelítés lassabb, de biztonságosabb - tapasztalat szerint 10-ből 9 sikeres legacy modernizáció inkrementális, nem rewrite.
Mikor egyértelmű jel hogy legacy modernizációra van szükség?
Négy egyértelmű jelzés: az integráció az új üzleti igényekkel már nem lehetséges, a karbantartási költség meghaladja az értéket, a compliance elvárások a jelenlegi architektúrában nem teljesíthetők, vagy az üzleti fejlődés blokkolva van.
Mit jelent a legacy rendszer discovery fázis?
A discovery fázis egy rövid - általában 2-4 hetes - előkészítő szakasz, amelynek során feltérképezzük a meglévő rendszer üzleti logikáját, azonosítjuk a valódi fájdalompontokat és megvizsgáljuk az alternatívákat. Ez a fázis dönti el, hogy szükséges-e egyáltalán a modernizáció, és ha igen, milyen megközelítéssel. Enélkül a legacy modernizáció vakrepülés.
Meddig lehet fenntartani egy legacy rendszert?
A kérdés nem az, hogy hány éves a rendszer, hanem hogy milyen üzleti értéket hordoz és milyen problémát okoz. Sok pénzügyi szektorbeli legacy rendszer 15-20 év után is stabilan fut, mert a benne kódolt üzleti logika valódi értéket képvisel. A döntést nem a kor, hanem az üzleti igény és a karbantarthatóság kell vezérelje.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban.
LinkedIn: linkedin.com/in/laszlobehan | FrontX blog: frontx.hu/blog
