Sok cégnél a legacy rendszer lecserélése évek óta „a jövő évi projekt”. A büdzsé megvan, a szándék is, szállító is akadna, a téma mégis minden évben lekerül a napirendről. És valahányszor komolyan nekifutnánk, ugyanabba a falba ütközünk: nem tudjuk pontosan, mihez nyúlunk.
A belső csapat nem meri levetni a régit
Aki nap mint nap a rendszerrel dolgozik, az tudja a legjobban, mennyi ismeretlen van benne. Egy tizenöt éve épülő core tele van olyan döntéssel, amit ma már senki nem tud megindokolni, és olyan rejtett függőséggel, ami csak akkor derül ki, amikor eltörik valami. A csapat ezért inkább a meglévőt foltozza, semmint hogy belenyúljon a sötétbe. Aki tudja, mennyi ismeretlen van a rendszerben, az kétszer meggondolja, mihez ér hozzá.
A beszállító cseréje sem oldja meg a helyzetet, hiszen az új csapat ugyanazzal az átláthatatlansággal találja szembe magát, csak még kontextus nélkül. A felügyelet közben azt látja, hogy a modernizáció csúszik, és a kérdései egyre kellemetlenebbek.
Miért nem az újraírás az első lépés?
A szokásos reflex a csere: írjuk újra az egészet egy modern technológiai stacken. Igenám, de amit nem látunk át, azt nem tudjuk biztonságosan újraírni. A könnyebb nyolcvan százalék gyorsan elkészül, aztán a maradék, a legbonyolultabb és leginkább üzletkritikus rész viszi el az idő és a költség nagyját (arról, hogy önmagában egy LLM miért nem oldja meg ezt a húsz százalékot, külön is írtunk). Ráadásul a régi rendszer rejtett hibáit és megkerülő megoldásait hajlamosak vagyunk vakon átörökíteni, mert nem tudjuk, melyik viselkedés szándékos és melyik baleset.
Így lesz a kétéves nagyprojektből hároméves, és így kerül vissza a modernizáció minden évben a „majd jövőre” rovatba.
A megértés az első lépés
Mielőtt bármit lecserélnénk, vissza kell szerezni a rálátást a rendszerre, mégpedig úgy, hogy az ellenőrizhető legyen. Ez nem újabb, polcra kerülő dokumentációt jelent, hanem a kódbázisból épített, élő, kereshető tudásréteget, ahol minden állítás visszavezethető a forráskód egy konkrét pontjára. Egy szakértő napok alatt leellenőrizheti, tehát nem hitre épül, hanem tényekre.
Innentől a modernizáció tervezhetővé válik. Látszik, mi mit érint, mi a ténylegesen futó és mi a holt, sosem hívott kód, hol vannak a kockázatos pontok. A „mi dől be, ha hozzányúlunk” kérdésre konkrét, kódra hivatkozó válasz érkezik, órák, nem hetek alatt. Egy közép-európai lakossági banki core-nál például a hatáselemzés ezzel a megközelítéssel hetekről egy-két órára rövidült, és közben végig ellenőrizhető maradt. A lecserélés így már tervezhető: lépésről lépésre halad, és minden szakasz kockázata előre felmérhető.
Mit jelent ez a vezetőnek
A modernizáció elakadása ritkán technológiai kérdés. Sokkal inkább arról szól, hogy a döntéseinket bizonytalanságra alapozzuk, és emiatt halogatjuk őket, teljesen érthetően. Ha a megértés a kódból, ellenőrizhetően adott, a roadmap újra szállíthatóvá válik, a board elé tények kerülnek, a kulcsemberi függőség pedig oldódik, mert a tudás nem egyetlen ember fejében él tovább.
Egy határ, amit itt is érdemes kimondani: ez nem egygombos csoda, és nem is kétéves nagyprojekt. Egy jól körülhatárolt területen viszont hetek alatt kiderül, hol tartotok valójában, és a következő lépést már nem becslésre alapozzátok, hanem arra, amit a kód ténylegesen mutat.
Hol érdemes kezdeni
Ha nálatok is évek óta csúszik egy modernizáció, az első lépésnek nem kell projektnek lennie. Összeraktunk egy rövid önértékelőt: hat dimenzió mentén, kizárólag a saját válaszaidból rajzol board elé vihető kockázati képet, akár adatmegadás nélkül. Mérd fel, hol áll most a rendszered (kb. 5 perc). Azt pedig, hogy maga a megközelítés hogyan működik, a Nitro Legacy Explorer oldalán nézheted meg.
Az érdemi első lépés ezután egy kisebb, jól körülhatárolt modul: egy ilyen szeleten kiderül, hogyan fest a kódra visszavezethető, ellenőrizhető válasz a ti legnehezebb kérdésetekre, mielőtt bármilyen nagyobb döntés születne. Ha szeretnéd, egy rövid beszélgetésen közösen átnézzük, nálatok melyik modul lenne erre a legalkalmasabb.
