TOGAF elemei a gyakorlatban

TOGAF elemei a gyakorlatban

Vinczellér Gábor 2009 06 04 2009.06.04

Bemutatkozás 2

ƒ 8 éves szakmai tapasztalat ƒ IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető ƒ Tanácsadási és Szoftverfejlesztési projektek ƒ 2007 óta TOGAF Certified

ƒ Számos Vállalati Architektúrához és Konfiguráció menedzsmenthez kapcsolódó projekttapasztalat ƒ ƒ ƒ ƒ

Pénzintézeti szektor Telekommunikáció Államigazgatás, közüzemi szolgáltatók Gyártás- és Gyógyszeripar

Az előadás célja 3

ƒ A Vállalati Architektúra Menedzsment jelentőségének j g hangsúlyozása ƒ Saját tapasztalataink megosztása, elsősorban a hazai helyzetről ƒ Tipikus jelenségek

ƒ Javaslatok megfogalmazása a TOGAF egyes részeinek gyakorlati alkalmazására ƒ TOGAF és ITIL

Miért is csináljuk? 4

ƒ Minden vállalatnak van architektúrája, csak… … van amit megterveztek

… és van, ami „csak így sikerült”

Bárhogy is alakult, a működésre és a hatékonyságra jelentős hatása van!

Vállalati Architektúra ígéretei ƒ Teljes rálátás a vállalatra -> az egészet tervezzük ne csak a részeket

5

ƒ G Gyakorlatban k l tb inkább i kább csakk az IT-re IT koncentrálunk, k t ál k az üzleti ü l ti vonatkozásokat erősíteni kell

ƒ Eredmények: E d é k ƒ Közös irányelvek, terminológia, kommunikáció erősítése ƒ Jobban integrált megoldások fejlesztése, fejlesztése különösen a több területet, területet vagy az egész vállalatot érintő kérdésekben ƒ Hatékony erőforrás kihasználás ƒ Költségcsökkentés (duplikációk kiszűrése) ƒ Kockázatok csökkentése ƒ Gyorsabb fejlesztések ƒ Összehangolt üzleti igények és IT megoldások

TOGAF áttekintés 6

ƒ Architecture Development Method (ADM) Indulás Változáskezelés

Implementációk követése ö é

AS-IS és TO-BE architektúrák kidolgozása rétegenként

Indulás 7

ƒ Vállalati Architektúra csapat felállítása ƒ Jellemzően néhány fős csapatok ƒ IT oldalon ƒ Vállalati Architekt , System Architekt közti különbség

ƒ Működés kialakítása, szervezeten belüli elfogadottság ƒ Hozzáadott érték nyújtása ƒ A szervezetek jól láthatóan igénylik az architekteket!

ƒ Ti Tipikus ik probléma: blé a „Vállalati Váll l i architekt-et hi k b í j egy erőforrás beszívja őf á hiányos projekt” (20%-ban vagyok Vállalati Architekt) ƒ Egyensúly a stratégiai és az operatív feladatok között között, nehéz mindenkinek megfelelni

AS-IS és TO-BE kidolgozása rétegenként 8

ƒ Vállalati Architektúra adatbázis (EA Repository) kialakítása ƒ Az architektek fejében össze kell állnia a teljes képnek ƒ Az egészet tervezzük, ne csak a részeket

ƒ Ez nem megspórolható, g p a kulcs a megfelelő g absztrakciós szint megválasztása, ÉS MEGTARTÁSA! ƒ Irányelvek szintetizálása ƒ a tervezési szempontok és a jövőképek lényegi üzeneteinek összefoglalása, a megvalósítók számára

ƒ Tipikus probléma: Kiszervezett fejlesztések miatt gyakran még a legfelső szintű tervezést is külsősök végzik

Vállalati architektúra adatbázis 9

ƒ Jelen állapot nyilvántartása ƒ Ne kelljen mindenre emlékezni

ƒ Különbségek meghatározása a jelen állapot és a jövőbeli tervezett állapot között ƒ Több réteg, a rétegek közti kapcsolatok ƒ Nézőpontok, nézetek (ugyanazon adat nézőpont függő megjelenése)

ƒ Két típusú tí ú eszköz kö terjedt t j dt el:l ƒ „Inkább rajzoló” típusú eszköz ƒ „Inkább adatbázis adatbázis” típusú eszköz

ƒ Az adatbázis használata kulcsfontosságú ƒ Publikáljuk! Ne csak az architektek olvassák ƒ Alkalmazás térképek, referencia architektúrák, aktuális helyzet, stb. ƒ Példa: A fejlesztések indító dokumentumának kötelező melléklete az AS-IS ábra

Vállalati architektúra adatbázis kialakítása 10

ƒ A TOGAF csak nagyon „META” szinten segít ƒ Technical Reference Model ƒ Integrated Information Infrastructure Ref. Model

ƒ Az igazi kihívás a vállalat specifikus architektúra és megoldás g kialakítása ƒ Rugalmas adatszerkezet (meta-model) ƒ Az absztrakciós szintek megfelelő megválasztása ƒ Kapcsolatok, megfeleltetések fontossága

Példa adatbázis szerkezetre Megoldás szint - Nézet 1: Meta szint:

Nézet 2:

11

Implementációk követése 12

ƒ Beépülés a fejlesztési, implementációs projektekbe ƒ Architekti követelmények (irányelvek) betartatása, adott esetben eszkaláció ƒ ha sértik is az irányelvet, akkor annak magyarázata legyen! TUDATOSSÁG!

ƒ Az irányelvek: ƒ Publikusak legyenek, széles körű konszenzuson alapuljanak ƒ Általános, Ált lá ritkán itká változó ált ó „mondások”, dá k” de d lényegi lé gi mondanivalójuk d i lój k legyen l g ƒ Példa irányelvek: funkcionális dekomponálás, a teljes architektúra technológiai g szempontú rétegezése, g adatok kezelése

Változáskezelés 13

ƒ A baseline ((AS-IS)) architektúra változásainak folyamatos átvezetése a repository-ba ƒ A következő ADM ciklusban a baseline már aktuális lesz

ƒ Beépülés a változáskezelési folyamatba ƒ Példa: Az architekti csapat egyetértése kell a változás megtörténtéhez ƒ Példa: A változás megtörténte után a repository aktualizálása

ƒ Humán H á Workflow W kfl az adminisztráció d i i á ió megkönnyítésére kö í é é

TOGAF és ITIL 14

ƒ Egymást kiegészítő két dologról van szó ƒ Gyakorlatban y sokszor felmerül az EA repository p y és CMDB kapcsolata ƒ Integráció, vagy egy adatbázisba mindent TOGAF (EA Repository)

ITIL (CMDB)

Hangsúly: g y

Megoldások g fejlesztése, j , tervezés

Napi p üzem,, szolgáltatások g folyamatos nyújtása

Kulcsszó:

Solution

Service

Támogató Tá ó adatbázis:

EA Repository: R i Architektúrális szempontok

CMDB: Konfiguráció CMDB K fi á ió kkezelési lé i szempontok

Adatbázisban tárolt adatok:

Absztrakt elemek, building blocks, konkrétumok közül is inkább üzleti szoftverek, hardver szint ritkán

Konkrét hardver és szoftver entitások, kevés absztrackió (kivéve service)

Összefoglalás 15

ƒ Sokan érzik szükségességét egy tudatosabb, szervezettebb és átfogó architektúra menedzsmentnek ƒ Kihívás: dedikált erőforrás és az egész szervezetet átfogó folyamatszabályozás

ƒ Nehéz N hé kimutatni ki t t i a gyakorlati g k l ti hasznot h t a szűkös űkö erőforrások őf á k miatt i tt ƒ Kihívás: kritikus súly elérése, egyértelmű hozzáadott érték nyújtása

ƒ Az EA mint szabályozó szervezet, ugyanakkor erősíteni szükséges a szolgáltató funkciót is! ƒ Architektúrális információk szolgáltatása ƒ Ajánlások, irányelvek

Összefoglalás ƒ Indulás: ƒ Erőforrások kérdése

ƒ AS-IS és é TO-BE architektúrák ú á kidolgozása á rétegenként: ƒ Repository ƒ Absztrakció helyes megválasztása

ƒ Implementációk követése: ƒ Vegyünk részt a fejlesztésekben ƒ Irányelvek, Tudatosság

ƒ Változáskezelés: ƒ Meglévő folyamatokhoz kapcsolódás ƒ Elektronikus munkafolyamat támogatás

ƒ Hozzáadott érték

16

Köszönöm a figyelmet 17

Vinczellér Gábor [email protected]