Már a felhőbe készülnek a magyar bankok, de a nagy rendszercserék ideje még nem jött el

Hogyan lehet képessé tenni a nagybankok rendszereit az innovációra úgy, hogy közben nem állnak meg, folyamatosan rendelkezésre áll a rendszerük?

Jó ideje a vállalatok legnagyobb problémája az, hogy hogyan szabaduljanak a legacy IT-megoldásoktól. Nagyon nehéz egyszerre megfelelni az új ügyféligényeknek, illetve az üzleti környezet folyamatos változásának anélkül, hogy az értékáram, illetve a profit ne sérüljön. Nehéz feladvány, de látunk erre nagyon jó megoldásokat. Egyszerűnek tűnik, de az egyik bevált séma a „terítő-elv”, amit nagyon gyakran alkalmazunk:

jóízűen lehet falatozni egy olyan asztalról, amelyiken csodálatos a terítő, akkor is, ha az asztal felülete kopott.

A pénzintézetek gyakran komplex rendszercserékben gondolkodnak, miközben nagyon sok olyan megoldás létezik, amivel a rendszer hiányosságait, hibáit szépen el lehet fedni, így az ügyfélélmény jelentősen javul, ezáltal a pénzintézet megítélése is. A háttérben pedig olyan cache és egyéb mechanizmusokat lehet bevezetni, amelyekkel a legacy rendszerek hibáit át lehet ugrani, sokkal gyorsabbá lehet tenni.

A meglévő infrastruktúrára lehet modern bankot építeni?

A frontend felől kell haladni befelé, rétegről-rétegre lehet megújítani és gyorsítani a rendszert. A core rendszer cseréje általában 3-4 évet vesz igénybe, és nagyon sok pénzintézetnél ezzel nincs is probléma. Inkább a core és a frontend közötti middleware rendszerekben rejlik a lassúság. A frontendet viszonylag könnyen ki lehet cserélni, és mi azt ajánljuk, hogy ne várjanak ezzel, hanem bátran nyúljanak hozzá, mert amivel napi szinten találkozik az ügyfél, az határozza meg, hogy mit gondol a pénzintézetről. Ezzel párhuzamosan érdemes kiépíteni a microservice, cloud native megoldásokat, ami a meglévő backendre vagy core rendszerre is épülhet, ezekkel ugyanis jelentősen fel lehet gyorsítani a régi vasakat is.

Sok pénzintézet előtt az a megoldás lebeg, hogy a jelenlegi rendszert, úgy, ahogy van, ki kell tenni a felhőbe, de szerintem ez egy zsákutca. A másik jellemző felfogás, hogy a cloudot megtagadják, ez szintén nem vezet jóra. Sok vállalat ennek ellenére még ebben a fázisban van. Hosszú távon működőképesek lehetnek cloud only rendszerek is, de az évtized közepéig inkább a cloud native korszak lesz jellemző a nagyvállalatoknál. Ez azt jelenti, hogy házon belül elkezdenek cloud-kompatibilis módon fejleszteni, de a megoldás a saját infrastruktúrán működik. Így megmarad a lehetősége annak, hogy amikor a törvényi szabályozás lehetővé teszi, és amikor a bank úgy dönt, akkor felhőbe teheti a rendszere mélyebb rétegeit is, de ezt nem egyik pillanatról a másikra kell drasztikusan meglépni.

A Covid-időszak „digitális robbanást” hozott a bankszektorban is, a kijárási korlátozásokkal sokan a virtuális térben kezdtek el ügyeket intézni, nagyobb terhelést kaptak a rendszerek. Jól jöttek volna a felhős megoldások ebben az időszakban?

Az on-premise, azaz földi infrastruktúrára épülő rendszereknek a legnagyobb hátránya a dinamikus skálázhatóság hiánya. Egy bizonyos ügyfélszámra, forgalomra tervezték a rendszert, és ha jön egy nagyobb terhelésű időszak, egy nagyobb hullám, akkor imádkozunk, hogy a vasak bírják. A hagyományos infrastruktúra-megoldások a legcsúnyább, legsötétebb napra, a maximális terhelésre vannak beállítva. Így az idő 90 százalékában ezek a vasak valójában panganak, ez igazi pazarlás.

Az elmúlt 10 évben villámsebességgel elkezdtek terjedni a felhős megoldások, melyek nagyon rugalmas, dinamikus skálázhatóságot biztosítanak. Ha pillanatnyilag szükség van egy sokkal nagyobb teljesítményre, akkor pár mozdulattal lehet növelni azoknak az alkalmazásoknak a számát, amik kiszolgálják a rendszert, és ha erre éppen nincs szükség, akkor lejjebb lehet skálázni.

Az IT-szektoron belül megjelent egy újfajta standard, és az eszerint fejlesztett szoftvereknek nem feltétlenül kell a felhőben futniuk. Egyre gyakrabban találkozunk olyan hibrid megoldással, amikor alapesetben a pénzintézet földi kiszolgálást végez a meglévő rendszerével, hiszen amíg azt nem tudják 100 százalékban kihasználni, addig felesleges a felhő használata. De ahogy eléri a terhelés a kritikus pontot, amikor már a földi infrastruktúra nem bírja a forgalmat, bekapcsolódik a cloud kiszolgálás. De ez csak abban az esetben lehetséges, ha azok a rétegek, amelyek a földi kiszolgálásban részt vesznek, cloud native-ok.

Milyen előnyök származnak a cloud native irányba történő elmozdulásból?

A skálázhatóság mellett a cloud native megoldásoknál a szabványnak is nagyon fontos szerepe van. Ahogy standardizáljuk a megoldásokat és azok csomagolását, konténerizáljuk őket,  az ugyanazt a forradalmat hozza el, mint ami a szállítmányozáson söpört végig évtizedekkel ezelőtt. Amíg nem voltak konténerek, minden egyes hajónak megvolt a szakértője, aki tudta, hogy a zongorát hova kell rakni, hol kell elhelyezni a halakat, a kávét, hogy ne büdösödjönek meg, ne legyen hatással egymásra a két áru. A konténerizáció azt oldotta meg, hogy bármilyen szervertípust berakhatunk egy standard konténerbe, és innentől kezdve standard eszközünk van arra, hogy a konténert hogyan fogom meg, hogyan pakolom rá a hajóra. Nem kell feltétlenül kell érteni a konténerek belsejéhez ahhoz, hogy a fejlesztők kezelni tudják őket, mégis sokkal szélesebb spektrumú alkalmazásportfóliót tudnak üzemeltetni.

A hagyományos IT-infrastruktúra olyan, mint egy házikedvenc: minden egyes szervernek, strukturális elemnek neve van, napi szinten simogatjuk. A cloud native rendszerekre sokkal inkább a csordaszellem jellemző, nincs neve a szervernek, az alkalmazásnak, hanem valamilyen azonosítója van, és ha bővíteni kell, akkor csordában gondolkodhatunk.

Meddig lehet a meglévő core rendszereket csiszolgatni? Mikor jön el az a pont, amikor már muszáj lecserélni?

A core rendszerek sokkal nagyobb teljesítménnyel bírnak, mint amennyi eljut ebből az ügyfélhez. Az igazi problémát nem a core rendszerekben látom, hanem a middleware rétegben. A pénzintézetek ezen a problémán sokat javítottak, hiszen az azonnali fizetéssel járó fejlesztéseket végrehajtották, ott nagyon keményen bele kellett nyúlni ebbe a rétegbe. Az alaprendszer és a frontend között már van egy olyan réteg, amihez szabadon hozzá tud nyúlni a pénzintézet, meg tudja jeleníteni az adatokat, be tudja kérni az ügyfél-interakciókat, be tud vezetni új technológiákat eszközöket, ami kritikus lehet, hiszen ezek nagyon gyakran változnak a core rendszer életciklusához képest.

Mit szerveznek ki és mit tartanak meg házon belül a bankok az IT-területen?

Ez nem csak operációs, hanem kulturális kérdés is: vannak olyan IT-beszállítók, amelyek agilitásban, cloud native kultúrában előrébb járnak, mint a pénzintézetek, de azoknak a bankon belüli fejlesztőknek, akik begyakoroltak egyfajta működést, nagyon nehéz lehet elhinni, hogy más módon is biztonságos lehet a munkavégzés, mint amihez 15-20 év alatt hozzászoktak. Ha létrehozunk egy vegyes csapatot a külső beszállítóval, nagyságrendekkel nagyobb a valószínűsége, hogy a kulturális változás végig fog menni a szervezeti egységben.

Amikor a pénzintézetek önállóan azzal próbálkoztak, hogy nulláról, beeső csapattal új módszertanra álljanak át, kívülről agilisnak, cloud native-nak látszó, de valójában hagyományosan működő csapatok jöttek létre.

Ezt úgy kell elképzelni, mintha a teknősre ráteszel egy nyuszifület, és azt mondod neki, hogy ugráljon, de az első stresszhatás, probléma hatására látod, hogy nem ugrik. Pedig kívülről úgy néz ki, mint egy nyúl.

Azt is látjuk, hogy csak belső munkatársakkal dolgozni vagy 100 százalékban mindent kiszervezni sem jó megoldás. Rengeteg féle innovációra van szükség a pénzintézeteknél, az új irányok, trendek befogadásához egy ökoszisztéma szintű működésre van szükség, ezt senki nem tudja megcsinálni egyedül. Másrészt pillanatnyilag egy hiperautomatizációs korszak előtt állunk, amikor minden bank és pénzintézet szinte minden folyamatot automatizálni szeretne, a belső erőforrásokat nem tudják olyan mértékben felskálázni, hogy ennek az elvárásnak meg tudjanak felelni.

Ha nőnek az igények, és a belső csapat nem győzi a munkát, ideiglenesen nem biztos, hogy érdemes belső erőforrásból építkezni, és utána visszaskálázni. Mi azt látjuk, hogy sok helyen egyidejűleg belsőcsapat-építkezés is folyik és a külső beszállítót is erősítik pont a kulturális előnyök miatt vagy új technológiák megtanulása, átvétele miatt. Magyarországon most ez a hibrid működés jellemző, de ez önmagában nem garancia semmire, hogy ez hol sikeres és hol nem, arról megoszlanak a vélemények.

A Covid-időszakban a nagyobb lélegzetvételű fejlesztések leálltak, viszont kisebb, gyors fejlesztésekre sor került. Most mi a helyzet?

Tény, hogy a Covid után óriási fellendülése volt a „quick win” projekteknek, mostanra ezek ki is futottak. Most azok a projektek kezdődnek, amelyek túlmutatnak ezen a kategórián: komolyabb előkészületet igényelnek, hosszabb tervezést. Sokkal óvatosabbak lettek a pénzintézetek, a fejlesztési ciklus rövidült, a második félévet az elsőben tervezik meg, sokkal agilisabb lett a tervezés. Ilyen helyzetben a beszállítók minősége és minősítése nagyon fontos kérdéssé válik, azt látjuk, hogy nagyon megnőtt az igény az A+-os, kiváló minőségű beszállítókra, akik nemcsak egy speciális területen jártasak, hanem az ügyfél fejével is tudnak gondolkodni és az egész pályán látnak.

Kovach Anton

ShiwaForce.com, vezérigazgató

Kovach Anton a ShiwaForce.com Zrt. vezérigazgatója, 23 éves vezetői tapasztalattal. Az online tartalomkezelő piacon elért szakmai sikerek, a lean módszertan eszközeivel - Scrum, Kanban, Lean Startup -

Tovább

Kovach Anton a ShiwaForce.com Zrt. vezérigazgatója, 23 éves vezetői tapasztalattal. Az online tartalomkezelő piacon elért szakmai sikerek, a lean módszertan eszközeivel - Scrum, Kanban, Lean Startup -… Tovább

A címlapképen Kovach Anton szerepel. Fotó: Mudra László.