Új szemüveget kellene feltennünk, mielőtt nekilátunk a több mint hatvanéves COBOL programnyelvet ócsárolni, véli a kormányzati informatika problémáival foglalkozó kaliforniai Government Technology Magazine (GovTech).

Épp egy éve történt, hogy New Jersey állam hirdetésben keresett natív COBOL-tudással rendelkező programozókat, mert félő volt, hogy az állam nem fogja tudni működtetni az abban írt munkanélküli-ellátást támogató rendszert. A rendszer nem is tudta kezelni a pandémia miatt ugrásszerűen megnőtt segélykérelmeket. A sztorit világszerte felkapta a sajtó, annak idején a Bitport is megírta.

Mint a GovTech szerzője írja, miután lehozták a New Jersey-i esetet, számtalan levelet kaptak, melyek többségében szörnyülködtek, hogy milyen képtelenség kritikus helyeken ilyen régi technológiát használni. Össztűz zúdult a programnyelvre, divat lett a COBOL-on élcelődni, az abban írt rendszereket csepülni. Pedig az 1959-ben kiadott objektumorientált magas szintű programnyelv mind a mai napig jelentős szerepet tölt be többek között az állami és pénzügyi szektorban (erről itt írtunk bővebben).

Valóban a COBOL a probléma?

A legacy rendszerek problémája közismert. Például az állami szervek vagy a bankok szolgáltatásait megalapozó ún. core rendszereket jellemzően hosszú távra vezetik be. Nem lehet évente leállni a core-rendszer cseréje miatt (óriási költség és kockázat). Az évtizedekig cipelt rendszer mellett viszont szükségszerűen elszalad a technológia.

De mi a szerepe a legacy rendszerekben magának a programnyelvnek? Valóban a COBOL-lal van probléma? William Malik, a Trend Micro infrastruktúra-stratégiáért felelős alelnöke, aki a szakma régi motorosa (1973-ban végzett az MIT-n), és többek között a COBOL-lal is barátságban van, azt mondta a New Jersey-i ügyről: az állam valószínűleg 10-15 éves gépeket használ. De, húz párhuzamot Malik: ő is azért jár egy 2006-os Audival, mert azzal eljut bárhova, nem kell, hogy gyorsabban legyen, teljesen biztonságos, hiszen rendszeresen karban van tartva, és pontosan tudja, hogyan kell vezetnie. A nyugdíjrendszernél szerinte a feldolgozási teljesítmény vagy a memória lehetett a szűk keresztmetszet, de nem a programnyelv vagy a kód.

A GovTech által megkérdezett szakértők Malikkal összhangban állították: a COBOL továbbra is jó bizonyos feladatokhoz, például adatok kötegelt feldolgozásához, hiszen eredetileg is ahhoz tervezték.

Nem jelent biztonsági kockázatot. Például a COBOL programok nem kommunikálnak kifelé, csak annyit jeleznek, hogy éppen adatot olvasnak vagy írnak. Ha a COBOL-alkalmazásokkal kapcsolatban felmerülnek biztonsági aggályok, legtöbbször kiderül: azok eredője az informatikai architektúrában vagy az alkalmazottak között keresendő. (Utóbbi problémát a pandémia még fel is erősítette).

Mindezeknek a faktoroknak semmi közük ahhoz, hogy az adott programot milyen nyelven kódolták. Az kétségtelen, hogy vannak a COBOL-nak biztonsági jellegű kihívásai, mondta a szaklapnak Pennsylvania állam CISO-ja, Erik Avakian. Általában a régebbi technológiákból hiányoznak a manapság természetes szolgáltatások (rendszeres biztonsági frissítés, többtényezős hitelesítés stb.). És való igaz, egyre kevesebben is értenek az ilyen rendszerekhez.

Túl van tolva a nyugdíjpánik?

A felmérések azonban ellentmondásosak, ugyanis jellemzően arra koncentrálnak, hogy a COBOL-szakértők hány százaléka éri el a nyugdíjkort (a nyugdíj nem akadály, lásd a COBOL Cowboys cég sztoriját), Valamilyen furcsa ok miatt a COBOL-programozók átlagéletkora alig változott az elmúlt másfél évtizedben. Egy 2006-os felmérés a 45-55 éves sávba tette az átlagot, egy 2020-as kutatás, amit a Micro Focus készíttetett, 50 évet hozott ki. A Gartner szerint számuk évről évre csökken (ahogy valószínűleg a futó COBOL programoké is), pedig évente csak az USA-ban ezreket képeznek ki az érdekelt vállalatok (pl. a Micro Focus vagy az IBM).

A hozzáértők körének szűkülése felszínre hoz egy a szervezetek belső működésére jellemző problémát: mennyire gyenge a szervezeteken belül az intézményes tudásmegőrzés és -átadás. Hogy lehet, hogy amikor nyugdíjba vonul az, aki az adott programot írta és fejlesztette 20 éven át, senki sem tudja átvenni a helyét? A COBOL lecserélése nem oldja meg ezt a problémát.

Mindezzel együtt számos helyzet lehet, amikor igenis célszerű váltani. De csak ha valamiféle holisztikus szemlélettel az egész architektúrát újra szeretnénk gondolni egy olyan modernizációs projekt keretében, ami komoly hozzáadott értéket is hoz.

Az nem indok a cserére, hogy valami régi, a szó ugyanis még az IT-ban sem szinonimája a 'rossz'-nak. Ha csak emiatt váltanánk, végezzünk el egy gondolatkísérletet, javasolja William Malik. Fogunk egy működő kódot, és újraírjuk egy másik nyelven, aminek a működését természetesen újra kell tesztelni. A nap végén pedig mérleget vonhatunk: miért költöttünk pénzt arra, ami már jól működött?