Míg a diákigazolványokról, felvételi ponthatárokról mindenki hallott, az ezek mögött álló Educatio Kht.-t csak kevesen ismerik. Az Oktatási és Kulturális Minisztérium háttérintézményének persze az említetteknél jóval szerteágazóbb a feladata: az oktatási ágazat központi informatikai megoldásait kell szállítania és üzemeltetnie. Egyik nagyszabású feladata a FIR (Felsőoktatási Információs Rendszerének) kialakítása volt, amelyhez az IBM WebSphere Message Broker nevű, alkalmazásintegrációs megoldását hívták segítségül. A Brokerről és a projektről Csulyák Gáborral, az Educatio informatikai igazgatójával, valamint az üzleti partner AAM csoport munkatársaival beszélgettünk.
Bár a felsőoktatás, hallgatóként és oktatóként, közel félmillió magyar állampolgárt érint (s ha még a közoktatás egészét is hozzávesszük, máris két és félmilliónál tartunk), korábban az oktatási ágazatban nem volt olyan egységes nyilvántartási rendszer, mint amilyet az egészségügyben vagy mondjuk a pénzügyi szektorban használnak. Ezt a helyzetet próbálta orvosolni egy 2005-ben született jogszabály, amely kötelezte a felsőoktatást egy központi nyilvántartás létrehozására. E hosszú folyamat egyik fontos állomása a FIR, azaz a Felsőoktatási Információs Rendszer kialakítása volt. Ez eddig viszonylag egyszerűen hangzik, ám a megvalósítás korántsem volt gyerekjáték, lévén, hogy az érintett 72 felsőoktatási intézményben különféle alapokon nyugvó, egymástól eltérő informatikai-nyilvántartási rendszereket használnak (pl. Neptun, ETR vagy ETN, és akkor még nem is beszéltünk az egyedileg fejlesztett, egy-két intézményben működő megoldásokról).
A jogszabály viszont éppen azt írta elő, hogy olyan egységes személytörzs jöjjön létre, amely a felsőoktatásban tanulókat, illetve oktatóikat tartja nyilván, s oktatási azonosítókat (hallgatói, illetve oktatói azonosítókat) rendel valamennyiükhöz - avat be a részletekbe Csulyák Gábor.
Meg kellett oldanunk az érintettek hozzáférését a nyilvántartáshoz, az ide kapcsolódó események kezelését, illetve az adatok napra készen tartását. Minthogy szinte minden felsőoktatási intézménynek van saját elektronikus rendszere, ráadásul a jogszabály eleve kizárta a papíralapú bejelentést, mindenképpen olyan elektronikusan hitelesített kommunikációs megoldásra törekedtünk, amely kihasználja a már létező rendszerek tudását. Döntés született arról, hogy a kapcsolódó intézmények a kialakított hitelesített kommunikációs csatornán, a meglévő nyilvántartásokból szolgáltatnak adatokat.
A kialakított alkalmazásintegrációs koncepció szerint az alaprendszereket érintetlenül hagyták, némi módosításra volt csupán szükség a rendszerillesztések kivitelezéséhez. Kiderült ugyanakkor, hogy néhány helyen nem teljesen a jogszabályoknak megfelelő részletezettségben tárolják a diákok és a tanárok adatait, így ezekben az intézményekben ezzel párhuzamosan egyfajta adattisztításra is szükség volt.
Ahol viszont a nyilvántartás mindenben megfelelt a jogszabályokban előírtaknak, semmit sem kellett átalakítani, csupán egy, a központi rendszer interfészéhez csatlakozó, kétoldalú kommunikációt biztosító modult kellett kifejleszteni. Biztos vannak olyan intézmények, ahol nem kevés időt és fáradságot kellett fordítani az új típusú, központi nyilvántartáshoz való kapcsolódásra, de ha beindul élesben a rendszer, akkor az a központi bejelentésen túl, egyéb jelentési kötelezettségeiket is egyszerűsítheti, vagy akár meg is szüntetheti. Egyfajta közvetett eredményről tehát máris beszélhetünk: a projekt lezáródása után valamennyi felsőoktatási intézménynél az előírásoknak megfelelően lesznek tárolva az adatok.
Bár mindenképpen üdvözlendő egy egységes felsőoktatási nyilvántartási rendszer, azonban ez önmagában öncélúnak tűnhet. Mik voltak kialakításának valódi mozgatórugói?
A törzsadatok bekérése természetesen csak az első lépés, erre mindenképpen szükség van ahhoz, hogy kialakuljon maga a nyilvántartás - avat be a megvalósítás szempontjaiba Csulyák Gábor.
A nyilvántartás elsősorban az oktatási ágazat és az ágazatban működő intézmények, többek között a nyilvántartás kezelését végző, a kapcsolódó hatósági feladatokat ellátó Oktatási Hivatal munkáját támogatja, illetve maguk az állampolgárok információhoz jutását segíti. Ezen felül háttérül szolgál minden, a fentieket megvalósító jelen vagy jövőbeli szolgáltatásnak; egy ilyesfajta alapnyilvántartásnak éppen az a célja, hogy képes legyen adatot szolgáltatni vagy törzsadatként szolgálni más, ráépülő nyilvántartások számára. Itt van például a TAJ szám, az egészségügy jól ismert azonosítója, amelyet számos alkalmazás és szolgáltatás használ. Hasonlót szeretnénk megvalósítani az oktatásban is, a mi „TAJ számunk” az egységes oktatási azonosító lenne. A jövőbeli szolgáltatások érdekében már fel is vettük a kapcsolatot az Országos Egészségbiztosítási Pénztárral, illetve a Nyugdíjfolyósító Intézettel (az árvaellátás miatt), de később akár a Diákhitel Központ, akár a közlekedési vállalatok is kaphatnának adatokat a vonatkozó szabályozások mentén a nyilvántartásunkból.
Hallhatnánk valamit a projekt konkrét menetéről?
Először meg kellett ismernünk, milyen adatokat és hogyan tartanak nyilván a felsőoktatási intézmények. Alaposan átvizsgáltuk a jogszabályok ránk vonatkozó előírásait, azaz hogy nekünk milyen formában kell őriznünk az adatokat. Ezután megterveztük, milyen legyen a bejelentés folyamata, és milyen egyéb lépésekre van szükség ahhoz, hogy a bejelentés zökkenőmentes legyen. Nyilvánvalóan – tekintettel a kapcsolódó közigazgatási hatósági eljárásokra vonatkozó előírásokra is – gondoskodni kellett a bejelentés visszavonásának, illetve az adatok módosításának a lehetőségéről is, azaz a való életet és az abban felmerülő problémákat próbáltuk modellezni. Kialakítottuk azokat az interfészeket, amelyeken keresztül szabványosíthattunk, majd kiadtuk a specifikációkat az intézményeknek, akik fejlesztőikkel közösen felkészítették a saját rendszereiket ezen interfészek használatára. A már tisztított adatokkal történő bejelentések a projekt utolsó mozzanatát jelentették (és jelentik), hiszen ez a fázis még nem zárult le teljesen.
Mikor került a tervezési folyamatba üzleti partnerük az AAM Vezetői Informatikai Tanácsadó Zrt. és annak leányvállalata, az AAM Techologies Kft.?
Gyakorlatilag a tervezési fázis elején, egy közbeszerzés után, 2006 nyarának végén vettük fel velük a kapcsolatot. Együtt kezdtük a tervezést, s együtt vittük végig a projektet.
A projekt terméktámogatójaként az IBM mellett döntöttek. Miért éppen ezt a céget választották?
Mivel már régebb óta használunk IBM technológiákat, IBM-s kompetenciákkal rendelkezünk, ezt a projektet is ilyen technológiai támogatóval képzeltük el. Fontos volt ugyanis, hogy a későbbiekben is képesek legyünk majd az üzemeltetésre, s mivel korábban, más rendszerekben már használtunk IBM-s eszközöket, nagy előnyt jelentett az ezekkel szerzett tapasztalat. És persze az is sokat nyomott a latba, hogy körbenéztünk a piacon, melyek azok az eszközök, amelyek az általunk elképzelt üzleti menetet szolgálják, s erre az IBM-nek volt egy remek megoldása, a WebSphere Message Broker. Az üzleti partner kiválasztásánál is számított, hogy az AAM csoport szakemberei otthonosan mozognak az IBM-s technológiákban, minthogy az AAM Technologies Kft. IBM Advanced Partner minősítéssel rendelkezik, és sikeres alkalmazásintegrációs projektek vannak a háta mögött.
Adott volt egy feladat: 72 felsőoktatási intézmény különböző informatikai rendszerei és a központi nyilvántartás között kellett megoldani a kommunikációt, illetve az adatfeldolgozást. Milyen szerepet szántak ebben a Message Brokernek? - kérdezem Bacskai Jánost, az AAM vezető architectét.
A Message Broker kifejezetten ilyen alkalmazásintegrációs feladatok ellátására hivatott. Kommunikációs és adattranszformátor rétegként segít abban, hogy a különböző rendszerek megértsék egymást. Az alkalmazások közé beülve, mindenkivel a saját nyelvén „beszél”, és mindenki számára bárhol elérhető és érthető formátumban szolgáltatja az adatokat. Biztosítja azokat a kulcsfontosságú funkciókat, amelyekre szükség van az adatok átalakításához és az alkalmazások közötti továbbításához. Emellett méretezhető architektúrájú, nagy rendelkezésre állású és egyszerűen használható.
És persze azt se hagyjuk említésen kívül, hogy a Broker tipikusan megfelel az oktatási ágazat jövőbeni elképzelésinek, hogy többfelé, sokféle nyilvántartásba szolgáltasson adatokat - teszi még hozzá az informatikai igazgató.
Mennyire kötődik az oktatáshoz a Broker? - fordulok Lakhegyi Péterhez, az AAM szakmai partneri kapcsolatokért felelős képviselőjéhez.
A Broker különböző alkalmazások különböző nyelvei között képes fordítani, és szó sincsen alkalmazás - vagy ágazatspecifikusságról. Az alapvető üzleti igény ágazatoktól függetlenül nagyon általános: sok elszigetelt rendszer között kell megtalálni a közös nevezőt, a közöttük lévő kommunikációra kell hatékonyan működő, továbbfejleszthető és üzemeltethető megoldást szolgáltatni. A Brokert e meggondolás alapján át lehet vinni bármilyen más környezetbe, legfeljebb a helyi igényekre kell kicsit átszabni. Egyébként éppen ebben jó a Broker: könnyen testre szabható. Vitathatatlan előnye, hogy a bevonásával olyan új szolgáltatások fejleszthetők, amelyek önállóan egyik meglévő rendszerben sem lennének megvalósíthatók. Ráadásul a használatával áttekinthetőbbé válik az egész alkalmazás és szolgáltatás infrastruktúra, s ennek megfelelően hatékonyabb lesz a hibakeresés és -javítás, a szolgáltatástervezés és -fejlesztés. És persze az sem mellékes, hogy csak a hozzákapcsolódó technológia naprakész ismeretére van szükség, csak ebből kell mélyebb szintű képzést biztosítani.
Azt persze az AAM szakemberei sem tagadják, hogy csak bizonyos méret felett érdemes a cégeknek ilyen megoldást választaniuk. Hiszen 1-2 kapcsolódó alkalmazás még jól kezelhető a hagyományos eszközökkel is, csak egy kritikus méret fölött válik kezelhetetlenné, áttekinthetetlenné egy alkalmazás infrastruktúra. Nem véletlen, hogy Magyarországon ma még nem tolonganak azok a cégek, akik belefognak egy ilyesfajta projektbe, ahhoz ugyanis, hogy megérje a befektetés, szükség van egy adott cégméret és/vagy bonyolultsági szint elérésére. Ha viszont megvan ez a bizonyos méret, akkor ágazattól függetlenül, akár a közszférában, akár a versenyszférában éppen az ilyen egyszerűsítő, a káoszban rendet teremtő megoldásra van szükség.
Igényelt-e külön hardverberuházást a FIR-projekt? - kérdezem ismét Csulyák Gábort.
Biztonságos megoldást akartunk kialakítani, ezért clusteres környezetben, elkülönített hardveren helyeztük el a rendszert, illetve - már a jövőbeni fejlesztésekre gondolva - kialakítottunk egy tesztelői-fejlesztői környezetet is. Mindehhez természetesen szükség volt új hardverekre, tehát nem elsősorban a Broker miatt bővítettünk. Inkább úgy fogalmaznék: készült egy új nyilvántartás és ennek kellett megfelelő hardverhátteret biztosítani.
Szükség volt-e továbbképzésre a Broker használatához?
IBM-es tapasztalatunk ugyan volt, persze az nem egyenlő a Brokeres tapasztalattal; ez utóbbi elég komoly új tudást igényelt a kollegáktól. Másfajta gondolkodásmódra van szükség, hiszen itt folyamatokról, folyamatok karbantartásáról van szó. Természetesen mind az IBM-től, mind az AAM-től sok segítséget kaptunk.
A kialakított rendszerhez kapcsolódó ismereteket is kétfelé lehet bontani - teszi még hozzá Molnár Viktor, az AAM vezető tanácsadója. – Adott egy alaptechnológia, egy tudásanyag, amely magára az új eszközre van kihegyezve, ide tartoznak a Broker használatához szükséges elméleti és gyakorlati képzések. Amikor viszont már a konkrét folyamatokat kell kialakítani, ott másfajta üzemeltetési feladatok jelentkeznek, és ilyenkor az ezekhez kapcsolódó elméleti és gyakorlati tudást kell átadnunk. Az Educatióval együtt folytatott tervezés, paraméterezés egyébként mindkét fél számára egy igen jó tanulási folyamatnak is tekinthető.
Egyszeri találkozásról volt szó csupán, vagy másra is akarják használni a jövőben a Brokert? - kérdezem ismét az informatikai igazgatót.
A FIR kidolgozása remek alkalom volt arra, hogy kipróbáljuk a Brokert, és alaposabban megismerkedjünk vele. Igen pozitívak a tapasztalataink, így biztos lesz még feladatunk a számára. Az oktatási területen nagyon sok különböző nyilvántartás létezik, épp a múltkor számoltunk össze legalább 37-et közülük. Ezek pókhálószerűen össze-vissza vannak, illetve lehetnének kapcsolatban egymással, és ebben a káoszban próbálunk majd rendet teremteni. Azt szeretnénk, ha a Broker lenne az a platform, az az oktatási szolgáltatás-busz – azaz a szolgáltatások közvetítéséért felelős rendszer –, amely átláthatóbbá teszi az adatáramlásokat és a különböző nyilvántartások közötti szolgáltatásokat az oktatási ágazatban. Hamarosan elindítjuk ezt a projektet is, amelytől azt várjuk, hogy sokkal rugalmasabbak lesznek az oktatási szférában működő nyilvántartások, és könnyen lehet majd újakat illeszteni közéjük, ezáltal számos új szolgáltatást tudunk majd létrehozni az oktatás és az állampolgárok számára.