FEJLESZTÉSI ÚTMUTATÓ ÉS MENETREND (ROADMAP)

Átírás

1 FEJLESZTÉSI ÚTMUTATÓ ÉS MENETREND (ROADMAP)

2 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:

3 1. 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 Fejlesztési útmutató és menetrend (roadmap) szolgáltatásorientált architektúra; architektúra; útmutató A dokumentum a szolgáltató állam által a közeljövıben kialakítandó ügyfélközpontú és ügyfélbarát elektronikus közigazgatási szolgáltatások megvalósításához szükséges informatikai rendszer létrehozásának módjára, kifejlesztésének lépéseire tesz javaslatot. Áttekintve az EA rendszerek fejlesztésének legjobb gyakorlatát, módszert definiál a SOA alapú rendszerre történı átállásra. A módszer iteratív és inkrementális, lehetıvé teszi a fokozatos és rugalmas fejlesztést, idıt hagy a résztvevıknek a felkészülésre. szöveg Magyarország e-közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal BME Informatikai Központ magyar V2 végleges EKK_ekozig_Fejlesztesi_utmutato_ _V2.doc

4 2. Verziókövetési táblázat A dokumentum neve Fejlesztési útmutató és menetrend (roadmap) A dokumentum készítıjének neve BME Informatikai Központ A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám V2 Összes oldalszám 94 A projekt azonosítója e-közigazgatási Keretrendszer Kialakítása projekt 2.1. Változáskezelés Verzió Dátum A változás leírása V Annotált tartalomjegyzék V MeH-nek átadott verzió V3

5 3. Szövegsablon Megnevezés Leírás 1. Elıszó (Foreword) Az Elektronikus Közigazgatási Keretrendszer Kialakítása (EK3) projekt részeként indult Alkalmazásfejlesztési keretrendszer kidolgozása alprojekt célja: a) A magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájának specifikálása b) A közigazgatási szolgáltatási sín (ESB) és mőködési rendjének specifikálása c) Fejlesztési útmutató és menetrend (roadmap) elkészítése d) Fejlesztési keretrendszer és komponenstár tartalmi meghatározása e) A fenti témákban oktatási csomagok kidolgozása Jelen dokumentum az alprojekt egyik terméke. 2. Bevezetés (Preamble) A dokumentum célja a szolgáltatásorientált architektúra kialakítása módszerének definiálása. A módszer iteratív és inkrementális, lehetıvé teszi a fokozatos és rugalmas fejlesztést. 3. Alkalmazási terület (Scope) Elektronikus közigazgatás 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)

6 4. Tartalomjegyzék 1. Metaadat-táblázat Verziókövetési táblázat Változáskezelés Szövegsablon Tartalomjegyzék Vezetıi összefoglaló Bevezetés A téma elhelyezése Az anyag felépítése Helyzetkép Az e-közigazgatás fejlettségi szintje Magyarországon Az e-közigazgatási rendszer jellemzıi Jogi háttér Elfogadott fejlesztési projektek Problémák Jövıkép Az architektúra Az architektúra alapelvei A fejlesztési folyamat követelményei Fontosabb útvonaltervek (roadmap-ek) áttekintése Bevezetés EA módszertanok TOGAF Zachman Framework Gartner EA Process Model Practical Guide to Federal Service Oriented Architecture (PGFSOA) BEA SOA Roadmap ZapThink s SOA Roadmap Accenture roadmap Közigazgatási roadmap-ek Federal Enterprise Architecture (FEA) - USA BPIR - Australia Yesser Szaud Arábia Érettségi modellek Business Process Interoperability Maturity (BPIM) Microsoft Service Oriented Architecture Maturity Model The Gartner Assessment Framework Javasolt magyar roadmap Jövıkép Egy projekt roadmap-je A projekt lépései Kezdeményezés Egyetértés Feladatanalízis Modellezés Tervezés Implementáció Sikertényezık Fogalomtár... 91

7 13. Irodalomjegyzék... 93

8 5. Vezetıi összefoglaló Az e-közigazgatásra történı áttérés, a felhasználóbarátság, a felhasználói elégedettség javítása, a folyamatosan (7x24), gyakorlatilag bárki által elérhetıen szolgáltató állam kialakítása menedzsment és technológiai vonatkozásokban egyaránt jelentıs erıfeszítést igénylı feladat. A megoldás nehézségét növeli a közigazgatás természetébıl következıen a jogszabályok szigorú betartásának, és a változások gyors követésének követelménye. A közigazgatásban történı szemléletváltás megköveteli az azt kiszolgáló IT rendszerek átalakítását is. Az IT rendszerek átalakításának, az új technológiákra (SOA) történı átállásnak meghatározó követelménye a meglevı (legacy) rendszerekre történı építkezés úgy, hogy közben az állampolgárok kiszolgálása az eddig rend szerint zavartalan maradjon. A hasonló jellegő áttérési problémák kezelésére, megoldására az üzleti életben és a kormányzatban egyaránt olyan útvonalterveket dolgoztak ki, amelyeken haladva mind a mőködési modell, mind az architektúra váltása megvalósítható. Jelen anyaggal dokumentált munka célja egy áttérési útmutató kidolgozása a magyar e- közigazgatás szolgáltatási alapokra történı helyezésének végrehajtására. A Helyzetkép rövid áttekintést ad a magyarországi e-közigazgatás fejlettségérıl, jelenlegi állapotáról, kitérve a vonatkozó jogszabályokra és a futó fejlesztési projektekre. A Jövıkép megadja az e-közigazgatás keretében kialakítandó szolgáltatásokkal kapcsolatos követelményeket, és az architektúra kialakításának elveit. A Fejlesztési folyamat követelményei címő rész összefoglalja a folyamattal szemben támasztott követelményeket. A következı Fontosabb útvonaltervek (roadmap-ek) áttekintése fejezet több részbıl áll. A bevezetést követıen ismertet 11, a gyakorlatban is elterjedt módszertant, kiemelten a kormányzati feladatok megvalósítására szolgáló metodológiákat (amerikai, ausztrál, szaud arábiai), és az intézményi érettség vizsgálatára javasolt módszereket. Az útvonalak lényegének összefoglalása mellett utalunk az elérhetı támogató eszközökre, és kísérletet teszünk az összehasonlításra. Ezt követıen adjuk közre a magyar e-közigazgatási rendszer szolgáltatásorientált architektúrája (MKA) fejlesztésére kidolgozott javaslatainkat. Lényegét tekintve javaslatunk a fokozatos, iteratív és inkrementális megközelítés. Három iterációs ciklust tervezünk, ciklusonként 6 lépésben látjuk megvalósíthatónak a közigazgatás elektronizálásának ma belátható feladatait. A sikertényezık közül kiemelnénk a mérnöki szemléletmódnak, a projektben közremőködık elkötelezettségének és a szakmai, politikai támogatásnak a fontosságát. Hangsúlyozzuk továbbá, hogy az e-közigazgatás fejlesztése hosszú távú feladat, amelyik az es években kezdıdött és a vége egyelıre nem látható. Ennek a folyamatnak a spirál modell szerinti kezelését javasoljuk a mindenkori kormányzatok számára. Természetesen a stratégiát, a feladatterveket periodikusan karban kell tartani, és az aktuális környezeti feltételekhez kell igazítani. Jelen dokumentum az Új Magyarország Fejlesztési terv idıhorizontjára tervez.

9 6. Bevezetés 6.1. A téma elhelyezése Az Európai Unió országaiban prioritásként kezelik az e-közigazgatás fejlesztését. Az i2010 egovernment cselekvési tervben [10] megcélozták az elektronikus kormányzat létrehozásának, továbbfejlesztésének felgyorsítását a társadalom egészének javára. Ezek az átfogó célok az E- közigazgatás 2010 stratégiában is megjelennek [4]. Magyaroszágon a 2010-ig terjedı idıszakban a kormányzat a következı célokat definiálta [3]: Az ügyfelek igényei szerint kialakított közszolgáltatások Az elektronikus ügyintézés jogbiztonságának megteremtése Az ügyintézési rendszerek megbízhatóságának növelése A szolgáltatások egyetemleges elérhetısége, a szolgáltatási háló (ÜGYNET) kialakítása az állam házhoz megy Az elektronikusan aktív állampolgár, ügyfél tevékenységének átfogó támogatása A non-stop közigazgatás (7x24) megvalósítása A háttérfolyamatok érdemi elektronizálása, egységes elektronikus alapszolgáltatások A közigazgatáshoz értı informatikai és folyamatszervezı szakemberek koncentrálásával létre kell hozni a tervezıi, fejlesztıi, menedzsment kapacitások kínálatát, valamint az informatikai biztonsági, interoperabilitási, modellezési, és a közszolgáltatások újratervezését (reengineering) elısegítı specializált háttér tudás-platformokat. Magyarország az Új Magyarország Fejlesztési Tervben [6] egyik fontos prioritásként az államreformot jelölte meg, amelynek megvalósítására az Államreform Operatív Programot (ÁROP) [7] és az Elektronikus Közigazgatás Operatív Programot (EKOP) [8] indította el. Ezek a programok lehetıvé teszik, hogy az elektronikus közigazgatás fejlesztésének stratégiai céljait az Európai Únió támogatásával valósítsuk meg. Az EKOP projektek konvergenciájának elısegítésére az ÁROP projektek egyikeként indult az Elektronikus Közigazgatási Keretrendszer Kialakítása (EK3) projekt. Az EK3 projekt célja azoknak az elıírásoknak, szabványoknak és követelményeknek a meghatározása, amelyek biztosítják az elektronikus közigazgatás teljes fejlesztéséhez és üzemeltetéséhez az egységes technikai, szemantikai, IT biztonsági, alkalmazásfejlesztés módszertani, valamint projekt-menedzselési és monitoring platformot. Ennek a célkitőzésnek a megvalósulása és következetes érvényesítésének biztosítása megfelelı garanciát jelent ahhoz, hogy a más projektek keretében, önállóan megvalósuló szakágazati, illetve önkormányzati alrendszerek fejlesztése, továbbfejlesztése eredményeként interoperábilis, biztonságos és korszerő elektronikus közigazgatási rendszer jöjjön létre. Az EKOP projektek eredményeként az egyes szakrendszerek továbbfejlesztésén túl ki kell alakulnia a magyar közigazgatás integrált háttérrendszerének. Ennek szem elıtt tartásával az EK3-ban, azon belül az "Alkalmazásfejlesztési keretrendszer kialakítása" c. alprojektben szoros együttmőködésben a folyamatleírással, a biztonsággal és az interoperabilitással kapcsolatos alprojektekkel kidolgozásra kerül a szakrendszerek együttmőködésének koncepciója. A koncepció az együttmőködés bázisaként szolgáltatásorientált architektúra és szolgáltatási sín kialakítását célozza meg.

10 A mai technológiákat és trendeket tekintve ez a megoldás látszik a legígéretesebb fejlesztési keretnek, mert a fejlesztés az integrációban résztvevı szervezetek számára kevesebb munkát jelent, miközben a szakrendszerek önállósága megmarad (heterogén, lazán csatolt alrendszerek és szervezetek együttmőködése valósul meg) a fejlesztés fokozatosan, lépésenként valósítható meg a meglévı funkcionalitás folyamatos fenntartása mellett az EU követelményeire, elvárásaira figyelemmel van a változások követése, a rendszer bıvítése áttekinthetı, uralható feladat marad. Az Alkalmazásfejlesztési keretrendszer kidolgozása alprojektben az alábbi dokumentumok készülnek el: A magyar SOA alapú architektúra rendszerterve (Rterv) A magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájának specifikációja (MKA) A közigazgatási szolgáltatási sín és mőködési rendjének specifikációja (MKSZS) Fejlesztési útmutató és menetrend (Roadmap) jelen dokumentum Fejlesztési keretrendszer és komponenstár szoftver (Keret) Oktatási anyagok (Okt) Jelen dokumentum célja az elektronikus közigazgatás megvalósításására javasolt szolgáltatásorientált architektúra fejlesztésére kidolgozott módszer útmutató és menetrend (roadmap) formában történı bemutatása Az anyag felépítése A Helyzetkép c. fejezet rövid áttekintést ad a magyarországi e-közigazgatás fejlettségérıl, jelenlegi állapotáról, kitérve a vonatkozó jogszabályokra és a futó fejlesztési projektekre. A Jövıkép megadja az e-közigazgatás keretében kialakítandó szolgáltatásokkal kapcsolatos követelményeket, és az architektúra kialakításának elveit. A Fejlesztési folyamat követelményei címő rész összefoglalja a folyamattal szemben támasztott követelményeket. A következı Fontosabb útvonaltervek (roadmap-ek) áttekintése fejezet több részbıl áll. A bevezetést követıen ismertet 11, a gyakorlatban is elterjedt módszertant, kiemelten a kormányzati feladatok megvalósítására szolgáló metodológiákat, és az intézményi érettség vizsgálatára javasolt módszereket. Ezt követıen adjuk közre a magyar e-közigazgatási rendszer szolgáltatásorientált architektúrája (MKA) fejlesztésére kidolgozott javaslatainkat.

11 7. Helyzetkép 7.1. Az e-közigazgatás fejlettségi szintje Magyarországon A közigazgatás informatikai támogatottságának több szempontú, összesített értékelése alapján az ENSZ E-Government Survey 2008 [1] jelentése Magyarországot a 30. helyre teszi a világban (e-government Readiness Index). (2005-ben a 27. helyre rangsoroltak.) A részletesebb adatok elemzésébıl megállapítható, hogy a web-es jelenlét és a humán-tıke tekintetében ennél jobban állunk, míg az infrastruktúra (fıként a számítógépes ellátottság) és az állampolgárokkal tartott interaktív kapcsolat (e-participation) tekintetében kevésbé jól ban az OECD készített felmérı tanulmányt [2], amelyben a következı területeken tartja szükségesnek a magyar e-közigazgatás fejlesztését: a felhasználó-orientált fejlesztést a kormányzati ügyintézési folyamatok átszervezését az erıforrások felszabadítása érdekében az elektronikus szolgáltatásokra való építkezést az ügyfelek kiszolgálásában a kormányzati intézmények közti együttmőködés, interoperabilitás megteremtése Az e-közigazgatási rendszer jellemzıi A magyar e-közigazgatási rendszer legfontosabb alrendszere a központi elektronikus szolgáltató rendszer (KR). Emellett összességében jelentıs az önkormányzatok, és egyes szervezetek önálló szolgáltatásainak súlya is. Az E-közigazgatás 2010 stratégia [4] összefoglalja a legfontosabb jellemzıket: Az elmúlt évek hazai e-kormányzati, e-közigazgatási fejlesztései fıként az alapinfrastruktúra megteremtéséhez kötıdtek, ezen belül is a KR kiépítéséhez. A KR részeként kiépült az Elektronikus Kormányzati Gerinchálózat (EKG), a kormányzati portál, az ügyfélkapu és a Kormányzati Ügyfél-tájékoztató Központ (KÜK). A KR gerincét jelentı EKG-hoz februárra 1598 intézményi telephely kapcsolódott közel 70 ezer felhasználóval. Az EKG megteremti az interneten keresztül nyújtott kormányzati szolgáltatások elérésének hálózati hátterét. Emellett biztosítja a TESTA (az Európai Közösség saját zártkörő, IP alapú hálózata) és H-Sec-Net (minısített nemzetközi információk fogadására alkalmas hálózat) kapcsolatot. A kormányzati portál és az ügyfélkapu biztosítja az egységes kormányzati online információ- és tranzakciós szolgáltatások elérését, és a KÜK telefonon, smsen, -en és faxon keresztül is elérhetıvé teszi az ügyleírásokat, az ügyintézéshez szükséges ismereteket. Jelenleg a KR az államigazgatás (kivéve önkormányzatok) interneten bonyolított forgalmának a 95%-át bonyolítja, valamint az internet alapú állampolgári és vállalkozási információközvetítés 60%-át, és az interaktív szolgáltatások 80%-át teszi elérhetıvé. Az ügyfélkapun keresztül jelenleg 372 szolgáltatás érhetı el, ebbıl a leggyakoribb EU 20 szolgáltatás az összes államigazgatási ügyforgalom 80%-át teszi ki május 1. óta az

12 ügyfélkapu alkalmazásával mintegy 39 millió azonosítási szolgáltatást vettek igénybe, több mint 28 millió dokumentumot továbbítottak, a kormányzati portálról 352 millió oldalnyi információt töltöttek le. Az ügyfélkapun regisztráltak száma több mint 640 ezer. A virtuális okmányirodában közel 80 féle közigazgatási ügy kezdeményezhetı, köztük a legsikeresebb az okmányirodai idıpontfoglalás, melyet 2007-ben közel alkalommal vettek igénybe. A kormányzati portálon elérhetı a hatályos jogszabályok győjteménye és mintegy 800 közigazgatási ügy leírása. Az elektronikusan letölthetı, illetve kinyomtatható nyomtatványok száma meghaladja a 2000-et. 33 hazai kormányzati, 26 EU-s szervezet és 8 közszolgáltató vállalat nyújt elektronikusan elérhetı szolgáltatásokat. Az ügyfélkapu szolgáltatásai: Az ügyfél biztonságos, egyszeri azonosítása, majd összekötése az elektronikus szolgáltatást nyújtó intézmény alkalmazásaival. Az ügyfelek a rendszert magát, valamint az egyes elektronikus intézményi szolgáltatásokat böngészın keresztül érik el (kiegészítve esetleges letöltıdı alkalmazásokkal). A piacon lévı szabványos elektronikus aláíró alkalmazások fogadása. A rendszer felkészült a jövıbeni alternatív aláíró eszközök (pl. mobiltelefon) használatára, szabványos kapcsolódási felületek kialakításával. Az ügyfélkapu biztonsági alapelve: a kockázattal arányos, szükséges és elégséges mértékő biztonság garantálása. Az ügyfélkapu a szakrendszerek felé az alábbi szolgáltatásokat nyújtja [9]: Egységes be- és kijelentkeztetı ügyfél-azonosítási eljárás, tranzakciós kód ellenırzése, viszontazonosítás. A szakrendszer az ügyintézés elıtt az ügyfélkapura irányítja az ügyfelet, ahol megtörténik a beléptetése, azonosítása. A sikeres bejelentkezést követıen az Ügyfélkapu visszairányítja az ügyfelet a szakrendszerhez, paraméterként egy tranzakciós kódot adva. A szakrendszer az ügyfélkapunál a tranzakciós kóddal kéri az ügyfél nevét és címét. Ha a szakrendszer saját azonosítóval is rendelkezik (pl. TAJ), akkor azt elkérve az ügyféltıl, kérheti a saját nyilvántartásában szereplı természetes azonosítók hitelességének ellenırzését az ügyfélkaputól a viszontazonosítás keretében. Saját portállal nem rendelkezı szakrendszereknek a Kormányzati Portálon történı megjelenést támogató interfész. A Kormányzati Portálhoz a szakrendszer a Központi Rendszer Integrátorán (KRI) keresztül csatlakozik. A szakrendszer feladata az ügyintézéshez szükséges folyamatok vezérlése, az adattartalom szolgáltatása (a megjelenítést vezérlı információkkal együtt). A Kormányzati Portál elérhetıvé teszi a csatlakozó intézmény szolgáltatásait, megoldja a bejelentkeztetést, továbbá egységes megjelenítést biztosít. A felek közötti kommunikáció SOAP kérdés/válasz tranzakciókon keresztül valósítható meg. Az e-közigazgatási szolgáltatások fejlettségi szintjét az EU-ban elfogadott értékelési rendszer négy, újabban öt fokozatú skálán méri [12]. Ennek lényege a tájékoztatás, egyirányú on-line,

13 kétirányú on-line, tranzakciós kapcsolati szintek megkülönböztetése, illetve a felhasználócentrikus kiszolgálás. Ezzel összhangban van az ENSZ 2008-as jelentésében alkalmazott értékelés [1]. Fejlıdı (emerging) az e-közigazgatási szolgáltatás, ha csupán statikus, kapcsolatokat alig kínáló információkat közöl a felhasználókkal. Fejlett (enhanced), ha az információközlés bıvebb, dinamikusabb, kapcsolatokat, navigációs lehetıségeket, aktuális jelentéseket, jogszabályi tájékoztatást kínál. Interaktív (interactive), ha az ügyintézésekhez szükséges őrlapok letöltésére, ügyindításra is lehetıséget ad. Tranzakcionális (transactional), ha kétirányú, on-line, folyamatosan rendelkezésre álló (7/24) kapcsolat vehetı igénybe, beleértve az on-line fizetési lehetıségeket. Egységes (connected) a szolgáltatás, ha integrált back-office infrastruktúrára támaszkodva a felhasználó igényeihez alkalmazkodó kiszolgálást nyújt. Az E-közigazgatás 2010 stratégia [4] értékelésébıl kiolvasható, hogy az átlagos szintnek megfelelı helyünk a rangsorokban elsısorban az ügyfélkapu és a kormányzati portál által kínált szolgáltatás-elérhetıség eredménye, az egységes szint felé való továbblépés az integrált backoffice kialakítását, a technikai, szervezési és jogi kérdések együttes kezelését igényli. Sajátos, és külön említendı kérdés az önkormányzati rendszerek kérdése, a helyzetkép ezen a területen nagy változatosságot, színvonalukban is széles skálán elhelyezkedı, zömében önálló szigetrendszereket és egyedi megoldásokat mutat. Az a tény, hogy az önkormányzatok kötelezı feladatai egységesen rögzítettek, lényeges egyszerősítésekre, hatékony fejlesztésre ad lehetıséget Jogi háttér Az Európai Bizottsága i2010 egovernment cselekvési terv-e [10] szerint A tagállamok elkötelezték magukat amellett, hogy az elektronikus kormányzatra vonatkozó, a társadalmi integrációt szem elıtt tartó célkitőzések megvalósításával annak biztosítására törekedjenek, hogy 2010-re minden polgár beleértve a társadalmilag hátrányos helyzető csoportokat is az elektronikus kormányzat fontos haszonélvezıje lehessen Az elektronikus ügyintézés jogi keretei Magyarországon lényegében adottak, mert novemberében hatályba lépett, a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló évi CXL. törvény (Ket.). a Ket. az online ügyintézést egyenrangúvá tette a hagyományos ügyintézéssel, elkészültek a végrehajtási rendeletek a Ket. a Központi Elektronikus Szolgáltató Rendszert határozza meg az e-ügyintézés központi alapinfrastruktúrájaként az e-aláírás szabályozása kiegészült a közigazgatásban való használat szabályaival az e-fizetés bevezetése érdekében több jogszabály-módosítás megtörtént (pl. illeték) az elektronikus információ szabadságáról szóló törvény garantálja az ügyfelek tájékoztatását Mindemellett a jogi környezet nem ellentmondásmentes (például az adatvédelmi jogszabályok és a Ket. rendelkezéseinek gyakorlati alkalmazása tekintetében), és indokolt az elektronikus közszolgáltatásokról szóló törvény megalkotása [3].

14 A jelen alprojekt keretében kimunkálandó architektúrát érintı legfontosabb jogszabályok a következık: évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket) 182/2007. (VII.10.) Korm. rendelet a központi elektronikus szolgáltató rendszerrıl 195/2005. (IX. 22.) Korm. rendelet 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 194/2005. (IX. 22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítés-szolgáltatókra vonatkozó követelményekrıl 193/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézés részletes szabályairól 9/2005. (VII. 21.) IHM rendelet az elektronikus aláírási termékek tanúsítását végzı szervezetekrıl, illetve a kijelölésükre vonatkozó szabályokról 7/2005. (VII. 18.) IHM rendelet a digitális archiválás szabályairól, valamint az információs társadalommal összefüggı szolgáltatásokkal kapcsolatos elektronikus archiválás szabályairól évi XXXV. törvény Az elektronikus aláírásról 2/2002. (IV. 26) MeHVM irányelve a minısített elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó biztonsági követelményekrıl. 3/2005. (III. 18.) IHM rendelet az elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó részletes követelményekrıl Az ÚMFT, az ÁROP és EKOP projektek tervezése során kialakított fejlesztési koncepcióknak [4] megfelelıen folyamatban van a Ket. módosítása és vele párhuzamosan az elektronikus közszolgáltatásokról szóló törvény kidolgozása Elfogadott fejlesztési projektek Az EKOP átfogó célja a közigazgatás teljesítményének a javítása. Az operatív program magában foglalja a közigazgatás és igazságszolgáltatás mőködésének, eljárásainak, folyamatainak, szolgáltatásainak az infokommunikációs technológiát kihasználó modernizációját, továbbá az összes infokommunikációs eszközön keresztül nyújtható közszolgáltatás közös elemeként az ügyfelek azonosítását biztosító beavatkozásokat. Az átfogó célt az alábbi két specifikus cél megvalósítása szolgálja: javuljon a közigazgatási szolgáltatások eredményessége, továbbá növekedjen a mőködési hatékonyság. A célok teljesülését az alábbi indikátor méri: a lakosság és a vállalkozások közigazgatás tevékenységével kapcsolatos országos szintő elégedettségének változása a program hatására, illetve az állami szerepvállalás minısége és hatékonysága hatással van mind az üzleti környezetre, a vállalatok versenyképességére, mind pedig a lakosság életminıségére, így

15 az állami funkciók ellátásának az átalakítása segíti a lisszaboni célkitőzések megvalósítását. Az EKOP-ban az alábbi projektek indítását fogadták el: Projektgazda Projekt IRM A cégbírósági és céginformációs rendszerek korszerősítése KEKKH Jogügyletek biztonsága PMISZK Költségvetési Gazdálkodási Rendszer kiépítése Kopint-Datorg Zrt. Központi rendszer bıvítése és szolgáltatásfejlesztése PMISZK Egyablakos vámügyintézés megteremtése PMISZK Központi elektronikus fizetés megvalósítása Nemzetbiztonsági Szakszolgálat Biztonságos elektronikus összeköttetés kiépítése FÖMI Ingatlan-nyilvántartások elérhetısége Kopint-Datorg Zrt. Elektronikus Levéltár Kopint-Datorg Zrt. Közigazgatási Informatikai Közmő Elektronikus azonosítás KEKKH Elektronikus anyakönyvi ügyintézés MVH Agrártámogatások feltételeként elıírt megfeleltetési rendszer MeH EKK Interoperabilitás megvalósítása egyes nyilvántartásoknál PMISZK Családtámogatási ellátások folyósításának korszerősítése OITH Civil szervezetek nyilvántartásának modernizációja PMISZK Adóalany-centrikus adatszolgáltatási modell megvalósítása Az Államreform Operatív Program (ÁROP) célja, hogy az igazgatási rendszer teljesítményét és a nyújtott szolgáltatások színvonalát a szőkös erıforrások optimális felhasználása mellett növelje. A közigazgatás akkor képes az átfogó célhoz a legnagyobb mértékben hozzájárulni, ha eléri az alábbi specifikus célokat: javuljon a társadalmi eredmény (növekvı eredményesség); takarékosan legyenek felhasználva a rendelkezésére bocsátott, illetve a mőködése által érintett társadalmi erıforrások (optimalizált hatékonyság) javuljon a közszolgálatiság. A célok teljesülését az alábbi indikátor méri: a lakosság és a vállalkozások közigazgatás tevékenységével kapcsolatos országos szintő elégedettségének változása a program hatására, illetve növelni szükséges a közszektor termelékenységét. Ennek jegyében az ÁROP tartalmában a közfunkciók költséghatékonyabb megszervezését, pénzügyileg pedig a program keretében megvalósítandó intézkedések hosszabb távú fenntarthatóságát feltételezi. Az ÁROP keretében a közvetkezı projektek indítását fogadták el: Projektgazda Projekt MeH Közpolitikai Titkárság Dereguláció MeH EKK Elektronikus közigazgatási keretrendszer kialakítása MeH EKK E-közigazgatási Tudásportál

16 TÖOSZ Kistérségek feladatellátásának támogatása A fenti táblázatok a jelen projekt kezdetekor, 2008 elején fennálló állapotot mutatják Problémák Az E-közigazgatás 2010 stratégia [4] három fı területen lát feladatokat: Az IT fejlesztéseknek, a közigazgatási intézményeket középpontba állító hagyományos ügyintézési filozófiával ellentétben, az állampolgárok és a vállalkozások köré kell épülniük A közigazgatásnak az elosztott, integrált szolgáltatási kultúra felé kell elmozdulnia Szükséges a közigazgatási hozzáértés és tudás szélesítése és mélyítése az informatikai szolgáltatóknál Dr. Baja Ferenc kormánybiztos, a Technológiai platform és e-közigazgatás workshop-on tartott elıadásában [3] április 29-én a következı problémákat azonosította: A stratégiai irányítás és koordináció nem megfelelı háttere, hatékonysága A különbözı hivatalok ellenérdekeltsége, ellenállása A szolgáltatások nem megfelelı minısége, megbízhatósága, rendelkezésre állása A felhasználók felkészültségi hiányai, a nem kellıen ügyfélközpontú megoldások miatti elégedetlensége Az e-közigazgatási informatikai rendszerének jelenlegi mőködését tekintve az alábbi problémák vetıdnek fel: A jelentıs állami nyilvántartások mőködtetésének felelıssége szervezetileg tagolt. Saját informatikai rendszerét minden szervezet önállóan fejleszti. Különbözı szakrendszerek nyilvántartásainak összekapcsolása adatvédelmi szempontokból csak törvényi felhatalmazással, a célhoz kötöttség elvének érvényesítésével lehetséges. Ebbıl az következik, hogy a nyilvántartások adattartalmát törvények rögzítik. A törvényi felhatalmazások alapján alakítják ki az ellenırzött (naplózott) hozzáférési pontokat a felhatalmazott külsı szervezetek számára, jellegzetesen egyedi, pont-pont kapcsolatok kialakításával meglehetısen szoros csatolást okozva a szakrendszerek között. Minden jogszabály-módosítás az érintett nyilvántartás(ok), és a nyilvántartást használók oldalán is fejlesztési feladatokat generál. Bármilyen módosítás a kapcsolatok ismételt, páronkénti egyeztetését igényli. Az ügyfélkapu túl az ügyfelek beléptetésén módot ad a saját portállal nem rendelkezı szakrendszerek megjelenésére a Kormányzati Portálon. Ez szükségessé teszi az együttmőködést, ami SOAP üzenetváltásokkal történik. Az üzenetek megjelenítendı adattartalmakból és annak formájára vonatkozó információkból állnak. A központi rendszer a szakrendszerbıl nézve egy speciális utasításkészlettel rendelkezı browserként viselkedik, a kommunikáció tehát a megjelenítés szintjén zajlik.

17 Mindez nem lehet alkalmas a szakrendszerek logikai, szolgáltatás szintő, biztonságos kapcsolatának kiépítésére.

18 8. Jövıkép Az e-közigazgatás mőködésének jövıképét a következı szolgáltatásokkal jellemezhetjük. Az állampolgárok (ügyfelek) lehetıségei: Minden állampolgár, aki erre igény tart, a hatóságokkal és egyre bıvülıen a közszolgáltatást végzı szervezetetekkel és az üzleti élet szereplıivel adott élethelyzetében, felmerülı problémájának megoldására elektronikus ügyintézés keretében lehetıséget kap (elektronikus állampolgár). A szolgáltatásokat a számára legmegfelelıbb eszközökrıl (számítógép, mobiltelefon, stb.) helytıl és idıtıl függetlenül igénybe veheti. A szolgáltatások folyamatosan (7x24) rendelkezésre állnak. Rendelkezésére áll egy garantált, letagadhatatlan, biztonságos elektronikus üzenetközvetítı rendszer, amelyet a hatóságokkal és a rendszerhez csatlakozott szolgáltatókkal, üzleti szereplıkkel való hivatalos kommunikációra használhat, küldemény érkezésérıl igénye szerinti értesítést kap (pl. sms). Rendelkezik egy csak általa elérhetı, biztonságos (sérülések, adatvesztések ellen védett, titkosított) tárhellyel. Az állampolgár biztonságos azonosítására a kockázatokat elfogadható szintre mérséklı megoldások állnak rendelkezésre. Az állampolgár észszerő keretek között megválaszthatja az adott ügyhöz általa szükségesnek tartott biztonsági szintet. Az állampolgár egyetlen belépéssel (azonosítási folyamat) elintézheti az adott élethelyzethez kapcsolódó ügyeit, eközben egységes környezetben érezheti magát. Az azonosításhoz szükséges adatok kivételével nem kell olyan adatokat igazolnia, megadnia, amelyet valamely hatóság jogszabállyal rendszeresített nyilvántartásának tartalmaznia kell. A szolgáltatás igénybevételével ugyanakkor felhatalmazást ad arra, hogy az ügy elintézéséhez szükséges adatokat a hatóságok célhoz kötötten felhasználják. További szereplık lehetıségei: A közhivatalok munkatársai az állampolgárokhoz hasonló, de szerep alapú azonosítási és jogosultsági rendszerrel kezelhetı lehetıségeket használhatnak. Ügyintézési folyamataikat fejlett alkalmazások támogatják, amelyek végigvezetik ıket az ügyintézés jogszabály szerinti menetén. A rutindöntések automatizáltak, a mérlegelést igénylı döntéseket a releváns adatok ergonomikus prezentációja segíti. A rendszerhez a közigazgatás szereplıi mellett fokozatosan továbbiak is csatlakozhatnak (közszolgáltatók, egyéb, jelentıs ügyfélforgalmú üzleti szereplık). Az üzemeltetık lehetıségei: A jogszabály-változások, az új csatlakozók belépése technikailag egyszerő, könnyen végrehajtható, átlátható módosításokkal valósítható meg. A jogosultsági rendszer átlátható, jól konfigurálható, a jogszabályoknak való megfelelés könnyen igazolható

19 A rendszeradminisztráció és a felügyelet hatékony eszközökkel támogatott Az architektúra A fentiekben felsorolt funkciókhoz és elvárásokhoz szükségesnek tartjuk egy szolgáltatásorientált architektúra kialakítását. Az Alkalmazásfejlesztési keretrendszer kidolgozása alprojekt elızı munkaszakaszában közreadtuk javaslatainkat a SOA alapú architektúra rendszertervében [11]. Az anyagot a projekt minıségbiztosítója a lényeget nem érintı megjegyzésekkel kiegészítve elfogadta. A rendszerterv alapján jelen munkaszakaszban elkészítettük A magyar e- közigazgatási rendszer szolgáltatásorientált architektúrája (MKA) címő anyagot, amely az architektúra specifikációja. Jelen dokumentációban az architektúra fejlesztésére kidolgozott módszert adjuk közre. Nyilvánvaló, hogy fejlesztési módszer maga az architektúra ismeretében értelmezhetı és értékelhetı. A következı pontban röviden összefoglaljuk az architektúrát megalapozó elveket (tekinthetık magas-szintő követelménynek is), egyebekben pedig az architektúra specifikációjának ismeretét feltételezzük Az architektúra alapelvei Önálló szakrendszerek A szakrendszerek önállóan, egymástól függetlenül fejlesztett, különbözı technológiai bázison álló informatikai rendszerek. Az architektúrában fekete dobozként viselkednek, velük szemben csak kapcsolódási felületükön (interfész) írhatók elı funkcionális és nem funkcionális követelmények. Meglévı rendszerek integrálása A rendszer teljes újratervezése, zöldmezıs beruházás indítása nem reális, de nem is indokolt. A meglévı alrendszerek jelentıs értéket képviselnek, és feladataikat nagyrészt megfelelıen ellátják, így teljes cseréjük az esetek többségében nem indokolt. Laza csatolás igénye A szakrendszerek önállóságának alapelvébıl következıen olyan megoldásra kell törekednünk, amelyben a kapcsolódó alrendszerek és komponensek (itt szakrendszerek) fekete dobozként viselkednek, közöttük a függıség a lehetı legkisebbre korlátozódik. Sín topológiájú logikai kapcsolatok kialakítása. A rugalmas bıvíthetıség és a fokozatos fejlesztés igénye miatt a kapcsolódó komponensek belsı szerkezetének elrejtése mellett a kapcsolatot biztosító sín egységesítését, szigorú felügyeletét, skálázható kialakítását kell biztosítani. Az egységes sín az összekapcsolt komponensek számának növekedésekor is elkerülhetıvé teszi a páros kapcsolatok számának négyzetes növekedésébıl adódó komplexitási problémát, így a várható további csatlakozások (önkormányzat, régió, közszolgáltatók, üzleti szereplık) kezelése könnyebben uralható. Nyílt szabványok és specifikációk alkalmazása A szakrendszerekben mőködı informatikai rendszerek különbözı platformokon épülhetnek fel. Ezen heterogén rendszer elemeinek összekapcsolásához gyártófüggetlen, nyílt, lehetıleg

20 elterjedten alkalmazott szabványokon alapuló megoldásokra kell építeni. Ez a megoldás csökkenti a szállítófüggıséget, a gyártóknak való kiszolgáltatottságot, egyben biztosítja a rugalmas továbbfejleszthetıséget és a szállítói verseny lehetıségét. A folyamatos mőködés fenntartása fokozatos fejlesztés A közigazgatás biztonsága, folyamatos mőködésének fenntartása, a folyamatban levı és a korábbi ügyek elérésének igénye miatt ez az igény természetes, hiszen nem lehet tartós (1-2 napot meghaladó) közigazgatási üzemszünetet meghirdetni. Ezért az architektúra rugalmasságának a fejlesztés fokozatosságát is támogatnia kell. Biztosítani kell, hogy a meglévı egyedi szakrendszer-közi kapcsolatok együtt éljenek a sín jellegő új kapcsolatokkal, és fokozatosan legyenek azokkal kiválthatók. Helytıl és idıtıl független elérhetıség Az architektúra kialakításakor figyelemmel kell lenni a helytıl és idıtıl független elérhetıségre, a különféle eszközökkel való csatlakozás lehetıségére. Összetett szolgáltatások végrehajtásának támogatása A több szakrendszert érintı ügyintézés támogatására a szakrendszerek együttmőködését is magába foglaló, magasszintő munkafolyamat-kezelı komponenseket kell kialakítani.

21 9. A fejlesztési folyamat követelményei Az elızı pontban definiált követelményeknek megfelelı architektúrát megvalósító informatikai rendszer fejlesztési útmutatójának kidolgozásához elsıként tisztázni kell a fejlesztési folyamat jellemzı alapelveit. Az alább felsorolt elvek a megelızı két fejezetben (Helyzetkép, Jövıkép) közreadottak egyenes következményei: Szervezeti felépítés. A fejlesztés kimenetele szempontjából meghatározó jelentıségő a megfelelı szervezeti struktúra kialakítása. A szervezetnek alkalmasnak kell lenni a kormányzati célok technikai, informatikai megoldásokká történı átalakítására, illetıleg ennek az átalakításnak a levezénylésére. A 7.5 Problémák alfejezetben körülírtak következtében a szervezet felállítása, de különösen a megfelelı jogosítványok és hatáskörök kialakítása jelentıs feladatnak tőnik. Az intézmény érettsége a technológia fogadására Iteratív megközelítés. A szolgáltatás alapú architektúra (SOA) által nyújtott lehetıségek a tapasztalatok szerint egy tanulási, érési folyamaton keresztül ismerhetık meg, ahol az informatikus és a közigazgatási szakértık folyamatosan, együtt tanulják, hogy miként határozhatók meg a sikert igérı célok, a megoldás hogyan tervezhetı, implementálható, és a fejlesztés hogyan irányítható. A közigazgatás és az informatika közötti elkötelezettség. Szabályokat kell alkotni arra, hogy az ellenérdekő partnerek közötti konfliktusok miként kezelhetık, hogyan harmonizálhatók az érdekeltek céljai, elvárásai a közös siker érdekében. Irányítási keretrendszer. Az irányításnak kritikus szerepe van a szolgáltatások azonosításában, alkalmazásában és újrahasznosításában. A fejlesztési projekt irányítása esetenként az intézmény irányítási gyakorlatának felülvizsgálatát és szükség szerinti átalakítását is jelenti. Szolgáltatások granularitása. A kérdés az, hogy a szolgáltatás mekkora funkcionalitást fed le. Ha bonyolult funkciókat valósít meg a szolgáltatás, akkor az könnyen specifikus lehet, aminek kérdéses az újrahasznosíthatósága. Elemi (adatelérés) szintő szolgáltatások ismételten hasznosíthatóak ugyan, viszont belılük nehezebb építkezni. Az újrahasznosítás jelentısége. Mivel az újrahasznosíthatóság gyakran ellentmondáshoz vezet a követelmények fontosságának sorrendezésében, ezért a projekt vezetésének irányelvekben (policies) kell szabályozni, hogy az újrahasznosíthatóság milyen formában lehet jelen a specifikációban, a tervezés és a megvalósítás fázisában. A szolgáltatás életciklusának tudatosítása. Minden szolgáltatásnak van élete, amely a követelményekkel kezdıdik és a használatból való kivonással végzıdik, és sokban hasonlít a hagyományos szoftverfejlesztési ciklushoz. A szolgáltatás életciklusának menedzselése az üzemeltetés egy jelentıs problémája.

22 A szolgáltatás minısége (QoS). A közigazgatási szakemberekkel történı konzultáció alapján egyetértésre kell jutni abban, hogy a szolgáltatásoknak milyen minıségi attribútumai vannak, azok hogyan mérhetıek. Architekturális terv készítése. Ez teszi lehetıvé, hogy a különbözı aspektusok (biztonság, szervizek orkesztrációja, metaadat menedzsment, process integráció stb.) szisztematikusan egymáshoz illeszthetıek legyenek. Informatikai biztonság. A kialakítandó rendszer az intézmények információtechnológiai vagyonát (adatokat, folyamatokat) láthatóvá teszi mások számára, ami kockázattal jár. A biztonsággal kapcsolatos technikai eszközök a gyakorlatban megfelelıen mőködnek. A kockázat kezelésére vonatkozó jogszabályok rendelkezésre állnak. Informatikai, közigazgatási és adatvédelmi szakértık együttmőködésével célszerőnek látszik az adatvédelmi szabályok és megvalósíthatósági szempontok harmonizálása, szükség szerint a jogszabályok változtatásának kezdeményezése. Fejlesztıi csapatok felállítása. Az intézményekben fejlesztıkbıl, architektúra tervezıkbıl és közigazgatási, adatvédelmi szakemberekbıl álló monkacsoportokat kell felállítani. Világos siker kritériumok

23 10. Fontosabb útvonaltervek (roadmap-ek) áttekintése Bevezetés Az architektúra, az enterprise architecture vagy rövidítve EA, az architecture framework kifejezések értelmezése tekintetében még nem sikerült teljes konszenzust kialakítani a szakmában. Megítélésünk szerint ennek elsıdleges oka az, hogy a témában dolgozó különbözı cégek, fejlesztık, az általuk fejlesztett és/vagy használt eszközökben, keretrendszerekben alkalmazott terminológiából indulnak ki, amely általában szőkítı értelmő. Jelen bevezetıben adunk egy terminológiai összefoglalót [13] alapján. Tisztában vagyunk vele, hogy a szakirodalomban, a leírásokban az itt közreadottaktól eltérı értelmezést is találni. És itt mindjárt saját munkánkra is hivatkozhatunk, hiszen az anyagban röviden összefoglalunk különbözı módszertanokat, amelyek természetesen eltérı terminológiát használnak. Az "Enterprise Architecture" lehet dokumentáció, amely különbözı nézıpontokból leírja egy intézménynek és az ott alkalmazott információs rendszernek a szerkezetét és viselkedését. folyamat, amely leír egy intézményt és az ott alkalmazott információs rendszert az intézmény hatékonyságának, integritásának javítására szolgáló változások tervezési folyamata A fenti szövegben elıforduló "intézmény" szóra fordítottuk az "enterprise"-t. A különbözı módszertanok leírása során is az "intézmény"-t használtuk (esetleg még akkor is, ha ez az intézmény konkrétan a közigazgatás, vagy annak szereplıje volt). Az "enterprise" kapcsán gyakorta megjelenı fogalom a "busieness" (business strategy, business case, business modelling stb.). Az anyagban általában "üzlet"-re (üzleti stratégia, üzleti eset, üzleti modellezés stb.) fordítottuk, és értettük alatt az intézmény fı tevékenységét. A közigazgatás is tekinthetı üzletnek (tevékenységnek), amelyet a közigazgatásban szereplı hivatalok, intézmények végeznek. Sőrőn elıforduló fogalom a "policy", amelyet "eljárás"-nak, "eljárásrend"-nek, "eljárásmód"-nak, irányelv -nek fordítottunk. Az ANSI/IEEE Std a következıképp definiálja az architektúrát: Egy rendszer alapvetı felépítése, beleértve az alkotó elemeket, azoknak az egymással és a környezettel való kapcsolatát, valamint a tervezést és a kialakulást meghatározó elveket. Az architektúra leírás egy információs rendszer olyan formális modellje, amely a rendszer strukturális jellemzıivel kapcsolatos érvelést, döntéseket támogatja. A leírás megadja a rendszer általános felépítésére szolgáló építıelemeket, komponenseket, továbbá tervet ad arra, hogy miként lehet az építıelemek felhasználásával, az azok együttes mőködésén alapuló rendszert megvalósítani. Általánosabban, megalapozza az üzleti célok elérésére irányuló egész IT projekt menedzselését. Az architektúra keretrendszer különbözı architektúrák kifejlesztésének eszköze. Le kell tudni írni az információs rendszer fejlesztésének metódusát, kiindulva az építıelemekbıl, és azok egymáshoz kapcsolódásából. A keretrendszer tartalmaz az architektúra építéséhez szükséges

24 eszközöket, és közös szótárat. Ugyancsak magában foglalja az ajánlott szabványokat, és a megvalósítás során felhasznált elemek, eljárások megfelelıségére vonatkozó elıírásokat. A 9. fejezetben felsorolt követelmények lényegüket tekintve megegyeznek vagy nagyban hasonlítanak az enterprise application (EA) rendszerek fejlesztésének követelményeivel. Ezért nyilvánvaló, hogy a magyar közigazgatás informatikai korszerősítésére szolgáló rendszerek kifejlesztésének definiálásakor kiindulásként kezeljük általában az EA módszertanokat, azokon belül is a kifejezetten kormányzati rendszerek készítésének módszereit. A következıkben összefoglaljuk a hasonló követelmények kielégítésére szolgáló módszertanokat, azon belül is a kormányzati feladatok megvalósítására szolgáló metodológiákat, és az intézményi érettség vizsgálatára javasolt módszereket. Ezután kerül bemutatásra a magyar viszonyokra kidolgozott javaslatunk EA módszertanok TOGAF A TOGAF (The Open Group Architectural Framework) [14] architektúra keretrendszerként definiálja magát. A fı cél kritikus alkalmazásokat megalapozó szoftver infrastruktúra ( middleware, technical architecture ) fejlesztések támogatása, de a célcsoportba tartoznak a következı architektúra típusok is: Üzleti rendszerek architektúrái üzleti stratégiai, kormányzati, szervezeti, üzleti kulcs folyamatokra. o Az architektúra a szervezet üzleti céljának egyfajta leképezésének is tekinthetı. Az üzleti folyamatok forgatókönyvezésének (business scenarios) technikája garantálja, hogy az üzleti célok az architektúra tervezı tudomására jussanak. Egyedi alkalmazások architektúrája olyan esetekre, amikor a cél a specifikus folyamatoknak a szervezet általános központi rendszeréhez, folyamataihoz (core business processes) történı illesztése. A TOGAF által nyújtott támogatások: o Az alkalmazás használhatja a TOGAF-ban megtervezett olyan rendszer-szintő elemeket, mint a biztonság, a környezet és a rendszerfelügyelet o A központi rendszer által nyújtott alapinfrastruktúra áttervezése, testreszabása o Hatékonysági szempontok érvényesítése miatt alkalmazói programok, vagy azok kritikus részeinek beépítése a központi rendszerbe o Különbözı, heterogén, korábban egymástól függetlenül fejlesztett (legacy) rendszerek közötti információcseréhez szükséges interoperabilitás kerete. Adat architektúra alkalmas a szervezet logikai és fizikai adatvagyonának, és adatmenedzsment erıforrásainak leírására o Az IT architektúra tervezı ennek ismeretében tudja helyesen értékelni az adattárolási és -elérési követelményeket o A fejlesztés során erre figyelemmel kell megtervezni az adatok továbbítását és az erre szolgáló infrastrukturális hátteret, szolgáltatásokat.

25 A TOGAF fı részei A TOGAF ADM (Architecture Development Method) módszer, amely leírja a szervezet üzleti követelményeinek megfelelı szervezet-specifikus architektúra (EA, Enterprise Architecture) elkészítését. Az ADM o az architektúra fejlesztés megbízható, igazolhatóan helyes módszere o definiál architektúra nézeteket, amelyek alkalmassá teszik a komplex követelmények az architektúrába történı leképezését és annak megjelenítését o alkalmazását gyakorlati esettanulmányok is igazolják o iránymutatást (guidelines) ad a támogató eszköz elkészítésére Az Enterprise Continuum, amely a képzetes tárháza (virtual repository) mind a szervezetben, mind az IT technológia egészében fellelhetı azon architektúrával kapcsolatos modelleknek, mintáknak, leírási sémáknak, amelyek az architektúra kialakítása szempontjából jelentıséggel bírnak. Az ADM jellegzetes pontjain referenciák mutatnak az adott lépés, eljárás, módszer során alkalmazandó, felhasználható, az Enterprise Continuumban tárolt elemekre, mintákra. A TOGAF-ban két referencia modell is rendelkezésre áll a szervezet saját Enterprise Continuum-ának kialakításához: o A TOGAF Foundation Architecture (FA) generikus szolgáltatások és funkciók rendszere, amelyek felhasználásával specifikus architektúrák és azok elemei (Architecture Building Blocks, ABB) építhetık. A Foundation Architecture további két részbıl áll: Technical Reference Manual (TRM), generikus szolgáltatások modellje és taxonómiája. Standard Information Base (SIB), a nyitott ipari szabványok tárháza, amely szabványok felhasználható a létrehozandó architektúra és annak elemei kifejlesztése során. o Az Integrated Information Infrastructure Reference Model (III RM) a Foundation Architecture-re alapozva támogatatja a fejlesztést, különös tekintettel a Határnélküli Információfolyam (Boundaryless Information Flow) alapgondolatára. A TOGAF Resource Base, amely az ADM használatát megkönnyítı különbözı erıforrások iránymutatások, minták, háttér információk halmaza Az architektúra fejlesztési ciklus Az ADM iteratív, értve ezalatt az egész folyamatot, a fázisok közötti és azon belüli lépéseket. Az ADM mindegyik iterációjában az alábbi területekre vonatkozó döntéseket kell áttekinteni, meghozni, módosítani: o Az alkalmazás kiterjedésének a határai o A részletezettség mértéke o A mőködés idıbeli korlátai, beleértve a közbülsı idıhorizontokat is. o A testreszabott Enterprise Continuumba helyezett eszközre vonatkozóan a korábbi iterációkban készült eszközök

26 más keretrendszerekben, rendszer modellekben, ipari standardokban elérhetı eszközök A fenti döntéseket a meglevı erıforrások és kompetencia, valamint az architektúra hatáskörébe tartozó területrıl reálisan elvárható üzleti haszon gyakorlati jellegő elemzése alapján kell meghozni. Az ADM-et, mint generikus módszer, mind földrajzi, mind szakmai, üzleti értelemben széles körben, különbözı szakmai területeken alkalmazható. Ehhez nem szükségképp, de alkalmasint szükséges lehet a specifikus igények szerinti hangolása, testreszabása. Például: o A módszernek alkalmasnak kell lenni más adott területen alkalmasabbnak tartott, vagy annak látszó keretrendszerekben keletkezett anyagokkal, termékekkel történı együttmőködésre. o A módszernek alkalmazhatónak kell lenni a Zachman Framework-kel. Az ADM struktúrája az 1. ábrán látható. Az ábrán a fázisok szerepelnek, amelyek tovább bonthatók lépésekre. Az ábra középpontjában a Követelmény-menedzsment áll, és az valamennyi fázissal kapcsolatban van. A kapcsolat lényege, hogy a fázisokon és a lépéseken belül folyamatosan vizsgálni kell, hogy a javasolt szerkezet döntés konform-e a követelményekkel. Preliminary Phase: Framework and Principles (Bevezetı fázis, Keretrendszer és elvek) A fázis célja annak definiálása, hogy miként készíthetı architektúra az adott intézménynél az adott alkalmazás megvalósítására. A feladatot két nézetbıl is közelíti: egyfelıl, definiálja a keretrendszert, másfelıl kialakítja a további munka keretét képezı architektúra elveit. Felkészíti az intézményt a sikeres architektúra projektre. Phase A: Architecture Vision ( A fázis: Architektúra elképzelés) A fázisban meg kell határozni a létrehozandó alkalmazás és az architektúra határait, azaz mi van a rendszer határain kívül és belül, illetve számba kell venni a legfontosabb korlátozásokat. A fázis kiindulópontja a megrendelı fél vagy a vezetés részérıl érkezı üzleti célkitőzések és környezet megfelelıségének vizsgálata, a Statement of Architecture Work Dokumentum elkészítése. Phase B: Business Architecture ( B fázis: Üzleti architektúra) A fázis két meghatározó terméke az üzleti architektúra jelen állapotát rögzítı, és az üzleti célokat kielégítı, tervezett jövıbeni állapotot megadó dokumentum. A fázisban összehasonlítjuk az aktuális és a kívánatos állapotokat és elemezzük a kettı közötti különbséget (gap analysis) Phase C: Information Systems Architectures ( C fázis: Információs rendszer architektúrák) A feladat hasonlít az elızı fázishoz, de itt nem az üzleti architektúra leírásával foglalkozunk, hanem az azt támogató információs rendszerekével. Áttekintjük a létezı és tervezett alkalmazásokat, vizsgálva az adatkezelést, az ember-gép kapcsolatot. A fázisban figyelmen kívül hagyjuk a számítógépes és technológiai szempontokat.

27 1. ábra, az ADM szerkezete Phase D: Technology Architecture ( D fázis: Technológiai architektúra) Az absztrakciós szint csökkentése zajlik ebben a fázisban is. Mint az elızıekben, most is a meglevı és a kialakuló rendszert kell definiálni, de ez a fázis a konkrét technológiai aspektusokra fókuszál. Az elızı fázisban figyelmen kívül hagyott számítógépes és technológiai szempontok kerülnek a középpontba. Phase E: Opportunities and Solutions ( E fázis: Lehetıségek és megoldások) Kidolgozzuk a különféle implementációs alternatívákat. Phase F: Migration Planning ( F fázis: Migráció tervezés) Kiértékeljük a különbözı implementációs lehetıségek elınyeit és hátrányait. A követelmények között megadott jellemzık prioritásai alapján sorrendezzük a megoldásokat, végül kiválasztjuk a megvalósítandó architektúrát és körvonalazzuk az implementáció tervét. Phase G: Implementation Governance ( G fázis: A megvalósítás felügyelete) A megvalósítás irányítása közben folyamatosan ellenırizzük, hogy a kialakuló termék megfelel-e a korábbi fázisokban definiáltaknak, végsı soron, eleget tesz-e a követelményeknek. Phase H: Architecture Change Management ( H fázis: Architektúra változás menedzsment) A cél megegyezik a szokásos változáskezelés, változásmenedzsment projektek céljaival.

28 Az ADM adaptálása Az ADM generikus módszer, következésképp csaknem minden esetben el kell végezni annak testreszabását, a munka eredményeként létrehozzuk az intézményre specifikus ADM-et. A kialakuló specifikus ADM-et általában erısen befolyásolja két tényezıcsoport: Az üzleti folyamatok kezelésének és az architektúra rendszerek alkalmazásának érettsége az adott szervezetben, intézményben A korábban alkalmazott fejlesztési módszertan, az azt támogató eszközrendszer, valamint az adott üzleti szegmensre vonatkozó speciális ágazati szabványok, ajánlások, bevett gyakorlat Az Enterprise Continuum Az ADM leírja azt a folyamatot, amelynek során a TOGAF Foundation Architekture-bıl (FA) kiindulva eljuthatunk az intézmény-specifikus architektúrá(k)ig. A folyamatban felhasználjuk az FA és más megfelelı architektúra építı elemet, komponenst, mintát. Az ADM jellemzı pontjaiban emlékeztetı hivatkozások vannak az Enterprise Continuumnak az ADM adott pontjához kapcsolható építıelemre. Ezek a hivatkozások mutathatnak magára az FA-ra, de más architektúra referencia modellekre is, amelyeket például az alkalmazás szakterületén ajánlásként vagy szabványként kezelnek. Az intézmény-specifikus Enterprise Continuum felépítéséhez két referencia modellt szolgáltat a TOGAF. TOGAF Foundation Architekture generikus szolgáltatások és funkciók rendszere, amelyek felhasználásával specifikus architektúrák és azok elemei (Architecture Building Blocks, ABBs) építhetık. Az Enterprise Continuum kifejezés a következı két komplementer fogalom kombinációját is jelöli. Az Architecture Continuum (AC) egy konzisztens definícióját adja az információs rendszerekre jellemzı generikus szabályoknak, reprezentációknak és kapcsolatoknak. Megadja a kapcsolatokat az alapvetı keretrendszerek (mint pl. a TOGAF), közös rendszer architektúrák (pl. III-RM) és szakmai, ágazati és céges architektúrák között. Az AC hasznos eszköz a különbözı architektúrák közötti különbözıségek felismerésére és a redundanciák kiküszöbölésére. A Solution Continuum (SC) egységesen leírja és magyarázza az AC megvalósítását, implementálását. Az SC definiálja a szervezet, intézmény által elérhetı, újrahasznosítható építıelemeket, a Solution Building Blocks (SBBs)-okat. A solution elnevezés arra utal, hogy az SC valójában az ügyfelek és az üzleti partnerek közötti megegyezés, megoldás leképezései, amelyek az architekturális térben definiált szabályok és kapcsolatok megvalósulásai.

29 Zachman Framework A Zachman Framework [15] egy 6*6-os mátrix elrendezés (2. ábra), amelynek csomópontjaiban egy dolog különbözı vonatkozásait leíró reprezentációk állnak. Maga a dolog tetszıleges bonyolult szerkezet (például egy építmény, repülıgép, intézmény, multinacionális vállalat, a világ egészére kiterjedı számítógépes alkalmazás, mint például a repülıjegy foglalás, de akár a közigazgatás is) lehet. A mátrix elrendezést két, évszázadok óta használt, ortogonális osztályozási rendszer határozza meg. Az egyik kategorizálás a bonyolult fogalmak, rendszerek felbontása (dekomponálása) céljából alkalmazható hat primitív kérdésre (mi, hogyan, hol, ki, mikor, miért) adható válaszok általános felépítését veszi alapul. A mi vagy mit kérdésre adott válaszok alapján felvázolhatjuk az összetett dolog statikus szerkezetét, belsı felépítését. A hogyan-nal a dolog illetve az azt alkotó (a mi-vel felderített) elemek mőködése, funkciója, tevékenysége elemezhetı. A hol kérdéssel a dolog illetve az elemek fizikai, telepítési helyére vonatkozóan győjthetünk ismereteket. A ki kérdésre adott válaszok mutatnak rá arra, hogy a dologgal kapcsolatosan milyen emberi szerepek (használó, közremőködı, mőködtetı, kiszolgáló, stb.) fordulnak elı, ezek a szerepek hogyan kapcsolódnak egymáshoz, és a dologhoz, annak elemeihez. A mikor a történések, tevékenységek, dolgok, elemek idıbeliségére fókuszál. A miért-tel a szereplık motivációjára kérdezünk.

30 2. ábra, a Zachman Framwork (

31 Ugyanezt a kategorizálást definiálhatjuk az egyes kategóriákra jellemzı döntésekhez kapcsolódó domináns fogalmakkal és strukturáló objektumokkal. Ezek, a hat primitív kérdés sorrendjében az alábbiak: leltár, folyamat, hálózat, szervezet, idızítés, motiváció. A mátrix komponálásához felhasznált másik kategorizálás a reifikációnak (egy elvont fogalom dologgá alakulása, to reify is simply to turn an idea into a res (a thing)) már a görög filozófusok által posztulált mozzanatain alapul: azonosítás, definiálás, reprezentálás, specifikálás, konfigurálás, példányosítás. A mátrixon szokásosan elfogadott peremezés lehet még a felsorolt mozzanatoknak a reifikáció terjedelmére (hatáskör, üzlet, rendszer, technológia, komponens, mőködés), és a mozzanatokhoz kapcsolható jellemzı szereplıkre (stratéga, igazgató, architektúra tervezı, mérnök, technikus, munkás) történı kivetítése. A mátrix egy-egy celláját a két osztályozási rendszer alapján a strukturáló objektum és a mozzanat nevének összerakásából származó névvel látjuk el. Például: folyamat-specifikálás, hálózat-azonosítás, vagy leltár-példányosítás. Minden cellához tartozik egy leírási módszer, technika, bevett diagram, őrlap. Például: a leltár-definíció leírására szolgálnak az üzleti szintő entirás-relációs diagramok, vagy az idızítés-specifikáció eszköze a technológiai szintő idı-, vagy ütemezési diagram. Mivel a tapasztalatok szerint a keretrendszerben szereplı reprezentációkkal jellemezhetı valamennyi bonyolult rendszer, ezért többen evidenciának tekintik, hogy a Zachman Framework az Enterprise Architektúrák alapvetı struktúrája, azaz a keretrendszerben szereplı reprezentációk megfelelıek az Enterprise Architektúrák leírására is. A Zachman Framework egy ontológia. Egy dolog lényeges komponenseit magában foglaló strukturált szerkezetek létezésének elmélete, amely szükséges, talán nélkülözhetetlen ahhoz, hogy maga a dolog (esetünkben az Enterprise Architektúra) létrehozható, mőködtethetı, változtatható legyen. A Zachman Framework nem módszertan. A mátrixból az olvasható ki, hogy a dolog létrehozása, változtatása érdekében milyen szerkezeteket kell létrehozni, de arról, hogy ezeket a szerkezeteket milyen sorrendben kell elkészíteni, a keretrendszerben nincs információ. A módszertannak azt kellene megadni, hogy milyen lépésekbıl áll (milyen szerkezeteket kell elkészíteni) a létesítési, implementációs folyamat. Az ontológiára támaszkodó fejlesztési folyamat várhatóan megismételhetı, kiszámítható eredményt ad (például kémiában a periódusos rendszer). Megfordítva, az ontológiát nélkülözı folyamat eredménye véletlenszerő, általában nem megismételhetı, esetleges, a kimenet elıre át nem látható és mérhetı komponensek hatásától függ (például az alkímiai folyamatok, aranycsinálás). A Zachman Framework egy metamodell, és a módszertantól eltérıen a következı kérdésekre nem ad választ: Mikor érdemes architektúrát építeni és mikor elegendı egy egyszerő alkalmazás implementálása? Azaz, milyen feladatok esetében célszerő a Zachman Framework által definiált szerkezet részben vagy egészben történı bejárása, az ott megjelent leírások elkészítése, és mikor megfelelı az ad-hoc kódimplementáció, esetleg egy primitív modellezési fázist követıen? Milyen architekturális stílust érdemes használni (pl. top-down vagy bottom-up)? A keretrendszer bejárását melyik mezıbıl érdemes indítani? Milyen legyen a rövid és hosszútávra szóló mérnöki tevékenység aránya? Azaz, milyen komponensek esetében célszerő az újrahasznosítással járó többletmunkát vállalni bízva a más alkalmazásokban történı újrahasznosítás során felmutatható nyereségekben, és mikor kell a célok kielégítésére direkt megoldásokat alkalmazni? Mennyire legyen flexibilis az implementációs modell az architekturális modellhez képest? Mivel az alkalmazás elkészítése során szükségképp fentrıl lefelé járhatóak be

32 a keretrendszer egyes cellái, a kérdés úgy is feltehetı, hogy egy oszlopon belül egy sorral lejjebb lépve milyen mértékő korlátozást érdemes bevezetni? A Zachman Framework az architektúra alapja. Az ipari termékek (repülıgépek, számítógépek, stb.) estében ma már tisztán látjuk az architektúra szerepét. A bonyolultság kezelése, az összetett feladatok egyszerőre való visszavezetése standardizálható alapelemeket és összeköttetéseket teremtett. Hasonló folyamatok zajlanak ma az informatikában, ahol a globális alkalmazások szabványos, újrahasznosítható megoldásokat követelnek. Többek véleménye szerint a Zachman Framework alkalmas keret lehet az architektúra elemeinek kimunkálására, rendezésére Gartner EA Process Model A Gartner EA Process Model-je Enterprise Application (EA) [16] fejlesztésére kidolgozott módszer. Alapja egy többfázisú, iteratív, nemlineáris modell, amelynek fókuszában az EA fejlesztés, az evolúció és migráció, az irányítás, szervezés és menedzsment alfolyamatok állnak. Magába ötvözi a sikeres EA folyamatok legfıbb jellegzetességeit, és tanulságait, a legjobb mérnöki gyakorlatot. Az 1996-ban kidolgozott elsı változatot kiegészítették a Gartner kutatásainak eredményeivel, és megjelentek a technikai vonatkozásokra koncentráló folyamatmodellel ben kezdıdött meg a technikai aspektusokon túlmutató teljeskörő, mára a 2005-ös változatával jelenlevı EA modell kidolgozása. Az elkövetkezı néhány évben a Gartner EA Process Model jelentısebb változására nem kell számítani. A Gartner EA Process Modell-jének természetes kiegészítıje a Gartner EA Framework, amely megteremti az üzleti, az információs, és technikai architektúra közötti kapcsolatot, belılük szintetizálva az Enterprise Solution Architecture-t (ESA). Ugyanakkor a Gartner EA Process Model-je nagyon értékes komponensnek bizonyult más keretrendszerekben. Az EA Process Model alapja a más hasonló modellekben is alkalmazott fı ciklus, amelynek elemei a jelenlegi és a jövıbeni architektúra megjelenítése, kiegészítve a kettı közötti rés (gap) analízisével, továbbá az analízis eredményére és ajánlásokra építı portfólió menedzsmenttel. A Gartner EA Process Model célja áthidalni a stratégiai tervezés és az implementáció közötti szakadékot. Ehhez elengedhetetlen, hogy a folyamat az intézményt, szervezetet a teljes szélességében lefedje, az üzleti stratégiától a technológiai vonatkozásokig. A következıkben sorra vesszük a 3. ábrán szereplı komponenseket.

33 3. ábra, Gartner EA Process Model Environmental Trends (környezeti trendek) Az intézmény dinamikusan változó környezetben mőködik, amely környezet fontosabb összetevıje a gazdasági klíma, a piaci helyzet, szabályozók és jog, a földrajzi elrendezés, a politikai feltételek, kultúra, technológia. Ezeknek az elemeknek az állapota, de még inkább a trendje befolyásolja az intézmény üzleti stratégiáját, azon keresztül a fejlesztéseket, beszerzéseket és az EA-t is. A felsorolt összetevık a technológia kivételével a stratégiai és taktikai üzleti tervezéseken keresztül gyakorol hatást az EA-ra. A technológia, mint környezeti tényezı viszont az üzleti aspektusokon kívül, közvetlenül befolyásolja az EA-t. A technológiai trendeket ismétlıdıen célszerően évente elemezni kell, és a IT és üzleti vezetıket tájékoztatni kell a trendek okozta várható kihívásokról. Business Strategy (Üzleti stratégia) Ha van az intézménynek üzleti stratégiai terve, akkor kell lennie egy mechanizmusnak, amely a stratégia céljait implementálja a szervezetben, intézményben. A Gartner nézete szerint ez a mechanizmus maga az EA. Gyakran a szervezet, intézmény elıtt álló legnagyobb kihívás nem is az üzleti stratégia elkészítése, hanem a megjelenítése és érvényesítése azoknak a változásoknak, amelyek a stratégiát az intézmény alacsonyabb szintjein implementálják. Ha a vezetés elkötelezett egy üzleti vízió mellett, akkor a döntéseket az egész intézményben megfelelıen kell kommunikálni, hogy a mértékadó személyek és csoportok egységesen felzárkózzanak a közös célok mentén. Fontos megjegyezni, hogy egyfelıl az EA függvénye az intézményi üzleti stratégiának, másfelıl befolyásolja azt, azon keresztül, hogy egyre érettebb modellekkel szolgál az üzleti tervezéshez. Az EA az üzleti stratégiának alakítója, hiszen a precízebb üzleti modelleken túlmenıen elkészíti és közreadja az intézmény információs és technológiai architektúráját, megkönnyítve ezáltal az üzleti forgatókönyvek és hatáselemzések készítését. Organize Architecture Effort (Architektúra szervezés) A komponens speciális szerepet játszik az EA projektben. Kétségtelen, hogy a projekt indítása jelentıs szervezımunkát igényel, de a szervezıi feladatok az egész projekt során fontosak maradnak. Ezért a komponens részfeladatait folytonosan ismételni kell a projekt menetében.

34 Az EA fejlesztéshez kapcsolódóan megjelenı tipikus Architektúra szervezıi tevékenységek: o Az EA projekt, az aktuális és a következı iteráció hatókörének felülvizsgálata, az enterprise fogalom értelmezése, o A projektben érdekelt vezetık együttmőködésének koordinálása, o Az EA vezetı és az architektúra tervezı kiválasztása, o Az EA csapat kialakítása és menedzselésük, o A szervezet felkészültségének és az EA érettségnek a mérése o A projekttel kapcsolatos külsı és belsı kommunikáció szervezése, végrehajtása, o A vezetési technikák és mechanizmusok elterjesztésének és alkalmazásának tervezése, o A sikertényezık (indikátorok) meghatározása, mérési módszereinek kidolgozása, o A fejlesztési ciklusokban az indikátorok mérése, értékelése, az eredmények kommunikálása. A mérések célja az elırehaladás, az üzleti célok megközelítésének, és az EA csapat hatékonyságának mérése. Future-State Architecture (Cél-architektúra) A komponens célja az üzleti stratégia leképezése egy jövıben üzleti és IT architektúrára. Az elkészült anyagok követelmények, elvek, és modellek formájában jelennek meg. Az elvek a magas szintő döntésekhez adnak iránymutatást, a modellek pedig a részletekre vonatkozó alacsonyabb szintő döntések támogatásának környezetét definiálják. o Követelmények kidolgozása A tapasztalatok szerint az EA fejlesztést üzlet-vezérelt (business-driven) alapon érdemes folytatni. Következésképp a fejlesztés az üzleti követelmények különbözı architekturális szempontok szerinti azonosításával kezdıdik. Mivel az üzleti célokra hivatkozó követelményekbıl lehetetlen egy lépésben leszármaztatni a technikai architektúrára érvényes követelményeket, ezért az EA fejlesztı csapatnak az üzleti stratégiai célokból, illetıleg a kapcsolatos követelményekbıl elıször az üzleti informatika architektúrájára vonatkozó követelményeket kell kidolgozni és csak ezen alapulva a technikai architektúra elıírásait. o Elvek kidolgozása Elvek alatt azokat a szabályokat, irányelveket, policy-ket, iparági és intézményi szabványokat, ajánlásokat értjük, amelyeket a különbözı szintő vezetıi döntésekben érvényesíteni kell az üzleti célok legális elérhetısége érdekében. A gyakorlat szerint ebben a munkafázisban is iterálni kell. o Modell kifejlesztése A megcélzott architektúra modelljének kialakítása a követelmények és elvek kidolgozása függvényében, iteratívan történik. A modell részletezettségének, specificitásának nem szabad meghaladnia a követelmények és elvek hasonló tulajdonságait. Elsıként üzleti stratégiai, majd üzleti informatikai, végül pedig a technikai architektúra modellje készül el. Míg az elvek, követelmények, szabványok és ajánlások stabilnak (kvázi-állandónak) tekinthetık, addig a modellek dinamikus szerkezetek. A modellek célja, hatásköre, az általuk lefedett jellemzık, viselkedés folyamatosan változik a fejlesztés elırehaladása során. A modellnek meghatározó szerepe van a gap-elemzés elıkészítésében, megalapozásában. Current-State Architecture Documenting (Jelenlegi architektúra dokumentálás) Az intézmény aktuális architektúrájának ismerete, dokumentálása nélkülözhetetlen a célarchitektúra definiálása és a gap-elemzés elvégezhetısége miatt. A jelen állapot dokumentálásának célja o alapvonal definiálása, amelyhez az elérendı célállapot hasonlítható,

35 o a diszfunkciók, az ismétlıdések, a bonyolult részek és az összefüggések felismerésének elısegítése, o olyan dokumentációhalmaz létrehozása, amely alkalmas a fejlesztés során meghozott döntések hátteréül szolgálni. Általános szabálynak tőnik, hogy célszerő a megcélzott architektúrát elıbb definiálni, mint a jelenlegit. Ugyanis az elérendı állapottal kapcsolatos kezdeményezések, befektetések iránymutatásként szolgálnak a jelenlegi architektúra felméréséhez, dokumentálásához. A célrendszerrel szemben támasztott követelmények, elvek és technológiai elvárások jelenítik meg az alkalmazható technológiai termékek és szabványok kiértékelésének szempontjait. A jelenlegi architektúrának a célrendszer architektúrája szempontjából történı vizsgálata segítséget ad az alkalmazásokkal, infrastruktúrával és szabványokkal kapcsolatos következı kérdések megválaszolásában: o Támogatja-e a jövıbeni rendszer IT követelményeit? o A jelenlegi és jövıbeni pozíciók megfelelnek-e a technológiai és piaci trendeknek? o Megfelel-e a tervezési elveknek? Ha sikerül definiálni, hogy a célrendszertıl elvárt IT követelmények kielégítésére mennyiben nem alkalmas a jelenlegi technikai infrastruktúra, akkor megtaláltuk a gap -et. Closing the Gap (A gap zárása) A gap elemzésének célja azonosítani a jelenlegi és jövıbeni rendszerek specifikációi közötti különbséget. Az elemzés a jelen és jövıbeni architektúrák modelljének fogalmaival operál. Az elemzést az összes architekturális szempontból el kell végezni. Sikeres munkához, érdemi ajánlások megtételéhez a következı bemenı anyagokra mindenképp szükség van: o Az üzleti stratégiai víziókból az üzleti megoldásokkal szemben támasztott követelmények o Az architektúrákkal kapcsolatos elvek o A cél architektúra specifikációja o A cél architektúra modellek és termékek o A jelenleg architektúrát leíró dokumentációk Az elemzı munka lépései: o A gap -ek azonosítása és osztályozása a jelen és jövı architektúrája közötti kulturális, strukturális, funkcionális különbségek felmérése és csoportosítása o A gap -ek elemzése a felismert különbségek megértése, vizsgálata o Ajánlások készítése Akciók, tevékenységek a különbségek eltüntetésére. Különbözı forgatókönyvek készítése. o A különféle ajánlások rendezése, válogatása az egyes javaslatok közötti különbségek, elınyök, hátrányok vizsgálata Governing and Management (Irányítás és menedzsment) Az irányítás és menedzsment kiterjed az egész fejlesztési folyamatra és a szervezeti struktúrára, beleértve az irányítási és döntési jogosultságokat. A fontosabb aspektusok: o Az EA termékek készítésének irányítása A termékekkel szemben tartalmi, elvi és formai követelményeket kell állítani, amelyek betartatása, ellenırzése, felülvizsgálata céljából a megfelelı jogosítványokkal ellátott szervezetet célszerő kialakítani. Gartner az Architecture Review Board (ARB) felállítását javasolja.

36 o Dokumentumtár menedzsment o Projekt/beszerzés menedzsment o Minıségirányítás A projektmenedzsmentnek csak egyik oldala a projekt normál vitelével és a beszerzésekkel kapcsolatos döntések meghozatala és azoknak megfelelı levezénylése. Egy másik, jelentıs vonatkozása az EA megfelelıségének (minıségének) folyamatos ellenırzése és az eltérések felderítése. Módszereket kell kidolgozni és alkalmazni az eltérések esetén alkalmazott eljárások menetére, a döntési és végrehajtási rendszerre vonatkozólag. A Gartner EA Process Model-jével kapcsolatosan tett értékelı megjegyzések közül az egyik úgy szól, hogy a Gartner szerint az architektúra szó nem fınév, hanem ige. Amelyik jelenti azt a folyamatot tevékenységet, gyártást, karbantartást, amely egy enterprise architektúrát életre kelt, életben tart. Gartner úgy látja, hogy az architektúra kulcsa a három fıszereplı (üzleti érdekelt, IT szakértı, technológiai megvalósító) egy asztalhoz ültetése, és közöttük az üzleti vízióban rögzített értékek alapján egység kialakítása. A siker mérıszáma pragmatikus üzleti jellemzı (profit, megtérülés, stb.), nem pedig a követelmény mátrix és indikátor táblák kitöltögetése. A módszertan arra koncentrál, hogy a szervezet merre megy, nem pedig arra, hogy hol van. Ha ki akarjuk takarítani a házat, akkor annak nem a legokosabb módja, hogy hibátlan leltárat készítünk a kidobni szándékolt dolgokról. Helyette bölcsebb a végeredményre figyelnünk. Ha tudatosul a cél, akkor láthatjuk meg, hogy a jelen helyzet miként viszonyul ahhoz. A módszertan azt ajánlja, hogy mondjuk el, mik a stratégiai célok, melyek az elérni kívánt üzleti célok. Mindehhez használjuk köznapi nyelvet, dobjuk ki a dokumentációs szabványok, techno-zsargon táblázatok nagy részét. Az egyetlen cél az üzleti vízió mögötti egységes demonstratív felsorakozás. Az EA a Gartner szempontjából a stratégiáról szól, nem a technológiáról. A két legfontosabb megválaszolandó kérdés: a szervezet merre tart és hogyan lehet a célba jutni. Minden egyéb másodlagos Practical Guide to Federal Service Oriented Architecture (PGFSOA) A módszertan [17] nagy kiterjedéső SOA rendszerek megvalósítására fókuszáló projektek számára az irányok és célok meghatározása, a lényeges tényezık, munkaterületek azonosítása, és a fontos lépések definiálása tárgyában tesz ajánlásokat. Az elsı lépés annak vizsgálata, hogy a SOA mennyiben járul hozzá az intézmény üzleti stratégiájának megvalósulásához A módszertan fı lépései: A SOA bevezetésére készülı intézmény számára felállít egy SOA érettségi modellt a technológia befogadására való alkalmasságát, felkészültségét mérendı. Egy alapos érettségi vizsgálaton vezet végig abból a célból, hogy meghatározzuk az intézményben a SOA bevezetésével kapcsolatos tényezık érettségi szintjét. Ez figyelembe veszi az irányítás, a szolgáltatásokkal való ellátottság, a technológiai környezet állapotát, a vezetés elkötelezettségét és jövıképét, a munkatársak felkészültségét és képességeit. Az érettségi felülvizsgálat eredményeinek fényében kiértékeli a meglevı szervezetirányítási, és a kapcsolódó intézményekkel, szervezetekkel folytatott együttmőködési

37 folyamatokat, és meghatározza a szolgáltatás orientáltság bevezetéséhez szükséges kiigazításokat. Egyes kiválasztott területeken, az érettségi modell és az elérendı célok alapján meghatározott súlyponti szolgáltatások azonosításával megkezdi a SOA megvalósítást. Az intézményi szintő bevezetésre definiál egy inkrementális megközelítést, amellyel sőrőn megjelenı, apró, de jól érzékelhetı eredmények érhetık el, és a fejlesztési módszer közben tökéletesíthetı. Az alábbi ábrán a SOA áttérési (adoptálási) folyamatnak az áttekintı képe látható. 4. ábra, a SOA adoptálási folyamat A SOA roadmap egy stratégia, amely az intézmény, vállalat igényeibıl, elképzeléseibıl indul ki a kialakítandó architektúra kialakítása érdekében célokat definiál a SOA implementáció bevett, legjobb gyakorlatára épít A SOA roadmap elemei a szolgáltatási keretrendszer nézıpontjából ábrázolva

38 Szolgáltatás Orientált Vállalkozás (Service Oriented Enterprise) 1. Kezdeményezı A menedzsment világos jövıképbıl (vízióból) kiindulva irányítási alapelveket és folyamatokat dolgoz ki, megalapozza a stratégiát, az alkalmazott megközelítéseket 2. Szervezett a szervezeti rendhez illeszkedı felelısségek rendszerét alakítja ki 3. Együttmőködı a stratégiák, a tervezés megalapozza a résztvevık közös fejlesztését és a szolgáltatások újrahasznosítását Szolgáltatás Orientált Architektúra (Service Oriented Architecture) 1. Keretrendszeren alapul a SOA keretrendszer és szabványosított folyamatok teszik lehetıvé az interoperábilis, megbízható, irányítható, felügyelhetı folyamatokat és infrastruktúrát 2. A szolgáltatások életciklusának menedzsmentje eszközökkel támogatott egységes referencia-architektúra és platform áll rendelkezésre a szolgáltatások életciklusának felügyeletére Szolgáltatás Orientált Infrastruktúra (Service Oriented Infrastructure) Integrált run-time futtató rendszer és környezet, kiegészítve hatásos menedzsment és felügyeleti eszközökkel A roadmap sikerének tényezıi Jól definiált és elfogadott elvek arra vonatkozóan, hogy mikor és hol kerüljön sor a SOA alkalmazására Mérnöki szemléletmód (pl. újrahasznosíthatóság, modularitás, összeépíthetıség) a szolgáltatások kialakításánál Megerısített kommunikáció a munkacsapatok között Közvetlen visszacsatolás az aktuális üzleti folyamatokból a rendszertervezésbe Megfelelı pénzügyi támogatás az üzleti folyamatok megújítására, megváltoztatására Mértékek, amelyek alkalmasak a modularitás és az összeépíthetıség miatti extra erıbefektetések valóságos megtérülésének mérésére Megalapozott lépések és támogatások a SOA-hoz illeszkedı irányítási elvek, eljárások és mechanizmusok bevezetésére és alkalmazására Világos és egyértelmő támogatás az IT és üzleti vezetés részérıl A roadmap középpontjában álló területek A közös szolgáltatások azonosítása és leírása o Tökéletesíteni kell a szolgáltatások azonosításával, definiálásával, fejlesztésével, implementálásával és mőködtetésével kapcsolatos eljárásokat, azaz az üzleti folyamatok menedzsmentjét és az üzleti felügyeletet

39 o Ki kell alakítani az intézmény szolgáltatási portfóliójának menedzsmentjét és fejlesztését o A projektben érdekeltek körében tökéletesíteni kell a szolgáltatás azonosításával és menedzsmentjével kapcsolatos koordinációt o A szolgáltatások életciklusának támogatását meg kell oldani. A projekt irányító testületet érdekeltté kell tenni o a szolgáltatások fejlesztésének, integrálásának, tesztelésének, telepítésének és kivezetésének menedzselésében és felügyeletében o az EA gyakorlati tapasztalatok, a használati esetek, architekturális minták és elvek, valamint az életciklust támogató rendszerek kiterjesztésével és módosításával kapcsolatos tapasztalatok összegyőjtésében o a szolgáltatásmenedzsment szerepek és felelısségek meghatározására és elosztására o kommunikációs és képzési tervek készítésében és megvalósításában o a szervezeteken, intézményeken átívelı szolgáltatások fejlesztésére és mőködtetésére szolgáló támogató folyamatok áttekintésére és tökéletesítésére Szolgáltatás infrastruktúra, integrációs platform és eszközök o A SOA fejlesztı, tesztelı, integráló és futtató rendszerek kialakítása és üzemben tartása o A szolgáltatás szintő megállapodások (SLA) és irányítási elvek hétköznapi alkalmazására és felügyeletére szolgáló eszközök felderítése és üzembe állítása o SOA környezet kialakítása és üzemben tartása o A SOA-val kapcsolatos termékek elhelyezésére, elérésére megfelelı tárház kialakítása, a termékek, erıforrások életciklusának menedzselésére szolgáló irányelvek és támogató rendszerek létrehozása és fenntartása o Alapvetı SOA menedzsment komponensek megvalósítása és az infrastruktúrába integrálása A SOA-érettség szintjei A SOA érettségi modell jellemzıket határoz meg a SOA bevezetésével és gyakorlatával kapcsolatosan. IT tanácsadók és eszközgyártók különbözı érettségi modellekkel jelentek meg. Jelen modell nem kívánja kritizálni az egyéb modelleket, ellenkezıleg az érettségi modellek alkalmazása és fontossága mellett érvel, javasolja az intézmény számára leginkább alkalmasnak tőnı modell kiválasztását és használatát. A modellek általában négy vagy öt egymással kapcsolódó szintet határoznak meg, amelyek a SOA-ra történı átállás fogalmainak részleges megértésétıl kezdve a szolgáltatások köré épített üzleti modellezésig terjednek. Jelen leírás egy generikus érettségi modellt javasol arra, hogy a szervezet elhelyezze saját magát. A modell publikus információk alapján öt szintet definiál: Betanulás, Alkalmazás, Adaptálás, Optimalizálás, Szövetkezés. Minden egyes szintet úgy definiál, hogy ugyanazon hat kulcs-tényezı jellemzıit adja meg. Az intézménynél végrehajtott felmérések alapján meg kell határozni a kulcs-tényezık intézményi jellegzetességeit, majd azokat össze kell hasonlítani az egyes szinteknél megadottakkal. Túl az intézmény érettségi besorolásán, a táblázatból kiolvasható, hogy az intézménynek mit kell

40 tenni helyzetének elıre mozdítása érdekében, és egyben a roadmap kialakítására is támogatás ad. Initiative Management Organization Collaboration [ EARLY LEARNING ] Funding is primarily directed to individual projects. Either individual application architects or the Chief Architect sponsors SOA. Application projects are generally focused on their own deliverables; limited cross-project collaboration. Architectural Process and Alignment Services Lifecycle Management Services Infrastructure Architecture is fragmented and exploratory. Architecture frameworks are ad hoc; no mature enterprise approach. Services are mostly not identified. If services are identified, they are not managed in a cross-project, enterprise manner. Limited services infrastructure; primarily supports individual Proofs-of Concept; possible project Enterprise Services Bus. [ APPLICATION ] Initiative Management Organization Collaboration Architectural Process and Alignment Services Lifecycle Management Services Infrastructure Services are identified and managed as an IT architecture concept. SOA is generally a project level responsibility and is found consistently in most appropriate projects. Service delivery and usage governance, process and practices are incorporated into projects and projects collaborate to share services. Management recognizes the need for a collaborative DT&E process. Project architectures are service oriented; no enterprise level service orientation within the enterprise architecture. There are consistent project level architectures; no overall enterprise level SOA reference architecture. Services are available for individual projects to use and leverage. There is an Enterprise Service Bus Proof of Concept; some projects beginning to use common services and sharable services.

41 [ ADOPTION ] Initiative Management Organization Collaboration Architectural Process and Alignment Services Lifecycle Management Services Infrastructure Funding processes specifically support the development, implementation and use of shared services; governance processes are in place to manage services effectively. There is a single organizational entity responsible for integration and processes in place to facilitate integration. Project processes and governance are built around identifying and incorporating shared assets. Some projects are beginning to perform collaborative DT&E. SOA is employed as a component of EA. There are standards in place for rich service specification and use. There is an enterprise level SOA reference architecture and implementation processes in place; they are governed at the enterprise level. There is an enterprise level services repository that provides consistent lifecycle governance of run-time service assets. There is an enterprise level ESB that is mandatory for project use; common enterprise services are available, well governed, and can be found and used. [ OPTIMIZATION ] Initiative Management Organization Collaboration Architectural Process and Alignment Services Lifecycle Management Services Services are managed effectively as enterprise business assets. Governance processes for managing services are mature, applied consistently across the organization. Services are owned by business units but managed as enterprise business assets. There are processes in place for service quality management that are understood and used by individual projects. Collaborative DT&E occurs regularly across internal projects. Internal agency EA goals and objectives are realized. The agency has an enterprise services portfolio plan and uses it to identify, develop, and use service assets as a fundamental way of doing business. There are agreed-to and managed business processes and business architectures for business collaboration. Services are managed within a service-oriented enterprise architecture as shared federated assets. The enterprise registry and repository provides design and runtime service asset lifecycle governance and asset dependency analysis. There exists a common framework and tools for enterprise management of

42 Infrastructure services, and security services facilitate inter and intra business collaboration. [ FEDERATION ] Initiative Management Organization Collaboration Architectural Process and Alignment Services Lifecycle Management Services Infrastructure Services facilitate inter and intra business collaboration. Services are defined and managed within an inter-business, collaborative basis. Collaborating parties within the SOA relationship operate and act as service provider and consumer. Collaborative DT&E occurs seamlessly and virtually across multiple agencies. EA goals and objectives are realized across multiple agencies. There are agreed business processes and data architectures for integration and business collaboration. A complete, agreed SOA reference architecture exists and is used to manage key collaboration points. Ecosystem registries provide governance structures and processes over collaborative business processes. Services are managed as enterprise sharable but federated assets. Structures, tools and processes are in place at the infrastructure level to facilitate this SOA csapat felállítása A projekt sikere szempontjából meghatározó egy olyan szakemberekbıl álló csapat létrehozása, amelynek tagjai elkötelezettek a változtatás és az azzal járó folyamatok mellett, de a megfelelı szakmai kompetenciával is rendelkeznek. A tagoknak rendelkezni kell vezetıi és mérnöki készségekkel, szakmai (üzleti, igazgatási) ismeretekkel, valamit az alábbi területek valamelyikén komoly szakértelemmel: változás kezelés, biztonság, agilis módszertanok, modellezés és szimuláció, üzleti folyamatok elemzés (business process analysis). A csapat akkor lesz sikeres, ha rendelkezik a felsı vezetés feltétel nélküli támogatásával, képes a projekt céljait jól kommunikálni mind az intézményen belül, mind azon kívül. Egy ilyen csapat képes az új integrációs technikák bevezetésére, a megfelelı szabványok és követelmények kiválasztására, és a SOA irányítási modell kidolgozására. Általában a legjobb megközelítés egy pilot elkészítése, amely világosan igazolja az elképzelések helyességét és üzleti értékét.

43 SOA Roadmap modell A SOA érettségi modell alapján az intézmény kidolgozza a saját útitervét az elérendı célok felé. Az An Example SOA Implementation Roadmap Based on Maturity Phase táblázat segítséget nyújt az érettségi modelltıl függı elırelépés és útiterv kidolgozására. Az 5. ábrán összegezzük egy képzelt intézményben definiált célok elérése érdekében a hivatkozott táblázat szerint szükséges tevékenységeket. 5. ábra, SOA implementációs példa

44 An Example SOA Implementation Roadmap Based on Maturity Phase TIMELINE : Phase 1 Phase 2 Phase 3 Phase 4 MATURITY PHASE : Scope of SOA Adoption Early Learning Application Adoption Project-Centric, Opportunistic Strategic, Business Segment Wide Enterprise Wide Optimization/ Federation Business Transformation Timeframe 0-6 months 6-12 months months 18 months to indefinite Key SOA Implementation Processes *Secure executive support for SOA pilot Create rudimentary collaborative DT&E environment Establish a core SOA Team Establish incentives for collaborative SOA governance Lay out scope, objectives and governance for SOA pilot. Re: o Business Engagement o SOA Design Patterns. o Basic integration platform & middleware. o SOA Standards. o Service level o metrics. Business improvement * Document tangible performance improvements based on SOA pilot. Extend collaborative DT&E environment to active and critical candidate projects. Extend common services discovery scope to include: o Individual project o analysis, Critical support of business domain requests, and legacy systems analysis. Execute analysis to fulfill business and IT strategies for initial portfolio assessment Develop and implement services funding and pricing models for a few services. *Extend service level metrics to encompass all projects using enterprise services. Utilize full scope of SOA design patterns across all candidate projects. Services funding and pricing models are in use for all enterprise services and tied to SLAs. Full portfolio of services is developed and used to identify key SOA initiatives. Engage in enterprisewide analysis to accelerate SOA benefits. Service level metrics in place for all projects tied to performance and business agility. SOA executive dashboard providing realtime performance results of service level metrics. *Identify mechanisms and processes to consolidate and optimize services. Continuously evaluate alternative approaches to allow adaptation and evolution. As the industry matures, evaluate and adopt/adapt alternative approaches, Federated services discovery, run-time policy governance and performance monitoring are in place and drive service delivery. Service level performance is provided real-time to program managers who use it to perform business process innovation Standards based business systems are composed rapidly to react to

45 goals. Extend scope and depth services available to project developers including security, data sharing, and run-time integration services. Core SOA team propose candidate enterprise services. Core SOA team identifies touch-points and approach to align IT strategies Identify key commodity services that support multiple lines of business. Identify customized services that support core business areas. Project engagement process documented and provided to projects at onset of engagement. Define strategic planning services identification process Extend service level metrics Implement pilot service performance dashboard. SOA enables top-down EA analysis Identify cross lines of business and cross agency integration opportunities Create SLAs between mutual services providers and mutual lines of business for shared services. Establish run-time SOA governance across lines of business Identify common services through: process for bottom-up discovery. Strategic planning with business partners. Implement run time discovery processes. business performance requirements. Development and operating environment are fully service oriented. Cross domain collaborative incentives are clear and collaborative process for mutual investment and engineering are seamless Collaborative DT&E environment is, continuous, seamless, virtual, and ad hoc.

46 BEA SOA Roadmap A BEA iteratív, inkrementális módszert [18], [19] javasol az intézmény SOA-ra történı átállításához. A SOA roadmap az alábbi három kritikus tényezıvel jellemezhet: 1. Érettség Az útvonal egy élı dokumentum -nak tekinthetı, amelyben folytonosan tükrözıdnek az addig megszerzett tapasztalatok. Ahogy az áttérési folyamat halad elıre, várható úgy nı az intézmény felkészültsége, képessége a SOA kezdemény vezénylésére. A SOA roadmap kialakításának elsı lépéseként (majd rendszeresen a projekt folyamán) felül kell vizsgálni az intézmény felkészültségét, érettségét a SOA megvalósítására. Ehhez a BEA technikai támogatást is ad a BEA's Online Self-Assessment Tool-jával. 2. Kiterjedés A SOA roadmap-nak ki kell terjednie az alábbi ábrán szereplı 6 területre (domain). A területek csak látszólag különállóak, valójában egymáshoz kapcsolódnak és függenek egymástól. Valamennyi terület lefedése része a SOA sikeres bevezetésének. A roadmap-ban világos látszódnia kell a SOA bevezetés határainak, és egy átlátható és rugalmas idıtervet kell adnia a SOA-tól remélt célok elérésére. Ezen céloknak megfelelıen irányítási fázisokat kell létrehozni, amelyek ismétlıdıen, folyamatosan épülnek egymásra. 3. Minıség Mivel a létrejövı rendszer minıségét alapvetıen az azt létrehozó folyamat határozza meg, a SOA áttérési folyamatban az érdekeltek bevonásával rendszeresen felülvizsgálatot kell tartani, és ezzel kell visszacsatolni a folyamatra. 6. ábra, a BEA Domain model

47 A BEA Roadmap fázisai: 1. SOA vízió A fázisban megtörténik a SOA kezdeményezés definiálása és megszervezése. Az érdekeltek az üzleti célokon túl, meghatározzák azok prioritásait is. Különös jelentısége van a különbözı területrıl (üzlet, IT, jog, programozás) érkezı szakemberek közötti együttmőködésnek, ezért kiemelt cél a megbízható és jó kommunikáció. A SOA kiterjedésének definiálása Más IT rendszerekkel való határok és kapcsolatok meghatározása Esettanulmányokkal és kísérletekkel kell igazolni a SOA gazdasági jelentıségét A jelen és jövıbeli üzleti folyamatok elemzése 2. SOA érettség vizsgálata A fázisban elsıként mértékeket kell meghatározni a jelen helyzet jellemzésére. Ez kiterjed a SOA megvalósítás szempontjából ígéretesnek tőnı szolgáltatások és képességek felmérésére, valamint a jelölt üzleti folyamatok értékelésére. Interjú és kérdıíves adatgyőjtési technikákat alkalmazva kell validálni a felmérés eredményét. A BEA Domain modell szerinti csoportosításban a következıket kell megvizsgálni: Üzleti stratégia és folyamat (Business Strategy and Process): Áttekintı kép az intézmény üzleti stratégiájáról és fontosabb folyamatairól. Architektúra (Architecture): A fennálló architektúrák, eljárás- és ügyrendek, szabványok áttekintése. Költségek és hasznok (Cost and Benefits): A költségek és bevételek (hasznok) összevetése intézményi és nagyobb egység szinten. Építıelemek (Building Blocks): A meglevı szolgáltatások, folyamatok, eszközök, technológiák elemzése. Projektek és alkalmazások (Projects and Applications): A meglevı rendszerek felmérése, beleértve a futó és tervezett projekteket. Szervezetek és irányítás (Organization and Governance): Az aktuális intézményi struktúra és irányítási rendszerek, eljárások, módszerek összefoglalása. 3. A SOA bevezetése utáni helyzet Mőhelymunka keretében definiálni kell, hogy a SOA átállást követıen miként mőködik majd az intézmény Üzleti stratégia és folyamat (Business Strategy and Process): Vizsgálni kell, hogy az elvárt mőködés egybeesik-e az intézmény üzleti stratégiájával. Architektúra (Architecture): A létrehozandó architektúrára vonatkozó követelmények megfogalmazása, a kapcsolatos alapvetések rögzítése, az új eljárásrendek, szabványok, ajánlások és referenciák definiálása. Költségek és hasznok (Cost and Benefits): Mértékekre és mérésekre vonatkozó követelmények állítása.

48 Építıelemek (Building Blocks): Az elosztott szolgáltatások megvalósításához tartozó infrastruktúrával szembeni elvárások, korlátozások meghatározása, a figyelembe vehetı eszköztámogatás áttekintés. Projektek és alkalmazások (Projects and Applications): A SOA szolgáltatások és a projektek, alkalmazások összevetése. Szervezetek és irányítás (Organization and Governance): A kívánatos intézményi felépítés és eljárásrend. 4. SOA roadmap definíció Az intézmény SOA céljai és stratégiája, kiegészítve a bevezetés ütemezésével valamint az elızı három fázisban győjtött anyagok és tapasztalatok alapján el kell végezni gap-elemzést. Az elemzés alapján meg kell határozni a szükséges lépéseket (az idıben közeli eseményeket, pontosabban, a késıbbieket csak nagy vonalakban). Üzleti stratégia és folyamat (Business Strategy and Process): Az üzleti lehetıségek, alternatívák hangolása, finomítása Architektúra (Architecture): Rövid, közepes és hosszú távú architektúra kiépítési terv elkészítése Költségek és hasznok (Cost and Benefits): A mértékek és mérések bevezetésével kapcsolatos különbözı idıtávra szóló munkaterv kialakítása Építıelemek (Building Blocks): Az elosztott szolgáltatások megvalósítása eszközkészletének elemzése alapján prioritási lista felállítása Projektek és alkalmazások (Projects and Applications): A SOA szolgáltatások és a projektek, alkalmazások ütköztetése, a megfelelıek választása. Szervezetek és irányítás (Organization and Governance): A javasolt intézményi felépítés és eljárásrend. A kialakuló roadmap nem egy statikus szerkezet, hanem egy élı dokumentum, amelyikbe folytonosan be kell emelni az útvonalon történı elırehaladás közben szerzett tapasztalatokat, tanulságokat. Az elırehaladás során a SOA kezdeményezés egyre kiterjedtebb, alaposabb és bonyolultabb lesz. Az iterációt jeleníti meg a 7. ábra.

49 7. ábra, SOA Learn and Adapt Roadmap ZapThink s SOA Roadmap ZapThing szerint [20],[21],[22] a SOA és web szolgáltatások (WS) közötti különbség lényege: a SOA egy szoftver architektúra, míg a WS csak egy szabványhalmaz a SOA megvalósítására. Egy SOA alkalmazás fejlesztéséhez tartozó út elején meg kell találni az üzleti szempontból legérzékenyebb pontokat. Legegyszerőbben ezekhez a pontokhoz a következı vagy hasonló kérdések megválaszolásán keresztül juthatunk el: A meglevı rendszerben elzárt adatokhoz mennyire bonyolult hozzáférni? Az alkalmazás igényli olyan adatokhoz történı hozzáférést, amelyeknek a forrása különbözı, régen telepített elosztott relációs adatbázisokban van? Szükséges a legfontosabb teljesítmény-mutatók (KPI, Key Performance Indicator) világos és áttekinthetı, egyértelmő megjelenítése? Az intézmény által felügyelet folyamatok újraszervezése szükséges? Az intézmény számára hasznos, az értékes adatvagyonának ismételt és sokirányú újrahasznosítása? Egy SOA rendszer implementálása inkrementális és iteratív folyamat, amelyhez kellı szerénységgel érdemes közelíteni. Az IT projektek szokásos természete szerint a projekt az architekturális terv és a irányítási keretrendszer elsı változatával kezdıdik, amelyen teszteket végeznek és prototípus rendszert építenek abból a célból, hogy a fejlesztık megtanulják az eszközkészlet és a komponensek használatát, valamint lemérhessék az intézmény felkészültségét a SOA bevezetésére. A specifikusabb kérdések: Üzleti, szakmai érettség: Az intézményben megfogalmazhatók azok az üzleti követelmények amelyek megvalósításában a SOA szerepet játszik? HA igen, akkor az

50 intézmény, annak érintett egységei, tagjai hogyan viszonyulnak a szükséges változtatásokhoz? IT infrastruktúra érettsége: Milyen informatikai (adat, folyamat, stb.) elemeket tud az IT felvonultatni az üzleti célú szolgáltatások kielégítésére? IT szervezeti felkészültség: Az IT csapatnak megvan a megfelelı felkészültsége, gyakorlata, eszközei a SOA implementálására, vagy megvannak azok a partnerek, akik ezekkel a készségekkel rendelkeznek? A SOA megvalósítást az egymástól elkülönült rendszerekben (silók!) megtalálható alkalmazással kapcsolatos IT vagyon (adatok, folyamatok) felmérésével érdemes kezdeni. A SOA alkalmazása során győjtött tapasztalatok alapján meg lehet tanulni, miként lehet a silókon átnyúló hasznos üzleti szolgáltatásokat kialakítani, és folyamatosan tökéletesíteni addig, amíg a szolgáltatások valódi üzleti sikerekhez vezetnek. A megfelelı irányítási rendszer hiányában a SOA implementálás is egy újabb nem kellıen megalapozott fejlesztési projekthez vezethet. A következmények általában nem kellıen használható és újrahasználható szolgáltatásokhoz vezetnek. Hasonlóképp, ha az intézmény megfelelı biztonságpolitika híján nem rendelkezik megbízható és egységes azonosító, hitelesítı rendszerrel, a feltörés és illetéktelen behatolás veszélye jelentısen megnı. Következésképp, megfelelı irányítás szükséges új ügyfelek új módon történı kiszolgálását biztosítandó, úgy hogy az konform legyen (maradjon) a biztonságra és az adatvédelemre vonatkozó policy-val. Nem meglepetés, hogy az üzembe állított szolgáltatások számának növekedésével az alábbi kérdések is felmerülnek: Hogyan azonosíthatóak a létezı szolgáltatások, és a szolgáltatásoknak kik a felhasználói Hogyan állapítható meg, hogy melyik felhasználó melyik szolgáltatás melyik verzióját használhatja? Mi a módja egy új szolgáltatás új változata bevezetésének? Hogyan kell dokumentálni egy szolgáltatást, és az hogyan hozható nyilvánosságra? Hogyan lehet kiválasztani a megfelelı SOA eszközt? Hogyan támogatja a technológia architektúra és az eljárásrend a szolgáltatások életciklusát, beleérte a szolgáltatások létrehozását, tesztelését, osztályozását, a hozzáférés menedzselését, a módosítást és a használatból történı kivonást? A kiinduló pont pilot A SOA megvalósítást egy pilot projekttel célszerő indítani, amelyben az intézménynek alkalma van egy szisztematikusan felülvizsgálni a következı idıszakra vonatkozó elképzeléseit, üzleti terveit, céljait. Sok olyan cél van, amelynek elérésére egy intézmény pilot projektet indíthat, egyebek között az alábbiak: a SOA intézményi elfogadtatása, eddig áttörhetetlen látszó architekturális és szolgáltatás modellezési korlátok lerombolása, az intézmény IT csapatának szakmai felfejlesztése, a SOA fejlesztési módszertanok bevezetése, begyakorlása, a piacon elérhetı SOA termékek alkalmazhatóságának vizsgálata.

51 A pilot a legjobb módszer arra, hogy egy új architektúra bevezetésével kapcsolatos kockázatot lecsökkentsük. A pilot valóságos üzleti célú feladat megoldására irányul, de a megoldásnak költséghatékonynak kell lenni. Noha a szolgáltatás üzleti jellegő, a valóságos és elsıdleges cél nem a teljes funkcionalitás, hanem az architektúra alkalmazhatóságának igazolása. Közvetkezésképp a pilot funkcióját érdemes korlátozni egy a gyakorlatban önállóan megálló egyszerő funkcióhalmazra, amely integrálja a meglevı alkalmazások néhány komponensét és példát mutat a modernizálásra. Mindez azt jelenti, hogy a web szolgáltatások számának növelés helyett az architektúra alkalmazhatóságára kell fókuszálni. Ez a következıket is jelenti: Meg kell találni azokat a kulcsembereket, akik a SOA-val kapcsolatos szakértelemmel rendelkeznek. A megfelelı ismeretek és eszközök korai azonosítása és megszerzése létfontosságú. Architektúra terv specifikálása. A SOA egy enterprise architecture, amely egy átfogó magas szintő terv arra, hogy az üzleti folyamatokat miként hatja át az IT. Pontosabban, a SOA-nak támogatni kell az IT-t abban, hogy az intézmény felkészülhessen a jelenleg még nem is látható jövıbeni változásokra. Ebbıl a szempontból a SOA pilot által megvalósítandó szolgáltatást az intézményben tervbe vett funkciók közül érdemes kiválasztani. A folyamat hatásköre. A SOA megvalósítás együtt jár a megfelelı szolgáltatás kiválasztásával. A fenti szempontokon túlmenıen célszerő mások funkciók, ügyfelek által használt szolgáltatást választani. A kockázat csökkentése. A pilotnak nem lehet célja az óceán felforralása. Olyan folyamatot, folyamatokat kell választani, amelyben mind a kockázat, mind a hatáskör korlátozott. Nem szabad olyat választani, ami sikertelenség esetén üzleti veszteséget okoz. Iteratív módszertan. Mind a funkció, mind az implementációs eszköz tekintetében érdes egy szélesebb körben kezdeni a kiválasztást, amit iteratíven fokozatosan lehet szőkíteni. Legyen világos a siker. Egyértelmően definiálni kell, hogy mikor tekintjük sikeresnek a pilot projektet Az éles SOA áttérés elıkészítése A pilot sikerébıl kiindulva létrehozzuk az architektúrát a SOA kiterjesztésére az üzleti folyamatok jelentıs részére. Elsıként a pilot eredményét kell nagyon alaposan átvizsgálni és reálisan összegezni a tanultakat, különös tekintettel arra, hogy mennyire sikeres volt a szolgáltatások kiválasztása, megfelelı-e a teljesítmény, a szolgáltatások újrahasznosíthatóak-e, a SOA bevezetése valóban a feltételezett üzleti hasznokkal jár-e. A tapasztalatok alapján meghozandó döntés: valóban szükséges-e a SOA bevezetése? A ZapThing a következı forgatókönyveket ajánlja a SOA bevezetésre: Pragmatikus irányítás: A SOA irányítás kezdeményezéskor az IT a SOA bevezetésére vonatkozó policy-k prioritását a kockázat/haszon arány alapján álltja be. Például kezdetben a prioritási sorrendben az elsı biztonság, majd azt követi az újrahasznosíthatóság és a minıség. Pragmatikus újrahasznosítás: Bár sokan úgy gondolják, hogy a SOA természetes velejárója az újrahasznosíthatóság, valód eredményt ebben elérni nem könnyő. A

52 hatékony újrahasznosítás precíz projektirányítást igényel, és annak átlátását, hogy az újrahasznosíthatóság felismeréséhez tapasztalat kell. Fontos, hogy az elvárások megfeleljenek a realitásoknak. A meglevı rendszer elfogadása: Alapvetı annak áttekintése, hogy az üzleti folyamatok IT támogatása a valóságban mennyire igényli a SOA által nyújtott rugalmasságot, agilitást. Egy lehetıség, hogy a meglevı alkalmazások maradnak használatban, csak néhány, speciális területen kerül sor a SOA alkalmazására, ott, ahol a bevezetésének és alkalmazásának valóságos költségei megtérülnek. Pragmatikus felhasználói felhatalmazás: A legambiciózusabb SOA cél az, ha a felhasználó számára lehetıvé tesszük, hogy az intézmény (és egyéb külsı szolgáltatók) rendszere által nyújtott szolgáltatásokra saját maga építsen folyamatokat az intézmény IT csapatának közremőködése nélkül. Ma még inkább az ilyen típusú rendszerek alapszolgáltatásainak (böngészı, őrlapkezelı, kártyás fizetés, SMS küldés, fogadás stb.) kiépítése és szabványosítása folyik, de néhány területen találhatunk sikerrel kecsegtetı megoldást. Magyarországon például ilyennek tekinthetık a biztosítási ügynökök által nyújtott biztosításkötési (kgfb, casco, utazási, lakásbiztosítás) szolgáltatások, amelyek egy részben a mögöttes biztosítók által nyújtott szolgáltatásokra épülnek A SOA Roadmap kimunkálása A munkát az intézmény céljából kiindulva kell végezni. A konkrét célok halmazába tartozhatnak olyanok, mint az újrahasznosíthatóság, vagy az integráció erısítése, a folyamatok tisztítása, az üzleti partnerek integrálása, vagy egyszerően a költségek csökkentése. Kezdve a pont-pont kapcsolatokon alapuló integrációval, a szervezet kifejlıdhet odáig, hogy dinamikusan csatolt flexibilis szolgáltatásokkal kihasználja a SOA elınyeit. Ebben a pontban különösen fontossá válik a menedzsment szerepe, akkor, ha túl az izolált diszkrét kapcsolatokon, kialakul az a környezet, amiben a fejlesztés hajtómotorja a szolgáltatási szerzıdés lesz. Így a szolgáltatások komponálhatókká válnak. A ma sikernek tekinthetı végállapotban a kritikus folyamatok intézményen belül és azok között is optimalizáltak. Az intézmény abba a ciklusba kerül, amelyikben az üzleti folyamatok modellje kialakítható a meglevı szolgáltatások összekombinálásából, módosításából, adaptálásából, anélkül, hogy a hagyományos fejlesztési folyamaton keresztül kellene mennie. A tipikus SOA adaptációs folyamatot egyszerősített változatában a 8 ábra mutatja be, amelynek egy kibıvített változata a 9. ábrán látható.

53 8. ábra, ZapThing SOA áttérés A SOA metodológia kulcselemei: Iteratív megközelítés. Mint az fentebb már említettük, a SOA kiteljesítése egy tanulási, érési folyamatban történhet meg, ahol az IT és az üzleti csapatok folyamatosan tanulják, hogy miként határozhatók meg az ígéretes célok, és a megoldás hogy tervezhetı, implementálható, és ez a munka hogyan irányítható. Az IT és az üzlet közötti elkötelezettség. Szabályokat kell alkotni arra, hogy miként harmonizálhatók az érdekeltek céljai, elvárásai a közös siker érdekében. Irányítási keretrendszer. Hangsúlyozzuk az irányítás kritikus szerepét a szolgáltatások azonosításában, alkalmazásában és újrahasznosításában. A SOA irányítás valójában az intézmény irányítási gyakorlatának felülvizsgálatát és szükség szerinti átalakítását is jelenti. Szolgáltatások azonosítása. Ennek a pontnak az egyik legfontosabb kérdése a szolgáltatások granularitása, azaz, hogy a szolgáltatás mekkora funkcionalitást fed le. Ha a szolgáltatások túlzottan elemiek, akkor az kevéssé hasznos, azt az esetet kivéve, ha mások az egyszerő szolgáltatásokból építkezve ajánlanak ki összetett szolgáltatásokat. Fordítva, ha bonyolult funkciókat valósít meg a szolgáltatása, akkor az könnyen specifikus lehet, aminek kérdéses, vagy lehetetlen az újrahasznosíthatósága.

54 9. ábra, ZapThing SOA roadmap

55 Szolgáltatás fejlesztése újrahasznosítás alapján. Mivel az újrahasznosíthatóság költségcsökkentı hatása miatt általában magas prioritású cél, a szolgáltatások gyakran a közös nevezı szerepére kárhoztatnak. Ennek elkerülés érdekében az intézménynek irányelvekben (policies) kell szabályozni, hogy az újrahasznosíthatóság milyen formában lehet jelen a specifikációban, a tervezés és a megvalósítás fázisában. A szolgáltatás életciklusának tudatosítása. Minden szolgáltatásnak van élete, amely a követelményekkel kezdıdik és a használatból való kivonással végzıdik, és sokban hasonlít a hagyományos lineáris szoftverfejlesztési ciklushoz. A szolgáltatásnak van minısége (QoS). Az üzleti oldallal való konzultáció alapján meg kell határozni, hogy a szolgáltatásnak milyen minıségi attribútumai vannak, azok hogyan mérhetıek. Architekturális terv készítése. Ez teszi lehetıvé, hogy a különbözı aspektusok (biztonság, szerviz orkesztráció, metaadat menedzsment, process integráció stb.) szisztematikusan egymáshoz illeszthetı legyen. Kockázat kezelése. Más IT projektekhez hasonlóan a kockázat kezelése a SOA projekteknél is fontos. A SOA az intézmény IT vagyonát (adatokat, folyamatokat) láthatóvá tesz mások számára, ami kockázattal jár. A kockázat kezelés a szolgáltatást használók azonosításának, hitelesítésének, felhatalmazásának tervezésével, az üzenetek integritásának és letagadhatatlanságának biztosításával kezdıdik, majd kiteljesedik a tartalmi biztonság, precizitás, valamit a megbízhatóság témakörével, és átfogja a szolgáltatás teljes életciklusát SOA csapat kialakítása Az indulás elıtt biztosítani kell a csapatba a megfelelı embereket. A jó fejlesztıkön kívül szükség van erıs architektúra tervezıkre, akik definiálják és alkalmazzák a SOA-val kapcsolatos ajánlásokat és szabványokat. Az ajánlások és szabványok átfogják a szolgáltatás granularitásától kezdve a WS szabványokig az összes fontosabb területet. A csapatba fel kell venni az üzleti folyamatokhoz értı elemzıket, akik tisztában vannak az üzleti folyamatokkal, könnyedén együtt tudnak mőködni az üzleti terület szakértıivel, és a fejlesztıi csapat számára korrekten képviselik az üzleti követelményeket. A fejlesztıkbıl, architektúra tervezıkbıl és üzleti elemzıkbıl álló csapattal elvégezhetı a SOA adaptáció úgy, hogy a valóságos üzleti érdekeket és célokat nem hagyjuk figyelmen kívül A SOA útvonal megválasztása Mivel a SOA egy új módja az intézményben meglevı IT-vagyon (adatok, folyamatok) menedzselésének, telepítésének, felhasználásának, és támogatja új típusú felhasználások készítését, ezért meghatározó jelentıségő a SOA roadmap megválasztása az említett IT-vagyon kezelése szempontjából. A következıkben bemutatunk néhány tipikus megközelítést: Meglevı adatvagyon modernizálása és integrálása Becslések szerint a világon fellelhetı adatvagyon több, mint 70 százaléka elavult, önmagukat túlélt rendszerekben található. Ezek az alig használható adatok értéke jelentısen megnövelhetı

56 lenne. A SOA bevezetésével az eredeti üzleti alkalmazás akadályozása nélkül, többé-kevésbé automatikusan elıállítható csomagoló szolgáltatásokat készíthetünk, amelyek a felhasználó elıl elfedik az adat kezelésének idejét múlt mechanizmusait, egyben csökkentik az adatokat felhasználó alkalmazásoknak a régi elavult technológiától való függését. Több forrásból származó adatok kombinálása Ebben az esetben a cél különbözı helyekre települt adatvagyon egységes nézetben történı megjelenítése. Az üzleti szemantikát alapul véve az adatok köré kifelé egységes szolgáltatásként megjelenı lekérdezéseket készítünk, amelyeket magasabb szintő adatbányászati, megjelenítési alkalmazásokkal összefogva alkothatunk konszolidált képet az egyébként inhomogén szerkezető adatokról. Üzleti folyamatok ésszerősítése és integrálása Ennek lényege, hogy a szolgáltatások olyan készletét valósítjuk meg, amelynek elemeibıl magasabb szintő szolgáltatások rakhatók össze. A SOA lehetıségei megengedik, hogy új folyamatokat komponáljunk dinamikusan vezényelt elektronikus részfolyamatokból és emberek által végrehajtott munkafázisokból. Tipikus példa erre valamely szolgáltatások brókerelése. A szolgáltató az ügyfél által megadott prioritási lista alapján sorrendezi az ı beszállítói által nyújtott szolgáltatások eredményeit, és ezt felkínálja az ügyfélnek. Az kiválasztja a számára legkedvezıbb ajánlatot, és a bróker közremőködésével létrejön az ügylet a felhasználó és a végsı szolgáltató között, mellesleg esetleg egy bank közremőködésével megtörténik a fizetés. A fizetés megvalósításába bekapcsolódik egy mobil szolgáltató is, aki gondoskodik az SMS továbbításáról. Absztrakt építıelemek A SOA lehetıvé teszi, hogy a elvonatkoztassunk a meglevı rendszerekben silózott adatokból és folyamatokból, helyette a szolgáltatások olyan absztrakt szerkezetét építsük fel, amelybıl a létrehozni kívánt üzleti szolgáltatás leszármaztatható. Ilyen lehet: o Alkalmazás kompozíció. Megfelelı eszköz segítségével meglevı szolgáltatások konfigurálásával, paraméterezésével mőködési idıben testreszabott szolgáltatások gyors létrehozása. Például vehetjük az Excel olyan módon történı kiterjesztését, ahol az egyes cellákhoz az interneten keresztül elérhetı tetszıleges szolgáltatás eredményét rendeljük. o Business Process Management (BPM). Megmaradva a hagyományos alkalmazási silóknál, a fejlesztık és üzleti elemzık a BPM megoldásokkal üzleti folyamatokat állíthatnak össze és menedzselnek a teljes életcikluson keresztül. o Információ integrálás. Különbözı, elosztott adatbázisokból származó adatok egységesen kereshetı képének létrehozása. o Ránk maradt (legacy) rendszerek integrálása. A mainframe gépeken futó alkalmazások felújítása, szolgáltatási interfészek és korszerő API kialakítása. o Szolgáltatások orkesztrálása. A SOA lehetıségeinek kihasználásával, a pontpont kapcsolatok elvetésével szolgáltatások komponálása.

57 Accenture roadmap 10. ábra, Accenture 4 fázisú SOA roadmap Az Accenture [23]roadmap-ja a 10. ábrán látható. Más módszertanokkal összevetve ezt a javaslatot, az alábbiakat állapíthatjuk meg: A javaslat egy iterációs modellt takar, ahol a második fázisban egy pre-pilot alkalmazás készül web-szolgáltatás alapon, a harmadik fázisban már üzleti célokat megvalósító, SOA eszközökkel fejlesztett szolgáltatásokat vezet be, a negyedik fázisban pedig intézmények közötti professzionális szolgáltatásokat realizál. A módszertan inkább a SOA technológiai aspektusokra fókuszál, kevésbé veszi figyelembe a menedzsment és együttmőködési szempontokat A fázisokat idıben is skálázza. A fejlett, ipari jellegő szolgáltatások megjelenését és üzemelését az indulástól számított 3-4. évre helyezi. Az Accenture a sikert az alábbi tényezıkben látja: Szolgáltatás és folyamat alapú gondolkodás A fejlesztés és megvalósítás során szolgáltatás definíciókban és folyamatokban kell gondolkodni, nem pedig a funkcionalitásra koncentrálni. A folyamatokat úgy kell meghatározni, hogy azok kifelé a változatok széles skáláját nyújtsák, befelé pedig egyszerősítsék a rendszert. o Átfogó intézményes szolgáltatások

58 Szabványok és ajánlások szükségesek ahhoz, hogy az intézményben mit tekintenek szolgáltatásnak, a szolgáltatás különbözı változatainak. o E2E folyamattervezés Az etom (enhanced Telecom Operations Map) ajánlástól a kezelı által testreszabott folyamatokig mindenütt alkalmazni kell az end-to-end szemléletet o Differenciált kifelé, egyszerő befelé A SOA alapú teljes körő szolgáltatások és folyamatok célja egyrészt a külsı felhasználók felé azok igénye és képessége szerint differenciált szolgáltatások nyújtása, másrészt a kötséghatékonyság szempontjainak eleget tevı egyszerő technológia megoldások szállítása. Egységes technológia A SOA implementálás szükséges feltétele az architekturális szabványokon és az interoperabilitáson alapuló egységes platform (sín, busz). Az egyes komponensek csak akkor kapcsolódhatnak a platformhoz, ha az adatszerkezetek egységesek. o Platform Az operációs rendszertıl az alkalmazásig tartó technológiai stack-et az egyes eszközöket beszállítóktól függetlennek kell tervezni o Architektúra szabványok és interoperabilitás Az elızı pontban említett követelmény kielégítése során törekedni kell az egyre szélesebb körben megjelenı és alkalmazott szabványok használatára. o Adat architektúra A csatlakozó régi technológia csak akkor integrálható, ha sikerül egységes szemantikailag is interoperábilis adatszerkezeteket létrehozni. o Folyamatos alkalmazkodás A SOA elvek implementálása során követni kell az infrastruktúra fejlesztésével kapcsolatos projektek folyamatosan képzıdı eredményeit, és lehetıség szerint hamar alkalmazásba venni azokat. Naprakész szolgáltatások A szolgáltatásoknak követniük kell az üzlet valóságos folyamatainak folyamatos változásait, azaz a szolgáltatásoknak megvan a saját életciklusuk. Az életciklus kezelésére megfelelı eljárások, eszközök, tesztelés és minıség-ellenırzés szükséges. o Folyamatok életciklusa A roadmap-nek fokozott figyelmet kell fordítani a folyamatok létrehozására és karbantartására, a szükséges támogató eszközök alkalmazására o Tesztelés és minıségbiztosítás A SOA tesztelési folyamatnak különösen nagy jelentıséget kölcsönöz az E2E szemlélet, amely a szokásos tesztelési lépések kiegészítését vonja maga után. o Biztonság Az egyedi biztonsági megoldások helyébe a teljes körő biztonság lép, amely egy önálló aspektusként áthatja fejlesztés és a megvalósítás egészét. Felkészült irányítás

59 Az üzleti és technológiai folyamatokban végrehajtandó változtatások végrehajtatására megfelelı szervezet és személyzet szükségeltetik. Mind a vezetési struktúra, mind a vezetık felkészültsége javítandó. o Elosztott rendszerek A SOA alapon együttmőködı rendszerek jelentıs programok elosztott megvalósítását és telepítését jelentik, aminek elıfeltétele a szakemberek közötti együttmőködés o A szervezetek felkészülése Az egyes résztvevı szervezeteknek alkalmasnak kell lenni a helyi rendszerek átalakítására, hangolására, a SOA megoldáshoz való csatlakozásra, technikai és szervezeti szempontból egyaránt o Változások támogatása A közremőködıknek aktívan részt kell venni az új SOA paradigmára történı áttéréssel kapcsolatos tanulásban, oktatásban.

60 10.3. Közigazgatási roadmap-ek Federal Enterprise Architecture (FEA) - USA A FEA [24],[25],[26],[27] az amerikai szövetségi kormányzat legutóbbi kísérlete a rengeteg különbözı hivatal és ügynökség által nyújtott nagy számú szolgáltatás egy közös, mindenre kiterjedı architektúrában történı egységesítésére. A FEA ma még gyerekcipıben jár, mivel a nagyobb, fontosabb komponensei is csak 2006 óta érhetık el. Mivel a FEA már a sokadik kísérlet ezen a területen, így jelentıs tradíciókkal rendelkezik. Ha mást nem is, de annyit bizonyosan demonstrál, hogy a tervezık tanultak a korábbi kudarcokból. A FEA a legérettebb, legteljesebb módszertanok közé tartozik. A Zachman Framework-höz hasonlóan rendelkezik egy megfelelı taxonómiával, és a TOGAF-hoz hasonlóan egy architekturális folyamattal. A FEA két nézetben is megmutatkozik. Egyfelıl tekinthetı egy EA létrehozására szolgáló módszertannak, másfelıl az architekturális folyamat egy speciális területen az amerikai kormányzatban történı alkalmazása eredményének. A szokásos ismertetık a FEA-t leegyszerősítik öt referencia modellre, amelyek a következıkre fókuszálnak: teljesítmény, üzlet, szolgáltatás, komponens és adat. Ez, természetesen, igaz, de a FEA ennél sokkal több, mivel tartalmaz mindent, ami szükséges egy EA készítéséhez, a valószínőleg a világ legbonyolultabb szervezete: az amerikai kormányzat -ra. Így magában foglalja az EA szegmens modelljét az EA elıállításának folyamatát az EA elıtti és utáni paradigmák közötti váltás folyamatát az elkészítendı dokumentációknak, anyagoknak egy taxonomiáját az üzleti célokra és értékekre alapuló mérési módszer, amellyel az EA sikere megítélhetı A FEA-Program Management Office (FEAPMO) szerint a FEA: közös nyelv és keretrendszer IT befektetések leírására és elemzésére azon cél érdekében, az elnök munkatervével (President's Management Agenda) összhangban hogy a Szövetségi kormányzatot egy polgárközpontú, piac-orientált szervezetté alakítsák A FEA és az EA A FEA framework (FEAF) [24] bevezeti a szegmens fogalmát. A szegmens olyan nagyobb funkcióhalmaz, mint például a HR (human resources) amely a vállalat, az intézmény nélkülözhetetlen építıeleme, a fejlesztés során meghatározó a szegmensek modellezése. Három szegmenst különböztetünk meg. core mission-area (célterületi) szegmens. Azt az üzleti feladatcsoportot foglalja magában, amelynek kezelésére, megoldására jött létre maga az intézmény. Például az USA-ban a kormányzat Health és Human Services ügynökségének a célterületi szegmense az egészség.

61 business-service (kiszolgáló) szegmens. A kiszolgáló szegmensekbe az olyan üzleti feladatok tartoznak, amelyek mindegyik, vagy csaknem mindegyik hivatal, ügynökség mőködtetéséhez szükséges, függetlenül az intézmény szakterületétıl. Ilyen például a pénzügyi menedzsment. enterprise service szegmens. Az elızı két szegmenstıl eltérı dimenziót, jelent mivel ebbe a szegmensbe nem üzleti, hanem IT szolgáltatások kerülnek, például security management. A 11. ábra bemutatja, hogy a szegmensek miként hatják át a szövetségi kormányzatot. 11. ábra, a szövetségi kormányzat szegmensei FEA Referencia modellek A referencia modellek egy közös nyelvet definiálnak, amely lehetıvé teszi a kormányzati területek és intézményi határokon átnyúló együttmőködést, a kommunikációt. Az öt referencia modell a következı: 1. Business Reference Model (BRM) megadja a szövetségi kormányzat különbözı funkcióinak üzleti nézetét. Például a BRM definiálja a szabványos water resource management-et, ami az alrendszere a natural resources nak, ami pedig egy szolgáltatáscsoport a services for citizens célterületi szegmensben. 2. Components Reference Model (CRM) az üzleti folyamatokat segítı alrendszerek IT nézetét definiálja. Például a CRM megadja egy customer-analytics rendszer modelljét,

62 amely modell leírja a megvalósításhoz szükséges komponenseket és a közöttük fennálló együttmőködéseket. 3. Technical Reference Model (TRM) definiálja a különbözı technológiákat, szabványokat és ajánlásokat, amelyeket az IT rendszer felépítése során alkalmazni kell. Például a TRM rögzíti, hogy a HTTP egy kötelezıen alkalmazandó protokoll, a service transport alrendsze része, ami pedig egy részhalmaza a service access and delivery rendszernek. 4. Data Reference Model (DRM) az adatleírásokra vonatkozó értelmezı rendelkezéseket, elıírásokat, szabványokat sorolja fel. Például a DRM-ben felsoroljuk az XML, XSD ajánlásokat, a fontosabb alkalmazandó névtereket. 5. Performance Reference Model (PRM) az EA által nyújtott szolgáltatások jellemzıinek, értekeinek leírására szolgáló értelmezések, ajánlások és szabványok. Például a PRM definiálja a quality t, mint technológiai mértéket, amely leírja, hogy az alkalmazott technológia mennyiben elégíti ki a funkcionális és egyéb követelményeket FEA folyamat A FEA folyamat célja a teljes intézmény egy részéhez tartozó szegmens architektúra létrehozása (az USA kormányzatát példának tekintve a teljes intézmény a szövetségi kormányzat, a rész pedig valamely kormányzati ügynökség). A folyamat lépéseit a szegmens fejlesztési folyamat és a teljesítmény javítás életciklusának mátrixában a 12. ábra szerint definiálják. Architekturális analízis (Architectural Analysis) A szegmens egyszerő és tömör víziójának kidolgozása és összevetése a szervezetfejlesztési stratégiai tervekkel. Architektúra definíció (Architectural Definition) A szegmens architekturális terveinek elkészítése, a teljesítmény-követelmények dokumentálása, tervezési alternatívák kidolgozása, elemzése, a szegmens megvalósítására egy architektúra javaslat kiválasztása, beleértve az üzleti, adat, szolgáltatási és technológiai aspektusokat. Pénzügyi stratégia (Investment and Funding Strategy) A projekt pénzügyi terve Program menedzsment és végrehajtás (Program-Management Plan and Execute Projects) A projekt végrehajtásának terve, beleértve a mérföldköveket és a projekt elırehaladását, sikerét jelzı indikátorok mérésére vonatkozó elıírásokat is A FEA sikertényezıi A FEA Assessment Framework [26] definiálja az EA bevezetésével kapcsolatos sikertényezıket. A keretrendszer 13 kritériumot definiál az EA program érettségének és hatásosságának vizsgálatára. Az érettségi szintek 1-tıl 5-ig számozottak. A mértékek három nagy csoportba sorolhatóak. 1. teljesség magának az architektúrának az érettsége, az alkalmassága 2. használat mennyire hatékonyan használja a hivatal az architektúrát 3. eredmény az architektúra használatából származó mérhetı eredmény

63 12. ábra, a FEA folyamat lépései A következı táblázat összefoglalja a teljességgel kapcsolatos érettségi szinteket A mért értékek alapján összesített eredményt számolnak és a hivatalok érettségét színkódokkal jelölik zöld a teljesség kategóriában legalább 4-es, a másik kettıben legalább 3-as sárga a teljesség kategóriában legalább 4-es, a másik kettı egyikében legalább 3-as piros minden egyéb

64 BPIR - Australia A Business Process Interoperability Roadmap (BPIR) egy magas szintő módszertant definiál az ausztrál kormányzat interoperabilitási projektje számára. A módszertan hivatkozik a Business Process Interoperability Framework (BPIF)-re [28] és más kormányzati dokumentumokra. A módszertan eredendıen a különbözı hivatalok fölött átívelı folyamatok menedzselésére koncentrál, de természetesen egyszerősített formában alkalmazható a hivatalok, ügynökségeken belüli folyamatok kialakítása, megvalósítása esetén is. A roadmap hat lépésre osztható: terv (Plan), megegyezés (Agree), felfedezés (Discover), leképezés és modell (Map and Model), megvalósítás (Implement), ellenırzés és felülvizsgálat (Monitor and Review). A roadmap nem egy teljesen lineáris folyamat, minden egyes lépés végrehajtását felülvizsgálatnak kell követnie, és a tanulságokat levonva, a célokat, prioritásokat módosítva a lépés ismét végrehajtandó. Az intézmények az interoperabilitási folyamat végrehajtása során egyre érettebbek lesznek és ennek megfelelıen képesek a folyamatot is módosítani. A lépések iteratív végrehajtása és közben a célok, a prioritások rugalmas módosítása az érettségnek megfelelıen a 13. ábrában foglalható össze.

65 13. ábra, az Ausztrál roadmap 1. Terv (Plan) A terv fázisban világossá kell válni valamennyi, a projektben érintett intézmény számára, hogy mi a szükséges változtatások mozgató rugója, azokra milyen környezetben kerül sor; mik az elvárások a kezdeményezést illetıen; mi a változás lényege. Az üzleti folyamatok interoperabilitása szempontjából a fenti kérdésekre adott válaszok alapján alakíthatjuk az üzleti eseteket (business case). A projekt sikerének záloga, hogy az említett üzleti eseteket sikerül-e megfelelıen kommunikálni az érdekeltekkel, valóban megnyerhetık-e a projektnek. A terv folyamatos felülvizsgálatával kell mindenki számára világossá tenni a projekt céljait, a partnerek szándékait, és a kihívásokat. Szándékok/célok A szükséges változások kiváltó okainak és a változtatási szándékoknak az azonosítása. Ez vonatkozik az intézményi változásokra, az új eljárás- és szolgáltatási rend kialakítására. A lehetséges konfliktushelyzetek felderítése. Az egymással ellentétes érdekek felismerése, annak felmérése, hogy ezek az érdekek, hogyan harmonizálhatóak. A központi kormányzati stratégiának és céloknak való megfelelés ellenırzése. A kormányzatban keletkezett dokumentumok, tervek, határozatok összevetése a projekt céljaival. Környezeti feltételek Az intézmények funkcionalitásának definiálása, más intézmények, ügynökséges funkcióinak tükrében. Az ausztrál kormányzati architektúra definiál egy taxonomiát, amely segítséget ad az intézménynek a kormányzati adminisztrációban történı elhelyezésére. A projektben résztvevı intézmények motivációi és szerepük. Ennek a nézetnek a tisztázása módot ad arra, hogy a szándékok ismeretében a partnerek közös nyelvet alakítsanak ki. Szervezeti képességek Az intézmények projektben való részvétele képességének és felkészültségének meghatározása. A BPIR definiál egy érettségi modellt és vizsgálati eljárást, amellyel felmérhetı, hogy az intézmény mennyire képes az interoperabilitás folyamatban történı részvételre. Az intézmények érettségi szintjeinek felismerése lehetıvé teszi, hogy a projekt, a kommunikáció és az együttmőködés fókuszába az intézményi sajátosságoknak megfelelı aspektusok kerüljenek. 2. Megegyezés (Agree)

66 Miután az együttmőködéssel kapcsolatos szándékok, célok, motiváció és hajtóerık tisztázódtak az érintettek számára, ebben a lépésben meg kell szerezni a partnerek elkötelezettségét, támogatását és egyetértését a projekt céljai iránt. A GovDex ( a különbözı intézményben dolgozó partnerek számára szolgáltat egy a közös munkát és együttmőködést támogató eszközt, amely lehetıvé teszi a dokumentumok, modellek, egyéb erıforrások megosztását. Az egyébként védett site, a leírások alapján nagyjából a BME-n is használatos bscw rendszernek feleltethetı meg. Együttmőködés Az együttmőködési megállapodás kidolgozása Az együttmőködést napi operatív szinten támogató technikai mechanizmusok felállítása. Az együttmőködés irányítására intézmények fölötti irányító testületet létrehozása, a testület mőködését definiáló szabályzatok kidolgozása. A munkacsoportok felállítása, munkarendjük meghatározása. Az egyéni, csoportos és intézményi felelısségi körök kijelölése. Szabványok Az alkalmazandó szabványok, ajánlások meghatározása. Keretrendszerek, referencia modellek, modellezı eszközök kiválasztása, elterjesztése. Kommunikáció Az intézményeken átívelı az egyes résztvevıkre kiterjedı kommunikációs stratégia kidolgozása. Azon kulcs-szereplık azonosítása a projekten belül és kívül egyaránt, akiket meg kell nyerni, el kell kötelezni a projekt mellett. 3. Felfedezés (Discover) Miután a résztvevık a projekt céljaiban és az együttmőködés elveiben egyetértésre jutottak, a következı feladat azon konkrét az állampolgároknak nyújtandó szolgáltatási folyamatok megismerése, felfedezése, amelyek érdekében mag a megegyezés létrejött. Azzal a területtel érdemes indítani, amelyen a résztvevı intézmények érettsége a legnagyobb, a terület feladatai egyszerőek és a munka gyors sikert ígér. Az érettségi modell és az architektúra jó kiindulást ad a döntésekhez. Folyamatok felmérése Olyan folyamatot kell kiválasztani, amit egyszerő szabványosítani és a résztvevık között könnyő egyetértésre jutni. Az ausztrál kormányzat által kidolgozott taxonomia alapján a megfelelı folyamatok kiválaszthatóak. A választott folyamatnak okvetlenül át kell nyúlnia több intézményen. Leképezés A kiválasztott folyamat(ok) magas szintő,de egyszerő tevékenységi leírásokban, ábrákban történı megjelenítése. Ezen leírások alapján o a folyamatok gazdájának és a résztvevıknek az azonosítása; o a folyamatokhoz kapcsolódó, azokat használó polgárok, intézmények, piaci szereplık azonosítása; o a folyamatok jellemzı paramétereinek, a jellegzetes dokumentumoknak a meghatározása. Visszacsatolás

67 A projekt résztvevıi számára rendszeresen konzultációt kell szervezni a folyamatok különbözı aspektusainak megvitatására, áttekintésére. Ezek alapozzák meg a részletes folyamattervek kialakításának irányába történı továbblépés környezeti feltételeit. A felvetıdı témákat, szempontokat prioritási sorba kell állítani, majd a prioritások szerint értékelni kell a folyamatokat, vizsgálva, hogy azok megvalósítása hogyan történhet, és milyen kihívások várhatóak. 4. Leképezés és modell (Map and Model) Miután a folyamatokat azonosították, a különbözı aspektusokat felderítették, a prioritások alapján lehet továbblépni a részletes leképezések és modellezés irányába. A megvalósítás szempontjából kritikus tényezı a bekövetkezı változások várható hatásainak helyes elemzése. Ugyancsak kritikus annak vizsgálata, hogy az interoperabilitás mennyiben érinti mind a különbözı felhasználókat, milyen hatással lesz az addig bevett gyakorlatra. Az elemzések támogatására különféle eszközöket alkalmaznak az ausztrálok. Az IOP kezdeményezés hatáselemzésére mérı és monitorozó eszközt vettek igénybe. Az eszköz egy szabványos, automatizált folyamattal számszerősíti a szabályoknak való megfelelés költségeit, A jelen helyzet modellezése Mechanizmusokat (workshop, munkacsoportok, más együttmőködési módok) kell kialakítani az aktuálisan létezı folyamatok modelljének elkészítése tárgyában a résztvevık és a felhasználók megnyerése és közremőködése érdekében. A modellnek a szabványtárban meghatározott elıírásoknak kell megfelelni. o IT szakértık bevonásával a megvalósítást támogató technológiák számbavétele; o Az elemzés során felderített aspektusok felülvizsgálata. A résztvevıktıl begyőjtött észrevételek alapján az egyes problémák forrásának felismerése; o A kormányzat által kidolgozott taxonómia használata a folyamatok és a kapcsolódó támogató szolgáltatások, és a technológiák leírásában. Magas szintő aktivitási diagramok alkalmazása; o A folyamatok részletezése érdekében a modellezés finomítása, a döntési pontok, felelısségek tisztázása; o A jellemzı teljesítmény mértékek definiálása (pl. KPI-k Key Performance Indicators), figyelembe véve az intézményekben esetleg már korábban kialakított SLA-kat (Service Level Agreement), mint alapvonalakat. Modellek érvényesítése o A kidolgozott modelleknek egyszerően elérhetınek kell lenni valamennyi érdekelt számára; o Például a már említett govdex használatával a keletkezett dokumentációk terjesztése; o A kidolgozott modellek helyességét illetıen a partnereknek egyetértésre kell jutni; o Az IT stábnak egyetértésre kell jutnia a helyesnek tekintett folyamat-modellek, az alkalmazandó technológia és a kettı közötti kapcsolatot korrektségére vonatkozóan. A jövı definiálása

68 o A kidolgozott helyesnek tekintett modellekbıl kiindulva meg kell vizsgálni, hogy milyen bıvítési és továbbfejlesztési lehetıség van; o A különbözı intézményekben keletkezett folyamatmodellek összehasonlítása és közöttük hasonlóságok keresése, a közös folyamatok szabványosításának vizsgálata; o A továbbfejlesztett folyamatmodellek felülvizsgálata abból a szempontból, hogy az új folyamatok mennyire fedik a jelenlegi helyzetet; o Az architektúrán közös keretrendszerként használva meg kell vizsgálni, hogy a folyamatok továbbfejlesztése milyen hatással van a szolgáltatásokra és általában a technológiai rétegekre. A technológia rétegben megjelenı párhuzamosság, duplikálás elkerülése, az alkalmazott komponensek újrahasználatának növelése, a rendszer ésszerősítése; o A folyamatok továbbfejlesztése mögött álló technológia lehetıségek, választások áttekintése az IT szakértık bevonásával; o Új teljesítmény és minıségi mértékek, benchmarkok definiálása, kiindulva a sikeres benchmarkokból; o Annak meghatározása, hogy a vizsgálati eljárások mennyire kemények vagy puhák, ezen keresztül azok besorolása SLA illetıleg best practice kategóriákba; o A jövıre vonatkozó modellek publikálása; o A szükséges változtatásokhoz a menedzsement jóváhagyásának megszerzése; o A modell felülvizsgálata és valamennyi szereplı egyetértésének és elkötelezettségének megszerzése. 5. Megvalósítás (Implement) Szemben az elemzési fázis top-down irányával, az implementációt célszerő bottom-up elvégezni. Ha megvan az egyetértés a partnerek között a korábbi lépésekben, akkor nem történhet meglepetés az implementációban sem. A korábbi lépésekhez hasonlóan a megvalósítás is iteratív és inkrementális, a folyamatos visszacsatolás, a felülvizsgálatok megakadályozhatják, hogy a megvalósított rendszer eltérjen a modelltıl. Ha változtatási igények merülnek fel a megvalósítás során, akkor ez azt jelenti, hogy a korábbi lépések végrehajtása során kidolgozott anyagok, dokumentumok, és ezen keresztül a korábban létrehozott egyezségek felülvizsgálata szükséges. A jövendı állapot forgatókönyvének implementálása o Stratégia kidolgozása a kiválasztott folyamat jelenlegi és jövıbeli állapota közötti különbség áthidalására; o Nagy jelentıségő az implementációs elırehaladás folyamatos kommunikációja a partnerek és érdekeltek felé; o A megállapított mértékek és jellemzık folyamatos ellenırzése, monitorozása. Az eredmények közreadása; o Az esetleges változtatásokhoz az összes érdekelt egyetértésének beszerzése; o Az implementációhoz szükséges iránymutatásokban, elıírásokban foglaltak betartása; 6. Ellenırzés és felülvizsgálat (Monitor and Review)

69 A legfontosabb sikertényezık egyike. A monitorozás mellett jelentıs szerepe van a mért adatokból származtatott minıségi jellemzıknek, mivel bizonyos elsısorban a felhasználók megelégedésére vonatkozó mértékek nem mérhetıek. Elırehaladás mérése o Elızetes egyetértéssel kialakított mértékek használata az elırehaladás mérésére. A mérések rendszerességes és részletezettsége nagyban függhet a folyamat bonyolultságától és fontosságától; o Mechanizmusok alkalmazásával vizsgálandók az érdekeltek, partnerek, felhasználók szempontjainak érvényesülése a fejlesztés során. A rendszeres visszacsatolás lehetıvé teszi a tervektıl való eltérés korai felismerését és a sikeres korrekciót; o Egyeztetett benchmarkok alapján kezdeményezni kell a felülvizsgálatot. Felülvizsgálat o Az együttmőködési folyamat, a szabványosítás, az elosztott szolgáltatások rendszeres felülvizsgálata tudatosítja a résztvevıkben a céljuk felé haladást; o A bármilyen okból (adminisztrációs, kormányzati, IT, szabványosítás) elıálló változtatási kényszerre adott választ követıen felülvizsgálandók az eredetileg kitőzött célok és azok elérésének lehetıségei. Változtatás o Ha a teljesítmény a kitőzött értéknél alacsonyabb, vagy a célok megváltoznak, akkor mind a folyamatokban, mind az együttmőködésben célszerő azokat követni; o Az idı elırehaladásával, az alkalmazási tapasztalatokkal együtt felvetıdik a változtatás igénye, ami a jelen helyzet és jövıbeni viselkedés új modelljének kidolgozását és egy újabb iterációs fejlesztési ciklus beindulását okozza Yesser Szaud Arábia Az e-kormányzati kezdeményezés [31] megvalósítása terén az elsı lépés egy koherens szervezeti struktúra kialakítása volt, ahol a kormányszervek és egyéb irányító hivatalok szerepe és felelıssége egyértelmően meghatározásra került. A Yesser szervezet felépítését a 14. ábra mutatja.

70 14. ábra, a Yesser szervezeti felépítése Legfelsıbb Felügyelı Bizottság: egy személyben felelıs a projekt megvalósulásáért, az elırehaladás folyamatos felügyeletéért, és az alárendelt Yesser Irányító Bizottság által felterjesztett kulcsproblémákban döntést hoz. Yesser Irányító Bizottság: felelıs az e-kormányzat Program-Igazgatóság munkájának segítéséért és az általuk felvetett problémákban döntések meghozataláért. e-kormányzat Program-Igazgatóság: felelıs az e-kormányzat program teljes körő operatív irányításáért, a Projektiroda támogatásáért és a Projektiroda által felterjesztett kérdésekben döntést hoz. Projektmenedzser (Projektiroda): felelıs a kijelölt feladat megvalósításáért, vezeti az alárendelt munkacsoportot, rendszeresen beszámol az elırehaladásról a Projektirodán. Az e-kormányzati kezdeményezés kidolgozott útvonal átnézeti képe a 15. ábrán látható. Az elıkészítésre egy két fı fázisból álló útvonalat dolgoztak ki a Yesser projekt számára. Stratégia fázis: o definiálni a projekt jövıképét és céljait, o megvizsgálni az intézmények felkészültségét a feladat végrehajtására, o a folyamatok feltérképezése, modellezése, át- és újratervezése,

71 o a projekt részletes munkatervének elkészítése Analízis és pályáztatás: o a munkatervben foglalt lépések végrehajtása, o funkcionális és nem-funkcionális követelmények elemzése, o a követelmények alapján a pályázati kiírás (RFP, Request for Proposal) elkészítése o az ajánlatok kiértékelése és a szállító kiválasztása Az implementációs fázis célja: o a kifejlesztett stratégia világos kommunikálása az érdekeltek és a polgárok felé, o az intézményekben esetleg mutatkozó aktív és passzív ellenállás letörése, o a kiválasztott szolgáltatások megvalósítása a pályázaton nyertes szállító közremőködésével, o a szolgáltatások elindítása

72 Stock taking/ Pilot Pilot Process Vision and Service E-readiness Process re-design/it objectives prioritization assessment requirements Define a vision of where you want to go and by when Articulate objectives with measurable criteria for success Business/ strategic activity IT activity Vision statement for government agency and list of (quantified) objectives End product List all the possible services you offer to your customers with details such as number of users, frequency of use, etc. Assess IT readiness of IT infrastructure of gvmt. agency Agency s branches & departments Connectivity to other government agencies Strategy Define criteria for prioritizing services Use criteria to prioritize and group similar services together List of Ranking of services services and offered within classification agency with in matrix needed details Assess e- readiness of services Describe IT business application, underlying IT infrastructure and connectivity Overview of process of services Flowcharts of services processes * Yesser Framework for Inter-operability (under development) Source: Team Analysis and RFP Development Implementation 7 Projects B Change management Scoping and Action Plan RFP mapping Communication Service A C Development implementation Document Redesign Write an Run projects A Communicate B Devise a C Implement steps of pilot services Action Plan to achieve the new strategy required service with the for the the goals service and plan to changes delivery, objective of government and objectives design to address with paper flows, simplifying agency, in the concerned resistance systems, owners of them in terms including all action plan parties (active and human process of ease, duration, infrastructure Analyse the explaining the passive) resources, steps, user sa- projects and functional benefits of the within etc. to performance, tisfaction, etc. service requirements new design agency to make legal and IT Involve key redesigns Write the new changes requirements process functional designs effective of pilots owners part of RFP Specify new IT requirements Infrastructure Business applic. Connectivity to other gvmt. agencies Ensure compliance with YEFI standards* Overview of new process of services Flowcharts of new services processes Describe IT infrastructure and redesign implementation projects Specify timeline and budget for implementation Overview of new process of services Flowcharts of new services processes 15. ábra, a Yesser roadmap Analyse the non-functional requirements. Write RFP the non-functional part The final RFP ready for issuing A vendor for the development selected Communication plan for stakeholders Change management plan Implement new business process application s and apply defined standards of application s Implemented new services processes As a prerequisite, a suitable organization must be setup to steer the e-government project of the government agency

73 Az e-kormányzati kezdeményezés sikertényezıi: Szervezeti: o világos, átlátható szervezeti struktúra kialakítása, o a szervezetben résztvevık felelısségének pontos tisztázása, számukra a megfelelı és hatékony eszközök biztosítása o az igazgatási folyamatok gazdáinak kijelölése, megnevezése o az informatikai szakértık és munkatársak o a projekt elırehaladásának rendszeres és tervezett felülvizsgálata Modellezés/Újratervezés: o a projekt hatáskörének és az elvárt eredményeknek a tisztázása, o pilot projekt végrehajtása a tapasztalatok győjtésére, o benchmarkok segítségével az analízis és tervezés ellenırzése, o külsı szakértık közremőködése az elemzésben és modellezésben, a kulcsfolyamatok gazdáinak bevonása a tervezésbe, o a látszólagos akadályok okozta gátak áttörése, o a felhasználók szempontjainak figyelembe vétele (interjú, kérdıív) az újratervezés során, o a keretrendszerrel (Yesser Framework for Interoperability, YEFI) való kompatibilitás megırzése Implementáció: o biztos, kielégítı finanszírozás idıben, o az újratervezés részleteiben már korán figyelemmel lenni a késıbbi tenderkiírás követelményeire, o a szállítóval kötendı szerzıdésben az ütemtervek és eredmények pontossága és ellenırizhetısége, o az elırehaladás monitorozása és a tervekkel való összevetés o a kockázatok periódikus felmérése, ellenırzése Érettségi modellek Business Process Interoperability Maturity (BPIM) Egy intézmény, vállalkozás számára fontos, hogy mennyire képes együttmőködni másokkal. Mielıtt az intézmény üzleti és informatikai folyamatait továbbfejlesztenénk, alkalmassá tennék az együttmőködésre, célszerő megvizsgálni az interoperabilitásra való érettséget. Ehhez szükséges egy érettségi modell, amelyen, mint egy térképen elhelyezhetı az intézmény az

74 aktuális állapotában. Definiálható egy kívánatos, elérendı állapot is, és megfelelı modell esetén útmutatást kaphatunk a célállapot elérése érdekében szükséges teendıket illetıen. Az intézményeknek a szoftver fejlesztésben mutatott érettsége mérésére a Capability Maturity Model-t (CMM) és annak különbözı továbbfejlesztett változatait használják világszerte sikerrel. Tekintettel arra, hogy a SOA alapú interoperabilitás bevezetésére való alkalmasság és az intézményben alkalmazott szoftver fejlesztési gyakorlat sokban eltérı képességeket kíván, ezért cégek, kutatók kifejezetten az interoperabilitásra való érettségre vonatkozóan önálló modelleket dolgoztak ki. Alább az ausztrál e-kormányzati projektben is alkalmazott BPIM modellt [28], [29] ismertetjük. A BPIM modell kiinduló feltételezése, hogy az üzleti folyamatok érettsége két-dimenziós, nemlineáris modellben írható le. Az elsı dimenziót a minden szervezetre jellemzı öt komponens (a változás öt faktora, five levers of change) alkotja. Ezeket a 16. ábrán mutatjuk. 16. ábra, a BPIM faktorok A második dimenzió a folyamatok érettségének állapota, amely a következı értékeket veheti fel: Silózott (Siloed, Ad-hoc) A szervezet mőködését funkcionális, telephelyi, termékvonal, adat silók jellemzik. Ezek az informatikai támogatással is rendelkezı csoportok egymástól elkülönülten, saját területükön akár optimálisan mőködnek, de a változó üzleti, informatikai környezethez alkalmazkodni nem, vagy csak nagyon nehezen tudnak. Taktikailag Integrált (Tactically Integrated, Tactical Collaboration) A silókon átnyúló, tipikusan funkcionális együttmőködés megvalósult. Az ehhez szükséges adatok interoperabilitása, megoldott, gyakorta standard megoldásokkal dolgoznak, de a

75 komponensek között inkább pont-pont kapcsolat van egy-egy partikuláris funkció megvalósítása érdekében. Folyamat-vezérelt (Process Driven, Re-use) Az üzleti folyamatokat azonosították, a középpontban továbbra is a funkciók állnak. A funkciók között az együttmőködés továbbra is gyenge, többnyire eseti megoldásokat alkalmaz. Optimalizált (Optimized Enterprise, Shared services) A középpontba a szolgáltatások kerülnek. BPM-et alkalmaznak. Intelligens (Intelligent Operating Network, Service oriented) Az üzleti folyamatokat monitorozzák, és annak alapján módosítják a szolgáltatásokat. A szolgáltatások dinamikusak, SOA-t alkalmaznak. A folyamatok érettsége ábrázolható a változásra fogékonyság (responsiveness) és a hatékonyság (efficiency) által kifeszített koordinátarendszerben, a 17. ábra szerint: 17. ábra, az érettség szintjei

76 18. ábra, az érettségi jellemzık

77 A két dimenzió egy mátrixot határoz meg, amelynek egyes mezıi megmutatják az intézmény változás faktorainak és a folyamat érettségének jellemzıit. Ez a mátrix a 18. ábrán látható A modell alkalmazása Az intézmény felülvizsgálata során meg kell állapítani, hogy az intézmény folyamatai az egyes faktorok szempontjából milyen érettséget mutatnak. Ezek a felmérések a legritkább esetben mutatják ki azt, hogy a szervezet mindegyik faktor szempontjából ugyanolyan érett. Általában a 19. ábrához hasonló képet kapunk. 19. ábra, az érettség javításának programja Az alacsonyabb minısítést kapott faktorok jellemzıit összevetjük az elérendı érettségi mértékhez tartozó jellemzıkkel és a különbségeket feltárva és elemezve megkapjuk, hogy mely az ábrán piros nyilakkal jelölt kezdeményezések és tevékenységek végrehajtása szükséges a magasabb felkészültség eléréséhez. Ezzel az eljárással az érettségi modell az intézmény fejlesztését meghatározó vagy legalábbis befolyásoló keretként használható Microsoft Service Oriented Architecture Maturity Model

78 A Microsoft szintén kidolgozott érettségi modellt [30] a SOA-képesség mérésére. İk négy érettségi szintet definiáltak, amelyeknek jellemzıit három tényezı függvényében vizsgáltak. Az általuk javasolt mátrix a 20. ábrán látható. A modell a BPIM-mel megegyezıen kell alkalmazni The Gartner Assessment Framework A 4-fázisú Gartner e-kormányzati modell [32] a referencia keretrendszer szerepét tölti be az e- közigazgatási projektekben. A projekt modellbeli leképezése alapján a projekt résztvevıje (az ügyosztály, a hivatal, a közigazgatás) meg tudja határozni az elırehaladásra való képességét, megérti, hogy mely területeken szorul fejlesztésre, és kidolgozhat egy munkatervet a kormányzati céloknak való megfelelésre. A javasolt modell egyszerő és lehetıvé teszi az összehasonlítást. A modellt a 21. ábra mutatja be. A négy fázist jellemzı oszlop egy három-dimenziós koordinátarendszerben ábrázolható, ahol a dimenziók rendre: költség/bonyolultság, idı és közösségi érték. A függıleges tengelyen szerepel a költség és bonyolultság. Az egyes fázisokhoz tartozó oszlopok relatív magassága a lényeges. Az oszlopon belüli szegmens magassága az adott szegmens relatív bonyolultságát/költségét jelöli, de mértékadó az ugyanazon típusú szegmensek arányai a különbözı oszlopok között is. Figyelemre méltó, hogy a költség/bonyolultság a technológiai szegmensnek való kitettsége a Transaction fázisban a legnagyobb.

79 20. ábra, a Microsoft érettségi modellje

80 BME IK 21. ábra, a Gartner 4-fázisú modellje A vízszintes tengelyen a relatív idı szerepel. Az oszlopok szélességének arányai jelzik a fázisok egymáshoz képesti hosszúságait. A fázisok idıtengelyen való elhelyezkedése logikai sorrendet követ, de érdemes két tényezıt figyelembe venni. Egyfelıl nem szükségszerő, hogy a vizsgált intézmény sorban végigmenjen valamennyi fázison. Elképzelhetı, hogy megfelelı intézményi fejlesztési politika esetén egy fázis kihagyható. Másfelıl ugyanazon intézmény különbözı fejlettségi szintő (fázisokhoz tartozó) szolgáltatásokat nyújthat. Például egy önkormányzatnál a helyi adó az interneten keresztül bankkártyával is befizethetı, míg ugyanezen önkormányzatnál gyámügyben a web-oldalról csak a félfogadási idı olvasható le. A z-tengely iránya a közösség, a polgár felé mutatott értéket jelzi. A fázisokon való elırehaladás során ennek az értéknek fokozatosan nınie kell, a szolgáltatásoknak mindinkább meg kell felelni a közösségi értékeknek. Mire a Transformation fázishoz érünk az intézménynek át kell formálnia magát, hogy a legjobban megfeleljen a közösség által elvárt igényeknek. Amennyiben ez nem történne meg, az intézmény átalakítása vagy teljes megszüntetése szükséges. Az e-kormányzati átalakítás során az intézménynek a következı szegmensekre kell fókuszálni: Strategy/Policy: A papíralapú igazgatási szolgáltatások megvalósítása során alkalmazott eljárásrendek sok esetben nem vagy ésszerőségi okokból csak korlátozottan feleltethetık meg az BME Informatikai Központ 80

81 BME IK elektronikus lehetıségeknek és kívánalmaknak. Az eljárásrendek (policy-k) megváltoztatása szükséges lehet. People: Az emberi tényezı különösen fontos. A közszolgálati dolgozóknak meg kell változni. Ott, ahol merev szabályok védik a közszolgák kiváltságait, a Transaction és Transformation fázisokba lépés jelentıs ellenállásba ütközhet. Az ellenállás kezelése, megfelelı hozzáállású alkalmazottak felvétele és kiképzése jelentıs költségekkel járhat. Process: A bürokratikus folyamatok gyökere az erısen hierarchikus intézményi szerkezetben és papírfolyamban fedezhetı fel. A közösségi érdekek elfogadása és az elektronikán alapuló együttmőködés szemléletváltást követel, a folyamatokat át kell tervezni. Technology: A technológiai váltás, a hivatal és az ügyfelek közötti új kommunikáció teremti meg az új típusú közigazgatás technikai bázisát. Az új technológia jelentıs befektetéseket igényelhet, de mindez megtérül a rohamosan növekvı közösségi értékekben. A Gartner keretrendszerét alkalmazták a szaudi Yesser projektben. Az érettséget taglaló Gartner jelentésbıl adunk közre néhány figyelemre méltó megállapítást az alábbiakban. A legnagyobb hatású technológiai váltás a 3. fázisban esedékes, amikor az on-line tranzakciók korábban ismeretlen megbízhatóságot és biztonságot követelnek. A 4. fázisban az emberek, a szervezet és a folyamatok olyan kihívást jelentenek, amelyek képesek a projekt megvalósulását is megakadályozni. Az eljárásrendek és a szabályozás fontos szerepet játszhat a 3. és 4. fázisban. Kormányzati körök erısen érdekeltek a 4. fázis gyors elérésében. Ugyanakkor a kezdeményezésnek a szaudi szociális, alkotmányos, jogi, gazdasági és technológiai környezetben kell gyökerezni, és egyben visszahatni is arra. Átgondolandó, hogy bizonyos területeken jelentıs eredménynek számíthat már a 2. vagy 3. fázis elérése is. BME Informatikai Központ 81

82 BME IK 11. Javasolt magyar roadmap A magyar közigazgatásban a szolgáltatás bázisra történı áttérésre javasolt útvonalterv Jövıkép Az e-közigazgatás magyarországi bevezetése kapcsán megfogalmazott (és az 1.1. pontban összefoglalt) célok egyetlen lépésben nem valósíthatóak meg. Az eddig elért eredmények, a futó projektek, az intézményi rendszer szerkezete és fejlettsége alapján az iteratív megközelítés lehet célravezetı. Az iterációhoz az ismétlıdés, a körben járás gondolata társul. A következıkben azt vizsgáljuk meg, hogy a magyar e-közigazgatásban hogyan értelmezhetıek ezek a fogalmak. A kormányzat az egymást követıen induló projektek céljául az e-közigazgatás folyamatos kiterjesztését jelöli meg. Ez a kiterjesztés vonatkozik a közvetlenül az állampolgároknak nyújtandó szolgáltatások körének bıvítésére a bevont szervezetek (hivatalok, önkormányzatok) számának növelésére az alkalmazott informatikai technológia tökéletesítésére a biztonsági és azonosítási módszerek javítására az érintett szervezetek átalakítására az adatvédelmi és egyéb jogszabályok valamint az e-közigazgatás technológiája között mutatkozó rés eltüntetésére a közigazgatási eljárások korszerősítésére Miközben az egyes projektek eredményei az e-közigazgatás kiteljesedéséhez járulnak hozzá, valamennyi projekt a magyar e-közigazgatási rendszer szolgáltatásorientált architektúrájára (MKA) a közigazgatási szolgáltatási sínre (MKSZS), a követelmény- (szabvány)tárra támaszkodik. Ezeket a központi elemeket nevezzük törzsnek! Az egyes projektek és a törzs közötti kapcsolat kétirányú. Egyrészt a projektek a törzsre épülnek, másrészt az egyes projektek eredményei, hozadékai, tapasztalatai beépülnek a törzsbe. A folyamat spirálmodellel írható le. Vizuálisan úgy képzelhetı el, hogy a projektek csavarvonal szerően az emelkedéssel utalva az e-közigazgatás fejlıdésére tesznek egy-egy fordulatot a törzs körül, miközben erısítik a törzset is. Jelen Elektronikus Közigazgatási Keretrendszer Kialakítása (EK3) projekt keretében kimunkálásra kerü(t) a törzs. Végrehajtás alatt áll egy pilot-projekt, amely kísérleti jellege ellenére alkalmas arra, hogy igazolja a technológia használhatóságát. A követelménytár alapján a jelenleg futó EKOP projektekben megvalósuló fejlesztéseket értékelni kell, továbbá célszerő ezeket úgy hangolni, hogy illeszkedjenek a javasolt roadmap következı menetéhez. A jelenleg futó projektek közül a jelen projekt megalapozza az architektúrát és a fejlesztések általános követelményrendszerét, azaz kialakítja a törzs kezdeti állapotát. A KOPINT- BME Informatikai Központ 82

83 BME IK DATORG Központi rendszer bıvítése és szolgáltatásfejlesztése projektje megteszi az elsı lépéseket az ügyfélkapu szolgáltatás-alapú kapcsolódási felületének kialakítására. A spirál következı, második menete a MeH Interoperabilitás megvalósítása egyes nyilvántartásoknál projektje lehet, amelyet azonban hangolni kell a javasolt menetrendnek megfelelıen. A projekt keretében létre kell hozni a Magyar e-közigazgatási szolgáltatási sínt, és éles pilotként meg kell valósítani néhány rajta mőködı éles szolgáltatást. A spirál harmadik menete az éles pilot tapasztalatai alapján újabb szolgáltatások megvalósítását, továbbá mind a horizontális, mind a vertikális intézményi kapcsolatok bıvítését tőzheti célul. A második menetben, az éles pilotban résztvevı hivatalok az alábbi célokat tőzheti maguk elé: az e-közigazgatás intézményi elfogadtatása, a szervezeti és szolgáltatás modellezési korlátok lerombolása, a jogszabályi környezet ellentmondásainak felderítése, az intézmény IT csapatának szakmai felfejlesztése, a fejlesztési módszertanok bevezetése, begyakorlása. A pilot valóságos közigazgatási feladat megoldására irányul, de az elsıdleges cél nemcsak a teljes funkcionalitás megvalósítása, hanem annak igazolása, hogy az intézmény kész a törzshöz tartozó architektúra, technológia, szabványok, ajánlások alkalmazására. Közvetkezésképp a pilot funkcióját érdemes korlátozni egy a gyakorlatban önállóan megálló egyszerő funkcióhalmazra, amely integrálja a meglevı alkalmazások néhány komponensét és példát mutat a modernizálásra. Mindez azt jelenti, hogy a szolgáltatások számának vagy bonyolultságának növelése helyett az architektúra alkalmazhatóságára kell fókuszálni. Ez a következıket is jelenti: Meg kell találni azokat a kulcsembereket, akik a technológiával és a közigazgatással kapcsolatos szakértelemmel rendelkeznek. A pilotnak támogatni kell az intézményt abban, hogy az felkészülhessen a jelenleg még nem is látható jövıbeni változásokra. Ebbıl a szempontból a pilot által megvalósítandó szolgáltatást az intézményben tervbe vett funkciók közül érdemes kiválasztani. A folyamat hatásköre. A fenti szempontokon túlmenıen célszerő más intézmények, funkciók, ügyfelek által igényelt szolgáltatást választani. Olyan szolgáltatást, folyamatot, folyamatokat kell választani, amelyben mind a kockázat, mind a hatáskör korlátozott. Iteratív módszertan. Mind a szolgáltatások, mind az implementációs eszköz tekintetében érdemes egy szélesebb körben kezdeni a kiválasztást, amit iteratíven fokozatosan lehet szőkíteni. Legyen világos a siker. Egyértelmően definiálni kell, hogy mikor tekintjük sikeresnek a pilot projektet. A spirál harmadik menetének feladatai az alábbiak lehetnek: Elsıként a pilot eredményét kell nagyon alaposan felülvizsgálni és reálisan összegezni a tanultakat, különös tekintettel arra, hogy mennyire sikeres volt a szolgáltatások kiválasztása, BME Informatikai Központ 83

84 BME IK megfelelı-e a teljesítmény, a szolgáltatások újrahasznosíthatóak-e, a minta e-közigazgatási szolgáltatások bevezetése valóban a feltételezett hasznokkal jár-e, a szolgáltatások fogadtatása kedvezı-e az állampolgárok, vállalkozók körében. A szolgáltatások továbbfejlesztése és új elektronikus szolgáltatások kialakítása kapcsán a következıket kell meggondolni: Pragmatikus irányítás: A pilot esetében a cél az architektúra intézményi alkalmazása és bevezetése volt. Ebben a fázisban a pilot tapasztalatain okulva a célok prioritási listáját fel kell állítani, és döntéseket a listában foglaltak alapján kell meghozni. Pragmatikus újrahasznosítás: A szolgáltatások újrahasznosíthatóságban valódi eredményt nem könnyő elérni. A hatékony újrahasznosítás precíz projektirányítást igényel, és annak átlátását, hogy az újrahasznosíthatóság felismeréséhez tapasztalat kell. Fontos, hogy az elvárások megfeleljenek a realitásoknak. A meglevı rendszer elfogadása: Alapvetı annak áttekintése, hogy a meglevı alkalmazások mennyiben maradnak, maradhatnak használatban. A SOA alapú architektúrára való áttérésre érdemes olyan funkciókat, szolgáltatásokat választani, amelyek sikert, a polgárok számára hasznot igérnek, ugyanakkor az átalakítás igénye és költsége elfogadható Egy projekt roadmap-je Az irányítás és menedzsment kiterjed az egész fejlesztési folyamatra és a szervezeti struktúrára, beleértve az irányítási és döntési jogosultságokat. A fontosabb aspektusok: Az EA termékek készítésének irányítása A termékekkel szemben tartalmi, elvi és formai követelményeket kell állítani, amelyek betartatása, ellenırzése, felülvizsgálata céljából a megfelelı jogosítványokkal ellátott szervezetet célszerő kialakítani. Dokumentumtár menedzsment Projekt/beszerzés menedzsment Minıségirányítás A projektmenedzsmentnek csak egyik oldala a projekt normál vitelével és a beszerzésekkel kapcsolatos döntések meghozatala és azoknak megfelelı levezénylése. Egy másik, jelentıs vonatkozása az elırehaladás és minıség folyamatos ellenırzése és az eltérések felderítése. Módszereket kell kidolgozni és alkalmazni az eltérések esetén alkalmazott eljárások menetére, a döntési és végrehajtási rendszerre vonatkozólag. A fontosabb feladatok: Elırehaladás mérése o Elızetes egyetértéssel kialakított mértékek használata az elırehaladás mérésére. A mérések rendszerességes és részletezettsége nagyban függhet a megvalósítandó szolgáltatások bonyolultságától és fontosságától; o Mechanizmusok alkalmazásával vizsgálandók az érdekeltek, partnerek szempontjainak érvényesülése a fejlesztés során. A rendszeres visszacsatolás lehetıvé teszi a tervektıl való eltérés korai felismerését és a sikeres korrekciót; o Egyeztetett benchmarkok alapján kezdeményezni kell a felülvizsgálatot. Felülvizsgálat o Az együttmőködési folyamat, a szabványosítás, az elosztott szolgáltatások rendszeres felülvizsgálata tudatosítja a résztvevıkben a közös célokat; BME Informatikai Központ 84

85 BME IK o A bármilyen okból (adminisztrációs, kormányzati, informatikai, szabványosítás) elıálló változtatási kényszerre adott választ követıen felülvizsgálandók az eredetileg kitőzött célok és azok elérésének lehetıségei A projekt lépései Kezdeményezés A kezdeti fázisban világossá kell válni valamennyi, a projektben érintett intézmény számára, hogy mi a szükséges változtatások mozgató rugója, azokra milyen környezetben kerül sor; mik az elvárások a kezdeményezést illetıen; mi a változás lényege. Az interoperabilitás szempontjából a fenti kérdésekre adott válaszok alapján válogathatunk a közigazgatási folyamatok között. A projekt sikerének záloga, hogy az említett közigazgatási folyamatok fontosságáról, megvalósíthatóságáról sikerül-e meggyızni a partnereket. A kezdeményezés folyamatos felülvizsgálatával és módosításával kell mindenki számára világossá tenni a a projekt céljait, a partnerek szándékait, és a kihívásokat. Szándékok/célok Az e-közigazgatásra történı áttérés, az e-szolgáltatások megvaslósítása és bevezetése következtében az intézményben változtatások szükségesek. Fontos a változások kiváltó okainak és a változtatási szándékoknak az azonosítása. Ez vonatkozik mind az intézményi változásokra, mind új eljárás- és szolgáltatási rend kialakítására. A lehetséges konfliktushelyzetek felderítése. Az egymással ellentétes érdekek felismerése, annak felmérése, hogy ezek az érdekek, hogyan harmonizálhatóak. A központi kormányzati stratégiának és céloknak való megfelelés ellenırzése. A kormányzati célokat megjelenítı dokumentumok, tervek, határozatok összevetése a projekt céljaival. Különös jelentısége van a különbözı területrıl (közigazgatás, informatika, jog, programozás) érkezı szakemberek közötti együttmőködésnek, ezért kiemelt cél a megbízható és jó kommunikáció. o A kezdeményezés terjedelmének definiálása o Esettanulmányokon és kisérleteken keresztül kell vizsgálni a bevezetés várható következményeit o A jelen és jövıbeli közigazgatási folyamatok elemzése Környezeti feltételek Az intézmények funkcionalitásának definiálása, a partner intézmények, funkcióinak tükrében. A projektben résztvevı intézmények motivációi és szerepük. Ennek a nézetnek a tisztázása módot ad arra, hogy a szándékok ismeretében a partnerek közös nyelvet alakítsanak ki. Más informatikai rendszerekkel (pl. bank, mobil szolgáltató) rendszerekkel való határok és kapcsolatok meghatározása Szervezeti képességek Az intézmények projektben való részvétele képességének és felkészültségének meghatározása. Az intézmények érettségi szintjeinek felismerése lehetıvé teszi, hogy a projekt, a kommunikáció és az együttmőködés fókuszába az intézményi sajátosságoknak megfelelı aspektusok kerüljenek. BME Informatikai Központ 85

86 BME IK Az érettség meghatározása céljából választani kell egy mérési módszert. Erre a célra megfelelınek látszik a korábban bemutatott, az ausztrál kormányzat is alkalmazott eljárás. A módszer öt kulcstényezı (stratégia, irányítás, folyamat, szakemberek, informatika) alapján határozza meg, majd kategorizálja mért intézményt. A módszer a mérésen túl támogatja az intézményt abban, hogy az érettebb szintre történı elırelépéshez definiálja a közvetlen célokat Egyetértés Miután a kezdeményezéssel kapcsolatos szándékok, célok, motiváció és hajtóerık tisztázódtak a partnerek számára, ebben a lépésben meg kell szerezni a partnerek elkötelezettségét, támogatását és egyetértését a projekt céljai iránt. Együttmőködés Az együttmőködési megállapodás kidolgozása. Az együttmőködést napi operatív szinten támogató technikai mechanizmusok felállítása (dokumentumkezelı, stb.). A projekttel kapcsolatos külsı és belsı kommunikáció szervezése, végrehajtása. Az együttmőködés irányítására intézmények fölötti irányító testületet létrehozása, a testület mőködését definiáló szabályzatok kidolgozása. A munkacsoportok felállítása, munkarendjük meghatározása. Az egyéni, csoportos és intézményi felelısségi körök kijelölése. A vezetési technikák és mechanizmusok elterjesztésének és alkalmazásának tervezése, Az elırehaladás mérésére, értékelésére alkalmas mértékek, azoknak a mérésére vonatkozó eljárások, szabványok kialakítása, a mérések kommunikálása szabályainak kidolgozása. Azon kulcs-szereplık azonosítása a projekten belül és kívül egyaránt, akiket meg kell nyerni, el kell kötelezni a projekt mellett. Szabványok Az alkalmazandó szabványok, ajánlások meghatározása a szabványtár áttekintése, speciális helyzetek kezelése. Keretrendszerek, referencia modellek, modellezı eszközök kiválasztása, elterjesztése. Kommunikáció Az intézményeken átívelı az egyes résztvevıkre kiterjedı kommunikációs stratégia kidolgozása Feladatanalízis Miután a résztvevık a projekt céljaiban és az együttmőködés elveiben egyetértésre jutottak, a következı feladat azon konkrét az állampolgároknak nyújtandó szolgáltatási folyamatok megismerése, felfedezése, amelyek érdekében maga a megegyezés létrejött. Azzal a területtel érdemes indítani, amelyen a résztvevı intézmények érettsége a legnagyobb, a terület feladatai egyszerőek és a munka gyors sikert igér. Az érettségi modell és az architektúra jó kiindulást ad a döntésekhez. Folyamatok felmérése Olyan folyamatot kell kiválasztani, amit egyszerő szabványosítani és a résztvevık között könnyő egyetértésre jutni. A választott folyamatnak okvetlenül át kell nyúlnia több intézményen. Leképezés BME Informatikai Központ 86

87 BME IK A kiválasztott folyamat(ok) magas szintő,de egyszerő tevékenységi leírásokban, ábrákban történı megjelenítése. Ezen leírások alapján o a folyamatok gazdájának és a résztvevıknek az azonosítása; o a folyamatokhoz kapcsolódó, azokat használó polgárok, intézmények, egyéb szereplık azonosítása; o a folyamatok jellemzı paramétereinek, a jellegzetes dokumentumoknak a meghatározása Modellezés Miután a folyamatokat azonosították, a különbözı aspektusokat felderítették, a prioritások alapján lehet továbblépni a részletes és modellezés irányába. A megvalósítás szempontjából kritikus tényezı a bekövetkezı változások várható hatásainak helyes elemzése. Ugyancsak kritikus annak vizsgálata, hogy az interoperabiltás mennyiben érinti mind a különbözı felhasználókat, milyen hatással lesz az addig bevett gyakorlatra. Általános szabálynak tőnik, hogy érdemes a megcélzott architektúrát elıbb definiálni, mint a jelenlegit. Ugyanis az elérendı állapottal kapcsolatos kezdeményezések, elvek iránymutatásként szolgálnak a jelenlegi rendszer felméréséhez, dokumentálásához. A célrendszerrel szemben támasztott követelmények, elvek és technológiai elvárások jelenítik meg az alkalmazható technológiai termékek és eljárások kiértékelésének szempontjait. A jövıkép definiálása Definiálni kell, hogy a SOA alapú e-közigazgatásra történı átállást követıen miként mőködik majd az intézmény, hogyan vehetık igénybe a szolgáltatások o Vizsgálni kell, hogy az elvárt mőködés egybeesik-e az intézményre vonatkozó kormányzati stratégiájával. o A létrehozandó konkrét rendszerre vonatkozó követelmények megfogalmazása, a kapcsolatos alapvetések rögzítése, az új eljárásrendek, szabványok, ajánlások és referenciák definiálása. o Mértékekre és mérésekre vonatkozó követelmények állítása. o Az elosztott szolgáltatások megvalósításához tartozó infrastruktúrával szembeni elvárások, korlátozások meghatározása, a figyelembe vehetı eszköztámogatás áttekintése. o A különbözı projektek, alkalmazások összevetése. o A kívánatos intézményi felépítés és eljárásrend. o A kidolgozott, helyesnek tekintett modellekbıl kiindulva meg kell vizsgálni, hogy milyen bıvítési és továbbfejlesztési lehetıség van; o A különbözı intézményekben keletkezett folyamatmodellek összehasonlítása és közöttük hasonlóságok keresése, a közös folyamatok szabványosításának vizsgálata; o A továbbfejlesztett folyamatmodellek felülvizsgálata abból a szempontból, hogy az új folyamatok mennyire fedik a jelenlegi helyzetet; o Az architektúrán közös keretrendszerként használva meg kell vizsgálni, hogy a folyamatok továbbfejlesztése milyen hatással van a szolgáltatásokra és általában a technológiai rétegekre. A technológia rétegben megjelenı párhuzamosság, duplikálás elkerülése, az alkalmazott komponensek újrahasználatának növelése, a rendszer ésszerősítése; BME Informatikai Központ 87

88 BME IK o A folyamatok továbbfejlesztése mögött álló technológia lehetıségek, választások áttekintése az informatikai szakértık bevonásával; o Új teljesítmény és minıségi mértékek, benchmarkok definiálása, kiindulva a sikeres benchmarkokból; o Annak meghatározása, hogy a vizsgálati eljárások mennyire kemények vagy puhák, ezen keresztül azok besorolása SLA illetıleg best practice kategóriákba; o A jövıre vonatkozó modellek publikálása; o A szükséges változtatásokhoz a menedzsement jóváhagyásának megszerzése; o A modell felülvizsgálata és valamennyi szereplı egyetértésének és elkötelezettségének megszerzése. A jelen helyzet modellezése Mechanizmusokat (workshop, munkacsoportok, más együttmőködési módok) kell kialakítani az aktuálisan létezı folyamatok modelljének elkészítése tárgyában a résztvevık megnyerése és közremőködése érdekében. A modellnek a szabványtárban meghatározott elıírásoknak kell megfelelni. o Informatikai szakértık bevonásával a megvalósítást támogató technológiák számbavétele; o Az elemzés során felderített aspektusok felülvizsgálata. A résztvevıktıl begyőjtött észrevételek alapján az egyes problémák forrásának felismerése; o A folyamatok és a kapcsolódó támogató szolgáltatások, és a technológiák leírása magas szintő aktivitási diagramokkal; o A folyamatok részletezése érdekében a modellezés finomítása, a döntési pontok, felelısségek tisztázása; o A jellemzı teljesítmény mértékek definiálása (pl. KPI-k Key Performance Indicators), figyelembe véve az intézményekben esetleg már korábban kialakított SLA-kat (Service Level Agreement), mint alapvonalakat. Modellek érvényesítése o A kidolgozott modelleknek egyszerően elérhetınek kell lenni valamennyi érdekelt számára; o A kidolgozott modellek helyességét illetıen a partnereknek egyetértésre kell jutni; o Az informatikai szakértıknek egyetértésre kell jutnia a helyesnek tekintett folyamat-modellek, az alkalmazandó technológia és a kettı közötti kapcsolatot korrektségére vonatkozóan Tervezés Az intézmény céljai és stratégiája kiegészítve az e-közigazgatás bevezetésének ütemezésével valamint az elızı fázisokban győjtött anyagok és tapasztalatok alapján el kell végezni gap elemzést. A elemzésnek célja azonosítani a jelenlegi és jövıbeni rendszerek specifikációi közötti különbséget. Az elemzést az összes architekturális szempontból el kell végezni. Az elemzés alapján meg kell határozni a szükséges lépéseket, azaz a tervet. BME Informatikai Központ 88

89 BME IK Sikeres munkához, érdemi tervezéshez a következı bemenı anyagokra mindenképp szükség van: A stratégiai víziókból a tervezett szolgáltatásokkal szemben támasztott követelmények Az architektúrákkal kapcsolatos elvek A cél architektúra specifikációja A cél architektúra modellek és termékek A jelenleg architektúrát leíró dokumentációk Az elemzı munka lépései: A gap -ek azonosítása és osztályozása a jelen és jövı architektúrája közötti kulturális, strukturális, funkcionális különbségek felmérése és csoportosítása A gap -ek elemzése a felismert különbségek megértése, vizsgálata Tervek készítése Akciók, tevékenységek a különbségek eltüntetésére. Különbözı forgatókönyvek készítése. A különféle ajánlások rendezése, válogatása az egyes javaslatok közötti különbségek, elınyök, hátrányok vizsgálata Implementáció Szemben az elemzési fázis top-down irányával, az implementációt célszerő bottom-up elvégezni. A megvalósítás is iteratív és inkrementális, a folyamatos visszacsatolás, a felülvizsgálatok megakadályozhatják, hogy a megvalósított rendszer eltérjen a modelltıl. Ha változtatási igények merülnek fel a megvalósítás során, akkor ez azt jelenti, hogy a korábbi lépések végrehajtása során kidolgozott anyagok, dokumentumok, és ezen keresztül a korábban létrehozott egyezségek felülvizsgálata szükséges. A jövendı állapot forgatókönyvének implementálása Stratégia kidolgozása a kiválasztott folyamat jelenlegi és jövıbeli állapota közötti különbség áthidalására; Nagy jelentıségő az implementációs elırehaladás folyamatos kommunikációja a partnerek és érdekeltek felé; A megállapított mértékek és jellemzık folyamatos ellenırzése, monitorozása. Az eredmények közreadása; Az esetleges változtatásokhoz az összes érdekelt egyetértésének beszerzése; Az implementációhoz szükséges iránymutatásokban, elıírásokban foglaltak betartása; Sikertényezık Jól definiált és elfogadott elvek arra vonatkozóan, hogy mikor és hol kerüljön sor az e- közigazgatás bevezetésére Mérnöki szemléletmód (pl. újrahasznosíthatóság, modularitás, összeépíthetıség) a szolgáltatások kialakításánál Együttmőködı, elkötelezett, magas szintő projektvezetés A kockázatok folyamatos monitorozása. A folyamatok egyértelmő felelıshöz rendelése (folyamat gazdák) Megerısített kommunikáció a munkacsapatok között Közvetlen visszacsatolás az aktuális közigazgatási folyamatokból a rendszertervezésbe BME Informatikai Központ 89

90 BME IK Megfelelı pénzügyi támogatás az választott folyamatok megújítására, megváltoztatására Mértékek, amelyek alkalmasak a modularitás és az összeépíthetıség miatti extra erıbefektetések valóságos értékének mérésére Megalapozott lépések és támogatások a SOA alapú architektúrához illeszkedı irányítási elvek, eljárások és mechanizmusok bevezetésére és alkalmazására Világos és egyértelmő támogatás az informatikusok és szakmai, politika vezetés részérıl BME Informatikai Központ 90

91 BME IK 12. Fogalomtár Architekúra egy rendszer alapvetı felépítése, beleértve az alkotó elemeket, azoknak az egymással és a környezettel való kapcsolatát, valamint a tervezést és a kialakulást meghatározó elveket. Architektúra keretrendszer architektúrák kifejlesztésének eszköze. Magában foglalja az ajánlott szabványokat, és a megvalósítás során felhasznált elemek, eljárások megfelelıségére vonatkozó elıírásokat. Architekturális leírás egy információs rendszer olyan formális modellje, amely a rendszer strukturális jellemzıivel kapcsolatos érvelést, döntéseket támogatja. E2E end-to-end. A protokoll-technológiából származó elv: az egyik végponttól a másikig definiáltnak kell lenni a kapcsolatnak. Enterprise intézmény, hivatal, a közigazgatás egy nem természetes személy szereplıje. Enterprise Architecture (EA) dokumentáció, amely különbözı nézıpontokból leírja egy intézménynek és az ott alkalmazott információs rendszernek a szerkezetét és viselkedését. Folyamat, amely leír egy intézményt és az ott alkalmazott információs rendszert. Az intézmény hatékonyságának, integritásának javítására szolgáló változások tervezési folyamata FEA Federal Enterprise Architecture, az USA szövetségi kormányzatának kísérlete a különbözı hivatalok, hatóságok, ügynökségek által nyújtott szolgáltatások egységes architektúrán történı egyesítésére. Gartner Inc. (Group) az információtechnológia területén az egyik legnagyobb kutató, fejlesztı, tanácsadó amerikai cég. Generikus osztályhoz, csoporthoz való tartozás. IT vagyon egy informatikai rendszerben meglevı adatok és folyamatok fontossága, jelentısége, értéke. KPI Key Performance Indicator. A teljesítmény legfontosabb mutatója. Legacy rendszer korábban készült, korszerőtlen, de ma is használatban levı gyakorta nélkülözhetetlen idejétmúlt informatikai rendszer. Metamodell olyan modell, amelynek elemei modellek. Ontológia egy adott területen használt fogalmak halmazának és a közöttük levı kapcsolatoknak a formális reprezentációja. BME Informatikai Központ 91

92 BME IK Policy eljárásrend, eljárásmód, irányelv. Döntések hozatalához, eredmények eléréséhez szükséges lépések, elvek tudatosan szervezett rendszere. QoS Quality of Service. A szolgáltatás minısége. Reifikáció egy elvont fogalom dologgá alakulása. Roadmap menetrend, útiterv, útvonalterv. Az e-közigazgatás megvalósításához szükséges projekt nagyléptékő terve. SLA szolgáltatás szintő megállapodás (Service Level Agreement). A szolgáltatási szerzıdés része, amelyben a szolgáltatás formálisan definiált. SOA Service Oriented Architecture. Szolgáltatás orientált architektúra. SOE Service Oriented Enterprise. Szolgáltatás alapú intézmény, hivatal, vállalkozás. Olyan intézmény, amely szolgátatás orientált architektúra szerint épül fel. Taxonómia az osztályozás, csoportosítás elmélete és gyakorlata. TOGAF The Open Group Architectural Framework.egy architektúra keretrendszer. BME Informatikai Központ 92

93 BME IK 13. Irodalomjegyzék [1] United Nations e-government Survey 2008, From e-government to Connected Governance, United Nations New York, 2008 [2] OECD e-government studies, Hungary; [3] Dr. Baja Ferenc: Az e-közigazgatási rendszer fejlesztésének aktuális feladatai, Technológiai platform és e-közigazgatás workshop, április 29. [4] E-közigazgatás 2010 stratégia utolsó hozzáférés: [5] E-közigazgatás 2010 Programterv, Miniszterelnöki Hivatal, 2007, utolsó hozzáférés: [6] Új Magyarország Fejlesztési Terv utolsó hozzáférés: [7] Államreform Operatív Program utolsó hozzáférés: [8] Elektronikus Közigazgatás Operatív Program utolsó hozzáférés: [9] KIETB 21. számú ajánlása: Az ügyfélkapu szolgáltatásaihoz történı kapcsolódás mőszaki specifikációja v1.1, utolsó hozzáférés: [10] i2010 egovernment cselekvési terv: az elektronikus kormányzat létrehozásának felgyorsítása a társadalom egészének javára, AZ EURÓPAI KÖZÖSSÉGEK BIZOTTSÁGA Brüsszel, COM(2006) 173 végleges utolsó hozzáférés: [11] A magyar SOA alapú architektúra rendszerterve, BME, IK, EK3 projekt EKK_ekozig_SOA_architektura_rendszerterv_080727_V2.doc [12] Capgemini: Online Availability of Public Services: How Is Europe Progressing? Web Based Survey on Electronic Public Services Report of the 6th Measurement, June 2006 [13] Roger Sessions: A Comparison of the Top Four Enterprise-Architecture Methodologies, May 2007, [14] The Open Group Architecture Framework, BME Informatikai Központ 93

94 BME IK [15] John A. Zachman: John Zachman's Concise Definition of the Enterprise Framework, 2008 Zachman International, [16] R. Scott Bittler, Gregg Kreizman: Gartner Enterprise Architecture Process: Evolution 2005, Gartner Research, 21 October 2005, ID Number: G , [17] A Practical Guide to Federal Service Oriented Architecture Version June 2008, [18] Steve Bennett: Successfully Planning for SOA: Building Your SOA Roadmap 12/13/2005, [19] Bennett: Successfully Planning For SOA, Building Your SOA Roadmap - Part 2 Feb. 27, 2006, [20] Ronald Schmelzer: SOA for egov: The SOA Roadmap, ZapThink, 2005, [21] Tony Baer: SOA: BUILDING THE ROADMAP, zapthink white paper, June 2007, [22] Ron Schmelzer: Finding the Lowest Risk Path to SOA Adoption, ZapThink, 2007, [23] Accenture: SOA roadmap of adoption - real cases, Budapest, 17 April, 2007 [24] A Practical Guide to Federal Enterprise Architecture by the CIO Council, Version 1.0, February [25] FEA Practice Guidance, December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget. [26] Federal Enterprise Architecture Program EA Assessment Framework 2.1, December [27] Enabling Citizen-Centered Electronic Government, FEA PMO Action Plan, AL.pdf [28] Australian Government Business Process Interoperability Framework, 2007, [29] D. M.Fisher: The Business Process Maturity Model A Practical Approach for Identifying Opportunities for Optimization, BPTrends Sept., 2004, [30] Microsoft: Assessment and Roadmap for Service Oriented Architecture, 91fed5d52818/Assessment_and_Roadmap%20_for_SOA_Datasheet.pdf [31] Yesser e-government Program, BME Informatikai Központ 94

95 BME IK [32] KSA e-gov Progress Assessment Report by Gartner, 07/04/2007, Gov_Progress_Assessment_Report_by_Gartner.pdf BME Informatikai Központ 95