Felmerül egy értekezleten, hogy hozzá kellene nyúlni az elszámolási modulhoz. Valaki felteszi a kézenfekvő kérdést, hogy ez mi mást érint, és a válasz egy jó nagy adag csend. Nem azért, mert rossz szakemberek ülnek az asztalnál, hanem mert a rendszert tizenkét éve mások építették, az eredeti csapatból ketten maradtak, és a kritikus tudás nagyrészt az ő fejükben él. A nagyvállalati IT-vezetőknél, akikkel beszélgetünk, ez egy elég nagy teher. A nagyvállalati IT-vezetőknél, akikkel beszélgetünk, ez egy elég nagy teher.
Bár hirtelen felindulásból felmerül, de a kérdés ilyenkor már nem az, hogy ki a hibás, hanem az, hogy mit lehet tenni, ha egy üzletkritikus rendszert már senki nem lát át teljesen.
A „van dokumentációnk” sokszor illúzió
Papíron általában van valami: örökölt Wordök, egy-két Excel-tábla, régi Confluence-oldalak, célozgatások arra, hogy egy emailben le vannak írva a legújabb változtatások… A baj az, hogy ezek ellentmondanak egymásnak, évek óta nem frissültek, senki nem tudja, ki küldte azt az emailt kinek, és pontosan ezért a csapat sem bízik ezekben az írásokban. Ami egyszer pontos volt, az néhány release után már félrevezet, hiszen a kód továbbment, a dokumentum pedig a fiókban maradt.
A hiányzó, megbízható dokumentáció így válik kockázattá. Ha a tényeket minden döntés előtt a kódból kell kibányászni, minden fejlesztés átfutása megnyúlik, az audit tűzoltássá válik, a board elé pedig becslések helyett elég erős tippek kerülnek. Vagyis vagy túlbiztosítjuk a projektet (ez drága), vagy alulbecsüljük, és menet közben jönnek a meglepetések.
És ha rádobunk egy AI-t?
Kézenfekvő ötlet: ott a sok új GenAI-eszköz, dobjuk be nekik a kódot, majd megmondják, mit csinál. A gyakorlatban ez önmagában nem elég, és ennek konkrét, technikai oka van. (Arról, hogy a teljes legacy modernizációt rá lehet-e bízni az LLM-ekre, korábban külön cikkben írtunk.)
Egy nyers nagy nyelvi modell (LLM) mindig csak akkora szeletet lát a rendszerből, amekkorát betöltünk neki. Egy nagy legacy core viszont nem fér bele egyetlen kontextusablakba, ráadásul a lényeg gyakran épp a modulok közti összefüggésekben rejlik. Ha a teljes kép hiányzik, a modell magabiztosan kitölti a réseket, azaz hitelesen hangzó, de esetleg téves választ ad. Szabályozott környezetben, ahol a döntés mögött felelősség áll, ez nem vállalható.
Pedig az AI ereje éppen a léptékben van: nagyságrendekkel nagyobb kontextust képes átlátni és összefüggéseiben értelmezni, mint amennyit mi kézzel végig tudunk követni. Igenám, de ez csak akkor ér valamit, ha minden állítása visszavezethető a forráskód konkrét pontjára.
A kontroll a kódból szerezhető vissza
Ahelyett, hogy újabb, gyorsan elavuló dokumentációt gyártanánk, a kódbázisból építünk egy élő, kereshető tudásréteget a rendszerről. Az alapja determinisztikus, tényekre épül; erre kerül az AI-narratíva, amely érthetővé teszi az összefüggéseket, a végén pedig emberi kéz ellenőrzi és kurálja az egészet. Minden válasz a kód egy konkrét pontjára mutat, így egy szakértő napok alatt visszaellenőrizheti.
A különbség a napi munkában látszik. A „mi mást érint, ha X-hez nyúlunk” kérdésre, ami eddig vállvonogatással vagy hetekig tartó, bizonytalan kézi átnézéssel járt, kézzelfogható választ kapsz: listát az érintett modulokról és folyamatokról, minden tétel mellett a kód pontos helyével, ahonnan az állítás származik. Egy közép-európai lakossági banki core rendszerénél a hatáselemzés ezzel a megközelítéssel hetekről egy-két órára rövidült, és ami ennél is fontosabb, ellenőrizhető maradt.
Az eredmény ráadásul az ő gitjükbe került, YAML- és markdown-fájlokként, a megszokott eszközökbe (Copilot, Cursor és társaik) beköthetően, és minden pull requesttel frissül. Tehát nem egy újabb beszállítói függőség: ha holnap leállítanak minket, a tudásréteg akkor is ottmarad.
Mit nyer ezzel a vezető
Üzletileg ez néhány jól látható ponton csapódik le:
- A kulcsemberi függőség oldódik. A tudás nem egy-két kolléga fejében létezik tovább, és nem sétál ki az ajtón egy nyugdíjazással vagy felmondással.
- A modernizáció kimozdul a holtpontról. A csapat végre látja, mihez nyúl, így ezt meg is meri tenni.
- Rövidül a betanulás, kiszámíthatóbb az audit. Az új kolléga nem hónapokig kérdezősködik, a megfelelési körökben pedig forrásra hivatkozó válaszokkal dolgoztok.
- A board előtt tényekkel érvelhetsz. A modernizációs döntéseket kimutatható adatokra alapozhatod, a túlbiztosítás és az alulbecslés közti ingadozás helyett.
Egy fontos határ, amit érdemes kimondani: ez nem egygombos csoda, és nem is kétéves nagyprojekt. Egy jól körülhatárolt területen hetek alatt látszik, mit nyersz vele, és onnan a következő lépést már nem találgatásra alapozod.
Hol érdemes kezdeni
Ha a fenti értekezleti csend ismerős, 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 meg lehet nézni, 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.
