MÓDSZERTANI ÚTMUTATÓ AZ INTEROPERABILITÁS TERVEZÉSÉNEK TÁMOGATÁSÁRA

MÓDSZERTANI ÚTMUTATÓ AZ INTEROPERABILITÁS TERVEZÉSÉNEK TÁMOGATÁSÁRA

A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az „Elektronikus közigazgatási keretrendszer” tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett:

2

Metaadat-táblázat Megnevezés Cím (dc:Title) Kulcsszó (dc:Subject) Leírás (dc:Description)

Típus (dc:Type) Forrás (dc:Source) Kapcsolat (dc:Relation) Terület (dc:Coverage) Létrehozó (dc:Creator) Kiadó (dc:Publisher) Résztvevı (dc:Contributor) Jogok (dc:Rights) Dátum (dc:Date) Formátum (dc:Format) Azonosító (dc:Identifier) Nyelv (dc:Language) Verzió (dc:Version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights)

Leírás Módszertani útmutató az interoperabilitás tervezésének támogatására Interoperabilitás; útmutató A dokumentum célja az inteoperabilitásra való tervezéshez segítséget nyújtani. Tisztázza az alapvetı fogalmakat, és kiindulópontokat ad az iunteroperabilitás fogalmának és aktuális helyzetének meghatározásához, .

e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal BME Informatikai Központ 2008.10.02. Word 97-2003 (*.doc) Magyar V4 végleges EKK_ekozig_IOPtervezes_081002_V4

3

Verzióvetési táblázat A dokumentum neve A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

Módszertani útmutató az interoperabilitás tervezésének támogatására BME Informatikai Központ

2008.10.02. V4 55 e-Közigazgatási Keretrendszer Kialakítása projekt Változáskezelés

Verzió V1 V2 V3 V4

Dátum 2008.05.29 2008.07.30 2008.08.29. 2008.10.02.

A változás leírása Tartalomjegyzék Vázlat MeH-nek átadott verzió Minıségbiztosító véleménye alapján átdolgozott verzió

4

Szövegsablon Megnevezés 1. Elıszó (Foreword) 2. Bevezetés (Preamble) 3. Alkalmazási terület (Scope) 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia 8. Rövidítésgyőjtemény 9. Fogalomtár 10. Ábrák 11. Képek 12. Fogalmak 13. Verzió 14. Mellékletek (Appendix)

Leírás

5

Tartalomjegyzék 1. 2.

Elıszó.............................................................................................................................................................. 8 Bevezetés ........................................................................................................................................................ 8 2.1. A dokumentum célja.............................................................................................................................. 8 2.2. A dokumentum tartalma ........................................................................................................................ 8 3. Az interoperabilitás és szükségessége az e-közigazgatásban .......................................................................... 8 3.1. Az interoperabilitás definíciója.............................................................................................................. 8 3.2. Az interoperabilitás szükségessége, hajtóerık..................................................................................... 10 3.2.1. A szigetszerő mőködés felszámolása a közigazgatásban ................................................................ 10 3.2.2. Nemzetközi (uniós) együttmőködés)............................................................................................... 11 3.3. Az interoperabilitás fıbb szervezési eszközei ..................................................................................... 12 3.3.1. Interoperabilitási keretrendszer ....................................................................................................... 12 3.3.2. Szervezeti architektúra .................................................................................................................... 13 3.4. Az interoperabilitás nemzetközi és hazai történetének rövid áttekintése............................................. 14 4. A kitőzött célok............................................................................................................................................. 17 5. Az interoperabilitás megvalósításának nehézségei, kockázatai .................................................................... 19 5.1. Nehézségek, akadályok ....................................................................................................................... 19 5.2. Kockázatok .......................................................................................................................................... 22 6. Néhány példa az interoperabilitás megvalósításának legjobb nemzetközi gyakorlatából ............................. 23 6.1. Egyesült Királyság............................................................................................................................... 23 6.2. Németország ........................................................................................................................................ 24 6.3. Dánia ................................................................................................................................................... 25 6.4. Ausztrália............................................................................................................................................. 25 6.5. Az Európai Unió kezdeményezéseibıl fakadó elvárások .................................................................... 26 6.5.3. Európai interoperabilitási stratégia (EIS) ........................................................................................ 27 6.5.4. Európai interoperabilitási keretrendszer (EIF) ................................................................................ 28 6.5.5. EIF 1.0............................................................................................................................................. 28 6.5.6. EIF 2.0............................................................................................................................................. 29 6.6. Architektúra irányelvek ....................................................................................................................... 31 6.6.7. Infrastrukturális szolgáltatások........................................................................................................ 32 6.7. A keretrendszerek összefoglalása ........................................................................................................ 33 6.7.1. Irányítás........................................................................................................................................... 33 6.7.2. Elfogadtatás..................................................................................................................................... 34 6.7.3. Terjedelem....................................................................................................................................... 34 6.7.4. Mőködtetés...................................................................................................................................... 34 7. Továbblépés az interoperabilitásban, fejlıdési irányok ................................................................................ 35 8. Az interoperabilitás lehetséges jogi és irányítási háttere a magyar közigazgatásban.................................... 37 8.1. A szabályozás és irányítás lehetséges „építıkövei”............................................................................. 37 8.2. Az interoperabilitás irányítása ............................................................................................................. 40 8.3. Lehetséges modellek az interoperabilitás területén ............................................................................. 41 8.4. A javasolt megoldás............................................................................................................................. 42 9. SOA és az interoperabilitás........................................................................................................................... 44 9.1. A SOA bemutatása .............................................................................................................................. 44 9.1.1. Kulcsfogalmak ................................................................................................................................ 44 9.1.2. Alapelvek ........................................................................................................................................ 46 9.1. Alkalmazási területek .......................................................................................................................... 46 9.2. Elınyök ............................................................................................................................................... 47 9.2.1. Lazán csatolt architektúra................................................................................................................ 47 9.2.2. Moduláris megközelítés .................................................................................................................. 48 9.2.3. Meglévı alkalmazások felhasználása.............................................................................................. 48 9.2.4. Szabványosság ................................................................................................................................ 48 9.2.5. SOA alkalmazásának kérdései ........................................................................................................ 49 9.3. A rendszer érettségi modellje .............................................................................................................. 49 A SOA architektúrát alkalmazni lehet meglévı rendszerekre, ezáltal egymással kommunikáló, önálló szolgáltatásokká szegmentálni. Amennyiben ezeket a szolgáltatási interfészeket definiáljuk és az egyes szegmensekre átfogóan alkalmazzuk, a rendszerek interoperabilisek lesznek, de tisztában kell lenni, hogy a

6

tiszta SOA architektúra kialakítása több lépésen keresztül valósítható meg. A megtett lépések között a már elkészített SOA rendszer érettségi szintjérıl lehet beszélni. ......................................................................... 49 9.4. Szolgáltatások osztályzása................................................................................................................... 50 9.5. Folyamat integritás .............................................................................................................................. 51 10. Szakirodalmi hivatkozás ........................................................................................................................... 52 11. Rövidítésgyőjtemény................................................................................................................................. 55 12. Fogalomtár ................................................................................................................................................ 56

7

1. Elıszó 2. Bevezetés 2.1.

A dokumentum célja

Az IOP tervezés során a rendszer azon paramétereit határozzák meg, melyek biztosítják az elkészülı komponensek interoperabilitását. Az IOP terv gyakorlatilag szabványok, alapelvek, táblázatok összessége, melyeket a fejlesztés során be kell tartani A dokumentum célja, hogy támogatást nyújtson az interoperabilitás fogalmának, felhasználási körének megismerésében, mintegy esettanulmányként bemutatva a területen nemzetközileg alkalmazott megoldásokat, illetve a témához kapcsolódó technológiákat. A dokumentum kiindulópontot, kapaszkodót nyújt azon további ismeretek megszerzéséhez, amely alapján kidolgozható, hogy hogyan lehet interoperabilis rendszereket tervezni, melyek azok a szempontok, amelyek fejlesztéskor döntı szerepet játszanak a kialakult rendszer interoperabilitási képességeinek szempontjából. A dokumentum célja, hogy közös képet alakítson ki az interoperabilitásról. A más országokban alkalmazott interoperabilitási szabványok rövid bemutatásával világít rá, milyen szempontok alapján érvényesítik interoperabilitási törekvéseiket az adott országok. Ezen felül bemutatja és illusztrálja az interoperabilitáshoz szorosan kapcsolódó SOA architektúra elemeit, amely architektúra mérvadó a gazdaprojekt szempontjából.

2.2.

A dokumentum tartalma

A dokumentum elsı része bevezeti az interoperabilitás fogalmát és elhelyezi a vizsgált, eközigazgatási területen. Rövid nemzetközi kitekintésben példákat sorol az Európai Unió egyes tagállaiban, illetve magában az Unióban megvalósuló interoperabilitási keretrendszerekbıl. Végül bemutatja a hazai interoperabilitási fejlesztésekhez szükséges jövıbeli lépéseket. A második rész az interoperabilitás technikai aspektusával foglalkozik. A vizsgált környezetben javasolt lletve a modern, inteoperabilitást megvalósító SOA architektúra és technológia bemutatását tartalmazza.

3. Az interoperabilitás és szükségessége az e-közigazgatásban 3.1.

Az interoperabilitás definíciója

Az interoperabilitásnak – magyar kifejezéssel együttmőködési képességnek – számos definíciója ismert, amelyek nem mondanak ugyan ellent egymásnak, de az interoperabilitás más-más jellemzıit emelik ki. Az alábbiakban bemutatjuk a leginkább mérvadó dokumentumok közül háromban található meghatározást:

8

a) Az interoperabilitás az IKT rendszerek és az általuk támogatott szervezeti folyamatok azon képessége, hogy adatokat tudnak cserélni, és információt, tudást tudnak megosztani egymással ([B18]). b) Az interoperabilitás különbözı és különféle szervezetek azon képessége, hogy kölcsönhatásba tudnak lépni egymással kölcsönösen elınyös és egyeztetett célok érdekében, beleértve az információnak és tudásnak a megfelelı IKT rendszereik közti adatcsere útján történı megosztását a szervezetek között az általuk támogatott szervezeti folyamatokon keresztül ([B14]). c) Az e-közigazgatási interoperabilitás – széles értelemben – a közigazgatási szervezetek azon képessége, hogy együtt tudnak mőködni egymással. Mőszaki szinten két vagy több különbözı közigazgatási IKT rendszer vagy komponens azon képessége, hogy értelmes módon és problémamentesen tudnak információt cserélni, és a cserélt információt felhasználni. Az interoperabilitás egyezményeken alapul (mőszaki specifikációk, szabványok, közös interfészek stb.) ([B16]). Az interoperabilitást gyakran azonosítják más fogalmakkal, amelyekkel kétségkívül átfedésben van, de nem azonos velük. A tisztánlátás érdekében ezekre a különbségekre is kitérünk: ― Az interoperabilitás nem azonos az integrációval. Az elıbbi inkább a lazán csatolt rendszerekre vonatkozik, míg az utóbbi a lazán csatolt rendszerek szorosabban csatolt rendszerekké alakításával foglalkozik. ― Az interoperabilitás nem azonos a kompatibilitással. Ez utóbbi inkább az eszközök csereszabatosságát jelenti egy bizonyos szempontból. ― Az interoperabilitás nem azonos az adaptálhatósággal. Ez utóbbi egy eszköz megváltoztathatóságát jelenti további képességek hozzáadásával ad hoc igények kielégítésére, míg az interoperabilitás belsı képességekre vonatkozik. Az interoperabilitás területeinek, szintjeinek leggyakrabban idézett és használt felosztását az EU Európai interoperabilitási keretrendszerének (EIF) 1.0 változata fogalmazta meg: ― Szervezeti interoperabilitás. A szervezeti célok meghatározásával, a szervezeten belüli és a szervezetek közötti folyamatok modellezésével foglalkozik abból a célból, hogy a különbözı belsı felépítéső és különbözı belsı folyamatokat használó szervezetek is együtt tudjanak mőködni egymással. Lényegileg a különbözı szervezetekben megvalósuló folyamatok egymással – szervezetek közötti – együttmőködésének megoldásáról van szó. Az egyes folyamatok ilyen tekintetben vett egymáshoz igazítása, újragondolása illetve a folyamatok közötti interakciót megvalósító interfészek meghatározása a cél. ― Szemantikai interoperabilitás. Arra törekszik, hogy a különbözı alkalmazások pontosan megértsék az egymásnak átadott információk jelentését. Ez azt jelenti, hogy az együttmőködı szervezetek közötti információáramlás során a cserélt információt egységesen és pontosan ugyanabban az értelemben használják a kommunikáló felek. A szemantikai interoperabilitás megteremtésének egyik fı lépése az egyes fogalmak értelmezésének egységesítése. Ez elsısorban nem informatikai feladat. Közigazgatási

9

környezetben például biztosítani kell, hogy az egyes szervezetek ugyanolyan módon értelmezzenek olyan fogalmakat, mint például lakcím, személynév, cégadatok, stb. illetve, hogy az egyes eljárásokban használt fogalmakat ugyanolyan értelemben és értelmezésben használjanak. ― Technikai interoperabilitás. Ez foglalkozik az IKT rendszerek összekapcsolásának mőszaki kérdéseivel, mint pl. a nyílt interfészekkel, adatintegrációval, adatok ábrázolásával és cseréjével, biztonsággal stb. Ez az interoperabiltási szint elsısorban hagyományos informatikai problémákkal és megoldásokkal foglalkozik, az együttmőködı szervezetek, alkalmazások által használt adatformátumok, adatsémák, kommunikációs protokollok, kódolási, titkosítási és hasonló kérdések megoldása a feladata. Az EIF 2.0-ás tervezete felismerte, hogy ezt a három szintet szükséges bıvíteni, többek között a közigazgatási környezet által, az általános együttmőködési kérdéseken túl támasztott követelmények miatt. Ezért tovább bıvíti az interoperabilitási szinteket: ― Jogi interoperabilitás. A megfelelı jogi háttér megteremtése annak érdekében, hogy ez együttmőködı szervezetek a megfelelı jogi felhatalmazással rendelkezzenek az adatcsere tekintetében. A közigazgatási környezet alapvetı sajátossága, hogy a megfelelı jogi-szabályozási háttér nélkül nem képzelhetı el mőködı megoldás. Ezért ennek megteremtése alapvetı igény. ― Politikai környezet. Az interoperabilitás megvalósítását és irányítását meghatározó és elıíró politikai akart. A tapasztalat szerint együttmőködı rendszerek és szervezetek csak kellıen elkötelezett és támogatást adó központi akarattal alakíthatóak ki. A politikai környezet célja az interoperabilitás irányába történı fejlıdés elısegítése, a divergáló megoldások megakadályozása és az erıforrások kellı koncentrálása. Ezek alapján tehát a teljes EIF 2 szerinti interoperabilitási szintek a következı módon épülnek egymásra Politikai környezet Jogi interoperabilitási szint Szervezeti interoperabilitási szint Szemantikai interoperabilitási szint Technikai interoperabilitási szint

3.2.

Az interoperabilitás szükségessége, hajtóerık

3.2.1. A szigetszerő mőködés felszámolása a közigazgatásban Korai informatika (számítástechnika) rendszerekben egy-egy probléma megoldására, egy-egy munkafolyamat támogatására készítettek programokat, amelyek csak a felhasználóval tudtak kommunikálni, de más programokkal nem. Ennek oka elsısorban a technikai lehetıségek korlátozott mivolta, illetve az automatizálásra szánt folyamatok viszonylagos egyszerősége, önállósága volt. Így volt ez az informatika alkalmazásával a közigazgatásban is. Mivel az eközigazgatás kezdeti idıszakában ilyen szigetszerő, egymással kommunikálni képtelen alkalmazásokat próbáltak különbözı áthidaló megoldásokkal mégis együttmőködésre

10

kényszeríteni, sokak szemében az e-közigazgatás a nem megfelelıen megvalósított komplex informatikai rendszerek példája lett, nem pedig a jobb közszolgáltatásé és a magasabb szintő kormányzásé, amire hivatott lett volna. Ahhoz, hogy az ügyfelek valós és jogos elvárásainak megfelelı, komplex szolgáltatásokat nyújtson a közigazgatás, meg kell szüntetni a szervezeti folyamatok és az azokat támogató információs rendszerek elszigeteltségét. Mindez nem csak, sıt elsısorban nem informatikai feladat, hanem egy olyan paradigmaváltást igénylı komplex szervezési kérdés, amely során meg kell valósítani az összhangot a közigazgatás jogi környezete, a szereplık igényei és az informatika lehetıségei között. Vagyis az interoperabilitás megvalósításának feladata egy több szintő, sok szereplıs folyamat, amely során nem tekinthetünk el a már létezı megoldások folyamatos mőködtetésétıl és a rendszerbe bevonásától, hiszen ebben a környezetben nem lehetséges „zöldmezıs” beruházásként teljesen és egyszerre lecserélni a létezı megoldásokat. A hagyományos közigazgatásra eredendıen jellemzı volt a szigetszerő mőködés. Az ügyintézık, ügyosztályok, hatóságok csak a legritkább és legszükségesebb esetekben kommunikáltak egymással, többnyire saját nyilvántartásaik voltak, esetenként részben azonos típusú – de sokszor mégis eltérı – adatokkal. Ha egy probléma megoldásához szükség volt az eljárások közti kapcsolat megteremtésére, adategyeztetésre, az az ügyfélre rótt terheket: neki kellett végigjárnia a különféle ügyintézési helyeket. Nyilvánvaló, hogy ha informatikai támogatással kívánjuk korszerőbbé, gyorsabbá, ügyfélbarátabbá tenni a közigazgatást, akkor értelmetlen ehhez a hagyományos mőködéshez igazítani az informatikai fejlesztéseket. Az informatikai eszközök képesek a gyors, hatékony kommunikációra, és joggal várhatja azt az ügyfél, hogy az ügye elintézéséhez ne neki kelljen közvetítenie az ügyintézık, hatóságok között, és hogy ugyanazokat az adatokat ne kelljen többször, több helyen is megadnia. De ma már ezt várják el a korszerősített jogszabályok is – bár a jogalkotás terén még nagyon sok a tennivaló, hogy minden jogszabályi akadály elháruljon az ilyen korszerő mőködés elıl. A Ket. ([R21]) pl. tiltja, hogy az ügyféltıl hatósági nyilvántartásban szereplı adat igazolását, vagy szakhatóság állásfoglalásának csatolását kérjék egy közigazgatási hatósági eljárás során – ezeket a hatóságnak kell beszereznie. Ehhez azonban meg kell teremteni a szervezetek, folyamatok együttmőködési képességét, és amennyiben ezeket a (rész)folyamatokat informatikai rendszerek támogatják, akkor ezen rendszerekét is. Együttmőködés csak akkor lehetséges, ha van közös nyelv: ez az interoperabilitás. Meg kell jegyezni, hogy az ideális az lenne, ha a közigazgatás teljesen integráltan mőködne, és egységes, integrált informatika támogatná a mőködését, de ez belátható idın belül számos ok miatt nem képzelhetı el. A közigazgatás olyan hatalmas rendszer, amelynek integrált mőködése a jelenlegi rendelkezésre álló eszközökkel megvalósíthatatlan, de akár pl. adatvédelmi okok miatt sem lenne kívánatos. Tehát az integráció helyett elsısorban lazán összekapcsolódó, autonóm rendszerek együttmőködése, vagyis az interoperabilitás megvalósítása jelentheti a korszerősítés útját. 3.2.2. Nemzetközi (uniós) együttmőködés) A nemzetközi életben is vannak olyan helyzetek, amikor az országok közigazgatásainak együtt kell mőködniük. A négy alapvetı uniós szabadság (áruk, tıke, szolgáltatások, személyek szabad áramlása) különösen sok együttmőködési kötelezettséget ró a tagállamok közigazgatására. Az EU az információs társadalommal kapcsolatos, i2010 nevő szakpolitikájában ([B1]) különösen nagy hangsúlyt helyezett „a korszerő, interoperábilis IKT alapú közszolgáltatások kialakítására”. A tagállamok e-közigazgatásért felelıs miniszterei a

11

legutóbbi, 2007-es lisszaboni e-kormányzati konferenciájukon aláírt közös nyilatkozatukban ([B24]) is hivatkoznak erre, és megállapítják, hogy „A határokon átnyúló információcserére vonatkozó igények kielégítésére, mint amilyenek a Szolgáltatások irányelv 8. cikke kapcsán is felmerülnek, a tagállamoknak növelni kell a határokon átnyúló interoperabilitás elérésére irányuló olyan erıfeszítéseiket, mint amilyeneket már eddig is hangsúlyoztak az elektronikus azonosítás és az e-közbeszerzés terén.”. Azt is leszögezik, hogy a széleskörő, országokon belüli és országok közti interoperabilitás a belsı piac akadálymentes megvalósításához is hozzájárul. A tagországok közigazgatásának interoperabilitása különösen a páneurópai e-közigazgatási szolgáltatások (PEGS) esetében nagy jelentıségő. Ezek olyan, határokon átnyúló közszolgáltatások, amelyeket vagy a nemzeti közigazgatási szervek, vagy az EU közigazgatási szervei szolgáltatnak egymásnak vagy európai vállalkozásoknak és polgároknak a közigazgatási szervek interoperábilis hálózata útján – annak érdekében, hogy eleget tegyenek közösségi jogszabályoknak. A PEGS-ekrıl az EIF kapcsán még lesz bıvebben szó. Az EU szintő interoperabilitás egyik legaktuálisabb alkalmazását az EU Szolgáltatások irányelvének ([B11]) 6-8. cikke által elıírt rendelkezések megvalósítása jelenti. A 6. és 7. cikk a szolgáltatások szabad áramlásának megkönnyítése érdekében elrendeli, hogy a szolgáltatások nyújtásához szükséges minden eljárás és információ egyablakos ügyintézési pontokon legyen elérhetı (a belföldi és a külföldi szolgáltatók számára egyenlı elbánással). A 8. cikk szerint ezen eljárások és információk elérése távolról, elektronikus úton is biztosítandó. Az egyablakos ügyintézés csak az érintett szervek magas fokú interoperabilitásával biztosítható, és ugyanez vonatkozik az elektronikus utat megvalósító informatikai rendszerekre is.

3.3.

Az interoperabilitás fıbb szervezési eszközei

Az interoperabilitásnak két fı szervezési megoldása terjedt el a gyakorlatban: az interoperabilitási keretrendszer és a szervezeti architektúra. Az alábbiakban röviden bemutatjuk ezek fıbb jellemzıit. 3.3.1. Interoperabilitási keretrendszer Az interoperabilitási keretrendszer egy közösség (szervezet, ország, országok közössége stb.) számára írja le annak egyeztetett vagy egyeztetendı módját, hogy a közösség tagjainak hogyan kell kapcsolatot tartaniuk egymással, és hogyan kell szabványokat, elıírásokat használniuk a kapcsolattartás során. Más szavakkal: magas szintő irányelveket és iránymutatást fogalmaz meg ahhoz, hogy hogyan lehet megvalósítani az interoperabilitást, milyen alapokon kell kiválasztani az ehhez szükséges szabványokat. Az interoperabilitási keretrendszerek különösen a közigazgatásban terjedtek el. Számos ország készített ilyen keretrendszert: ezeket nevezzük nemzeti interoperabilitási keretrendszernek (NIK). Az EU a PEGS-ek tervezéséhez és megvalósításához tette közzé az European Interoperability Framework (EIF) nevő keretrendszerét. Ezeknek a közigazgatási interoperabilitási keretrendszereknek az elsıdleges érintettjei a következık:

12

― ― ― ― ― ―

stratégiai elemzık, mőszaki elemzık, közigazgatási IT stratégiai tervezık, közigazgatási vezetık és projektvezetık, ipari beszállítók, együttmőködést igénylı közszolgáltatások tervezıi.

Az interoperabilitási keretrendszerek rendszerint tartalmazzák a használatra ajánlott (vagy kötelezıen elıírt) szabványok katalógusát, és ebben kiemelkedı jelentıséget tulajdonítanak a nyílt szabványok használatának, ill. ösztönzik a nyílt szabványok létrehozását. (Meg kell jegyeznünk, hogy szabvány alatt hivatalosan nemzeti vagy nemzetközi viszonylatban elismert szabványosítási testületek által elfogadott – mőszaki – specifikáció értendı, de hétköznapi szóhasználatban más szervek által készített specifikációt is értenek alatta. Jelen anyagban ez utóbbi, kiterjesztı értelemben használjuk a szabvány fogalmát.) A nyílt szabvány kritériumait az EIF 1.0 változata így fogalmazta meg: ― A szabványt non-profit szervezet fogadta el és tartja karban, folyamatos fejlesztése olyan nyílt döntéshozatali eljárás alapján történik, amely minden érintett fél számára elérhetı (konszenzusos vagy többségi döntéshozatal stb.). ― A szabványt közétették, és a szabvány specifikációjának dokumentuma ingyenesen vagy névleges díjért elérhetı. Mindenki számára ingyenesen vagy névleges díjért másolhatónak, terjeszthetınek és használhatónak kell lennie. ― A szabvány (vagy részeinek) szellemi tulajdonjoga – ha van, akkor a szabadalom – visszavonhatatlanul elérhetı jogdíjmentes alapon. ― A szabvány újbóli felhasználásának nincsenek korlátai. A nyílt szabványok használata többek között az alábbi elınyökkel jár (szemben a zárt, tulajdonosi szabványok használatával): ― csökkenti a piacra lépés korlátait, ezzel növeli a versenyt, a választás lehetıségét – ami a minıség javulásához és az árak csökkenéséhez vezet; ― ösztönzi az innovációt, mivel több alkotóerı jut a gondolatok megvalósítására és a fejlıdés elımozdítására; ― erısíti a felhasználók pozícióját a szállítókkal szemben; ― lehetıvé teszi, hogy a felhasználó együtt tudjon használni kulcsrakész és testreszabott rendszereket; ― az átláthatóság révén elısegíti az interoperabilitást; ― növeli a biztonságot; ― biztosítja az információhoz és a szolgáltatásokhoz való hozzáférést, mivel megakadályozza az olyan csapdahelyzeteket, amikor az ilyen hozzáférés speciális termékekhez kötött. 3.3.2. Szervezeti architektúra A szervezeti architektúra (SZA, angol terminológiával: Enterprise Architecture, EA) egy szemléletmód, amely az 1990-es évek elején alakult ki a versenyszférában mőködı szervezetek irányítását és napi munkáját támogató informatikai rendszerek létrehozásának elısegítésére. Maga az architektúra fogalma egy rendszer alapvetı szervezıdését jelenti, amelyet a részei és azok egymáshoz és a külvilághoz való kapcsolata, valamint a tervezését és mőködését vezérlı elvek írnak le.

13

Kezdetben a SZA szemléletmód újdonságszámba menı eleme az volt, hogy egyrészt az informatikai rendszer létrehozásának folyamatát az üzleti folyamatok és az üzletmenet elemzésével és átalakításával kezdi, másrészt a folyamatot iteratívan képzeli el, azaz az elkészült rendszert megvizsgálja, hogy mennyire felel meg az induláskor kitőzött céloknak, illetve a kialakítás ideje alatt keletkezett új követelményeknek, és a szükséges módosításokat újabb iterációs ciklusokban folyamatosan végzi. Elég hamar észrevették, hogy a SZA szemléletmód nemcsak a versenyszférában, hanem a közigazgatásban is jól alkalmazható, hiszen ott is folyamatok vannak, csak tartalmilag és céljaikban némileg különbözıek. A SZA egy átfogó és precíz módszer alkalmazásának gyakorlata arra, hogy leírjuk egy szervezet folyamatainak, információs rendszereinek, személyzetének és szervezeti egységeinek jelenlegi és/vagy jövıbeni szerkezetét és viselkedését – beleértve együttmőködésüket is –, ill. hogy azok mennyiben felelnek meg a szervezet alapvetı céljainak és stratégiai irányainak. Egy szervezet vagy akár egy ország közigazgatása számára egy egységes szervezeti architektúrában való megegyezés azt jelenti, hogy az egyes (IT) megoldásokat egyeztetett, egymással együttmőködésre képes módon szervezik. A SZA egy holisztikus szemléletmód, amelynek egyik pillére, eszköze az interoperabilitás, ezért az SZA keretrendszerek az interoperabilitási követelményekre is kiterjednek. A SZA egy szervezet mőködését támogató rendszer kialakítását legalább négy területre osztja fel, amelynek mindegyikében fontos szerepet kap az interoperabilitás: ― mőködési modell kialakítása, ― információs modell kialakítása, ― alkalmazási rendszer kialakítása, ― technikai infrastruktúra kialakítása. A SZA és az IK tehát egymással rokon, ugyanakkor egymástól – mind az alkalmazási területet, mind a technikai részletek szintjét tekintve – megkülönböztetendı és bizonyos fokig egymást kiegészítı fogalmak. Az IK-t szokták az építési szabályzathoz hasonlítani, ami szabályozza, hogy milyen elıírásokat kell betartani az építkezéseknél, az SZA-t pedig egy olyan várostérképhez, amelyik megmutatja, hogy milyen közös erıforrások állnak a rendelkezésre, és milyen módon használhatjuk azokat az építészetben.

3.4. Az interoperabilitás nemzetközi és hazai történetének rövid áttekintése Az interoperabilitás elıfutárának tekinthetjük a nyílt rendszerekre való törekvést, és ezen belül az ISO 1984-ben közzétett Open Systems Interconnection (OSI) Reference Model (nyílt rendszerek összekapcsolásának hivatkozási modellje) nevő szabványát. Ennek hatóköre természetesen minden IT rendszerre vonatkozott, nem csak a közigazgatási rendszerekre. Az USA kormányzati szabványügyi szervezete (NIST) már elsısorban a (szövetségi) kormányzati szervek számára alkotta meg 1988-ban a „Government Open Systems Interconnection Profile” (GOSIP) nevő, technikai szintő interoperabilitási szabványát (FIPS 146), amely az OSI modellen alapult. A GOSIP-nak az Egyesült Királyságban elkészítették az UK GOSIP nevő változatát, amelyet a 80-as évek végétıl az EU is alkalmazott.

14

A 90-es évek közepétıl megjelent a kormányzatoknál az e-közigazgatási szemlélet, amelynek már nem az IKT alkalmazása, hanem a közigazgatás korszerősítése került a fókuszába (az IKT alkalmazásával), és ezért az együttmőködés jelentısége is felértékelıdött. 2000-ben született meg az Egyesült Királyságban az elsı e-közigazgatási interoperabilitási keretrendszer, az e-GIF (eGovernment Interoperability Framework), amely az intézményközi együttmőködésre és e-közigazgatási szolgáltatásokra vonatkozóan számos betartandó specifikációt és irányelvet tartalmazott. Az e-GIF-et számos ország interoperabilitási keretrendszere követte, így a francia CCI (Le Cadre Commun d’Interopérabilité) 2002-ben, a német SAGA (Standards und Architekturen für E-Government-Anwendungen) 2003-ban, a dán DIF (Danish e-Government Interoperability Framework) 2004-ben, és folytathatnánk a sort. Jelenleg 12 uniós tagországnak van dokumentált nemzeti interoperabilitási keretrendszere (NIK). Idıközben az EU is intenzíven foglalkozott az interoperabilitás kérdésével az IDABC (korábban IDA) programja keretében – eleinte elsısorban az országok, valamint az EU intézményei közti, a transzeurópai hálózatokon történı adatcsere kapcsán, késıbb pedig a páneurópai e-kormányzati szolgáltatások (PEGS) vonatkozásában. 1999-ben született meg az Európai Parlament és a Tanács 1720/1999/EK határozata a közigazgatási rendszerek közötti elektronikus adatcserét lehetıvé tevı transzeurópai hálózatok együttmőködési képességét és az e hálózatokhoz való hozzáférést biztosító cselekvés- és intézkedéssorozatok elfogadásáról. Ehhez gyakorlati útmutatóként adták ki az Architecture Guidelines (AG, Architektúra irányelvek) címő dokumentumot, amely iránymutatásokat, konkrét megoldásokat, részletes mőszaki specifikációkat és bevált gyakorlatokat ismertet az európai e-közigazgatási együttmőködéshez. Az AG mind ez ideig utolsó, 7.1 változatát 2004-ben publikálták ([B5], [B6]). Az EU – ugyancsak az IDABC program keretében – elkészítette magas szintő irányelveit is az interoperabilitással kapcsolatosan, és 2004-ben European Interoperability Framework for Pan-European eGovernment Services címmel, 1.0 verziószámmal jelentette meg ([B18], rövid hivatkozással: EIF). Az EIF iránymutatást adott a NIK-ek létrehozásához is. Az AG, az EIF és a NIK-ek más-más aspektusát fedik le az interoperabilitás témakörének. Ezek egymáshoz való közelítésére projekteket indított az IDABC, amelynek eredményeképpen 2008 végére jelenik meg az EIF 2.0 változata. Ennek egy elıkészítı vitaanyagát tették közzé 2008 nyarán Draft document as basis for EIF 2.0 címmel ([B14]). Az Egyesült Államok szövetségi kormánya a szervezeti architektúra (SZA) megközelítés keretében kezelte (és kezeli) az interoperabilitás témáját: 1999-tıl kezdve folyamatosan jelentet meg a SZA alkalmazását különbözı szinten tárgyaló kiadványokat: [B19], [B4], [B17] stb. Jelentıs részben az amerikai kormányzati informatika fejlıdésének hatására az Egyesült Királyság, majd más európai országok is foglalkoztak az SZA megközelítéssel. Az e-GIF egy e-Services Development Framework (e-SDF, E-szolgáltatások fejlesztésének keretrendszere) nevő keretrendszer részeként készült el, amely többek között egy High Level Architecture (Magas szintő architektúra) nevő, SZA jellegő rendszerfelépítés leírását is tartalmazta. A dán kormány 2003-ban közzétett a SZA alkalmazásáról egy fehér könyvet ([B30]), és az abban lefektetett elvek alapján közös eszközök és irányelvek fejlesztése azóta is folyamatban van. Az Európai Bizottság által készített AG dokumentum is tartalmaz az SZA szemléletnek megfelelı rendszerfelépítési javaslatokat.

15

Magyarországon a Miniszterelnöki Hivatal (MeH), ill. az Informatikai Tárcaközi Bizottság (ITB) csatlakozott még a ’90-es évek közepén a nyílt szabványok alkalmazásának törekvéséhez néhány ilyen tárgyú ITB-ajánlás kiadásával. Késıbb a MeH, ill. az Informatikai Kormánybiztosság elsı interoperabilitási célú projektjei a közigazgatásban elérhetı adatok egységes metaadat-leírásának és keresırendszerének (KIKERES), valamint a közigazgatásban használatos fogalmak egységes ontológiai adatbázisának (FOGALOMTÁR) létrehozását célozták meg 2000-2002-ben. A kezdeti eredmények (néhány ezer metaadatrekord és fogalomleírás elkészítése) után a projektek nem folytatódtak tovább. 2004-2005-tıl a MeH fejleszti a központi elektronikus szolgáltató rendszert (KR), melynek egyik célja a közigazgatási IT rendszerek interoperabilitásának megteremtése. A MeH a Kormányzati Informatikai Egyeztetı Tárcaközi Bizottsággal (KIETB) együtt ajánlást is kiadott a KR egyik szolgáltatásához, az ügyfélkapuhoz való kapcsolódás mőszaki specifikációjáról ([B12]). 2003-2004-ben az Informatikai és Hírközlési Minisztérium (IHM) bonyolított le olyan projekteket, amelyek eredményeként az alábbi területeken születtek javaslatok az interoperabilitás kezelésérıl a magyar közigazgatásban: ― Magyar e-közigazgatási interoperabilitási keretrendszer (MEKIK) koncepciója, lehetséges jogi háttere, irányítási modellje, ― az interoperabilitási szabványokra épülı rendszerek fejlesztésének és üzemeltetésének módszertana, ― informatikai rendszerek kommunikációjával kapcsolatos biztonsági elvárások, ― javaslat a személyi adat- és lakcímnyilvántartással, a cégnyilvántartással és az ingatlan-nyilvántartással való kapcsolathoz szükséges eljárás-, esemény- és adatcsereszabványokra, ― központi szabványnyilvántartás, ― egységes specifikációk az elektronikus közigazgatás kommunikációjának hitelességére, bizalmasságára és az intelligens kártyák alkalmazására, ― egységes projektirányítási módszertan. A javaslatok egy része IHM-ajánlások formájában öltött testet az alábbi témákban: ― intelligens kártyák fájlszerkezete és interfésze, ― végfelhasználói tanúsítványok szerkezete és adattartalma, ― idıbélyegzés formátuma, ― elektronikus aláírás formátuma, ― elektronikus aláírási szabályzatok, ― hitelesítési rendek, ― viszontazonosítás protokollja. A dokumentumok, melyeket az Információs Társadalom Koordinációs Tárcaközi Bizottság Elektronikus Közigazgatás Albizottsága (ITKTB ELKA) által képviselt széleskörő szakmai nyilvánosság vitatott meg, jelenleg is elérhetık az ITKTB ELKA honlapján (http://www.itktb.hu/engine.aspx?page=elka_oldal). Az IHM közzétételre, ill. megvitatásra további ajánlásokat is elıkészített az alábbi szakterületeken, amelyek az IHM megszőnésével már nem jelenhettek meg IHM ajánlásként (ezek a dokumentumok is elérhetık az ITKTB ELKA honlapján):

16

― a közigazgatásban alkalmazható kulcs-visszaállítási rend irányelvei, ― elektronikus másolatok metaadatainak mőszaki specifikációja, ― a közigazgatás informatikai célrendszereinek kockázatfelmérése, biztonsági osztályba sorolása, ― a közigazgatás informatikai célrendszereire vonatkozó biztonsági intézkedések, ― interoperabilitási szabványtár a közigazgatás elektronikus rendszereinek fejlesztéséhez, ― XML formátumok az elektronikus dokumentumok titkosításához, ― elektronikus aláírás alkalmazására vonatkozó funkcionális, biztonsági, garanciális és üzemeltetési követelmények. A MeH a Közigazgatási Informatikai Bizottság (KIB) határozatával közzétette az elektronikus azonosításra, hitelesítésre, aláírásra és elektronikus azonosítók hordozására alkalmas eszközök újabb követelményeit ([B3][B2]), amely kiváltja az ilyen célú eszközök interoperabilitására született korábbi IHM-ajánlást. Ugyancsak a MeH irányításával folyik jelenleg az „Elektronikus közigazgatási keretrendszer kialakítása” címő projekt, amelynek egyik fókusza egy „mőködı” NIK létrehozása, és amelynek keretében a jelen dokumentum is készült.

4. A kitőzött célok Az alábbiakban összefoglaljuk, hogy egy NIK létrehozása milyen célok elérését tudja szolgálni: a) Élethelyzeten alapuló komplex szolgáltatások nyújtása Az együttmőködésre képes rendszerek szolgáltatásainak összekapcsolásával képes több közigazgatási szerv is együttmőködni az ügyfél komplex élethelyzetéhez tartozó valamennyi közigazgatási jellegő feladat megoldásában (pl. születés, házasságkötés, új lakásba költözés, haláleset stb.). b) Egyablakos ügyintézés lehetıvé tétele Olyan ügyek intézésénél, amelyhez több hatóság közremőködésére van szükség, elég csak egy helyen elindítani az ügyintézést, mert a közremőködı hatóságok képesek arra, hogy az ügyfél igénybevétele nélkül együttmőködjenek egymással. Ilyenkor nem az ügyfél „járkál” a hatóságok között, hanem az adat/irat. c) Egy információt csak egyszer kelljen megadni, hiteles adatforrások használata Ha a közigazgatásban már rendelkezésre áll az ügyfél valamely adata (pl. közhiteles nyilvántartásban szerepel, vagy az ügyfél már egyszer megadta), és ha az adatot ismerı/nyilvántartó rendszer képes az adat megosztására a másik rendszerrel, akkor nem kell az ügyfélnek az adatot feleslegesen újból megadnia. (Természetesen az adatvédelmi normák betartására ilyen esetekben is szükség van.) Ez elısegíti azt is, hogy lehetıség szerint mindig az aktuális, hiteles adatforrásokra támaszkodjon az ügyintézés. d) Testreszabott szolgáltatások nyújtása

17

Szabványok alapján együttmőködésre kész szolgáltatások lehetıséget adnak arra, hogy az ügyfél ismétlıdı komplex ügyei elintézésére saját szolgáltatás-portfóliót tudjon összeállítani és végrehajtatni. e) Ügyintézési idık csökkenése Az egymással együttmőködı hatóságok, rendszerek között az ügyek átfutási ideje csökken. Ez az ügyfélen kívül a hivatalok érdeke is, mert így kevesebb lesz az elintézetlen, függıben levı ügyek száma. f) Az ügyfélközpontúság növelése Az elıbbiekben felsorolt együttmőködési képességek az ügyfél természetes elvárásainak, kényelmének maximális kielégítését szolgálják. g) Adminisztratív terhek csökkentése, ügyintézés egyszerősödése Az elıbbiekben felsorolt együttmőködési képességek csökkentik az ügyfél adminisztratív terheit, egyszerősítik az ügyintézést. Mindez az ügyfél költségeinek csökkenésével is járhat. h) Átláthatóság növekedése Ha automatizált a hatóságok és informatikai rendszereik együttmőködése, akkor lehetıvé válik az ügy automatizált követhetısége annak teljes „élettartama” alatt. Ezáltal mind az ügyfél, mind a hivatali vezetık, ill. az ügy intézéséért elıdlegesen felelıs szerv/ügyintézı követni tudja az ügy sorsát. i) IKT beszállítói verseny növekedése, költségek csökkenése Ha nyilvános követelmények, szabványok határozzák meg a (rész)rendszerek kommunikációját, együttmőködését, akkor több szállító is kínál majd ugyanazon (rész)rendszerekre terméket, így nı a verseny, és ezáltal csökkenhetnek az árak. j) Szállítói kiszolgáltatottság csökkenése Az elıbb említett feltételek teljesülése megakadályozza a termékcsapdák kialakulását, és az olyan termékeket egyszerőbben le lehet cserélni, amelynek minısége, támogatottsága nem bizonyul megfelelınek. k) A döntéshozás hatékonyságának javítása Az együttmőködı rendszerek átláthatóságának hivatalon belüli növekedése révén a hivatalok vezetésének döntési képessége is javul. l) A köztisztviselık munkájának könnyítése A rendszerek együttmőködése révén lényegesen kisebb adminisztratív teher hárul a köztisztviselıkre is. m) A szükséges emberi és pénzügyi erıforrások csökkenése, költséghatékonyság növekedése Az elızıekben említettek közül több cél elérése is hozzájárul ahhoz, hogy csökkenjenek a hivatal költségei és az emberi munkaerıigény. n) A közigazgatás szereplıinek mőködése közti összehangoltság javítása

18

Az együttmőködési képesség megteremti annak lehetıségét, hogy a közigazgatás szervei a jelenleginél lényegesebben összehangoltabban végezzék munkájukat – különösen az egymással kapcsolatban álló ügyek esetében. o) Újrahasznosíthatóság, közös szolgáltató központok (shared service center), ill. alkalmazásszolgáltató (ASP) központok elterjedésének elısegítése A (rész)rendszerek közti együttmőködés megteremtése és az együttmőködés követelményeinek egységesítése, nyilvánossá tétele segíti annak elterjedését, hogy a hivatalok közös szolgáltatásait azonos (rész)rendszerek támogassák, sıt akár közös szolgáltató központok lássák el. Ez utóbbi lényegesen gazdaságosabb lehet, mintha minden egyes hivatalnál mőködtetni kellene az illetı szolgáltatást. p) Nemzetközi (uniós) együttmőködés feltételeinek megteremtése Ha egy országon belül a NIK alkalmazásának következtében kialakul az együttmőködı szolgáltatások rendszere, az megteremti annak a lehetıségét, hogy az együttmőködés nemzetközi szintre, pl. páneurópai szolgáltatásokban való részvételre is kiterjedjen. Ehhez természetesen a NIK létrehozása és fenntartása során figyelembe kell venni a nemzetközi interoperabilitási trendeket, az EIF elvárásait.

A fent felsorolt célok elérése következtében javul a kormányzás/közigazgatás eredményessége, minısége, költséghatékonysága, nı az ügyfelek elégedettsége, életminısége, javul a gazdaság adminisztratív környezete, az ország versenyképessége.

5. Az interoperabilitás megvalósításának nehézségei, kockázatai 5.1.

Nehézségek, akadályok

Az interoperabilitás megteremtésének, az interoperabilitási keretrendszer létrehozásának és alkalmazásának számos nehézsége van, amivel célszerő kezdettıl fogva számolni, és folyamatosan nagy figyelmet fordítani ezen akadályok leküzdésére, az esetlegesen ellenérdekelt szereplık negatív hozzáállásának megváltoztatására. Ha ez utóbbi intézkedésekre nem kerül idıben sor, az könnyen a keretrendszer alkalmazásának kudarcához vezethet. Az alábbiakban áttekintjük a legfontosabb ilyen nehézségeket, amelyek többsége az interoperabilitás megteremtésében Magyarország elıtt járó országok gyakorlatában is felmerült, és vázoljuk az elkerülésük érdekében teendı intézkedéseket is. a) A jogrendszer tagoltsága A jogalkotás sok esetben egy problémára koncentrál, azt kívánja megoldani, és nincs tekintettel arra, hogy az illetı probléma milyen komplex „élethelyzet” részeként merül fel. Ilyenkor elmarad annak szabályozása, hogy milyen együttmőködésre van szükség a teljes problémakör komplex, az ügyfél adminisztrációs terheit minimalizáló megoldásához. Mivel a közigazgatásra az a jellemzı, hogy szervei csak azt tehetik, amire jogszabály által fel vannak hatalmazva, sok esetben még a legnagyobb jóindulat és belátás esetén sem tudják megkönnyíteni az ügyfél dolgát együttmőködésük – pl. adatok átadása – útján (különösen vonatkozik ez a személyes adatok átadására). Ennek a problémának az elkerülésére,

19

csökkentésére erıfeszítéseket kell tenni annak érdekében, hogy a jogalkotó szervek már a jogalkotás során vegyék figyelembe az ügyintézésnek a végrehajtó szervek együttmőködésével megteremthetı könnyítését. Ez illeszkedik az EU-nak az adminisztratív terhek csökkentésére irányuló kezdeményezéséhez is. Szükség lenne pl. arra, hogy a szabályozások elızetes hatásvizsgálatai kiterjedjenek az adminisztratív terhekre, és azon belül az ügyintézés együttmőködéssel elérhetı egyszerősítésére is. b) Az ágazatok, szervezetek autonómiája Az interoperabilitási követelmények jelentıs része olyan jellegő, hogy azok betartását nem lehet jogszabályban elrendelni (legalább is közvetlen módon). Sok szerv számára csak törvényi szinten lehet kötelezettséget elıírni. Ugyanakkor az egyes közigazgatási szervek mőködéséért – és így a mőködést támogató információs rendszerekért is – a szerv vezetıje egyszemélyi felelısséggel tartozik, és neki esetenként más szempontok fontosabbak lehetnek, mint az interoperabilitás szempontjai. (Rossz esetben ellentmondó szempontok között kell választania.) Ennek a problémának a megoldására többféle intézkedés megtétele is ajánlható: ― az együttmőködés elızı alpontban említett jogszabályi elrendelése, ― az IK követelményei közül a lehetı legtöbb alkalmazásának a lehetséges legmagasabb szintő jogszabályban való elrendelése, ― közvetett elıírások alkalmazása (pl. a központi elektronikus szolgáltató rendszerhez való csatlakozás feltételeinek elıírásával, központi/uniós támogatás feltételei közé való beemeléssel), ― az ágazatok, szervezetek bevonása a követelmények kidolgozásába, és – anyagi, erkölcsi stb. – érdekeltségük megteremtése a követelmények betartásában, ― a következı alpontban említett irányítási eszközök használata. c) Az irányítás hiányossága A legmagasabb szintő elkötelezettség, a lehetı legszélesebb hatáskörrel és elegendı erıforrással rendelkezı irányítás nélkül nem valósítható meg az interoperabilitás, nem tartathatók be az IK követelményei. Az irányítás és a jogszabályi háttér megteremtésével külön fejezet foglalkozik, itt csak röviden vázoljuk a legfontosabb teendıket: ― a Parlament és a Kormány elkötelezettségének megnyerése, ― elegendı hatáskörrel rendelkezı irányító szerv, testület létrehozása, a hatáskört biztosító jogszabályi háttér megteremtése, ― az irányító szerv szükséges – anyagi és humán – erıforrásainak biztosítása. d) Az interoperabilitási igények, a jogszabályok, a technológia és a szabványok fejlıdésének figyelmen kívül hagyása Az interoperabilitási követelmények betartatása során komoly nehézség származhat abból a téves feltételezésbıl, hogy elegendı egyszeri erıfeszítést (és erıforrásokat) fordítani arra, hogy ezek a követelmények létrejöjjenek. A közigazgatás korszerősítésének elırehaladtával, a jogszabályok változásával újabb és újabb interoperabilitási igények keletkezhetnek, a technológia és a szabványok fejlıdése pedig megkívánja a régebbi követelmények rendszeres felülvizsgálatát. Ezeket a feladatokat folyamatosan el kell látni, és biztosítani kell a szükséges – pénzügyi és humán – erıforrásokat. e) Széleskörő konszenzus megteremtésének nehézségei Az egyoldalúan diktált interoperabilitás nem mőködıképes, mert a szereplık mindig meg fogják találni azokat a kiskapukat, amiken keresztül ki tudnak bújni a követelmények

20

betartása alól, ha azokat nem érzik sajátjuknak, egyéb –fontosabbnak tartott – érdekeikkel ütközıeknek tartják. Ennek elkerülésére széleskörő konszenzust kell megteremteni a követelmények kidolgozása során, amibe a lehetı legtágabb nyilvánosságot kell bevonni: a közigazgatás szereplıin, érdekképviseletein (pl. önkormányzati szövetségek) kívül a szállítókat (azok érdekképviseleteit), az egyetemi-tudományos szféra képviselıit és esetenként akár az ügyfelek érdekképviseleti szerveit is. Ez a konszenzuskeresési folyamat azonban nehézségekkel járhat, mert ― jelentıs idıveszteséget okozhat, ― számottevı erıforrásokat igényelhet, ― nem mindig található konszenzusos megoldás (egyetértés). Ezeket a nehézségeket pl. az alábbi módon lehet megelızni, megoldani: ― Elıre tervezni kell az újabb követelmények kidolgozását és a régiek felülvizsgálatát. A jogalkotás során a hatálybaléptetések idıpontját úgy kell megválasztani, hogy elég idı legyen a szükséges IKT rendszerek megtervezésére és megvalósítására – beleértve az interoperabilitási követelmények kidolgozását is. Ez ma egyáltalán nem jellemzı. Korábbi javaslatunkhoz hasonlóan a szabályozások elızetes hatásvizsgálatának ki kellene terjednie az IKT-igények – beleértve az interoperabilitási igényeket is – teljesítéshez szükséges erıforrások és idı szakmailag alátámasztott bemutatására, és jelentısebb IKT fejlesztési igény esetén ennek magában az elıterjesztésben is meg kell jelennie. ― A tervezés alapján biztosítani kell a szükséges erıforrásokat – olyan tartalékokkal együtt, amelyek elıre nem tervezhetı, rendkívüli esetekben használhatók fel. ― Ki kell dolgozni az egymással versengı megoldások közti választás olyan nyílt eljárásrendjét, amely biztosítja a demokratikus és szakszerő döntést olyan esetekben is, amikor a konszenzus nem teremthetı meg. f) Szállítói érdekek sérülése Korábban említettük, hogy az interoperabilitás egyik célja az IKT beszállítói verseny növelése, a termékcsapdák megszőntetése, és ennek révén az árak csökkenése. Ez nyilvánvalóan sérti azon beszállítók érdekeit, amelyeknek a felsoroltak révén veszélybe kerülhetnek stabil, sokéves szállítói pozíciói. Ezek a szállítók akár felhasználhatják lobbykapcsolataikat is az interoperabilitási követelmények elterjesztésének hátráltatására. Ennek a veszélynek az elkerülésére be kell vonni a szállítókat – elsısorban érdekképviseleteiken keresztül – a követelmények kidolgozásába, és kommunikálni kell feléjük, hogy ami az egyik oldalon piaci kiváltságaik megszőntetése, az a másik oldalon újabb piaci lehetıségek megnyílását jelentheti számukra. g) Régi IKT rendszerek problémái Az nyilvánvaló, hogy nem lehet egyik napról a másikra az összes örökölt, szigetszerő, együttmőködésre képtelen alkalmazást korszerő integrált vagy interoperábilis rendszerre lecserélni. Ez feltétlenül nehézséget okoz az interoperabilitás elterjesztésében. A nehézségek csökkentésére többek között az alábbi lehetıségek kínálkoznak: ― Tervezni kell a szigetszerő alkalmazások cseréjét, és össze kell hangolni azt az igények prioritásával, az új igények felmerülésével, a jogalkotással. ― Idıben ki kell dolgozni az interoperabilitási követelményeket a sorra kerülı alkalmazáscserékhez. Ez egyeztetést igényel a közigazgatás szereplıi és az interoperabilitást irányító szervezet között.

21

― Szükség esetén megfelelı (pl. „becsomagolási”) technikákkal interoperábilissá kell tenni az örökölt rendszereket. h) Alkalmazkodás az EU elvárásaihoz További nehézségeket jelenthet az, hogy az interoperabilitási követelmények kidolgozása során fel kell készülni a nemzetközi együttmőködésben – elsısorban az EU-ban – megjelenı igényekre is (pl. a PEGS-ekkel kapcsolatosan), de ezeknek az igényeknek a kidolgozása lassan halad a hazai IK kidolgozásának és alkalmazásának tervezett üteméhez képest. Ezzel a problémával kapcsolatosan nem lehet mást tenni, mint folyamatosan figyelemmel kell kísérni az uniós interoperabilitási követelmények kidolgozásának (rész)eredményeit, lehetıség szerint figyelembe kell venni azokat a hazai követelmények kidolgozásánál, ill. a már meglévı hazai követelményeket felül kell vizsgálni az uniós elvárások véglegesítése után.

5.2.

Kockázatok

Az interoperabilitási elvárásoknak való megfelelés vélt vagy valós összeütközésbe kerülhet más követelményekkel, és fennállhat annak a kockázata, hogy sérülnek más, legalább annyira fontos érdekek. A következıkben ilyen kockázatokat sorolunk fel, és egyúttal javaslatot teszünk a kockázatok elkerülésére is. a) Az adatvédelmi követelmények megsértése A személyes adatok adatkezelı szervek, azokat támogató IKT rendszerek közti cseréje adatvédelmi elıírásokat sérthet. Ennek elkerülésére lehetıség szerint törvényi szinten kell szabályozni az ilyen adatok cseréjét. Ha erre valamilyen ok miatt nincs mód, akkor meg kell teremteni annak a lehetıségét, hogy az ügyfél maga járulhasson hozzá személyes adatai átadásához – pl. annak érdekében, hogy csökkentse a rá nehezedı adminisztratív terheket. Ehhez természetesen részletes, pontos és érthetı tájékoztatást kell adni az ügyfelek számára az adatátadás valamennyi elınyérıl és adatvédelmi kockázatáról. b) A biztonsági, hitelességi követelmények sérülése Ha megteremtjük különbözı (IT) biztonsági szinten megvalósított rendszerek együttmőködését, akkor számolni kell azzal, hogy az így összekapcsolódó rendszerek eredı biztonságát a „leggyengébb láncszem”, azaz a legalacsonyabb biztonsági szinten megvalósított alkalmazás fogja meghatározni, és ezzel sérülhetnek egyes biztonsági elvárások. Erre a problémára mindig figyelemmel kell lenni rendszerek kapcsolatának megteremtésekor, és meg kell tenni a szükséges intézkedéseket (pl. a biztonsági „rések” megszőntetése az alacsony biztonsági szintő rendszer biztonságának növelésével, a fokozottan védendı rendszerbe további védelmek, ellenırzések beépítése az alacsonyabb biztonsági szintő rendszerek felé irányuló kapcsolatában stb.). c) Bizonyos szállítók elınyös helyzetbe hozása Az interoperabilitási követelmények meghatározása során elıfordulhat, hogy olyan megoldásra esik a választás, amely egyes szállítók számára versenyelınyt jelent. Ennek elkerülése, esetleg indokolt esetben az elfogadtatása pl. az alábbi intézkedésekkel lehetséges: ― nyílt szabványok elınyben részesítése, ― a lehetı legszélesebb körő egyeztetés a legmegfelelıbb megoldások kiválasztására, ― a vitás esetekre nyílt döntési mechanizmus kidolgozása.

22

d) Szubszidiaritás sérülése Fennáll annak kockázata, hogy olyan elıírások, követelmények is belekerülnek az IK-be, amelyekrıl nem feltétlenül szükséges központi döntés, és amelyek esetében több elıny származik abból, ha esetenként az egyes közigazgatási szervek választják ki a számukra optimális megoldást, mint amennyi az egységesítésbıl fakadhat. Ennek elkerülésére már az IK-be felveendı követelmények tárgyáról is széleskörő véleményezés alapján kell dönteni, továbbá arról is, hogy az egyes követelmények milyen szintő elıírással kerüljenek be az IKbe (legjobb gyakorlat, ajánlás, kötelezı elıírás stb.). e) Innováció nehezítése Minden elıírás, szabványosítás egyúttal azt a kockázatot is magában hordozza, hogy merevségével meggátolja az innovatív, új megoldások, technológiák alkalmazását. Ennek a kockázatnak a csökkentésére: ― csak a feltétlenül szükséges tárgyban kell követelményeket elıírni az IK-ben, ― kellı gyakorisággal felül kell vizsgálni az IK követelményeinek aktualitását, korszerőségét.

6. Néhány példa az interoperabilitás megvalósításának legjobb nemzetközi gyakorlatából Már korábban is említettük, hogy 12 uniós tagországnak van már dokumentált NIK-e. Ezek közül a legjelentısebbeket meg is neveztük a rövid történeti áttekintés során. Ezen túl még legalább ennyire tehetı azon – nem európai - országok száma, amelyek közzétett NIK vagy SZA-keretrendszer alapján törekednek kormányzati IT rendszereik együttmőködési képességének biztosítására. Különösen fejlett ezen a téren az USA, Kanada, Ausztrália, ÚjZéland, Malajzia és Brazília. Az alábbiakban röviden kiemelünk néhányat ezen országok legjobb gyakorlatai közül – elsısorban a hazai IK létrehozásához is felhasználható tanulságokat hangsúlyozva –, és összehasonlítást is teszünk közöttük. Feltétlenül a legjobb gyakorlatok között lehet megemlíteni az EU megközelítését is, de ezt egy külön fejezetben tárgyaljuk – elsısorban olyan szemszögbıl, hogy milyen elvárások fakadnak a hazai közigazgatás és a magyar NIK számára az EU kezdeményezéseibıl. Más dokumentumok részletesen taglalják a nemzetközi terület példáit, azonban röviden, sz eddig leírtak illusztrálásaként bemutatunk négy, példaértékő megoldást

6.1.

Egyesült Királyság

Az Egyesült Királyság NIK-ét, az e-GIF-et a 2000-ben megjelent e-kormányzati stratégiához kapcsolódóan bocsátották vitára majd léptették életbe. Jelenleg már a 6. verziónál tartanak. Az e-GIF elıírásai minden állami szervre nézve kötelezıek, beszerzéseik során csak ezekkel az elıírásokkal kompatibilis eszközöket vásárolhatnak. Az e-GIF nemcsak a kormányzati IT rendszerek egymással való kapcsolatára terjed ki, hanem azoknak az ügyfelekkel, a szolgáltatásközvetítıkkel és külföldi, uniós szervekkel való kapcsolatára is. Az e-GIF gondozásával a kormány fıinformatikusa által irányított, az e-közigazgatási stratégiáért és annak megvalósításáért is felelıs csoport foglalkozik a miniszterelnök irányításával mőködı Kabinetirodán belül. Az elıírásokat, specifikációkat többségében saját

23

szakértıik készítik, és jól szabályozott nyilvános vita után válnak az e-GIF kötelezıen alkalmazandó részévé, de pl. XML sémákat külsık is javasolhatnak (ezek készítését segédletekkel is ösztönzik). Jól szabályozott, a teljes nyilvánosság elıtt zajló eljárások biztosítják azt, hogy ne bizonyos cégeket elınyös helyzetbe hozó specifikációk kerüljenek az elıírások közé. Külön e-GIF akkreditációs szervezet is mőködik az e-GIF-fel kapcsolatos ismeretek terjesztésére, az e-GIF szakértık nyilvántartására és az e-GIF szakértelemmel rendelkezı szervezetek tanúsítására. Létrehoztak egy speciális holnapot is az e-GIF-nek megfelelı rendszerek szállításának, kiválasztásának segítésére. Az e-GIF fı részei, dokumentumai az alábbiak: ― Az e-GIF központi dokumentuma. Ez ismerteti az interoperabilitási alapelveket, ad áttekintést a keretrendszerrıl és annak részeirıl, mőködtetésérıl, a megfelelés követelményeirıl. ― Kormányzati metaadatszabvány. Az ebben rögzített módon kell ellátni minden kormányzati információforrást metaadatokkal. A szabvány a Dublin Core nevő, az ISO 15836-ban szabványosított sémán alapul. ― Mőszakiszabvány-katalógus. Négy fı területhez sorol fel szabványokat: összekapcsolhatóság, adatintegráció, e-szolgáltatások elérése és tartalommenedzsment. A szabványok lehetnek elfogadottak, ajánlottak, vizsgálat alatt lévık és késıbbi megfontolásra szántak. ― Integrált közszolgáltatási szótár. Ez egy szabályozott szótár (tezaurusz), amely hierarchiába rendezve tartalmazza a metaadatok létrehozása során használható tárgyszavakat. Egyúttal kormányzati nomenklatúraként is szolgál. ― Adatszabvány-katalógus. Az adatbázisok létrehozásához, adatcseréhez használható XML sémák katalógusa. Külön útmutató szolgál az XML sémák létrehozásának segítésére.

6.2.

Németország

Németországban 2002-ben publikált elıször NIK-et – SAGA rövid névvel ([R29]) – a Belügyminisztérium szövetségi e-kormányzatért felelıs szervezete. Ez a szervezet frissíti azóta is a dokumentumot, amelynek 2008-ban jelent meg a 4.0 változata ([B26]). A SAGA elsısorban a szövetségi hivatalok számára készült, de tartományi és önkormányzati szinten is ajánlják a figyelembevételét. Bár még a szövetségi hivatalok számára sem kötelezı betartani, ennek ellenére minden szinten nagy az elfogadottsága. A SAGA az interoperabilitás eléréséhez öt nézıpontból fogalmaz meg alapelveket, ajánlásokat, szabványokat: ― Szervezeti nézıpontból: ez a szervezettel, szabályozással, célokkal, szerepekkel, folyamatokkal, modellekkel kapcsolatos kérdéseket tárgyalja. ― Információs nézıpontból: ez az adatokra, adatmodellekre, adatszemantikára fókuszál. ― Számítástechnikai nézıpontból: ez a szoftverarchitektúrával, modulokkal, interfészekkel foglalkozik. ― Mőszaki szempontból: ez a hardver és szoftver infrastruktúra kérdéseit érinti. ― Technológiai szempontból: ez szolgáltatja a technológiai szabványok katalógusát.

24

A technológiai szabványkatalógusban az egyes szabványok kötelezı, ajánlott és megfigyelés alatti minısítéseket kapnak. (A kötelezı is csak azt jelenti, hogy ott kell alkalmazni, ahol célszerő.) A német NIK-et jelentı SAGA mellett még számos olyan kezdeményezés, projekt, dokumentum van Németországban, amely részben vagy egészben az interoperabilitást szolgálja.

6.3.

Dánia

A dán kormány két irányból is közelítette az interoperabilitás témakörét. Egyrészt 2004-ben közzétettek egy, a digitális közigazgatás architektúrájának elveit, keretrendszerét, folyamatait tárgyaló kézikönyvet, másrészt kiadták az interoperabilitási keretrendszer (DIF) elsı változatát. Azóta megjelent 2007-ben az OIO EA nevő SZA módszertan 1.0 ([B23]), míg 2008 áprilisában a DIF 2.0 változata. Mindkettıt a Tudományos, Technológiai és Innovációs Minisztérium által felügyelt Nemzeti IT és Távközlési Hatóság gondozza, és különbözı, a kormányzati, önkormányzati konszenzust garantáló bizottságok biztosítanak felügyeletet (pl. koordinációs, SZA, XML bizottság). A szállítókat is bevonják a bizottságok által szervezett szakmai fórumokba. Bár a dokumentumok nem kötelezı erejőek, de a kormány, a régiók és a települések megállapodtak abban, hogy magukra nézve kötelezınek tartják az ezen keretrendszerek által ajánlott nyílt szabványok és szoftverek alkalmazását. A DIF lényegében egy szabványkatalógus, amelyhez különbözı szabványtárak tartoznak. A szabványok három kategóriába tartoznak: ― Folyamatszabványok. Az információ feldolgozásának és elküldésének közös eljárásait írják le – tehát inkább a szereplıkre és a munkafolyamatokra vonatkoznak és nem a mőszaki szempontokra. ― Technikai szabványok. Többnyire láthatatlanok a felhasználó elıtt, és az IT rendszerek számára szükségesek az információcseréhez. ― Adatszabványok: adatcsere céljára kidolgozott szabványos XML sémák. Az OIOXML projekt keretében egy erre felhatalmazott bizottság által elfogadott szabályok szerint készülnek. Egy speciális, csoportmunkára is alkalmas eszköz, az Infostructurebase szolgál OIOXML sémák létrehozására és elfogadtatására. Annak megfelelıen, amit már jeleztünk is az SZA és az IK kapcsolatáról, az OIO EA saját részének tekinti a DIF által közzétett szabványokat is, de ezen túlmenıen módszertant szolgáltat a teljes SZA szemlélető tervezési folyamat alábbi lépéseihez is: stratégiai tervezés, üzleti/igazgatási tevékenység tervezése, mőszaki tervezés, eltéréselemzés, változástervezés, trendek elemzése (jogi, igazgatási, mőszaki), irányítás tervezése (mőködtetés, költségvetés, kapcsolódó folyamatok stb.).

6.4.

Ausztrália

Az Európán kívüli gyakorlatok közül az ausztrál példát emeljük ki, mivel ez egyesíti a legjobban az elsısorban az angolszász országokra jellemzı, amerikai minta alapján kialakított SZA szemléletet az európai interoperabilitási keretrendszer típusú megközelítéssel, amelyek jól megférnek egymás mellett, és harmonikusan egészítik ki egymást. Az interoperabilitással kapcsolatos megközelítés mintaértékő a felülrıl lefelé haladó felépítése tekintetében. A nemzeti szolgáltatásjavítási keretrendszerbıl indul ki, amely a szövetségi, tagállami és helyi

25

közigazgatás – nem feltétlenül IT jellegő – együttmőködésének kerete a jobb szolgáltatások biztosítására ([B28]). A keretrendszer által támogatott együttmőködés öt szinten mőködik: ― Az elsı szint az együttmőködés alapelveit, céljait állapítja meg. ― A második szinten szándéknyilatkozatban rögzítik a résztvevık az együttmőködés legfontosabb területeit, szabályait. ― A harmadik szinten helyezkednek el az egységes minta alapján aláírt általános együttmőködési szándéknyilatkozatok. ― A negyedik szinten szerepelnek az együttmőködési projektekkel, kezdeményezésekkel kapcsolatos specifikus megállapodások. ― Az ötödik szintet az együttmőködés közös eszközei alkotják: útmutatók, ellenırzılisták stb. – köztük a technikai szintő interoperabilitási keretrendszerek dokumentumai (lásd a továbbiakban). Az interoperabilitás következı rétegét a szervezeti folyamatok interoperabilitási keretrendszere írja le. ([B27]) Ez a keretrendszer épít az SZA keretrendszerre, és a szervezeti folyamatok kapcsolódásával, integrációjával, azok szükségességének, lehetıségének megállapításával, alapelveikkel, tervezésükkel, megvalósításukkal, érettségi modelljükkel foglalkozik. (Az SZA-t lásd késıbb.) Ez alatti réteget képez az információ-interoperabilitási keretrendszer, amely az információ megosztásának, a hiteles információforrások használatának alapelveit, jogi, adatvédelmi, biztonsági feltételeit, az információmegosztás és –újrahasznosítás protokolljait, az információ kezelését, életciklusát tárgyalja ([B8]). Ehhez kapcsolódik a GovDex nevő eszközrendszer (portál), amely a tapasztalatok megosztására, szakmai viták lefolytatására alkalmas felületet biztosít az interoperabilitási projektek résztvevıi számára, keresési felületet nyújt eszközök, webszolgáltatások, szervezetek megtalálására, és a GIEM nevő kormányzati információcsere módszertant szolgáltatja XML üzenetek, webszolgáltatás-interfészek, ill. webszolgáltatások modellezésére, tervezésére, tesztelésére. (A GIEM az UN/CEFACT UMM módszerének kormányzati célú bıvítésére épít. [B29]) Az interoperabilitás legalsó, technikai rétege ([B9]) lényegében a közigazgatási IT rendszerekben használatra ajánlott mőszaki szabványok katalógusa a következı csoportosításban: biztonság, adatkeresés (metaadat), kapcsolat, adatcsere, adatábrázolás, folyamatok és adatok leírása, elnevezés. Az ausztrál SZA két részbıl áll. A szervezetközi szolgáltatások architektúrájának alapelveivel foglalkozó kötet ([B13]) segédlet a szervezetek közti, ill. a közös szolgáltatások architektúrájának és mőködésének tervezésére – függetlenül attól, hogy a szolgáltatást támogatja-e IT vagy sem. Az anyag bemutatja a legfontosabb tervezési alapelveket, és azt is, hogy hogyan lehet ezeket IT rendszerekkel megvalósítani. A másik SZA dokumentum a kormányzati architektúra hivatkozási modellje ([B7]). Ennek célja, hogy közös gondolkodási alapot biztosítson a szervezetközi szolgáltatások „felépítéséhez”, és az építkezési eszközök (szabványok, útmutatók, tervezési és megvalósítási megoldások) tárháza legyen.

6.5.

Az Európai Unió kezdeményezéseibıl fakadó elvárások

Az Európai Bizottság a politikai nyilatkozatoktól a stratégiaalkotáson, szabványosításon, specifikációk készítésén át az alkalmazásig minden szinten foglalkozik e-közigazgatási interoperabilitással mint az e-közigazgatás egyik kulcskérdésével. A célterület elsısorban a páneurópai e-kormányzati szolgáltatások (PEGS), amelyek kiterjednek

26

― egy tagország állampolgárainak és vállalkozásainak más tagországok adminisztrációjával való közvetlen interakcióira, ― különbözı tagországok adminisztrációjának egymás közti adatcseréjére, ― az EU szervezeteinek egymás között vagy a tagországok egy vagy többi közigazgatási szervével lefolytatott adatcseréjére. Mivel ezen interakciók túlnyomó többsége érinti a tagországokat, ezért a tagországoknak nagy figyelmet kell fordítaniuk arra, hogy milyen koncepciók, egyezmények, elıírások születnek az EU-ban, hogy meg tudjanak felelni az elvárásoknak. Megjegyezzük, hogy ezek az elıírások mindig a tagországok bevonásával és konszenzusos döntésével születnek, tehát a tagországok kormányai folyamatosan figyelemmel tudják kísérni az ilyen irányú kötelezettségeiket, és fel tudnak készülni alkalmazásukra. A PEGS-ek letéteményese az EU-n belül az IDABC program, amelyet az Informatikai Fıigazgatóság felügyel. A PEGS-ek részben az EU belsı mőködését, részben pedig a négy alapvetı uniós szabadság (áruk, tıke, szolgáltatások, személyek szabad áramlása) megvalósítását szolgálják. Egy részükben való részvételt az uniós jogszabályok írják elı, más részük még csak olyan önkéntes közérdekő szolgáltatások vagy pilot projektek keretében valósulnak meg, amelyekben a tagországok részvétele ugyan nem kötelezı, de a jövıben akár kötelezıvé is válhat. Természetesen a PEGS-ek esetében az interoperabilitási követelményeknek egységeseknek kell lenniük – akár a hivatalok egymás közti, akár az ügyfelekkel való kommunikációjáról is van szó. Az alábbi ábra összefoglalja az EU interoperabilitással kapcsolatos különbözı szintő kezdeményezéseit:

A következıkben röviden áttekintjük ezeket a terveket, az eddigi eredményeket – kiemelve azokat, amelyeket a hazai NIK-nek is figyelembe kell vennie, ill. amelyek figyelembevételére fel kell készülnie a NIK-et mőködtetı szervezetnek. 6.5.3. Európai interoperabilitási stratégia (EIS) Az EU 2009-re kíván kidolgozni egy közös európai interoperabilitási stratégiát, amely ― elsısorban a határokon és szektorokon átívelı interoperabilitást kívánja támogatni,

27

lefekteti az európai közigazgatások közti interoperabilitás irányítási koncepcióját, igazodik az EU politikai prioritásaihoz, meghatározza a fı interoperabilitási prioritásokat, szervezési, pénzügyi és mőködtetési keretet ad az európai interoperabilitás megvalósításához, ― különféle szcenáriók értékelése alapján magas szintő cselekvési tervet is szolgáltat a megvalósításhoz. ― ― ― ―

Az EIS-t, amelynek kidolgozásában minden tagország részvételére számítanak, a Bizottság és a Tanács jóváhagyása mellett a tagországok minisztereivel kívánják elfogadtatni a 2009. októberi miniszteri konferencián. Az EIS által kijelölt prioritások és akciók a magyar NIK-re is jelentıs hatással lesznek. 6.5.4. Európai interoperabilitási keretrendszer (EIF) Az EIF egy olyan dokumentum, amely útmutatást ad a közszolgáltatások EU-szintő egységben és határokon keresztül történı nyújtásához szükséges interoperabilitási feladatok olyan módon történı megoldásához, hogy azok valódi páneurópai közszolgáltatások lehessenek. Az EIF kidolgozását és karbantartását az IDABC program keretében felügyeli az Európai Bizottság. Az EIF fı céljai az alábbiak: ― az európai akadálymentes interoperabilitás alapjául szolgáljon a közszférában, lehetıvé téve ezáltal a jobb európai szintő közigazgatási szolgáltatások nyújtását, ― határok és szektorok közti interoperabilitással támogassa a PEGS-ek szolgáltatását, ― páneurópai dimenzióval egészítse ki a NIK-eket. Az EU EIF-jének jelenleg érvénes, 2004-ben elfogadott változata az 1.0 verziószámot viseli, és elkészítés alatt áll a 2.0 változat. Az EIF nem kötelezı erejő a tagországokra nézve, de az EK alapszerzıdésének az IDABC alapjául is szolgáló 154. cikke értelmében figyelmen kívül sem hagyhatják azt a tagországok. Az EIF nem is a NIK-ek kiváltására törekedett, hanem azok kiegészítésére a PEGS-ek szempontjainak figyelembevételével. Mindazonáltal az EIF ajánlást ad a NIK-ek elkészítésére is. A NIK-eknek – így a magyar NIK-nek is – használniuk kell az EIF-t, hogy a páneurópai dimenziót is bevonják szempontjaik közé, hogy meg lehessen valósítani a páneurópai szolgáltatásokat. Az IDABC projektjeiben való részvétel során kötelezı figyelembe venni az EIF-t. Az EIF-et gondozó IDABC egy állandó NIK-megfigyelı szolgálat felállítását tervezi, hogy figyelemmel kísérje a tagországok interoperabilitás terén elért eredményeit, segítse az információcserét a tagországok között ezen a területen, és támogassa az EIF elveinek figyelembevételét a tagországok NIK-eiben. 6.5.5. EIF 1.0 Az eEurope 2005 cselekvési terv irányozta elı egy, a PEGS-eket támogató interoperabilitási keretrendszer kiadását. 2004-ben publikálták az EIF 1.0 változatát az IDA II. program keretében. A fı hajtóerıi, szempontjai a következık voltak:

28

― ― ― ― ― ― ― ―

elérhetıség (mindenki számára egyenlı eséllyel), többnyelvőség, biztonság, személyes adatok védelme, szubszidiaritás, nyílt szabványok használata, nyílt forráskódú szoftverek, multilaterális megoldások alkalmazása (kétoldalú megoldások helyett).

Az interoperabilitás területeinek az EIF 1.0 által bevezetett felosztását a 3.1 pontban már ismertettük. 6.5.6. EIF 2.0 Az EIF új változata 2008 végén jelenik meg, jelenleg még csak egy bı, vázlatos dokumentumot tettek közzé, amely az alapját fogja képezni az EIF 2.0-nak ([B14]). Az alábbiakban ezen vázlat alapján ismertetjük a 2.0 várható jellemzıit. Az 2.0 változatot az 1.0hoz képest az alábbiak fogják jellemezni: ― nagyobb együttmőködést teremt a NIK-ekkel, ― nagyobb hangsúlyt kapnak a PEGS-ek, ― nagyobb hangsúlyt kap az örökölt (régi) rendszerek kérdése és a szabványok fejlıdésének figyelembevétele, ― a fókusz a technikai interoperabilitásról a szemantikaira és szervezetire helyezıdik át, ― nagyobb hangsúlyt kapnak az európai infrastrukturális szolgáltatások. Az EIF 2.0 nyomán az alábbi célok elérése válik lehetségessé az interoperabilitás tekintetében a tagállamok számára: ― közös irányelvek, ― közös tervek, ― közös értelmezés, ― közös szóhasználat, ― közös célok, ― egyeztetett ajánlások. Az EIF 2.0 (önkéntes) figyelembevétele a tagállamoktól az alábbi megfontolásokat kívánja: ― Az alapelvek a PEGS-ek megvalósítása során már korábban kölcsönösen elfogadott interoperabilitási megállapodásokon alapulnak. Ezeket a PEGS-eknél figyelembe kell venni. ― A szabványok tekintetében olyan, korábban kölcsönösen elfogadott eljárásokat és kritériumokat tartalmaz majd, amelyeket a szabványok kiválasztásánál kell alkalmazni. ― A közös modellt célszerő az új szolgáltatások megvalósításánál figyelembe venniük a tagországoknak. A tervek szerint a tagországok és az érintett bizottsági szolgáltatások által konszenzussal elfogadandó új EIF 2.0 szerepelni fog a Bizottságnak a Tanács és a Parlament számára kiadott közleményében, és a Bizottság ajánlani fogja a tagországoknak, hogy ― igazítsák saját NIK-üket az új EIF-hez,

29

― közbeszerzéseik során írják elı a szállítóik számára a NIK-nek való megfelelést, ― tegyék közzé interoperabilitási ütemtervüket, és az ütemterv, valamint NIK-ük EIFhez való igazítása érvényre juttatásának folyamatát. Az EIF 2.0 az alábbi pillérekre épül: ― tíz alapelv, ― az interoperabilitás szintjei (területei), ― általános közszolgáltatási elvi modell, ― nyílt szabványok, ― nyílt forráskódú fejlesztési megközelítés. A következıkben ezeket a pilléreket tekintjük át vázlatosan. Az EIF 2.0 tíz alapelve (amelyek magyar NIK számára is fontosak): ― szubszidiaritás (az EIF nem kíván beavatkozni a tagállami közigazgatások belügyeibe), ― az ügyfelek igényeire és jogaira fókuszálás (lásd pl. a Szolgáltatások irányelv egyablakos ügyintézési rendelkezését), ― az e-befogadás és az elérhetıség hangsúlyozása, ― a biztonság és a személyes adatok védelmének szem elıtt tartása, ― többnyelvőség, ― a részvételi demokrácia és az átláthatóság támogatása, ― szabványosítás, innováció támogatása és a gyártófüggıség elkerülése, ― az adminisztrációs terhek csökkentése, ― költséghatékonyság hangsúlyozása és értékelésének alkalmazása, ― az információ hosszú távú megırzése. A 2.0 változat interoperabilitási szintjei az alábbi – legfelsı szintő – területekkel bıvülnek az 1.0-éihoz (szervezeti, szemantikai , technikai) képest: ― politikai kontextus: a kooperáló szervezetek víziójának, fókuszpontjainak kompatibilitása, ― jogi interoperabilitás: a kooperáló szervezetekre vonatkozó jogi szabályozás szinkronitása (ez különösen különbözı országok szervezetei között lehet komoly akadálya az együttmőködésnek). A már az EIF 1.0 által is tárgyalt szemantikai interoperabilitással kapcsolatban fontos javaslat az adatmegosztás/újrahasznosítás protokolljainak kidolgozása, az információ életciklusmenedzsment használata, továbbá az IDABC tartalom/szemantikai interoperabilitási stratégiájának javaslatai ([B20], [B21], [B22]) alapján elindított SEMIC.EU (lásd: [R30], [F6] és http://www.semic.eu/) projektjében való aktív részvétel. Az általános közszolgáltatási elvi modell az a szervezési elv, amely alapján az interoperabilitásra építı közszolgáltatások szervezıdnek. A modell három szintre épül. Az egyes szintek és a hozzájuk főzıdı, a magyar NIK-re is kiható megfontolások a következık: ― Valamennyi szinten: o át kell alakítani a rendszereket és alkalmazásokat úgy, hogy újrahasznosíthatók legyenek a komponensek, o szolgáltatási szint szerzıdések és mőködtetési irányelvek szabályozzák a komponensek mőködését,

30

o lazán csatolt, moduláris infrastruktúra-komponenseket kell alkalmazni (pl. webszolgáltatások), o multilaterális megoldásokat kell használni (kétoldalúak helyett). ― Alapvetı közfunkciók szintjén: o alapnyilvántartások mint hiteles forrásokat kell használni, o szabályozni kell a hozzáférést (pl. a személyes adatok védelme érdekében), o az örökölt (régi) rendszereket auditálni kell, hogy mennyire lehetséges újrahasznosításuk, o alapvetı interoperabilitási szolgáltatásokat kell biztosítani (pl. protokollátalakítók, formátumátalakítók, információbrókerek). ― Biztonságos adatcsere szintjén: o gondoskodni kell az adatok, személyek hitelesítésérıl, a bizalmasságról, o biztosítani kell a kommunikációmenedzsmentet, a hiteles szolgáltatások regiszterét és a naplózást. ― Aggregált (komplex) szolgáltatások szintjén: o gondoskodni kell alapvetı közszolgáltatások felépítésérıl alapnyilvántartások, interoperabilitási szolgáltatások, külsı szolgáltatások szabályozott és biztonságos módon történı összekapcsolásával. Az EIF 2.0 további pillérét képezik a nyílt szabványok. Ezekkel kapcsolatos ajánlások: ― Kerüljön sor a használandó szabványok és mőszaki specifikációk egy minimális halmazának összeállítására. ― Ennek során részesítsék elınyben a nyílt szabványokat. ― A kiválasztás történjen átlátható, korrekt és kiegyensúlyozott módon, az EU 2008-ban induló CAMSS projektje által kidolgozott módszer és kritériumok alapján ([R2], [F2], [B25]). ― Támogatni kell a szabványosítási folyamatokat. ― Elı kell írni a kiválasztott szabványok és specifikációk használatát a közbeszerzési eljárások során. ― Kerülni kell, hogy az ügyfeleknek vagy más partnereknek fizetıs termékeket kelljen használniuk a közszolgáltatások igénybevételéhez. Az EIF 2.0 utolsó pillére a nyílt forráskódú fejlesztési módszerek használata. Ennek során többek között ― figyelembe kell venni a nyílt forráskódú szoftverek használatát – egyenlı esélyt teremtve számukra a zárt, tulajdonosi szoftverekkel, ― minden fázisban alkalmazni kell a nyílt forráskódú fejlesztések módszereit (hibaértesítések, tesztelés, hozzájárulás a változásokhoz, változásmenedzsment, licencelés, biztonsági akkreditáció stb.), ― az általános közszolgáltatási elvi modellnek megfelelı, szabadon újra felhasználható építıelemeket kell fejleszteni.

6.6.

Architektúra irányelvek

Az Architektúra irányelvek (Architecture Guidelines, AG) címő dokumentum konkrét, pragmatikus útmutatásokat ad rendszerépítık, rendszerfejlesztık számára arra vonatkozóan, hogy hogyan kell alkalmazni az interoperabilitási keretrendszerben (EIF) lefektetett elveket,

31

ajánlásokat. Az IDABC az EIF 1.0 változatával párhuzamosan készítette el az IDABC AG irányelveinek utoljára megjelent 7.1 változatát ([B5], [B6]). Mivel az EIF 2.0-hoz igazodóan – várhatóan 2009 folyamán – jelentısen át fogják dolgozni az AG jelenlegi verzióját, ezért csak vázlatosan ismertetjük az AG mostani állapotát. Az AG részletesen megfogalmazza az alábbi típusú felhasználói követelményeket: ― alapkövetelmények (köztük az interoperabilitás), ― eljárásrendi követelmények, ― biztonsági követelmények, ― végrehajtási követelmények, ― kiegészítı követelmények. Az AG felsorolja a végrehajtási alapelveket is, amelyek lényegében az EIF-bıl átvett alapelvek. Végül az AG mellékletében részletesen foglalkozik a páneurópai szolgáltatásokat támogató általános szolgáltatásokkal (az egyes rövidítések jelentését és a szolgáltatások részletes ismertetését az IDABC honlapján lehet megtalálni): ― Összekapcsolási szolgáltatások o TESTA (transzeurópai telematikai hálózat) ― Adatintegráció és köztesréteg o MoReq (elektronikus iratok kezelésének modellkövetelményei) o MIReG (e-kormányzati információforrások kezelése) o eLink (middleware biztonságos elektronikus információcseréhez) ― Adatközlés, adatcsere o CIRCA (kommunikációs és információforrás központ adminisztrációs eszköz) ― Biztonsági szolgáltatások o PKICUG (nyilvános kulcsú infrastruktúra zárt felhasználói csoportoknak) A felsorolt szolgáltatások egy része jelenleg is mőködik, más része csak pilot vagy ajánlás formájában valósult meg. 6.6.7. Infrastrukturális szolgáltatások Ez a szint azon közös szolgáltatások szintje, amelyeket a PEGS-ek megvalósításához nyújt az EU. Ezekkel azért kell számolnia a magyar NIK-nek is, mert a tagországoknak ezeket kell használniuk a PEGS-ekhez. A jelenleg mőködı, kísérletileg mőködtetett vagy korábban kipróbált szolgáltatásokat már felsoroltuk AG kapcsán, ill. megemlítettük az EIF 2.0 ismertetésénél (SEMIC.EU, CAMSS). Az alábbiakban további, tervezett szolgáltatásokat tekintünk át röviden. a) Közös személyazonosítási szolgáltatás Sok közszolgáltatás igénybevételének feltétele az ügyfél hiteles azonosítása. A legtöbb tagországban megteremtették az elektronikus személyazonosítás lehetıségét, de az egyes országokban ilyen célra használt eszközök jelentısen különböznek egymástól. Az állampolgárok mobilitásának megteremtése megkívánja, hogy a papírdokumentumokhoz hasonlóan az elektronikus személyazonosításra szolgáló eszközöket is elég legyen csak saját országukban megszerezni, és azt más országok közszolgáltatásainak igénybevételekor is használhassák. Az EU e-közigazgatási cselekvési terve ([B2]) egyik fı célként általánosságban is kitőzte egy, az interoperabilitáson és kölcsönös elismerésen alapuló európai elektronikus személyazonosítási keret 2010-ig történı megvalósítását. A páneurópai

32

elektronikus közszolgáltatások szempontjából is alapvetıen fontos lenne, hogy azokat bármely ország elektronikus azonosítási (eID) megoldásával igénybe lehessen venni. Az IDABC program ezért projektekkel vesz részt a cselekvési terv céljainak megvalósításában, és megcélozta egy közös személyazonosítási szolgáltatás megvalósítását 2009-ig. Ezen túlmenıen a tagországok egy nagyszabású pilot projektet is elindítottak az eID terén. b) Elektronikus közbeszerzés A már hivatkozott uniós cselekvési terv azt a célt is kitőzte, hogy 2010-re a közbeszerzések 100%-a elektronikusan is elérhetı lesz, és 50%-uk elektronikus úton fog lezajlani. Ehhez is jelentıs szabványosításra és az interoperabilitás megteremtésére van szükség. Ennek érdekében az IDABC is indított projektet az e-megrendelés és az e-számlázás egységesítésére, továbbá számos tagország részvételével egy nagyszabású e-közbeszerzési pilot projekt is elindult. c) Nyílt forráskódú szolgáltatások Az IDABC program elindította a legjobb nyílt forráskódú gyakorlatok, megoldások figyelését, összegyőjtését és szolgáltatását az OSOR.EU portálon (http://www.osor.eu/). d) Egyéb szolgáltatások További közös szabványosítás és szolgáltatások terve is felmerült (pl. e-dokumentumok, ealáírás, a Szolgáltatások irányelv megvalósítása területén), de ezek egy részének meghatározására valószínőleg az EIF 2.0 kidolgozása után, az új AG elkészítésével párhuzamosan kerül majd sor, ezért a magyar NIK aktualizálásához folyamatosan figyelemmel kell kísérni az uniós kezdeményezéseket. Itt jegyezzük meg, hogy az EIF hatókörén túlmenıen is folynak jelentıs egységesítési törekvések az EU-ban a közszféra interoperabilitásának megteremtése érdekében. Pl. az e-egészségügy területén nemrég adott ki a Bizottság egy ajánlást az elektronikus egészségügyi dokumentumkezelés interoperabilitására.

6.7.

A keretrendszerek összefoglalása

Az alábbiakban összefoglaljuk az ismertetett keretrendszerekbıl levonható legfontosabb tanulságokat. 6.7.1. Irányítás Fontos a magas szintő központi irányítás. Ez minden megismert példánál megvan. Általában minisztériumi szintő a koordináció, és magas szintő kormányzati testület hozza meg a fontos döntéseket. Ország/EU Egyesült Királyság Németország Dánia Ausztrália Európai Unió

Irányítás Miniszterelnöki kabinetiroda Belügyminisztérium (+ fıhatóság: BSI) Minisztérium által felügyelt fıhatóság Pénzügyi és Dereg. Minisztérium hivatala Fıigazgatóság programja (IDABC)

Döntéshozatal nyilvános vita után a kabinetiroda nyilvános vita után a Belügyminisztérium bizottságok közremőködésével kormányzati vezetı informatikusok tagországok képviselıi

33

6.7.2. Elfogadtatás Ahhoz, hogy minden érintett elfogadja és alkalmazza a közös elvárásokat, a lehetı legtöbb szempont érvényesülhessen, és ki legyen zárva a parciális érdekérvényesítés, biztosítani kell a legszélesebb körő vita lehetıségét és a demokratikus döntéshozatalt. Ezek minden megismert országban és az EU esetében is megvannak. A közös követelmények alkalmazásának jogi eszközökkel való kötelezıvé tételére sehol sem került sor a teljes közigazgatásra vonatkozóan. Az Egyesült Királyságban a kormányzati szervekre nézve ez megtörtént – itt közös infrastruktúraelemek is részét képezik az interoperabilitás eszköztárának (pl. a Government Gateway nevő közös kapu) –, a közigazgatás többi szereplıje önként kötelezte alá magát a használatra. A többi országban is biztosított azonban az ajánlások széleskörő alkalmazása az érintettek bevonásának, a konszenzus megteremtésének és a magas szakmai magas színvonalnak köszönhetıen. Ország/EU Egyesült Királyság Németország Dánia Ausztrália Európai Unió

Elfogadtatás kormányzati szervekre kötelezı, többi szereplı egyezményben kötelezte magát, vita a teljes nyilvánosság elıtt csak ajánlás, de nagy az elfogadottsága csak ajánlás, de nagy az elfogadottsága csak ajánlás, nincs információ az elfogadottságról csak ajánlás, de nagy az elfogadottsága

6.7.3. Terjedelem Azok a keretrendszerek a legperspektivikusabbak, amelyek a közigazgatás céljainak, feladatainak legmagasabb, stratégiai szintő megfogalmazásából kiindulva, egységes modellben tudják kezelni az interoperabilitási követelményeket. Ez az ausztrál példára a leginkább jellemzı, ahol a szolgáltatási interoperabilitástól kezdve a technikai interoperabilitásig minden szintnek megvan a saját interoperabilitási stratégiája, és ezek egymásra épülnek. Az EIF is három egymással kapcsolatban lévı épülı szinten tárgyalja az interoperabilitás szempontjait. Ezt a szemléletet segíti, ha az interoperabilitás igénye a korszerő szervezeti architektúra követelményeivel összhangban jelentkezik annak természetes megvalósításaként. Erre az ausztrálok mellett a dánok is jó példával szolgálnak. Ország/EU Egyesült Királyság Németország Dánia Ausztrália Európai Unió

Vertikum fıleg szemantikai és technikai teljes, a technikai szint a hangsúlyos az SZA-val a teljes vertikum teljes teljes (fıleg a készülı 2.0-ban)

Kapcsolat SZA-val implicit módon infrastruktúra szinten nincs SZA behivatkozza SZA-val kiegészítik egymást AG (elavult, majd új készül)

6.7.4. Mőködtetés Az interoperabilitási követelményeket nem elég egyszer kidolgozni, azokat rendszeresen frissíteni kell. Ez az ismertetett országokban megteszik, és az EU-ban is most készül az EIF 2.0 változata. A követelmények alkalmazásba vétele ott a legsikeresebb, ahol gyakorlati útmutatók, segédletek is segítik a megértést és az alkalmazást, továbbá tervezı, keresı, tapasztalatcserére szolgáló eszközöket (pl. portált) is rendelkezésre bocsát a követelményeket

34

gondozó szerv. Ebben eléggé sokszínő a kép. Külön ki kell emelni az Egyesült Királyság akkreditációs szervezetét. Ország/EU Egyesült Királyság

Segédletek gyakorlati ajánlások (pl. XML sémákra)

Németország Dánia Ausztrália

kapcsolódó projektek anyagai fıleg XML sémákra fıleg XML-re, webszolgáltatásokra, információcsere modellezésére nincs

Európai Unió

Eszközök keresésre, megfelelıségre akkreditációra szervezet kapcsolódó projektek keretében XML sémákra portálok XML-re, webszolgáltatásokra, keresésre, tapasztalatcserére nincs

7. Továbblépés az interoperabilitásban, fejlıdési irányok Amint említettük, jelenleg az uniós tagországok nem egész fele rendelkezik dokumentált interoperabilitási keretrendszerrel, de számos további országban is folyamatban van a NIK elkészítése. A nemzeti keretrendszerek általában – minimálisan – az alábbiakra terjednek ki: ― a célok, terjedelem, hatókör meghatározása, ― maga a szakmai tartalom, ― az eljárások leírása (a tartalom kialakításához, felülvizsgálatához stb.), ― a megvalósítás és a megfelelés ellenırzése. A keretrendszerek ki-, ill. átdolgozásának nyilvánvalóan újabb lendületet ad majd az EIF 2.0 elkészülése, mivel az számos ajánlást fog tartalmazni a tagországok számára, és ezért fontos elvárás lesz az EU részérıl, hogy a NIK-eket igazítsák hozzá az EIF-hez. Korábban már megállapítottuk azt is, hogy a hangsúly el fog tolódni a technikairól a szemantikai, szervezeti, sıt a magasabb szintő interoperabilitás felé.1 A NIK elkészítésén kívül fontos a megvalósítás gondos megtervezése, amelynek során figyelembe kell venni az alábbiakat: ― Nem lehet egy egész kormányzatra kiterjedıen az interoperabilitást egyetlen nagy ugrással elérni. ― Az interoperabilitás megvalósítása és továbbfejlesztése sok kis lépést igényel. ― Az interoperabilitás továbbfejlesztéséhez folyamatos ágazatközi koordinációra és megfelelı szervezetre van szükség. ― Különös jelentısége van a nyílt és minden érintettet befogadó eljárásoknak. Különösen a szolgáltatásorientált architektúrának (SOA) a közigazgatási informatikában várható elterjedésével megnı az interoperabilitás holisztikus, az SZA kontextusában való kezelésének jelentısége. Ha az elsı európai kezdeményezések ezen a téren (Dánia, Hollandia, és bizonyos értelemben az Egyesült Királyság és Írország) sikeresek lesznek, akkor várható, hogy a többi országban is terjedni fog ez a megközelítés.

1

Egy amerikai interoperabilitási stratégiai anyagban a kormányzat legfıbb tíz teendıje között elsı helyen ez szerepel: „szemantika, szemantika és szemantika” (http://www.eprocesssolutions.com/CMS/documents/InteroperabilityStrategy.2003-03-06.doc).

35

Elıre látható, hogy a következı idıkben felértékelıdik a nyílt szabványok jelentısége. Ez növelni fogja a rendszerek közti választás lehetıségét, a versenyt és az innovációt, javítani fogja az információhoz való hozzáférést. A nyílt szabványosítási folyamatok hozzájárulnak az ellenırizhetıséghez és az érintettek széleskörő részvételéhez, és ahhoz, hogy megszőnjön a szállítóktól való függıség. Ha mindenben elérhetık lesznek nyílt alternatívák, az eközigazgatási szolgáltatások igénybevevıinek nem kell kötıdniük egy-egy szállító technológiájához, nem kell nyílt helyett zárt technológiát használniuk amiatt, hogy a szolgáltatást nyújtó intézmény választ elıször technológiát. A nyílt, jól dokumentált szabványok alkalmazását az EU i2010 kezdeményezése is külön hangsúllyal kezeli. A nyílt szabványokkal kapcsolatosan két hangsúlyos tennivalója van a kormányzatoknak: ― a szabványok kiválasztása, ― a szabványosítás folyamatának segítése. A szabványok kiválasztásával kapcsolatosan várható, hogy a már említett CAMMS projekt majdani eredményeit egyre inkább figyelembe veszik a NIK-eknél. Az EU is úgy tervezi, hogy az új AG-be fokozatosan be fognak épülni ezek az eredmények. Ennek várható hatásai az alábbiak lesznek: ― Nem kell majd minden létezı szabványt és specifikációt figyelembe venni a kiválasztásnál – különösen azokat nem, amelyek akadályozzák az interoperabilitást. ― A kiválasztás során nem termékeket fognak versenyeztetni. ― Fókuszba kerülnek azok a területek, amelyek a legtöbbet nyerhetnek a szabványosításból. ― A már bizonyított, széles körben használt, nyílt szabványok kapnak prioritást. ― Lehetıség lesz a még nem kiérlelt, de legígéretesebb szabványok inkubációjára, hogy a lehetı legjobb minıségő szabványokká válhassanak. A szabványosítás és specifikációkészítés folyamatát az alábbiakkal kell segíteni: ― Ismertté kell tenni a belföldi cégek elıtt annak elınyeit, ha részt vesznek a szabványosítási tevékenységben. ― Folyamatosan győjteni kell a kormányzati szervek igényeit a szabványosítással kapcsolatosan, és ismertté kell tenni azokat a szabványosítás résztvevıivel. Ehhez a közigazgatási szerveknek megfelelı ismeretekre kell szert tenniük. ― Hangsúlyozni kell a nyílt szabványok iránti igényt a szabványosítással foglalkozó testületek felé, és támogatni kell a nyílt szabványok fejlesztésének folyamatát. ― Támogatni kell az olyan kutatás-fejlesztési tevékenységeket, amelyek részben vagy egészben nyílt szabványok elıkészítésére irányulnak. ― A közigazgatási szolgáltatások felhasználói elıtt is ismertté kell tenni a nyílt technológiák elınyeit. ― Segíteni kell azokat a nyílt szakmai közösségeket, intézményi kapcsolatokat, amelyek a privát, tudományos és a közszféra szakmai ismereteinek egyesítésére jönnek létre.

36

8. Az interoperabilitás lehetséges jogi és irányítási háttere a magyar közigazgatásban A legjobb nemzetközi gyakorlatok értékelése kapcsán már szóltunk röviden az interoperabilitás irányításának jelentıségérıl. Az irányításnak többek között az alábbiakra kell kiterjednie: ― igények megfogalmazása, ― célok meghatározása, ― fejlesztés, kiválasztás, ― karbantartás, ― megvalósítás, ― monitorozás, ellenırzés, ― kommunikáció. Az irányítás felelıssége, hogy az interoperabilitás folyamatai megfeleljenek a politikai, stratégiai céloknak – beleértve az uniós célokat is –, és hogy ezáltal az interoperabilitás megkapja a szükséges támogatást. Mivel a közigazgatás egésze jogszabályi alapokon mőködik, az interoperabilitásban rejlı lehetıségeket is csak akkor tudja kiaknázni a közigazgatás, ha megvannak hozzá a szükséges jogszabályi alapok. A következıkben azokat a lehetıségeket tekintjük át, amelyekkel biztosítani lehet az interoperabilitás szükséges jogi és irányítási hátterét. A jogi és irányítási háttér megteremtésével összefüggésben alapvetıen az alábbi kérdések megválaszolása szükséges: • milyen dokumentumban (milyen jogforrási szinten vagy egyéb dokumentumban) jelenjenek meg az elıírások? • ki alakítsa ki az elıírásokat? • milyen kényszerítı erı biztosíthatja az érvényesülést? • ki és hogyan ellenırizze a megfelelést?

8.1.

A szabályozás és irányítás lehetséges „építıkövei”

a) Jogszabályok és az állami irányítás egyéb jogi eszközei A jogszabályoknak lényegi eleme, hogy azok kötelezı jellegő elıírásokat fogalmaznak meg; az állami irányítás egyéb jogi eszközei pedig vagy az alárendelt szervek, szervezeti egységek számára jelentenek kötelezı elıírásokat, vagy jelentenek egyéb, szigorú értelemben véve nem kötelezı iránymutatásokat. A jogalkotásról szóló 1987. évi XI. tv. által felállított jogforrási hierarchia határozza meg a lehetséges eszközök komplex körét és azok kötelezı erejét. A kodifikációs technika és tudomány fejlıdése azonban abba az irányba halad, hogy jogszabály ne tartalmazzon részletes, precíz, konkrét technológiát vagy megoldást megkövetelı normát. A jogszabályokkal szemben ugyanis lényegi (bár hazánkban jelenleg meglehetısen korlátozottan érvényesülı) követelmény azok stabilitása. A jogszabály akkor tudja valódi rendeltetését betölteni, ha azt nem szükséges gyakran változtatni, ha az állandó követelményt jelent. Különösen igaz ez a törvényi szintő szabályozásra, azonban a

37

követelmény érvényes valamennyi jogszabályra egyaránt. Közvetve szintén a stabilitás felé mutat a jogszabályok elfogadását megelızı (gyakran idıigényes) egyeztetési folyamat. A technológiai fejlıdés ezzel szemben folyamatos és gyors, szükséges, hogy az elıírások rugalmasan és gyorsan alakíthatók, a változásokhoz igazíthatók legyenek. E követelmények alapján a mőszaki elıírások célszerően nem rögzíthetık jogszabályban. Kifejezetten akadályokba ütközik a szabványok jogszabályban történı kötelezıvé tétele. ― A szabványok szinte minden esetben szerzıi jogi védelem alatt álló mővek, amelyek használatáért – a nyílt szabványok kivételével – a jogtulajdonosnak (amely Magyarországon a Magyar Szabványügyi Testület) jogdíjat kell fizetni, ami a szabvány árában jelenik meg; így ezeknek jogszabályba történı „átemelése” jogsértést valósítana meg; ― A szabványok meghivatkozása és kötelezıként elıírása a hazai jogszabályokkal ellentétes lenne (l. lentebb). Szintén a mőszaki elıírások jogszabályokból való „kiemelését” támasztja alá az, hogy a jogalkotó tipikusan nem rendelkezik olyan informatikai szakértelemmel, amely az ilyen típusú konkrét mőszaki elıírások meghatározását lehetıvé tenné. De a jogszabályoknak a közigazgatáson belüli egyeztetési folyamata sem alkalmas arra, hogy annak keretében valódi mőszaki elıírások kerüljenek egyeztetésre, hiszen az ehhez szükséges szakértelem jellemzıen nem áll rendelkezésre az egyeztetéseken részt vevık oldalán. Fentiek eredményeként a mőszaki elıírások jogszabályi szintre „emelése” számos diszfunkcionális jelenséghez vezet, és így a törekvés egyre inkább ennek az elkerülése felé mutat. Ennek számos példája említhetı: ― a hatósági elektronikus ügyintézés mőszaki követelményeit maga a jogszabály nem határozza meg, hanem azokkal szemben alapvetı (funkcionális vagy elvi) követelményeket határoz meg, amelyeket részletesen ajánlások bontanak ki; ― az elektronikus számla mőszaki követelményeit csak általánosságban határozza meg a jogszabály, annak részletes feltételeit (fájlformátum, XML séma stb.) APEH közlemény tartalmazza; ― az elektronikus cégeljárásban alkalmazott nyomtatványok XML sémáját szintén nem a jogszabály, hanem a Cégszolgálat honlapján közzétett tájékoztató tartalmazza; ― stb. b) Szabványok A hazai szabványosítás alapvetı kereteit (a nemzeti szabványosítás szervezeti kereteit, mőködésének fıbb elveit, követelményeit, kapcsolatrendszerét és gazdálkodásának fıbb eszközeit) a nemzeti szabványosításról szóló 1995. évi XXVIII. törvény határozza meg. A törvény által elfogadott meghatározás szerint a szabvány: elismert szervezet által alkotott vagy jóváhagyott, közmegegyezéssel elfogadott olyan mőszaki (technikai) dokumentum, amely tevékenységre vagy azok eredményére vonatkozik, és olyan általános és ismételten alkalmazható szabályokat, útmutatókat vagy jellemzıket tartalmaz, amelyek alkalmazásával a rendezı hatás az adott feltételek között a legkedvezıbb.

38

A szabványok alapvetı típusai: a) nemzetközi szabvány: olyan szabvány, amelyet nemzetközi szabványosító vagy szabványügyi szervezet fogadott el, és tett a közösség számára hozzáférhetıvé. Nemzetközi Szabványügyi Szervezetek: ISO (Nemzetközi Szabványügyi Szervezet), IEC (Nemzetközi Elektrotechnikai Bizottság) b) európai szabvány: olyan szabvány, amelyet európai szabványügyi szervezet fogadott el, és tett a közösség számára hozzáférhetıvé. Európai Szabványügyi Szervezetek: CEN (Európai Szabványügyi Bizottság); CENELEC (Európai Elektrotechnikai Szabványügyi Bizottság); ETSI (Európai Távközlési Szabványügyi Intézet); c) nemzeti szabvány: A nemzeti szabvány olyan szabvány, amelyet a nemzeti szabványügyi szervezet alkotott meg, vagy fogadott el, és tett a nyilvánosság számára hozzáférhetıvé. A nemzetközi és az európai szabványokat szabványként közzétenni a Magyar Köztársaságban csak nemzeti szabványként lehet. A nemzeti szabvány nem lehet jogszabállyal ellentétes. Nemzeti szabványt tehát csak a nemzeti szabványügyi szervezet alkothat meg, fogadhat el és tehet a nyilvánosság számára hozzáférhetıvé. Korábban volt lehetıség arra, hogy államigazgatási szervek, minisztériumok bocsássanak ki szabványokat; e szervek szabványkibocsátása azonban Európában nem gyakorlat és a nemzeti szabványosítás alapelveivel is ellentétes; ennek megfelelıen a törvénybıl az erre vonatkozó rendelkezések egy módosítás útján kikerültek. A nemzeti szabványok lényegi tulajdonsága továbbá az önkéntes alkalmazás. A jelenlegi jogszabályi környezetben csupán arra van lehetıség, hogy egy mőszaki tartalmú jogszabály hivatkozzon valamely nemzeti szabványra, amelynek alkalmazását úgy kell tekinteni, hogy az adott jogszabály vonatkozó követelményei is teljesülnek. Korábban (2002-ig) volt lehetıség arra, hogy jogszabály kötelezıvé tegyen valamely nemzeti szabvány alkalmazását. Ez elsısorban az állami szabályozás szempontjából kiemelt területeken (biztonságtechnika, egészség, környezet, fogyasztói érdekek védelme) merült fel a gyakorlatban. A Magyar Szabványügyi Testület CEN és CENELEC tagságának azonban elıfeltétele volt, hogy a kötelezı szabványok létrehozásának jogi lehetısége megszőnjék. A hatályos jogi környezetben így nemzeti szabványok nem tehetık kötelezıvé. Kötelezı elıírások tehát jogszabályként tehetık közzé; a mőszaki tartalmú jogszabály elıírásait természetesen ugyanúgy be kell tartani, mint bármely jogszabályt. A kapcsolódó szabvány vagy szabványok alkalmazása pedig szükségszerően önkéntes. A szabványoknak való megfelelés ellenırzéséhez kapcsolódik a tanúsítási mechanizmus: a tanúsító szervezet az irányadó szabványoknak való megfelelést ellenırzi és tanúsítja. A tanúsító szervezetet • jogszabályban meghatározott eljárásrendben, az ott meghatározott szempontok alapján valamely miniszter jelöli ki (példa: 182/1997. (X. 17.) Korm. rendelet a mőszaki termékek megfelelıségét vizsgáló, ellenırzı és tanúsító szervezetek kijelölésérıl), vagy • az akkreditációra vonatkozó szabványok alapján a Nemzeti Akkreditáló Testület (NAT) akkreditálja; a tanúsító szervezet az akkreditációval szerez jogot a tanúsításra, az akkreditációs okiratban meghatározott körben.

39

c) Egyéb dokumentumok A fentieken túlmenıen természetesen lehetséges, hogy a mőszaki normák ne jogszabályban vagy szabványban, hanem valamilyen egyéb dokumentumban (tipikusan: ajánlásként) jelenjenek meg. Ezek tehát szükségképpen ― nem kötelezı erejő dokumentumok (mivel nem jogszabályként jelentek meg), és ― nem rendelkeznek a szabványok fogalmi ismérveivel sem (pl. mert nem a szabványügyi testület fogadta el ezeket). Ennek ellenére – fıként önkéntes követés útján – ezek az elıírások jelentıs szerepet tölthetnek be az interoperabilitás „szabályozásában”. Ezeknél az egyéb dokumentumoknál is felmerülhet egyfajta „kvázi kötelezı” jelleg, amikor valamely szereplı közvetve kényszeríti ki ilyen dokumentumok betartását. Példaként említhetjük az EKG-hoz, illetve a központi rendszerhez való csatlakozás követelményrendszerét, ahol a követelmények teljesülését a szolgáltatásokhoz való hozzáférés szüksége biztosítja. Ez a mechanizmus elvben felhasználható az interoperabilitási követelmények rögzítésére is, bár kiterjesztı alkalmazása már némiképp a fentebb bemutatott szabályozási (alkotmányos) kereteket feszegeti.

8.2.

Az interoperabilitás irányítása

Az EPAN az interoperabilitás irányítása terén – a virtuális vállalkozásokkal foglalkozó irodalom alapján – az interoperabilitási koordinációra az alábbi modelleket mutatja be: ― Hierarchikus modell, amelyben az egyik szervezet kezdeményezi a folyamatot és eldönti a workflow végrehajtásának módját. Ez a modell további alkategóriákra bontható attól függıen, hogyan alakítja ki a folyamat kezdeményezıje a workflow formáját: o Központosított, ahol az egyik domináns vagy delegált szerv önkényesen dönt a formáról. o Résztvevı, ahol a workflow formájáról meghozandó döntéshez a folyamatban részt vevı összes szervezettel konzultálnak. o Decentralizált, ahol az egyes szervezetek önállóan döntenek a teljes workflow rájuk esı részérıl. ― Piaci modell, ahol nem születik formális megállapodás, de a workflow-t kezdeményezı szervezet kiválaszthat egy szolgáltatót, beleértve az interfészt is, amelyet a kölcsönös adatcsere és a workflow számára biztosít. ― Ad-hoc modell, amelynél nem határozzák meg elıre a workflow-t, a folyamat alakulását a szervezetek az adott pillanatban döntik el. A jelenlegi hazai gyakorlat leginkább az ad-hoc modellhez hasonlítható, egyes hierarchikus elemekkel. A jogszabályok valójában meglehetısen kevés kifejezetten informatikai típusú követelményeket határoznak meg, ezek inkább elvi vagy funkcionális jellegőek. Tipikus példája ennek az elektronikus ügyintézést lehetıvé tevı informatikai rendszerek biztonságáról, együttmőködési képességérıl és egységes használatáról szóló 195/2005. (IX. 22.) Korm. rendelet interoperabilitásra vonatkozó követelményrendszere:

40

„27. § (1) Az informatikai célrendszerek tervezése és megvalósítása során törekedni kell a) az informatikai célrendszerek egymás közötti mőszaki együttmőködésére az informatikai célrendszerek közötti kommunikáció, adatcsere, adatelérés, alkalmazás integráció és azok biztonsága terén, b) az informatikai célrendszerek egymás közötti adatjelentéstani (szemantikai) együttmőködésre a kicserélt adatok feldolgozása terén, metaadat, fogalmi modellezés, adatelem, valamint tranzakció- és eseménykezelés vonatkozásokban…”

8.3.

Lehetséges modellek az interoperabilitás területén

A fenti szempontok figyelembevételével vázlatosan az alábbi lehetıségek körvonalazhatók: a) Önkéntes követésre épülı modell A mőszaki elıírások ebben a modellben szabványokként, ajánlásokként jelennek meg, jogszabályi kötelezés nélkül. A követés a beruházásokért felelıs döntéshozó belátásán múlik: annak felismerésén, hogy az interoperabilitás valamennyi közigazgatási szervnek a hatékonyságát növeli, így az adott szerv munkáját is segíti. Nincs azonban jogi értelemben vett garancia a teljesülésre, az interoperabilitás megvalósítására, valamint nincs (akár önkéntes) formális ellenırzési mechanizmus, amivel az adott szerv ellenırizni tudná, hogy a szervek közötti együttmőködésre maga részérıl valóban felkészült-e. A jelenlegi gyakorlat tulajdonképpen ehhez hasonlítható, bár természetesen egyes további szempontok, motivációk is szerepet kapnak. A fentebb is bemutatottak szerint a hatályos jogszabályi környezet inkább alapelvi szinten, „törekedni kell” jelleggel írja elı a követést. A modell hátrányát jelentik azonban a fentebb leírt sajátosságok: a kötelezés, az azt biztosító garanciák, ellenırzési mechanizmusok hiánya, amelyek fényében az elıírások teljesülése értelemszerően nem biztosított. Ugyanakkor elmondható: a fentebb bemutatott külföldi példák jellemzıen szintén a vezetık önkéntes belátására épülnek, a döntéshozók nem tartották szükségesnek a jogszabályi kötelezést. b) Jogszabályi elıírás Ebben a modellben az interoperabilitásra vonatkozó követelmények teljeskörően jogszabály(ok)ban kerülnek megfogalmazásra. A modell hátrányát és akadályait azonban fentebb bemutattuk, most csupán utalunk ezekre: ― a részletes mőszaki elıírások jogszabályba emelése a jogalkotás követelményeivel ellentétes; ― a már létezı szabványok beemelése aggályos (jogsértı) lehet. Így a modell e tiszta formájában a gyakorlatban nem kivitelezhetı. c) Tanúsítás A modellben az elıírásoknak való megfelelést ellenırzı mechanizmus segíti elı. A konkrét követelmények lehetnek akár jogszabályban, akár nem kötelezı erejő dokumentumban (ajánlás, szabvány stb.).

41

A tanúsítás lehet ― jogszabályban elıírt (kötelezı), ― önkéntes, de valamilyen más mechanizmus eredményeként „kvázi kötelezı” (pl. elınyben részesítés beruházásoknál a tanúsítás vállalása esetén, esetleg a tanúsítás feltétele valamely központi szolgáltatás igénybe vételének), ― teljesen önkéntes (a fenti önkéntes követésen alapuló modell, de a szerv vezetıjét az ellenırzésben segíti a tanúsíttatás lehetısége). E megoldás számos mintával, elızménnyel rendelkezik hazánkban is. Ezek közül kiemelünk két, a szabályozási modell szempontjából eltérı példát: ― iratkezelı rendszerek tanúsítása: a jogszabály részben konkrét követelményeket tartalmaz, részben pedig utal egyes szabványokra; a tanúsítás részben közvetlenül a jogszabályokban foglalt, részben pedig szabványokban foglalt követelményeknek való megfelelés ellenırzése; vagy ― CE jelölés használata: a jogszabályok csupán elvi követelményeket tartalmaznak, a mőszaki elvárások a konkrét szabványokban találhatók; a tanúsítás az e szabványokban foglalt követelményeknek való megfelelés ellenırzése. d) Egyéb motivációk Fentebb már utaltunk arra, hogy a jogszabályi elıíráson kívül számos formális vagy informális mechanizmus állhat rendelkezésre az interoperabilitási normák teljesülésének elısegítésére (kisarkítva: kvázi kötelezıvé tétel). Példák: ― Az informatikai beszerzés jóváhagyásának feltételévé tétel; ― A beruházáshoz támogatás igénylésének feltételévé tétel; ― Központi rendszerhez csatlakozás feltételévé tétel; stb. E mechanizmusok azonban természetesen csak megfelelı körültekintéssel alkalmazhatók. A központi rendszerhez csatlakozás feltételévé tétel például egyes interoperabilitási követelmények tekintetében indokolt lehet, a teljes interoperabilitási követelményrendszer teljesítésétıl függıvé tenni a csatlakozást azonban nem indokolható. Az informatikai beszerzés jóváhagyásának feltételévé tétel hatékony mechanizmus lehet, ez ugyanakkor nem biztosítja a már meglévı rendszerek együttmőködıvé tételét.

8.4.

A javasolt megoldás

A fenti szempontokat is figyelembe véve az alábbi megoldási javaslat körvonalazható. Az interoperabilitási követelmények teljesítésének kötelezettségét jogszabályban vagy állami irányítás egyéb jogi eszközében szükséges kimondani. Ennek pontos jogforrási szintje attól függ, hogy milyen érintetti körre szükséges kimondani e kötelezést: ― Kizárólag a kormány alá rendelt közigazgatási szervek esetében elégséges lehet egy kormányhatározatban rögzíteni a követelményt,

42

― Az önkormányzatokat, köztestületeket stb. is érintı kötelezéshez törvényi szintő szabály szükséges. A hatékony szabályozás érdekében célszerő különbséget tenni meglévı és újonnan megvalósításra kerülı rendszerek között: ― új rendszer már a jogszabály hatályba lépését követıen csak a követelményeknek megfelelıen valósítható meg; ― a meglévı rendszerek interoperabilitási követelményeknek való megfelelıvé tételére hosszabb türelmi idı engedése javasolt. Maguk a mőszaki követelmények célszerően ajánlásban vagy más hasonló dokumentumban (például az Egyesült Királyságban használt terminológia nyomán „specifikáció”-ban) határozhatók meg; ezek részben szabványokra való hivatkozásokat, részben önálló mőszaki elıírásokat is tartalmazhatnak. Az elıkészítés-egyeztetés-elfogadás folyamatait a fentebb bemutatott szakmai követelményeknek megfelelıen szükséges kialakítani, amely biztosítja a széleskörő konszenzust és a külföldi példák (és az Unió elvárásainak) figyelembe vételét is. A hatékonyság érdekében az elıkészítés történhet egy szőkebb szakértıi csapat által is, már korai – koncepcionális – szinten célszerő megkezdeni az egyeztetéseket, biztosítani a véleményezés lehetıségét. Az elfogadást követıen is gondoskodni kell továbbá a kialakuló vélemények becsatornázásáról, az elıírások rendszeres felülvizsgálatáról, továbbfejlesztésérıl is. A megfelelés ellenırzésére célszerő valamilyen fent bemutatott ellenırzési/tanúsítási mechanizmust kialakítani. Ezt célszerően jogszabály alapján kijelölt tanúsító szervezet végezheti (jelen megoldási javaslatban a NAT általi akkreditációs mechanizumus és az az alapján történı tanúsítás nem járható út, mivel sem az akkreditáció, sem a tanúsítás nem konkrét szabványok mentén történne). A tanúsításnak elvben alternatívája lehet, ha a megfelelés ellenırzését a MEH a beruházás jóváhagyása körében végezné el; ez azonban legfeljebb átmeneti megoldás lehet (a tanúsítási mechanizmus kialakításáig), mivel ez nem biztosítja a meglévı rendszerek átalakítását az interoperabilitási követelményeknek való megfelelés érdekében. Megfontolandó lehet továbbá, hogy egy késıbbi fázisban, amikor a kérdéses mőszaki követelmények „kiforrott”-nak mondhatók, a MEH kezdeményezze az interoperabilitási követelmények szabvánnyá „emelését”.

43

9. SOA és az interoperabilitás A SOA a közel 50 éve tartó szoftver modularizációs törekvések legutóbbi gyümölcse. A SOA a szolgáltatás fogalma köré épül, és bár meglehetısen egyszerő alapokon nyugszik, ezen egyszerő alapelvek alkalmazása igen bonyolult lehet a valós életben. A következıkben a SOA alapelveit tekintjük át. A SOA az interoperabilitás szempontjából kiemelt szerepet tölt be, interoperabilis rendszerek tervezésekor alkalmazandó architektúrának tekinthetı. A SOA rendszerek természetes interoperabilitást biztosítanak, amennyiben megfelelıen alkalmazottak az elıbb említett, és késıbbiekben részletesebben bemutatott alapelvek.

9.1.

A SOA bemutatása

Különbözı, egymással lazán csatolt szolgáltatások, amelyek pontosan meghatározott felületen keresztül tudnak kommunikálni. A SOA (Sevice Oriented Architecture) egy architekturális megközelítés, mely tiszta interoperabilitást biztosít. A SOA nem azonos a webszolgáltatásokkal. 9.1.1. Kulcsfogalmak Az architektúra tárgyalásához elkerülhetetlen az alapvetı komponensek azonosítása.

1. ábra SOA elemek

A SOA komponensei ( 1.ábra ):

44

a) Alkalmazás felület: Az alkalmazás felület a SOA aktív eleme. Ezen keresztül indíthatóak el az üzleti folyamatok. Az e-közigazgatás szempontjából ezen komponens az egyes hivatalokban található egyablakos ügyintézés felülete. b) Szolgáltatás: A szolgáltatás egy szoftver komponens, mely egy megkülönböztethetı funkcióval bír, mely funkció egyértelmően társítható egy üzleti folyamattal. A szolgáltatás részei: ba) Szerzıdés: A szerzıdés a szolgáltatás nem formális specifikációja, mely leírja a szolgáltatás funkcióját, kényszereit, és a szolgáltatás használatának a módját. Ezen szerzıdés nem kötelezı része egy formális interfész definíció, melynek megléte biztosítja a technológia, programozási nyelvtıl való függetlenséget. Fontos, hogy a szerzıdés több, mint az elıbb említett formális leírás. Az adott szolgáltatás adatainak szemantikáját is tartalmazhatja, mely nem része az IDL, ill WSDL specifikációknak. A SOA sikere, és egyben az IOP biztosítása nagyban függ a szerzıdés állandóságától. Nagyobb rendszerek esetén ez kizárólag egy központi csapat által koordinált módon teljesíthetı. bb) Interfész: A szolgáltatás funkcióit a szolgáltatás interfész fejezi ki a hálózatra csatlakozó kliensek felé. bc) Implementáció: Az implementáció szolgáltatja a konkrét üzleti funkciót, és az adatokat. Ez az implementáció a technikai megvalósítása a szerzıdésnek. bd) Adat: Egy szolgáltatás adatokat nyújthat, tipikus példa: adat – szolgáltatás. c) Szolgáltatás tárház: A szolgáltatás tárház eszközöket nyújt a szolgáltatások és a szolgáltatások igénybevételéhez szükséges paraméterek felderítésére. A szolgáltatás szerzıdés tartalmazza az elıbb említett információkat, a szolgáltatás tárház bıvítheti a paraméterek körét, pl. fizikai elhelyezkedés. d) Szolgáltatás busz: A szolgáltatás busz feladata, hogy összekösse a SOA résztvevıit. A busz elsıdleges feladata, hogy kapcsolatot biztosítson a SOA résztvevıi közt, ezáltal elérhetıvé teszi a szolgáltatásokat. A busznak támogatnia kell különbözı technológiákat, így lehetıvé téve különbözı programozási nyelven a szolgáltatások elérhetıségét. A busz többféle kommunikációs koncepciót kell, hogy támogasson, a legalapvetıbbek ezek közül a szinkron, és az aszinkron kommunikáció. Ugyancsak a busz nyújt technikai szolgáltatásokat a résztvevık számára. Ilynek pl. naplózás, biztonság, üzenet konverzió, tranzakciók… A SOA nagyvállalati alkalmazása során két fontos ökölszabályt lehet megállapítani: ― A szolgáltatás interfész ritka módosítása ― A szolgáltatás tárház központi koordinációja ― A szolgáltatás kötés egyszerő szinten tartása: Az elıbb említett szolgáltatás tárház segítségével többféle kötés valósítható meg (kötés alatt az adott szolgáltatás használatához szükséges információk rendelkezésre állását értjük). Megkülönböztetünk fejlesztési idejő kötést, melynek során a használandó szolgáltatás interfésze az azt használó szolgáltatás / alkalmazás felület fejlesztésekor rendelkezésre áll ( ismert a szolgáltatás tárházban a szolgáltatás azonosítója ), illetve futási idejő kötést, mely jóval bonyolultabb. A dinamikus kötésen belül több alszint különböztethetı meg: o futási idejő kötés név alapján ( a szolgáltatás definíciója ismert, csak a neve dıl el futási idıben),

45

o futási idejő kötés a szolgáltatás tulajdonságai alapján ( ugyanaz, mint az elızı eset, kivéve, hogy nem név, hanem tulajdonságok alapján történik a keresés), valamint o reflekció alapú kötés ( a keresett szolgáltatás leírása nem ismert fejlesztéskor, ebben az esetben reflekciót kell alkalmazni a kliensben, hogy a szolgáltatás szemantikáját dinamikusan megállapítsa). Annak ellenére, hogy a SOA magában hordozza a maximálisan dinamikus, reflekció alapú kötést, így egy állandó szolgáltatásokat nyújtó, mégis állandóan változó rendszer képét vizionálva, a statikus elemek mindenképpen egyszerősítik a rendszert. A SOA szempontjából a határ meghatározása szabadon választott. A konkrét projekt várható élettartama, mérete együtt határozzák meg. Ellentmondó szempontrendszerben kell megtalálni a középutat. 9.1.2. Alapelvek Az architektúra szempontjából fontos alapelvek felsorolása következik. Megértésük fontos, hiszen ezen nyugszik a lehetısége a natív interoperabilitás megvalósításának. a) A szolgáltatások újrahasználhatók. Annak ellenére, hogy konkrét, azonnali újrahasznosítási lehetıségek nem léteznek, a szolgáltatások felkészítettek az újrahasznosításra. b) A szolgáltatások megosztják formális szerzıdésüket: A szolgáltatások együttmőködéséhez alapvetıen fontos, hogy kölcsönösen ismerjék legalább a másik szolgáltatás formális leírását, az igényelt adatokat. c) A szolgáltatások lazán csatoltak: A tervezésnél fontos a szolgáltatások olyan kialakítása, hogy ne igényeljék a szoros csatolást. Ne alapozzanak szolgáltatások közti szoros kapcsolatra. d) A szolgáltatások absztrahálják a megvalósított logikát: A szolgáltatásnak kizárólag a szerzıdése látható a külvilág számára, minden implementációs, belsı részlet rejtett a külvilág számára. e) A szolgáltatások komponálhatóak: Egyes szolgáltatások más szolgáltatásokra épülnek rá. Ilyen tekintetben a logika különféle szintjei jelenhetnek meg a rendszerben. Ez az alapelv elısegíti az újrahasznosíthatóságot. f) A szolgáltatások önállóak: A nyújtott szolgáltatás hatókörén belül marad. Kizárólag a hatókörén belül, és nem függ más, hatókörén kívül elhelyezkedı szolgáltatástól. g) Állapotmentes szolgáltatások: A szolgáltatások ne legyenek állapotfüggık. Ezen elv alkalmazásával a lazán csatoltságot lehet növelni. A tervezéskor a maximális állapotmentességre kell törekedni, még azon áron is, hogy az állapotkezelés más szolgáltatásba kerül. h) A szolgáltatások felfedezhetıek: A szolgáltatások leírása (a szerzıdés nem csak formális leírásból áll) felfedezhetı legyen, és egyértelmő legyen az emberek, ill. a szolgáltatás igénylıi számára.

9.1.

Alkalmazási területek

A SOA egy rendszerszervezési szemlélet, komplex informatikai rendszerek kialakítását és integrálását lehetıvé tevı megközelítési mód. A megközelítési mód nem más, mint a szolgáltatások meghatározása, megosztása, és ezek laza összekapcsolásával komplex üzleti folyamatok kialakítása. Technológiai szempontból a SOA a webszolgáltatások családjába

46

tartozó szabványokra és technológiákra támaszkodik. Olyan területeken alkalmazható, ahol a feladat különbözı felépítéső és technológiájú környezetek összekapcsolása, és a cél sok alkalmazási terület egységes kiszolgálása. Fontos kiemelni, hogy a SOA alkalmazása esetében nem elsısorban technológiai változtatásról, hanem üzleti folyamat központú megközelítésrıl szól. A szolgáltatások rendszerének felépítése az üzleti folyamatok támogatásában, és azok rugalmasságában jelent elınyöket. A közigazgatás különbözı szektorai, a maguk komplex informatikai rendszereivel olyan területek, amelyek a SOA megközelítésbıl egyértelmően profitálhatnak. Az informatikai eszközök és módszerek fejlıdésével túlzás nélkül állapítható meg, hogy az egyes részterületek informatikai alkalmazásai viszonylag gyorsan kifejleszthetıek és üzembe állíthatóak, ahogy erre számos példa van. Az egyik legfontosabb probléma azonban az, hogy a megvalósított rendszerek szabályozási, üzleti és technológiai okokból gyorsan elévülnek. Számos olyan példa hozható fel, ahol a meglévı informatikai alkalmazásokat lecserélték és újakat vezettek be: a fejlesztés-bevezetés súlyos költségekkel és kockázatokkal jár. Szükség van tehát egy olyan megközelítésre, amely a létezı informatikai alkalmazások által képviselt értékeket újra hasznosíthatóvá teszi. A szolgáltatás-orientált megközelítés erre a problémára is igyekszik választ adni: integrálni a meglévı rendszereket és olyan rendszerkapcsolatokat és mőködést kialakítani, amely a természetszerőleg bekövetkezı változásokat rugalmasan követni tudja, lehetıvé teszi az üzleti folyamatok átszervezését úgy, hogy a támogató informatikai infrastruktúrát nem kell gyökeresen átszervezni és a folyamatos mőködés biztosított.

9.2.

Elınyök

A továbbiakban ismertetjük a SOA megoldások elınyeit, de természetesen szó esik a nehézségekrıl is. A SOA elınyeit négy fontos tulajdonságból kiindulva mutatjuk be, ezek: a lazán csatolt architektúra, a moduláris építkezés, a meglévı alkalmazások felhasználása és a szabványosság. 9.2.1. Lazán csatolt architektúra A komplex rendszerek fejlesztése, a rendszerek integrációja során szoros csatolás jöhet létre az egyes rendszerek között. A szoros csatolás a rendszerek és a közöttük lévı kapcsolatok változtatásának egyik akadálya – akár egy kis módosítás is számos változást indukálhat, amelyek megnövelik a fejlesztési költségeket és számos kockázatot is rejtenek. A SOA lazán csatolt architektúrájának fıbb elınyei: ― Rugalmasság az üzleti folyamatokat támogató alkalmazások és rendszerek módosítása során. A lazán csatolt rendszerekben lehetıvé válik az üzleti folyamatok hatékony kialakítása (fejlesztési idı, költség), és könnyebb az utólagos módosítás a követelmények változása esetén. Ezzel a szervezetek a külsı és belsı változtatási igényekre gyorsan és költség-hatékonyan tudnak válaszolni. ― Csökkenti az implementációs költségeket. Elsısorban a megvalósított szolgáltatások újrafelhasználhatósága miatt: az egyszer megvalósított szolgáltatások több alkalmazásban is felhasználhatóak. Természetesen ennek elıfeltétele a megvalósítást megelızı analízis során a megfelelı szolgáltatások azonosítása, valamint a tervezés

47

során az újrafelhasználhatóság szem elıtt tartása. Az újrafelhasználhatóság az egyik legfontosabb SOA tervezési szempont. ― Rugalmassá teszi az informatikai infrastruktúrát. Az újonnan bevezetett informatikai alkalmazások integrációja a már meglévı informatikai rendszerekkel könnyebben valósítható meg. Amennyiben az új alkalmazások illetve a meglévık módosítása SOA kompatibilis, ezek könnyedén integrálhatóak 9.2.2. Moduláris megközelítés A SOA több szempontból is moduláris megközelítést tesz lehetıvé – az egyszerre történı, gyökeres változtatások elkerülhetık. Az ebbıl fakadó elınyök: ― Lehetıvé teszi az inkrementális fejlesztést, a megoldások fokozatos bevezetését és a szükséges módosítások és karbantartások szakaszolását. Sok esetben elkerülhetık az informatikai rendszereket érintı átfogó átalakítások. ― Az egyes szolgáltatások megvalósítása könnyebbé válik, a fejlesztés során az adott funkcióra lehet koncentrálni, a komplexitás uralható. ― Komplex funkciók és új alkalmazások alakíthatók ki a már kialakított szolgáltatásokra épülve, sok esetben ezek kialakítása vizuális eszközökkel is támogatott. 9.2.3. Meglévı alkalmazások felhasználása A létezı alkalmazások SOA illesztésével új szolgáltatások alakíthatók ki. Az elınyök: ― Lehetıvé teszi a meglévı informatikai alkalmazások, rendszerek illesztésével az ezekben a rendszerekben meglévı funkcionalitás és mőködési modellek újrafelhasználást. ― A fejlesztési költségek csökkenthetık a meglévı alkalmazások újrafelhasználásával, és így nemcsak a teljes fejlesztési ciklus költsége, hanem ideje is csökkenthetı, sıt a fejlesztéssel járó kockázatok is minimalizálódnak. 9.2.4. Szabványosság A szolgáltatás-orientált architektúrák technológiai alapjai általánosan elfogadott szabványokra épülnek. A szabványos megoldás elınyei: ― A platform függetlenség révén a SOA megoldások lehetıvé teszi a szervezetek számára, hogy az igényeiknek, lehetıségeiknek és a már meglévı informatikai eszközeikhez alkalmazkodó szoftver és hardver megoldást válasszanak. ― Az egyes üzleti folyamatok és szolgáltatások különbözı platformokon valósíthatók meg, összekapcsolásuk könnyen realizálható. ― Azonos technológia különbözı üzleti folyamatok támogatására használható. ― A nem-szabványos technológiák áthidalása komplex problémákat és felesleges architektúra és funkcionális elemeket hozhat be. ― A szabványok alkalmazása a potenciális szállítók és fejlesztık körét kibıvíti, a közülük való választást megkönnyíti.

48

9.2.5. SOA alkalmazásának kérdései Természetesen egy szolgáltatás-orientált architektúra kialakítása csak akkor indokolt, ha ennek a haszna nyilvánvaló. A vizsgálandó szempontok: ― az architektúra kialakításának szoftver és hardver költségei ― az alkalmazások illesztésének költségei Az esetek döntı többségében nyugodtan állíthatjuk, hogy a SOA megközelítés egy szervezet IT architektúrájának kialakításánál komoly elınyökkel jár. A SOA elınyei fıként akkor jelentkeznek, ha több különbözı környezetet kell összekapcsolni. Ez tipikusan alkalmazható a közigazgatásra, hiszen egy állami szervezetnél, önkormányzatnál meglévı informatikai alkalmazások és architektúrák nem homogének. Ennek több oka van: egyrészt történetileg az alkalmazások kifejlesztése és bevezetése eredményez heterogén struktúrákat, másrészt az önkormányzatok és más szervezetek sem kötelezhetik el magukat egyetlen szállító, technológia vagy eszközrendszer mellett. Ugyanakkor hosszú távon a SOA kialakítása mindenképpen elınyökkel jár, hiszen a kialakított architektúra rugalmassá, átalakítása, illetve más rendszerekkel való összekapcsolása hatékonyan megoldható válik.

9.3.

A rendszer érettségi modellje

A SOA architektúrát alkalmazni lehet meglévı rendszerekre, ezáltal egymással kommunikáló, önálló szolgáltatásokká szegmentálni. Amennyiben ezeket a szolgáltatási interfészeket definiáljuk és az egyes szegmensekre átfogóan alkalmazzuk, a rendszerek interoperabilisek lesznek, de tisztában kell lenni, hogy a tiszta SOA architektúra kialakítása több lépésen keresztül valósítható meg. A megtett lépések között a már elkészített SOA rendszer érettségi szintjérıl lehet beszélni. a) Alapvetı SOA: Az alapvetı szinten az alkalmazás felületében még mindig sok üzleti logika található b) Hálózati SOA: Ezen az érettségi szinten megjelennek a közvetítı szolgáltatások, melyek alacsony szintő alapvetı szolgáltatásokat használnak fel a mőködésükhöz. c) Folyamati SOA: Az alkalmazás felület a folyamatot teljes mértékben kidelegálja a SOA –nak. Fontos megjegyezni, hogy a SOA megengedi, hogy a rendszer különféle részei különféle érettségi szinten legyenek. Minden szinten interoperabilis funkciókat feltételezünk. Az interoperabilitás tagolásának egy új dimenzióját lehet bevezetni a SOA érettségi modell alapján, attól függıen, hogy az adott funkció belsı megvalósítása mennyire SOA kompatibilis, mennyire komplex szolgáltatások nyújtására képes a szolgáltatás rendszer. Az eközigazgatásban a SOA bevezetése egy bottom-up megközelítést feltételez. A jelenlegi alkalmazások azonosíthatóak alkalmazásfelületként. Az alapvetı érettségi szinthez azonosítani kell az ezen szolgáltatások által használt legalsóbb szintő szolgáltatásokat ( ezek nagyrészt adatszolgáltatások lesznek), majd ezen szolgáltatások SOA –ba ágyazását kell megoldani, a jelenlegi üzleti logika megtartásával. A SOA érettségei szintjein való feljebb lépések során lassan eltőnnek az önálló szigetet alkotó speciális folyamatok, és a rendszer funkciói elérhetıek a szolgáltatások összehangolt kompozíciójával. Természetesen minden SOA szinten interoperabilisek a SOA-ban található elemek, ugyanakkor, minden esetben más bonyolultságú komponensek interoperabilitásáról lehet beszélni. Alapvetı szinten alapvetı szolgáltatások, és bonyolult üzleti logikával ellátott alkalmazás felületek együttmőködésérıl, interoperabilitásáról van szó. Hálózati szinten a 49

bonyolult alkalmazásfelületekbıl azonosításra kerülnek magasabb szintő szolgáltatások, melyek SOA szolgáltatásként manifesztálódnak. A legfelsıbb szinten az üzleti folyamatoknak megfelelı elemek is SOA szolgáltatásként jelennek meg.

9.4.

Szolgáltatások osztályzása

A SOA architektúra osztályozza a folyamatokat: a) Alkalmazás felületek: Annak ellenére, hogy az alkalmazás felületek nem szolgáltatások, mégis szerepet kapnak az osztályozásban, tekintve, hogy ezen komponensek kezdeményezik az üzleti folyamatok végrehajtását. b) Alapvetı szolgáltatások: A SOA alapkövei. Ezen szolgáltatások nyújtják a függıleges témakör (lásd késıbb) alapvetı elemeit. Az alapvetı szolgáltatásokon belül két altípust különböztethetünk meg: ba) Adat központú szolgáltatás bb) Logikai szolgáltatás c) Közvetítı, közbensı szolgáltatások (javasolt: közvetítı szolgáltatások elnevezés használata): A közbensı szolgáltatásoknak a következı típusait különböztetjük meg: ca) Technológiai átjárók cb) Felületek cc) Funkció bıvítı szolgáltatások d) Folyamat központú szolgáltatások: Ezen szolgáltatások képviselik az üzleti folyamatokat. e) Nyilvános nagyvállalati szolgáltatások: Amennyiben a SOA nagyvállalatra alkalmazott, e felületek képviselik a nagyvállalat partnerei számára nyújtott nyilvános szolgáltatásokat. Az e-közigazgatás területén ezek a szolgáltatások lehetnek az állampolgárok által elérhetı folyamatok Jelen dokumentum az interoperabilitás szempontjából vizsgálja a SOA architektúrát. Gyakorlatilag ez az architektúra mintapéldaként szolgálhat arra vonatkozólag, hogy architekturális szinten milyen ecsetvonások szükségesek, hogy a készülı rendszer interoperabilis legyen. Az interoperabilitás tervezésénél figyelembe kell venni, hogy az elkészült elemek megfelelnek-e az architektúrának. Mindenképpen korlátozni kell a fogalmakat, amelyek a rendszerben feltőnhetnek, hiszen ezen elemekre lehet megfogalmazni interoperabilitási követelményeket. Sokszor az a tény, hogy az adott elemek átgondoltan osztályozottak, és megkülönböztethetıek egy osztályzás szerint, már elısegíti az interoperabilitás létezését. Hogy a készülı rendszerben valóban létrejöjjenek ezen kategóriák, érdemes a következı motivációk átgondolása, és megkövetelése: a) Közös nyelv: A projekt résztvevıi azonos nyelven beszéljenek, és azonos absztrakciós szintre helyezzék gondolataikat. Ezáltal a SOA projektben résztvevı, különbözı szakterület szakértıi hatékony osztályozást állítanak elı. b) Függıleges szétdarabolás: A szolgáltatások osztályzása, a természetük szerint. Ezen osztályzás alapfeltétele annak, hogy a komplex terület karbantartható részekre bontható legyen. c) Hatékony becslés: a szolgáltatások osztályozása elkerülhetetlen, hogy megfelelı becslések szülessenek a komponens létrejöttének idı, és költség –vonzatára. Az erıforrásigények függenek az adott szolgáltatás implementációjának bonyolultságától, és az implementáció idıbeni változásáról.

50

d) A különbözı újrahasznosítási karakterisztikával rendelkezı kódszegmensek elszeparálása: Bevett gyakorlat az újrahasználható kódrészletek elkülönítése a specifikus részletektıl. Ez a leválasztás megnöveli a kiszedett kód újrahasznosíthatóságát, hiszen a leválasztott, elszeparált kód mentes minden speciális részlettıl. e) A megfelelı implementációs stratégia kiválasztása: Típusonként más implementációs stratégiát igényelnek a szolgáltatások. Feleslegesen bonyolult implementálási stratégia választása egy egyszerő szolgáltatáson hatékonytalanná teszi a kódot. Például kommunikációs állapotot tartalmazó szolgáltatások leegyszerősíthetik a klienseket. A kliens implementáció ezen a módon megfelelıen egyszerővé tehetı, tekintve, hogy a szolgáltatás tartalmazza a kommunikációs állapotváltozókat, és így bonyolult üzleti szolgáltatásokat nyújthat. Az állapottal bíró szolgáltatások negatív irányban befolyásolják az elosztott rendszer skálázhatóságát. A megoldás azon szolgáltatások elkülönítése, melyek állapotot tárolnak. f) Változáskezelés: Mindenképpen szükséges az üzleti folyamatok osztályozása változásuk szerint. Ezáltal a karbantartás költségei, és kockázatai csökkenthetık.

9.5.

Folyamat integritás

Jelen dokumentum az interoperabilitás aspektusában vizsgálja a SOA architektúrát, a SOA egy tipikus alkalmazása mentén az interoperabilitással kapcsolatos fogalmakat, lényeges elemeket azonosítja. Az interoperabilitás szempontjából fontos az implementált SOA folyamatok integritása. A folyamatintegritás gyakorlatilag az adatintegritás egy magasabb szinten tárgyalása. Egy komplex IT rendszerben a folyamatok helyes együttmőködésének feltétele a folyamat integritás, mely nem szükségszerően feltételezi az adat integritást, hiszen komplex IT rendszernél nincs központi adatbázis, az architektúra szereplıi folyamatok. A folyamatok integritása rendkívül fontos az interoperabilitás szempontjából. Az egyes folyamatok különbözı állapotokban lehetnek, és fontos, hogy a rendszer szempontjából ezen folyamatok által alkotott kép egységes legyen. A folyamatintegritás szempontjából egy példán keresztül szemléltetjük a kérdéskört. A hatáslánc helyes értelmezéséhez elsı körben bevezetjük a szereplıket: ― Kiindulás: A folyamat, melynek teljesítéséhez a B folyamat igénybe vesz egy C folyamatot. A következıkben a rendszerben a folyamatok inkonzisztenciája a következı módon állhat elı: ― A folyamat elindul, ennek hatására B igénybe viszi C –t. Az A folyamatot megszakítják, de a C folyamat még fut. Egyértelmő, hogy a rendszerben lévı inkonzisztencia megsérti a rendszerrel szemben támasztott interoperabilitási követelményrendszert.

51

10. Szakirodalmi hivatkozás [B1]

A Bizottság Közleménye a Tanácsnak, az Európai Parlamentnek, az Európai Gazdasági és Szociális Bizottságnak és a Régiók Bizottságának. i2010: európai információs társadalom a növekedésért és a foglalkoztatásért, COM(2005) 229 végleges, Brüsszel, 1.6.2005., http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2005:0229:FIN:HU:PDF [B2] A Bizottság Közleménye a Tanácsnak, az Európai Parlamentnek, az Európai Gazdasági és Szociális Bizottságnak és a Régiók Bizottságának. i2010 eGovernment cselekvési terv: az elektronikus kormányzat létrehozásának felgyorsítása a társadalom egészének javára, COM(2006) 173 végleges, Brüsszel, 25.04.2006., http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2006:0173:FIN:HU:PDF [B3] A Magyarországon elektronikus azonosításra, hitelesítésre, aláírásra és elektronikus azonosítók hordozására alkalmas eszközök követelményei (HUNeID) 1.0 verzió, 2008, a KIB 26. számú ajánlása, Miniszterelnöki Hivatal, http://www.ekk.hu/hu/kib/HUNEID_v1.0_vegl.pdf [B4] A Practical Guide to Federal Enterprise Architecture, Version 1.0, USA, 2001, Chief Information Officers Council, http://www.gao.gov/bestpractices/bpeaguide.pdf [B5] Architecture Guidelines for Trans-European Telematics Networks for Administrations, Version 7.1, Brussels, 2004, European Commission, Enterprise DG, IDA Programme, http://ec.europa.eu/idabc/en/document/3485/5887 [B6] Architecture Guidelines for Trans-European Telematics Networks for Administrations, Annexes, Version 7.1, Brussels, 2004, European Commission, Enterprise DG, IDA Programme, http://ec.europa.eu/idabc/servlets/Doc?id=19281 [B7] Australian Government Architecture Reference Models, Version 1.0, 2007, Australian Government Information Management Office, http://www.finance.gov.au/publications/australian-government-architecture-referencemodels/docs/AGA_Reference_Models_Version_1.0.pdf [B8] Australian Government Information Interoperability Framework, 2007, Australian Government Information Management Office, http://www.finance.gov.au/publications/agimo/docs/Information_Interoperability_Fra mework.pdf [B9] Australian Government Technical Interoperability Framework, 2007, Australian Government Information Management Office, http://www.finance.gov.au/publications/australian-government-technicalinteroperability-framework/docs/AGTIF_V2_-_FINAL.pdf [B10] Az Európai Parlament és a Tanács 2004/387/EK határozata (2004. április 21.) páneurópai e-kormányzati szolgáltatásoknak közigazgatási szervek, üzleti vállalkozások és polgárok részére történı interoperábilis nyújtásáról (IDABC), http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32004D0387:HU:HTML

52

[B11] Az Európai Parlament és a Tanács 2006/123/EK irányelve (2006. december 12.) a belsı piaci szolgáltatásokról, http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:376:0036:0068:HU:PDF [B12] Az ügyfélkapu szolgáltatásaihoz történı kapcsolódás mőszaki specifikációja, 2006, KIETB 21. számú ajánlása, Miniszterelnöki Hivatal, http://misc.meh.hu/binary/7777_kietb_21_ajanlas.pdf [B13] Cross-Agency Services Architecture Principles, 2007, Australian Government Information Management Office, http://www.finance.gov.au/Publications/crossagency-services-architecture-principles/docs/CAS_Architecture_Principles.pdf [B14] Draft document as basis for EIF 2.0, Brussels, 2008., European Commission, DG Informatics, IDABC vitaanyaga, http://ec.europa.eu/idabc/servlets/Doc?id=31508 [B15] e-Government Interoperability Framework, Version 6.1, 2005, Cabinet Office, http://www.govtalk.gov.uk/documents/eGIF%20v6_1(1).pdf [B16] e-Government Interoperability: Overview, Bangkok, 2007, United Nations Development Program, http://www.apdip.net/projects/gif/GIF-Overview.pdf [B17] E-Gov Enterprise Architecture Guidance (Common Reference Model) Draft Version 2.0, USA, 2002, Federal CIO Council, http://www.cio.gov/documents/EGov_Guidance_July_25_Final_Draft_2_0a.pdf [B18] European Interoperability Framework for Pan-European eGovernment Services, Version 1.0, Brussels, 2004, European Communities, http://ec.europa.eu/idabc/servlets/Doc?id=19528 [B19] Federal Enterprise Architecture Framework, Version 1.1, USA, 1999, Chief Information Officers Council, http://www.cio.gov/Documents/fedarch1.pdf [B20] IDABC Content Interoperability Strategy: Working paper, 2005, IDABC Programme, http://ec.europa.eu/idabc/servlets/Doc?id=24405 [B21] IDABC Semantic Interoperability Strategy: The European XML Clearinghouse. Feasibility Study, 2005, IDABC Programme, http://ec.europa.eu/idabc/en/document/3875/5890 [B22] IDABC XML Clearinghouse: SEMIC.EU, 2008, IDABC Programme, http://www.semic.eu/semic/view/documents/semic-orientationpaper.pdf;jsessionid=6372E6F8EFA1FC55EA31EE2DC510F542 [B23] Introduction to the OIO Enterprise Architecture Method (OIO EA) Version 1.0, 2007, Ministry of Science, Technology and Innovation, http://ea.oio.dk/download/resolveuid/c04a4b75bf2ab893349d5911c2251977 [B24] Ministerial Declaration. Ministerial eGovernment Conference, Lisbon, 2007, http://www.egov2007.gov.pt/images/stories/ministerial_declaration_final_version_180 907.pdf [B25] Proposal for a “CAMSS”, 2008, IDABC Programme, http://ec.europa.eu/idabc/servlets/Doc?id=31492 [B26] SAGA. Standards und Architekturen für E-Government-Anwendungen. Version 4.0, 2008, Bundesministerium des Innern, http://gsb.download.bva.bund.de/KBSt/SAGA/SAGA_v4.0.pdf [B27] The Australian Government Business Process Interoperability Framework, 2007, Australian Government Information Management Office, http://www.finance.gov.au/publications/agimo/docs/Business_Process_Interoeprabilti y_Framework.pdf [B28] The National Service Improvement Framework (NSIF) - An Introduction, 2005, National Service Improvement Program, http://www.finance.gov.au/e-

53

government/service-improvement-and-delivery/docs/NSIP-Overview_Document__5_tiers.pdf [B29] UMM for Government, Phase 1 Specification Document, 2007, Australian Government Information Management Office, https://www.govdex.gov.au/confluence/download/attachments/31457632/GIEM+Spec ification+v1.1.doc [B30] White Paper on Enterprise Architecture, 2003, Ministry of Science, Technology and Innovation, http://en.itst.dk/architecture-and-standards/publications/whitepaper-on-itarchitecture/whitepaper.pdf

54

11. Rövidítésgyőjtemény [R1] [R2] [R3] [R4] [R5]

[R6] [R7] [R8] [R9] [R10] [R11] [R12] [R13] [R14] [R15] [R16] [R17] [R18] [R19] [R20] [R21] [R22] [R23] [R24] [R25] [R26] [R27] [R28] [R29] [R30] [R31] [R32]

AG: Architecture Guidelines CAMSS: Common Assessment Method for Standards and Specifications DIF: Danish e-Government Interoperability Framework (a dán NIK) IDA: Interchange of Data between Administrations = közigazgatási szervek közötti adatcsere IDABC: Interoperable Delivery of Pan-European eGovernment Services to public Administrations, Businesses and Citizens = páneurópai e-kormányzati szolgáltatásoknak közigazgatási szervek, üzleti vállalkozások és polgárok részére történı interoperábilis nyújtása EA: Enterprise Architecture = szervezeti architektúra (SZA) eID: electronic identification = elektronikus személyazonosítás e-GIF: eGovernment Interoperability Framework (az Egyesült Királyság NIK-e) EIF: European Interoperability Framework = Európai interoperabilitási keretrendszer EIS: European Interoperability Strategy = Európai interoperabilitási stratégia EK: Európai Közösség EU: Európai Unió GIEM: Government Information Exchange Methodology = kormányzati információcsere módszertan GOSIP: Government Open Systems Interconnection Profile IHM: Informatikai és Hírközlési Minisztérium IK: interoperabilitási keretrendszer IKT: információs és kommunikációs technológia ISO: International Organization for Standardization = Nemzetközi Szabványügyi Szervezet IT: információtechnológia ITKTB ELKA: az Információs Társadalom Koordinációs Tárcaközi Bizottság Elektronikus Közigazgatás Albizottsága Ket.: 2004. évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól KIB: Közigazgatási Informatikai Bizottság KIETB: Kormányzati Informatikai Egyeztetı Tárcaközi Bizottság KR: központi elektronikus szolgáltató rendszer MeH: Miniszterelnöki Hivatal NIK: nemzeti interoperabilitási keretrendszer NIST: National Institute of Standards and Technology PEGS: Pan-European eGovernment Services = páneurópai e-közigazgatási szolgáltatások SAGA: Standards und Architekturen für E-Government Anwendungen (a német NIK) SEMIC.EU: Semantic Interoperability Centre Europe SOA: Service Oriented Architecture = szolgáltatásorientált architektúra SZA: szervezeti architektúra (Enterprise Architecture, EA)

55

12. Fogalomtár [F1] Architektúra: egy rendszer alapvetı szervezıdése, amelyet a részei, azok egymáshoz és a külvilághoz való kapcsolata, valamint a tervezését és mőködését vezérlı elvek írnak le. [F2] CAMSS: az EU IDABC programjának kezdeményezése arra, hogy a tagországok kidolgozzák a szabványok és specifikációk értékelésének közös módszerét. [F3] IDA: az EU korábbi közösségi programja, az IDABC elıdje (feloldásához lásd [R4]). [F4] IDABC: az EU közösségi programja páneurópai elektronikus kormányzati szolgáltatások közigazgatási rendszerek, gazdasági szervezetek és állampolgárok részére interoperábilis módon való nyújtására (feloldásához lásd [R5]). [F5] Interoperabilitás: az IKT rendszerek és az általuk támogatott szervezeti folyamatok azon képessége, hogy adatokat tudnak cserélni, és információt, tudást tudnak megosztani egymással. [F6] SEMIC.EU: az EU szemantikai interoperabilitási kezdeményezése a páneurópai ekormányzati projektek adatcseréjének támogatására.

56