Élesedõ verseny, alternatív ügyfélelérési csatornák, dereguláció – a megváltozott üzleti körülmények a banki informatikusoktól is új módszerek és technológiák alkalmazását követelik meg.
Milyen gondokkal jár például az alternatív ügyfélelérési csatornák (internet, mobiltelefónia, ATMek) mûködtetése? Az ügyfelek hálásak, ha egy átutalás elindításához nem kell elmenniük a bankfiókba, hanem elintézhetik az interneten vagy mobiltelefonjukon keresztül is. Az igények azonban nõnek, és az ügyfelek immár azt szeretnék, ha a bankkártya- igényléstõl kezdve a kölcsönigénylésen keresztül a devizafolyószámla- lekötésig mindent el tudnának intézni elektronikusan.
Ez azonban csak akkor mûködhet, ha a háttérben zajló folyamatokat és az azokat kiszolgáló informatikai rendszereket elõbb integráljuk – mondja Sugár Péter, az IBM szoftverszakértõje. Az alkalmazásintegráció már régóta húzódó problémája a nagyvállalati, így a banki informatikai rendszereknek is.
Egy tál spagetti
Voltaképpen már ennek megoldására kezdték bevezetni az integrált programcsomagokat, akár az olyan általános jellegûeket, mint az SAP R/3 vagy az Oracle Financials, akár a kimondottan banki környezetre született szoftvereket, mint az Equation, a Kapiti, a BankMaster vagy a Sanchez Profile. Ez azonban – bár nagy lépés elõre – nem old meg minden gondot, figyelmeztet Sugár Péter. Hiába tartalmaznak az ilyen rendszerek nagyon sok hasznos funkciót, számos olyan szolgáltatás létezik, amelyek ellátására önmagukban nem alkalmasak. Következésképpen ezekhez külsõ szoftvert kell igénybe venni, amelyet megint csak integrálni kell – így aztán az integrált banki programcsomag csak újabb integrációs igényeket szül.
Könnyen belátható, hogy az alkalmazások külön-külön, pont–pont alapú öszszekapcsolása hosszabb távon nem járható út. Bár két alkalmazás között viszonylag egyszerûen létrehozható kapcsolat – akár adat-, akár állományátvitel révén –, ez már négy-öt rendszer esetén is igen nagy számú összeköttetést, különbözõ kapcsolódási felületet igényel, amelyeket külön-külön kell kifejleszteni, karbantartani, igény esetén megváltoztatni. A gyakran alkalmazott hasonlat szerint az architektúra olyan lesz, mint egy tál spagetti. Ilyen esetekben a teljes rendszer mûködtetése, biztonságának garantálása igen nehéz lehet.
Igazán jó, átfogó megoldást csak a köztesszoftverek (middleware) kínálhatnak, mondja Sugár Péter. Az informatikai infrastruktúra tradicionálisan négy rétegbõl épül fel. A legalsó szint a fizikai erõforrásoké (ez a hardver); erre épül rá az operációs rendszer, amely kezeli a fizikai erõforrásokat, és azokat leképezi logikai erõforrásokká. A következõ réteg a hálózat, amely ezeket a logikai erõforrásokat osztott környezetben is elérhetõvé teszi; és legfelül vannak az alkalmazások, amelyekkel a felhasználók tényleg dolgoznak.
Sugár Péter szerint mindinkább terjed az a nézet, hogy a köztesszoftvereknek ugyanolyan nélkülözhetetlen infrastrukturális rétegnek kell lennie (az alkalmazások és a hálózat között), mint a másik négy szintnek. Ez teszi ugyanis lehetõvé, hogy az alkalmazások gond nélkül, szabványosan tudjanak együttmûködni, függetlenül a hálózatkezelés módjától, az adat formátumától (szintaktikától) és az adattartalomtól (szemantikától).
A köztesszoftver fajtái
Még a szakértõk sem mindig értenek egyet abban, hogy mi tartozik a köztesszoftverek közé, és mi nem. A leginkább elfogadott definíciók ide sorolják a portál- és alkalmazásszervereket is (ezek a platform-köztesszoftverek), az adatkapcsolati megoldásokat (ODBC, JDBC), a kommunikációs middleware-eket, az integrációs brókereket, a folyamatintegrátor és általános munkafolyamat-vezérlõ szoftvereket.
Ezek közül az utóbbi hármat tartja a legfontosabbnak Sugár Péter. A kommunikációs köztesszoftverek – mint az IBM MQSeries, az Oracle Advanced Queueing, a Progress SonicMQ – igényesebb megoldásai garantálják az egyszeri és csakis egyszeri üzenettovábbítást még a váratlanul jelentkezõ, idõszakos rendszerkiesések esetén is, valamint támogatják a tranzakciós biztonságot. Az alkalmazásnak ebben az esetben nem kell a hálózati protokollok vezérlésével és az esetleges hibakezelésekkel foglalkozniuk; ezt a szerepet teljességgel átveszi tõle a middleware.
Az integrációs bróker egy szinttel magasabban végzi a munkáját: segít az alkalmazások által használt adatformátumok és -tartalmak különbségeinek áthidalásában. Ilyen termék az IBM WebSphere MQ Integrator, a Mercator hasonló nevû szoftvere vagy a See- Beyond e*Gate. Ebben az esetben az alkalmazások nem is egymással állnak kapcsolatban, hanem az integrációs brókerrel: az üzenetekbe csomagolt adatokat annak küldik, és a köztesszoftver – az üzleti szintû szabályok alapján – gondoskodik a továbbításról a megfelelõ formátumban és a megfelelõ címzetthez. Így megszûnik az a kényszer, hogy a rendszereket közvetlenül egymással kapcsoljuk össze; a „spagetti-elrendezés” helyét egy átlátható architektúra váltja fel.
Az integrációs bróker egy szinttel magasabban végzi a munkáját: segít az alkalmazások által használt adatformátumok és -tartalmak különbségeinek áthidalásában. Ilyen termék az IBM WebSphere MQ Integrator, a Mercator hasonló nevû szoftvere vagy a See- Beyond e*Gate. Ebben az esetben az alkalmazások nem is egymással állnak kapcsolatban, hanem az integrációs brókerrel: az üzenetekbe csomagolt adatokat annak küldik, és a köztesszoftver – az üzleti szintû szabályok alapján – gondoskodik a továbbításról a megfelelõ formátumban és a megfelelõ címzetthez. Így megszûnik az a kényszer, hogy a rendszereket közvetlenül egymással kapcsoljuk össze; a „spagetti-elrendezés” helyét egy átlátható architektúra váltja fel.
Gyorsabban és szabadabban
Hatékonyság és üzembiztonság – ezt kínálja a köztesszoftver
Lassan öt éve használja az IBM köztesszoftvereit, az MQSeriest és az MQSeries Integratort a tõkepiaci szereplõk (brókerek, bankok) értékpapír-ügyleteinek valós idejû elszámolását végzõ KELER Rt. A köztesszoftverek mintegy kéttucatnyi alkalmazást kapcsolnak össze, amelyek több mint háromszáz üzenetformátumot használnak – mondta Jungbauer József, a KELER informatikai igazgatója.
Az üzenetek továbbítása két szinten valósul meg: a kommunikációs middleware másodpercenként 600 üzenetet küld tovább, míg az MQSeries Integratorra épített „diszpécseralkalmazás” egy nagyságrenddel kevesebbet, másodpercenként 15–30-at. (Ez naponta több százezer üzenetet jelent – valós idõben továbbítva.) A különbség abból adódik, hogy az utóbbi a beépített üzleti logika alapján különbözõ mértékben fel is dolgozza az adatokat, üzeneteket, míg az elõbbi „egyszerûen” továbbítja õket a megfelelõ alkalmazáshoz. Azt, hogy egy üzenetnek át kell-e mennie a diszpécseralkalmazáson, a teljes KELER-re kidolgozott és érvényesített üzenetszabvány tartalmazza.
Az informatikai igazgató szerint a köztesszoftverek használata több területen is megkönnyítette a KELER mûködését. A vállalat gyorsan változó üzleti környezetben mûködik, számos alkalmazást évente akár kétszer is frissíteni kell: a middleware és a kidolgozott üzenetszabvány nélkül ezt nem tudnák a jelenlegi gyorsasággal és üzembiztonsággal végrehajtani. Egy másik elõny, hogy az alkalmazások terén szállítófüggetlenné vált a cég: a meglévõ szoftverek cseréje technológiai szempontból sokkal egyszerûbben megvalósítható.
Az üzletmenetet is nagymértékben befolyásoló elõny, hogy az alkalmazásfunkciók nyitottak, újabb alkalmazások kiépítéséhez is fel lehet õket használni. Ezt a lehetõséget nemrégiben ki is használta a KELER: a már korábban meglévõ, a származékos (derivatív) ügyleteket kezelõ rendszer funkcióit (többek között olyanokat, mint a kockázat- és pozíciókezelés) minimális fejlesztéssel át lehetett vinni az azonnali (spot) ügyletekre. Ennek köszönhetõen a KELER igen gyorsan fel tudta vállalni vezeknek az ügyleteknek a garantált elszámolását is.
Schopp Attila
