TOGAF 10 újdonságok

A The Open Group szervezet 2022. április 25-én bejelentette a TOGAF Standard 10. kiadásának megjelenését, és ezzel egy rugalmasabb, testreszabhatóbb keretrendszert biztosít, amit könnyebb bevezetni a vállalatoknál.

A The Open Group által 1995-ben kifejlesztett TOGAF ma az egyik legszélesebb körben használt vállalati architektúra keretrendszer. Kis-, közép- és nagyvállalatok, kormányzati szervek, nem kormányzati szervezetek és védelmi szervezetek egyaránt használják. 

A TOGAF szabvány 10. kiadása megkönnyíti a legjobb gyakorlatok átvételét, könnyebb megtalálni a tartós alapfogalmakat és a bevált legjobb gyakorlatokat és abban is segít, hogy hol keressük az újonnan megjelenő ötleteket. 

Az új dokumentum szerkezet még több, jobb aktuális útmutatást tartalmaz azzal kapcsolatban, hogy hogyan lehet a legjobb vállalati architektúrát létrehozni, amely támogatja az érdekelt feleket és a szervezetet.

A TOGAF 10 dokumentum két részekre oszlik, a TOGAF Fundamental Content (TOGAF alapvető tartalom) biztosítja az alapvető „tartószerkezetet”, a TOGAF Series Guides (TOGAF útmutató sorozat) pedig tanácsot ad annak konfigurálásához.

Az egyetemes fogalmak, a legjobb gyakorlatok útmutatásai és a feltörekvő ötletek együttesen segítik a TOGAF-szabvány alkalmazását hatékony testreszabott vállalati architektúra-gyakorlathoz.

A TOGAF 10 kiadásával a The Open Group célja, hogy a keretrendszert még elérhetőbbé és hasznosabbá tegye azoknak a vállalatoknak, amelyek szeretnék alkalmazni a legjobb gyakorlatokat. Ez a legnagyobb változás a keretrendszerben 2011 óta, amikor a vállalat kiadta a TOGAF 9.1-et. A frissített változat nagyobb hangsúlyt fektet az agilis környezetekre és a digitális átalakulásra, és kibővített dokumentációval segíti a szervezeteket a keretrendszer bevezetésének és az üzleti igényekhez való igazításának folyamatában.

Könnyebb navigáció

A TOGAF keretrendszer egyik legnagyobb átalakítása a dokumentáció szerkezetének kialakításában történt. Az Open Group átalakította a dokumentációt, hogy egyszerűbbé tegye, és könnyen navigálható moduláris formátumot hozott létre. A keretrendszert két részre osztották: TOGAF Fundamental Content és a TOGAF Series Guides, vagyis útmutatók.

A TOGAF Fundamental Content tartalmazza a keretrendszer alapjait, beleértve azt is, hogyan kell azt a szervezetben bevezetni. Ebben a részben található a bevezetés és az alapfogalmak, az architektúrafejlesztési módszer (ADM), az ADM technikák, az ADM alkalmazása, az architektúra tartalmak kezelése, valamint a vállalati architektúra képesség kialakítása és irányítása. Ez a rész a keretrendszer alapjaként szolgál, és a továbbiakban is várhatóan kevesebbet változik.

Történtek azért kisebb változások az alapvető tartalomban is, például az ADM grafikán a fázisok közötti kapcsolatokon lévő nyílhegyeket eltávolították, hogy elkerüljék azt a látszatot, hogy az ADM egy vízesésmodell. Az A fázis és az előzetes fázis közötti kapcsolat kétirányúvá vált, hogy tükrözze annak szükségességét, hogy az előzetes fázisba újra be kell lépni, ha az architektúra-képességet módosítani kell. Vagy például a Tartalom keretrendszer és metamodell elnevezés most TOGAF tartalom keretrendszerre és TOGAF vállalati metamodellre változott, mivel ez két különböző fogalom; a tartalom keretrendszer az architekti eredmények modellje, a vállalati metamodell pedig a vállalati entitások modellje.

Azért a nagyobb változások az útmutatókban találhatók. A keretrendszer Series Guides része kibővített tartalmat biztosít, amely az üzleti, információs, biztonsági, vállalati, agilis, digitális és technológiai architektúrára, valamint az MSA/SOA architektúrákra és az ADM adaptálására vonatkozó információkra vonatkozik. A referencia-modellek és -módszerek útmutatója is megtalálható, ahol különböző architektúramodellekre találhatunk példákat.

A Series Guides dokumentumokat úgy tervezték, hogy rugalmasak és adaptálhatók legyenek, így a változtatások könnyen bevezethetők anélkül, hogy a keretrendszer magját felforgatnák. Az Open Group a jövőben is tervezi a frissítések és új útmutatók kiadását, és a TOGAF 10-re való áttérés még könnyebbé teszi ezen új tartalmak felhasználását.

Még inkább testreszabható

A vállalati architektúra nem csak a technológiai cégek vagy az informatikai részlegek számára fontos, hanem minden iparágban a vállalkozások számára kiemelten fontos. A TOGAF legújabb kiadásával a The Open Group azt ígéri, hogy a felfrissített keretrendszer könnyebbé teszi az érdekeltek számára a navigációt és a szervezetükben való bevezetést. A keretrendszert úgy tervezték, hogy alkalmazkodjon a különböző típusú szervezetekhez, bármely iparágban, amelyek mindegyike saját vállalati architektúrával kapcsolatos igényekkel rendelkezik.

A TOGAF nem egy egy-méret-mindenkinek jellegű keretrendszer, hanem úgy tervezték, hogy a szervezet egyedi igényeihez igazítható legyen. Bár a TOGAF egy olyan alapvető keretrendszert kínál, amelyet a szervezetek követhetnek, az széles körben adaptálható. Ráadásul az új moduláris formátum megkönnyíti a vállalkozások számára annak azonosítását, hogy a Series Guides mely részei kapcsolódnak az üzleti igényeikhez és a keretrendszer mely részei nem vonatkoznak a jelenlegi vállalati architektúra-környezetükre.

Minden útmutató az adott területhez tartozó témák részletes listáját tartalmazza, hogy a vállalkozásoknak segítsen a számukra fontos konkrét témákra való leszűkítésben. Például az Agilis architektúra útmutatója alatt két szakasz található, amelyek a következők: Enabling Enterprise Agility (Vállalati agilitás lehetővé tétele) és Applying the TOGAF ADM Using Agile Sprints (A TOGAF ADM alkalmazása agilis sprintek segítségével). Vagy például az Information Architecture Series Guide alatt a Master Data Management (C-MDM) és az információs architektúra dokumentációját találjuk, ahogyan az az ügyfelekre vonatkozik.

Az agilitásra összpontosítva

A TOGAF eredeti, 1990-es évekbeli kiadása óta a vállalati architektúrák jelentősen megváltoztak és a keretrendszert rendszeresen frissítették, hogy tükrözze ezt a fejlődést. A TOGAF 10 esetében ez azt jelenti, hogy nagyobb hangsúlyt kapnak az agilis módszertanok és a digitális átalakulás. A mai vállalkozásoknak a saját iparágukon belüli növekedéshez rugalmasságra van szükségük a technikai igényeik kielégítésében, és a TOGAF 10 ezt figyelembe veszi azzal, hogy több dokumentációt kínál arra vonatkozóan, hogyan lehet a digitális átalakulást elősegítő agilis környezetekhez vállalati architektúrát építeni. 

TOGAF 10 tanúsítás

A The Open Group e sorok írásakor még nem jelentette be, hogy milyen tervei vannak a TOGAF tanúsítási rendszer módosításával kapcsolatban. Jelenleg a szervezet továbbra is az eddigi TOGAF 9 tanúsítványokat kínálja.

Képesség-alapú tervezés TOGAF és ArchiMate használatával

A képesség-alapú tervezés (CBP - Capability-Based Planning) egy olyan hatékony megközelítés, amely összekapcsolja a szervezet stratégiai irányát az Enterprise Architecture módszerekkel és a projekt / portfóliókezeléssel a szükséges képességek kialakítása érdekében.

Az üzleti képesség itt egy olyan meghatározott képességet vagy kapacitást jelent, amely az adott vállalkozás számára szükséges egy meghatározott cél vagy eredmény elérése érdekében. Leírja, hogy a vállalkozásnak mit kell tennie annak érdekében, hogy értéket teremtsen ügyfelei és tulajdonosai számára, de nem határozza meg részletesen, hogyan lehet elérni azt. Az üzleti képesség magában foglalja az embereket, a folyamatokat, a technológiákat és az információkat.

A CPB négy általános lépése (Map – Assess – Plan - Control) önmagában is használható, de a TOGAF ADM-mel (Architecture Development Method) együtt, vagy az ArchiMate nyelv használatával, avagy a TOGAF szabvány és az ArchiMate specifikáció együttes használatával még hatékonyabb az alkalmazása.

A Capability-Based Planning segítségével a szervezet képességei különböző aspektusainak érettségével és fejlődésével kapcsolatban a következetes értékeléshez megfelelő mérés és szabályozás alakítható ki. Hasonlóképpen mérést és nyomon követést biztosít az elért program és projekt eredményekre vonatkozóan. A CPB által biztosított nyomon követhetőség hatékony eszköz annak kiderítésében, hogy mely kezdeményezések eredményezték a legnagyobb javulást az üzleti területen, és melyikek nem. Igy a szervezet érettsége hosszabb távon is fenntarthatóvá válik.
Az érdekeltekkel való kommunikáció a képesség-alapú tervezés megvalósítása során elsődleges tevékenység, és az ArchiMate modellezési nyelv használata sokkal kifejezőbbé és pontosabbá teszi a kommunikációt.

Egy új Guide jelent meg ezzel kapcsolatban a The Open Group kiadásában.
Ez az új útmutató leírja a vállalati képességekre épülő tervezést, amely a rövidebb és hoszabb távú célokra, a szervezet képességeire, valamint a változási kezdeményezésekre való megfelelő rálátást biztosítja. Célja, hogy folyamatokat, módszereket és példákat mutasson be azzal kapcsolatban, hogy hogyan valósítsuk meg a szervezet képességalapú tervét.
Ez a 2019.07.16-án megjelent útmutató a 2016 novemberében közzétett, a CPB fehér könyvre (W16C) épül.

Az új kiadvány címe: G193: Capability-Based Planning Supporting Project/Portfolio and Digital Capabilities Mapping Using the TOGAF® and ArchiMate® Standards
Letöltési link: https://publications.opengroup.org/g193

A dokumentumban két modellezési módszert mutat be:

• Képesség-alapú tervezés a TOGAF metamodell használatával, artifaktokkal (architektúra modellek) az ArchiMate jelöléssel
• Képesség-alapú tervezés az ArchiMate modellezés segítségével

Így kiválasztható, hogy melyik metamodell és artifaktok kerüljenek felhasználásra, a TOGAF Standard, 9.2 változatban vagy az ArchiMate 3.0.1 specifikációban meghatározottak.

Az útmutató tartalmaz egy példát is a kapacitás alapú tervezésre az ArchiMate nyelv használatával, a dokumentumban leírt általános lépéseket követve, az ADM fázisok leképezését felhasználva. A példa az ArchiSurance esettanulmányra épül.

TOGAF 9.2 újdonságok

A The Open Group független szabványosító testület 2018.04.16-án bejelentette a legelterjedtebb enterprise architect keretrendszer új verzióját, a TOGAF® 9.2 szabványt.

A 2009-ben megjelent TOGAF 9 Enterprise Edition legújabb, 9.2 változatát jelentette be a szabványt fejlesztő gyártófüggetlen nemzetközi szervezet, a The Open Group.

A TOGAF szabvány nagyobb hangsúlyt fektet az üzleti architektúrára, a digitális trendekre és az IT-n kívüli üzleti átalakulásra. A szabványt átszervezték és ezzel az újonnan bevezetett TOGAF könyvtár központját alkotja. A TOGAF könyvtár olyan referenciakönyvtár, amely iránymutatásokat, sablonokat, mintákat és egyéb referencia anyagokat tartalmaz, amelyek felgyorsítják a vállalati új architektúrák létrehozását. Több mint 130 dokumentumot tartalmaz a TOGAF keretrendszer gyakorlati alkalmazásának támogatására.

A legfontosabb változások

• A TOGAF könyvtár bemutatása és alkalmazása az architektúra fejlesztési módszerben
• Erősebb összhang az ISO/IEC/IEEE 42010 szabvánnal
• Az IT4IT több helyre bekerült, mint példa a referencia architektúrákra
• Új fogalmak kerültek be a metamodellbe – főként az ArchiMate harmonizáció erősítésére
• Az architektúra Repozitóriumba bekerültek az architektúra követelmények és a megoldás gyűjtemény is
• Új artifaktok kerültek be, többek között az ArchiMate harmonizáció miatt is
• A két referencia modell kikerült külön dokumentumba, a TOGAF könyvtárba
• Külső dokumentumokba került a két architekturális stílus: Biztonsági és SOA architektúrák.
• Az Üzleti forgatókönyvek és üzleti célok fejezet külső dokumentumba került a TOGAF könyvtárba
• Kikerültek azok a hivatkozások, amelyek már nem aktuálisak vagy nem elérhetők
• Sok egyéb kisebb jelentőségű szerkesztői korrekció történt

TOGAF könyvtár 

A TOGAF® könyvtár a TOGAF szabványt támogató strukturált on-line könyvtár. A TOGAF könyvtárat a The Open Group Architecture Forum irányítása alatt tartják karban.

A könyvtár tartalma a TOGAF Enterprise Continuum szerint szerveződik:

• 1. rész: Alap dokumentumok - Általánosan alkalmazandó információk az TOGAF keretrendszer vagy a vállalati architektúra témájával kapcsolatban
• 2. rész: Általános útmutatók és technikák - Az architektúrák stílusát ismertető információk, valamint a TOGAF keretrendszer és az Enterprise Architecture alkalmazási lehetőségei specifikusabb kontextus jellemzőinek kiaknázására
• 3. rész: Iparág specifikus útmutatók és technikák - Információk, amelyek leírják, hogyan alkalmazható a TOGAF keretrendszer és a vállalati architektúra egyes vertikális iparági szegmensek sajátos igényeinek kielégítésére
• 4. rész: Szervezet-specifikus útmutatók és technikák - Információk, amelyek leírják, hogyan alkalmazták az TOGAF keretrendszert és a vállalati architektúrát az egyes vállalkozások igényeinek kielégítésére

Ha a könyvtáron belüli források a TOGAF architektúra fejlesztési módszer (ADM) megvalósítására vonatkoznak, és kifejezetten hivatkoznak a TOGAF szabvány egyes pontjaira, akkor a könyvtárban Függő dokumentumként vannak besorolva. Olyan erőforrások, amelyek útmutatást adnak a szabványban leírt jellemzők kihasználásához, Támogató dokumentumoknak minősülnek. Az általános architektúrához kapcsolódó erőforrások, amelyek nem tartalmaznak konkrét utalásokat a TOGAF szabványra, az EA Általános dokumentumok közé tartoznak.

TOGAF felhasználói közösség

A legelterjedtebb architektúra keretrendszer felhasználói tartották nemrégen ez évi első találkozójukat. Ennek kapcsán következik itt néhány gondolat a TOGAF felhasználásáról és a találkozó fontosabb részleteire is kitérünk.  

The Open Group TOGAF® User Group

Egyik korábbi blog bejegyzésben röviden már hírt adtam róla, hogy 2016. január 25-én megrendezésre került az első TOGAF® User Group Meeting San Franciscoban. A TOGAF fejlesztői eddig is rendelkeztek világméretű szervezettel: az Architecture Fórum erre szolgált. Hiányzott azonban a TOGAF felhasználóinak ilyen szintű közössége. Létrehozásának legfőbb célja az Open Group számára az volt, hogy a keretrendszer felhasználóitól több visszajelzés jusson el az Open Group szakembereihez és a felhasználók egymással is hatékonyabban tarthassanak kapcsolatot, együttműködésük professzionálisabb lehessen. A TOGAF 9 minősített szakemberek száma az egész világon a találkozó idején már meghaladta a 63 000 főt.

2017 elején ismét TOGAF User Group konferenciát tartottak, melynek központi kérdésköre az architektúra létrehozás és újrahasznosítás volt. Ez röviden azt jelenti, hogy az architekt szakembert célszerűbb-e jobban bevonni a meglévő architektúra modellek újrahasznosításába, mint újak létrehozásába azért, hogy az igényeknek megfelelő megoldások alakuljanak ki.

A konferencia nyitó vita

A rendezvény egy klasszikus oxfordi stílusban megrendezett vitával kezdődött. Az elmúlt évi hasonló vita tárgya az agilitás témaköre volt, amihez megfelelő architektúra modellek megléte nagyon lényeges. Így a mostani vita azzal foglalkozott, vajon ezeket a modelleket legjobb újrahasznosítani, vagy inkább célszerű elkészíteni minden alkalommal, amikor ilyen modellre szükség van.

Az újrahasznosítás melletti érvek között elhangzott, hogy a TOGAF eleve tartalmaz megfelelő iránymutatást arra, hogyan válasszunk eszközöket és referencia modelleket az újrahasznosításhoz. A technológiai területeken az már teljesen elfogadott, hogy modellek használatára van szükség az élet egyszerűbbé tételéhez. Szintén fontos érv, hogy a modellekre azért is szükségünk van, hogy a megvalósítás várható időigényét jobban tudjuk tervezni. Természetesen maguk az architektek sem szeretnék ugyan azt a problémát újra és újra megoldani. A meglévő referencia modellek egy közös nyelvet is biztosítanak az enterprise architektek számára, ezért is fontosak a munkájukhoz.

Az ellenzői érvek között elhangzott, hogy a referencia modellek csak akkor hasznosak, ha egy referencia architektúrába épültek be. A referencia modellek segítenek megérteni a referencia architektúrákat, de önmagukban haszontalanok. Az architekteknek gyakorlottaknak kell lenniük referencia modellek kialakításában, de azoknak a modelleknek referencia architektúrákon kell alapulniuk. Másrészről pedig a referencia architektúrákhoz hozzá kell tartoznia a világosan definiált problémának, a probléma megoldására vonatkozó iránymutatásnak, az ehhez szükséges képességek világos megfogalmazásának is, valamint annak ismerete is szükséges, hogy hogyan jutunk el az eredményekhez. Megfelelő referencia architektúrához szükséges tehát az az ökoszisztéma, ami meghatározza, hogy mi minden kell ahhoz, hogy a megoldás sikeres legyen.  Csak akkor rendelkezünk valóban értékes referencia modellekkel, ha bizonyított referencia architektúra áll rendelkezésre az előbbiek értelmében. Összegezve: az architekteknek először meg kell érteniük azt a problémát, amit meg kívánnak oldani, utána tudnak kitalálni olyan architektúrát, ami a megoldáshoz hasznos.

A végén a résztvevők többsége abban állapodott meg, hogy a vita döntetlennel zárult. A felmerült kérdésre a leghelyesebb válasz: „az attól függ …”. Vannak esetek, amikor valóban egy megfelelő modellt kell készíteni és vannak olyan estek is, amikor rendelkezésre áll elegendő mennyiségű újrahasznosítható információ.

Felhasználói tapasztalatok

A The Open Group Architecture Forum most a TOGAF ökoszisztéma kiterjesztésén dolgozik azzal is, hogy a gyakorló architekteknek a TOGAF minősítési program mellett útmutatókat és egyéb anyagokat is biztosít. A TOGAF sokrétű használatát bemutató felhasználói tapasztalatok között szerepelt például a BAE Systems , egy brit védelmi szállító cég példája is. A TOGAF több érdekes felhasználási területe között olyan is volt, ahol India nyomornegyedeinek lakható közösségekké alakítását úgy igyekeztek megoldani, hogy közben ne alakuljanak ki gettók. A módszertant arra is használták, hogy abban segítsenek vállalatoknak, hogy hogyan lehet az innováció kultúráját kialakítani náluk. Volt olyan beszámoló is, amely egy olyan modell kidolgozását ismertette, amelyről azt gondolták, jelentős megtakarításokat fog hozni a cégnek, azonban a modell kialakítása során teljesen figyelmen kívül hagyták a meglévő szervezeti kultúrát. Végül emiatt új tervet kellett készíteni az alapoktól kezdve. A Fujitsu a vállalati folyamataik tervezésének szabványosított megközelítési módját hozta létre a TOGAF használatával. De használták a TOGAF ADM módszertanát Indiában az országba illegálisan beáramló gyógyszerek kontrollálásának segítésére, Malajziában a pálma farmok kialakításához is tudták alkalmazni az ADM-et. Kínában mind a start-up cégek, mind pedig multinacionális vállalatok használják a TOGAF-ot a speciális strart-up fejlődésnek, illetve a nagyvállalatok digitális transzformációinak tervezéséhez.

Felhasználói igények

A konferencián elhangzott igény volt a TOGAF még jobb használhatóságával kapcsolatban, hogy több tapasztalatot kell megosztani arról, hogyan lehet „eladni” az Enterprise Architecture-t és jobban hatni az érintettek érzelmeire is.  Szintén igény fogalmazódott meg olyan aktív fórumra, ahol a felhasználók modelleket, használati eseteket, szükség esetén kérdéseikre válaszokat találnak.

A konferencia résztvevők között kiosztott kártyákon is gyűjtötték a felhasználói követelményeket a rendezvény során. A TOGAF szabvánnyal kapcsolatos javaslatokat továbbítják a The Open Group Architecture Forum-hoz, ahol azokat figyelembe veszik a szabvány tovább fejlesztése során.

Magyarországon az AEA Magyar Tagozat, a hazai enterprise architect szakmai közösség kiemelten foglalkozik a TOGAF felhasználók tapasztalataival, a keretrendszer használatával kapcsolatban felmerülő igényekkel.

Új lehetőségek az architektúra tervezőknek – megjelent az ArchiMate 3.0

A szabványos architektúra leíró nyelv használói számára jelentős esemény történt a napokban. Ezen a blogon is többször foglalkoztunk már ArchiMate architektúra definíciós nyelvvel: 2013. decemberben az ArchiMate és a TOGAF kapcsolatáról írtam abból az alkalomból, hogy megjelent a nyelv 2.1 változata. Egy 2014. júniusi blog bejegyzés tárgya pedig az ArchiMate architektúra leíró nyelv és az UMLviszonya volt. Ezen a nyáron a The Open Group ArchiMate® Forum elérhetővé tette az ArchiMate specifikáció legújabb verzióját, az ArchiMate Specification® 3.0 verziót. 

Ezzel kapcsolatban egy sor bejelentés és esemény zajlik egész június - júliusban. A hivatalos bejelentés az IRM Enterprise Architecture Europe konferencián Londonban történt június 14-én. Másnap egy élő webinaron is bemutatták az új szabványt gyakorlati példákkal. Az újdonságokat Marc Lankhorst mutatta be, aki még 2014-ben az AEA Magyar Tagozat budapesti rendezvényén ismertette meg a résztvevőket az ArchiMate lényegével. A szabvány hivatalos leírásán kívül már elérhető egy zsebkönyv (A Pocket Guide to the ArchiMate® 3.0 Specification), az ArchiMate 3.0 Reference Cards és egy rövidebb bevezető (An Introduction to the ArchiMate 3.0 Specification) is.

 

Az architektúrák legtöbbször az olyan vállalati / szervezetei célok támogatása miatt fontosak, mint például a fokozottabb stratégiai összhang, a jobb együttműködés és a nagyobb teljesítmény. Az architektúrák meghatározása, leírása során jelentős előnyökkel jár egy olyan, jól definiált, elterjedt architektúra leírásra kialakított nyelv használata, mint az ArchiMate.

Maga az ArchiMate egy modellező nyelv, amely könnyen érthető, szabványos képi ábrázolással teszi lehetővé a vállalati architektúrák leírását, elemzését és az architektúra területek közötti kapcsolatok megjelenítését is. Egy olyan közös nyelvet jelent, amellyel leírható egy vállalat különböző részeinek felépítése, működése, beleértve az üzleti folyamatokat, szervezeti struktúrákat, az információáramlást, az informatikai rendszereket valamint a technikai és a fizikai infrastruktúrát is. Napjainkban, amikor sok vállalkozás gyors változásokon megy keresztül, az ArchiMate modellek segítik az érintetteket abban, hogy ezeket a változásokat megtervezzék, kiértékeljék és hatékonyan kommunikálják akár egyes területeken belüli, akár azok közötti változásokról van szó. Segítenek a döntések lehetséges következményeinek vizsgálatában is akár az egész szervezet vonatkozásában.

Az új 3.0 változat jelentős előrelépés a korábbi 2.1 verzióhoz képest. Az újdonságok között megtalálhatók azok a nyelvi elemek, amelyekkel a vállalat stratégiai szinten is modellezhető, mint például a vállalati képességek, erőforrások és eredmények. Másik új területként most már támogatja a nyelv például az anyagok és berendezések fizikai világának modellezését is. Mindezeken túl a nyelv következetessége és szerkezetének egységessége is tovább javult. 

A meghatározásokat még jobban összhangba hozták más szabványokkal és a nyelv használhatósága is több téren tovább javult. Az ArchiMate 3.0 az eddigieknél is hatékonyabban támogatja a vállalati architektúrák tervezésének szabványos keretrendszerét, a TOGAF-ot (The Open Group Architecture Framework) is. Az alábbi ábra szemlélteti a TOGAF architektúra fejlesztési módszerének (ADM) fő fázisaihoz történő kapcsolódást.

Az ArchiMate olyan grafikus nyelvet biztosít, amely alkalmas arra, hogy a vállalati architektúrát úgy ábrázolja, hogy támogassa a stratégia, transzformáció és migráció tervezést és kifejezze az architektúrával kapcsolatos motivációt és indokokat is. A szabvány úgy készült, hogy a lehető legkompaktabb legyen, mégis használható a legtöbb vállalati architektúra modellező igényeinek megfelelően.

Hogyan használható számunkra a TOGAF?

Jól ismert tény, hogy a nagy nemzetközi vállalatok, szervezetek már jó ideje alkalmaznak enterprise architect módszereket. Ezzel együtt többször tették már fel a kérdést nekem is, vajon használható-e egyáltalán a TOGAF (The Open Group Architecture Framework®) a hazai vállalati környezetben? A közelmúlt egyik szakmai rendezvényén (AEA klub) is erről beszélgettünk a résztvevőkkel.

Az alábbiakban ezzel a kérdéskörrel kapcsolatban foglaltunk össze néhány hasznos gondolatot.

A TOGAF ismerete már most is többször előfeltételként szerepel a pályázók számára, amint azt néhány közelmúlt hazai pályázatból kiemelt részlet is mutatja az alábbi ábrán.

Az EA vállalati felhasználása természetesen igen eltérő képet mutat a különböző szervezeteknél. Ezt sok tényező befolyásolhatja, mint például a méret, komplexitás vagy akár a kulturális környezet is. 

Tekintsük át az alábbi ábrát követve azt az ideális folyamatot, amelyben a TOGAF felhasználása minden olyan esetben megtörténik, ahol az hozzájárulhat az eredmények javításához.

Amennyiben az adott szervezetnél még nincs hagyománya az architekti megközelítés használatának, akkor elsőként az ez irányú képességek kialakítására van szükség. Ez önmagában is kezelhető egy projektként. Természetesen meg kell keresni azt az optimális időtartamot és erőforrás ráfordítást, amivel az architekti képességeknek egy olyan minimális szintje kialakítható, amely már a szervezet számára értékes szolgáltatásokat tesz lehetővé. Jó hír, hogy a TOGAF önmaga alkalmazható erre a helyzetre is. Ennek részleteivel egy korábbi blog bejegyzésben már foglalkoztunk.

A fenti ábra bal felső sarkában a TOGAF részét képező ADM (Architecture Development Method) elterjedt kör folyamata ezt jelképezi. A gyakorlatban az ilyen típusú képesség kialakításra indított projekteknek tipikusan van két sajátossága:

• A tiszta képesség fejlesztési célok mellett szokás (kisebb komplexitású és kevésbé kockázatos) architekti feladatok megoldását is szerepeltetni az ilyen típusú projekt céljai között.
• A hatékonyabb haladás érdekében külső erőforrások (például gyakorlott EA szakemberek, tanácsadók, minőségbiztosítók, oktatók) bevonásával célszerű a saját vállalati EA képesség kiépítését megvalósítani.

Mindenképpen célszerű a jelentősebb vállalati architektúra projekt(ek)et a korábban kialakított saját architekti képességek birtokában elindítani. Ezeket a már összetettebb, kockázatosabb, nagyobb jelentőségű architektúra projekteket jelképezi az ábra jobb oldalán a két nagyobb méretű TOGAF ADM folyamatábra, a két sárga kör diagram.

Nos, a módszertan lépéseire alapozva az említett architektúra projektek az architektúra definíció elkészítése után az átmenet megtervezése során részletesen meghatározzák a szükséges megvalósítási projekteket, azok ütemezését, erőforrás igényét, kölcsönhatásait is. Amikor az adott architektúra projekt a TOGAF ADM módszer szerint a „G. Implementáció felügyelet” fázishoz érkezik, akkor indulnak el az ábra bal oldalán kék színnel jelzett megvalósítási, implementációs projektek. Ezek tipikusan (a korábban említett architektúra projektektől) független, önálló projektek, mégis az az architekti felügyelet, irányítás, ami a korábban tervezésre fókuszáló architekt csapat munkáját ebben az időszakban jellemzi, nagyon lényeges. Nem csak a megvalósítás minősége szempontjából, illetve a korábban jóváhagyott architektúra tervek minél pontosabb követése érdekében hasznos ez a tevékenység. Az architektek, akik több megvalósítási projekttel is kapcsolatban vannak, jelentős segítséget is nyújthatnak a megvalósítás során, felhívhatják a figyelmet más projektek újrahasznosítható komponenseire, másutt bevált módszerekre, fogásokra. Ugyanakkor az architektek ilyen jellegű tevékenységük során olyan hasznos információkat szereznek, amelyeket jól felhasználhatnak későbbi architektúra tervek készítésénél, akár az érvényben lévő architektúra alapelvek finomítására is, valamint nem mellékesen olyan áttekintő információkkal szolgálhatnak a vállalatnál folyó megvalósítási projektekről az érdekelt vezetés számára, ami jól kiegészítheti az egyébként szintén lényeges projektvezetői beszámolókat.

     

Természetesen a fentiekben ismertetett folyamat egy idealizált helyzetre vonatkozott. Az írás elején említett szakmai klubnapon végig vettük jó néhány hazai projekt tapasztalatait és ennek során világosan azonosíthattuk, hogy a fent ismertetett ideális folyamatnak mely részei valósultak meg az egyes projektekben. Megnéztük hol milyen előnyökkel járt a fentiek követése illetve hol milyen problémát okozott ha lényeges elemek hiányoztak, elmaradtak vagy összevonódtak más tevékenységekkel.

Összegzés

Az architekti megközelítés, a bevált módszertan alkalmazása a vállalati célok megvalósítását leginkább azzal segítheti, hogy a tervezett vagy szükségessé vált változásokat segít hatékonyan, a lehetséges legnagyobb előnyök és legkisebb kockázatok mellett véghezvinni. A TOGAF maga felhasználható már a későbbi munkához szükséges vállalati architektúra képesség kiépítéséhez is, majd pedig (erre alapozva) a célszerű változások gondos tervezéséhez és a megvalósítás felügyeletéhez.

Hol van leginkább szükség architekti munkára?

Az enterprise architect (EA) szakterület erőteljesen fejlődik, egyre kifinomultabb módszerek, technikák, eszközök állnak rendelkezésre. Ugyanakkor fontos kérdés, hogy egy vállalat vagy más nagyobb szervezet életében hol, milyen helyzetekben, területeken tudnak igazán hatékonyan segíteni az EA tevékenységek. Tanácsadóként magam is különféle helyzetekkel találkozom: van, ahol láthatóan arra van a legnagyobb szükség, hogy segítsünk azonosítani azokat változásokat, amik például a versenyelőnyhöz szükségesek vagy egyszerűen a túléléshez elkerülhetetlenek. Más szervezeteknél, ezen már túljutva, inkább arra van szükség, hogy a már magas szinten azonosított változásokról pontosabb meghatározás készüljön el. Végezetül a változások tényleges megvalósítását is jelentősen segítheti a megfelelő architekturális irányítás. Ez a kérdéskör egyébként gyakran felmerül olyan helyzetekben is, amikor oktatóként konkrét architektúra fejlesztési módszert tanítok a hallgatóimnak, akik közben joggal rákérdeznek: végül is hol, milyen helyzetekben lehet felhasználni az EA módszereket, eszközöket?  

Nos, többféle esetben is segítheti a szervezet céljainak elérését egy architektúra tervezéssel és megvalósítással foglalkozó csoport és ezzel összhangban többféle, különböző architektúra terv elkészítése majd implementálása a célravezető. Egy adott architektúra, amit a csoport megtervezhet, lehet magas szintű vagy részletezett, kiterjedhet a szervezet kisebb részére vagy egészére és foglalkozhat akár a jelenlegi állapottal akár pedig egy jövőbeni helyzettel. A vállalati architektúra fejlesztése ezek alapján legcélszerűbben iterációk sorozataként történhet, melynek során a fentiek szerint különböző célra készülő architektúra tervek készülhetnek.

Három jellemző fő területet érdemes kiemelni, ahol az architekt szakemberek munkájára nagy szükség van:

• A szükségszerű változások azonosítása
• Már azonosított változás pontos meghatározása
• Meghatározott változás megvalósításának elősegítése

Tekintsük át röviden ezt a három fő alkalmazási területet!

Változások azonosítása

Az EA technikák (amennyiben nem egy jól meghatározott változási kezdeményezés keretein belül kerülnek alkalmazásra) felhasználhatók arra is, hogy áttekinthetővé tegyék a meglévő IT képességeket és ezzel is segítsék a stratégiai döntéshozatalt és a megvalósítások összehangolását. Akár már a jelen helyzet következetes felmérése és dokumentálása is ráirányíthatja a figyelmet a fejlesztendő területekre, a szükséges változásokra.

Változás pontos meghatározása

Olyan területeken, ahol a változtatás szükségessége már meghatározásra került, az EA technikák arra használhatók fel, hogy strukturáltan azonosítsák a változások természetét és kiterjedését. Nagyméretű változási kezdeményezések esetében az adott program vagy portfólió keretein belül célszerű több részletes architektúra definíciót elkészíteni.

Változás megvalósítása

A szervezet összes szintjeire készíthetők architektúra tervek, amelyek jól felhasználhatók a megvalósítás tervezése, irányítása kapcsán, mivel segítik a teljes kép átláthatóságát, strukturált korlátozásokat határoznak meg és olyan kritériumokat biztosítanak, amelyekre támaszkodni lehet a technikai döntések értékelésekor.

Az alábbi ábra összefoglalóan mutatja a szokásos architekturális tevékenységek fajtáit a TOGAF 9.1 keretrendszer alapján. Az ábra után röviden kitérünk az itt jelzett területekre.

  

A szükségszerű változások azonosítása

Az üzleti stratégia támogatása

Ahogy az üzleti stratégia, a célok és a főbb hajtóerők megváltoznak, a vállalatnak is meg kell változnia az összhang megőrzése érdekében. Új üzleti stratégiák kidolgozását az EA az alábbiakkal támogatja:

• Ráirányítja a figyelmet a változási lehetőségekre
• Adott stratégiai választás várható gyakorlati hatásait kidolgozza
• Adott stratégiai irány megvalósíthatóságával és életképességével kapcsolatos vizsgálatokat végez

A teljes vállalati architektúra-gyüjtemény portfólió menedzsmentje

Nagy szervezetekben általános gyakorlat, hogy egy szolgáltatás menedzsmentért felelős szervezet gondoskodik az IT portfólió menedzsmentjéről valamint az IT portfólió működését bemutató jelentésekről.

Az EA újabb dimenzióval egészítheti ki a szolgáltatás menedzsment kapcsán említett riportokat azáltal, hogy jelzi a kapcsolatot az IT működési teljesítménye és az IT iránti stratégiai igények között.

Azáltal, hogy felhasználjuk az EA-ban meglévő információkat az üzlet és IT közötti kapcsolatokról, lehetővé válik, hogy az IT teljesítményét a vállalati teljesítmény és az üzleti igények szempontjából értékeljük (pl. költség, funkcionalitás, rendelkezésre állás, stb.) Így lehetséges azoknak a kritikus területeknek a meghatározása, ahol nincs összhang és változtatásokra van szükség.

A projektek architektúra portfólió menedzsmentje

Nagy szervezetekben bevált gyakorlat, hogy a program menedzsment szervezet biztosítja a programok, azok részeként megvalósuló projektek menedzselését és velük kapcsolatos jelentéseket. Az EA alkalmazásával újabb dimenzióval gazdagodhatnak ezek a jelentések, mivel itt biztosított a kapcsolat a projekt hatóköre, az architekturális hatások és a kapcsolódó üzleti értékek között.

A projekt prioritásokkal és finanszírozással kapcsolatos stratégiai döntéshozatal támogatása érdekében ilyen módon az architekturális tényezők is figyelembe vehetők az egyéb mennyiségi jellemzők mellett. 

Már azonosított változás pontos meghatározása

Az alapvető változási kezdeményezések architekturális meghatározása

Az alapvető változási kezdeményezések tipikusan olyan változtatási elképzelések, amelyeknek a célja jól meghatározott, de a hatóköre nem pontosan meghatározott és gyakran még nincs mögötte egyeztetett jövőkép és követelmény rendszer.

Az ilyen alapvető változási elképzelések esetében kezdetben a hangsúly a problémák természetének megértésén és a problémák strukturált meghatározásán van. Ha már a probléma megfelelően érthető, mód van a megfelelő megoldások meghatározására és az érdekelt felek összhangjának kialakítására egy közös jövőkép és cél alapján.

A kapcsolódó változási kezdeményezések architekturális meghatározása

Korábbi architekturális stratégia, kiértékelés vagy jövőkép meghatározás eredményeként gyakran ezekhez kapcsolódó változási kezdemények azonosíthatók.

Ilyen esetekben a kívánt eredmények már azonosítottak, ezekkel kapcsolatban egyetértés van. Ezért az ilyen típusú architekturális tevékenységek esetében a cél az, hogy hatékonyan meghatározzunk egy olyan kiinduló megoldást, ami az azonosított követelményeknek, problémáknak, hajtóerőknek és korlátozásoknak megfelel.

Meghatározott változás megvalósítása

A változás megvalósításának architekturális irányítása

Amennyiben egy architekturális megoldás modell meghatározásra került, ez lesz az alapja a további tervezésnek, megvalósításnak.

Annak érdekében, hogy biztosítható legyenek a meghatározott architektúra céljainak és értékeinek megfelelő megvalósítása, szükség van az implementációs folyamat architekturális irányítására. Ennek része az, hogy az architekt szakemberek támogatják a tervek felülvizsgálatát, az architektúra finomítását és a problémák eszkalálását. 

Gyakorlati tapasztalatok

Néhány személyes projekt tapasztalattal zárom az EA lehetséges alkalmazási területeivel kapcsolatos eszmefuttatást.

Egy szolgáltató vállalat azonosította azt a problémát, hogy a hosszú idő alatt kialakult informatikai rendszereikkel igen sok vállalati adatot kezelnek, de mára nincs aktuális képük a vállalat saját adatvagyonáról. Így megbízást adtak a meglévő adatvagyon felmérésére. Nos, a helyzetet EA szempontból elemezve rövidesen kiderült, hogy eredményesen használható a TOGAF (The Open Group Architecture Framework) ADM (Architecture Development Method) módszere a problémák feltárására és dokumentálására. Ez azonban azzal járt, hogy a konkrétan elvárt adat architektúra definíció (Baseline Data Architecture) elkészítéséhez egy (legalább magas szinten, nem részletezetten kidolgozott) üzleti és egy alkalmazás architektúra definíció is szükséges volt. Ezzel a megoldással a megrendelő számára valóban legértékesebb adatvagyon elemekre fókuszált felmérés valósult meg.

Egy másik projektben egy állami vállalat kiterjedt alkalmazás portfóliójának további racionalizálásához írt ki pályázatot alkalmazás architektúra definíció készítésre. A rendelkezésre álló igen rövid idő mellet az elvárt eredmények előállítása csakis a következők következetes betartásával látszott lehetségesnek: az EA projekt eredmény termékeit, a leszállítandó dokumentumokat a TOGAF ADM-ben definiált EA artifact-ok lehetőség szerint minél kisebb mértékű testreszabásával definiáltuk. Az igényelt leszállítandóknak a TOGAF artifaktokra történő leképezésére fordított idő messzemenően megtérült és ezzel lehetővé vált a határidőre történő teljesítés.

Az EA módszerek alkalmazásának utolsó példájaként egy egészen sajátos helyzetet említek. Egy nagy állami informatikai fejlesztési projekt során szükségessé vált a legmegfelelőbb tesztelési kapacitás kialakítása is. Architekti megközelítéssel ezt is célszerű volt egy szükséges változásként tekinteni, aminek megtervezésére a bevált ADM módszert alkalmazva, készítettünk egyszerű üzleti, alkalmazás és adat valamint IT technológiai architektúra definíciókat is, mielőtt az új tesztelési képesség gyakorlati kialakítását megkezdtük.  Ez biztosította, hogy a teszteléssel szembeni üzleti követelmények, az ehhez kialakított szervezeti megoldás, a biztosított erőforrások, a bevezetett speciális IT alkalmazások, kezelt adatok és a mindezt támogató technológia tudatos választás eredményeként, optimálisan támogatta a teljes fejlesztés céljainak megvalósítását.

Összegzés

Az architekti munka többféle helyzetben, több területen is segítheti a szervezet céljainak elérését, a szükséges változások azonosítást, pontos meghatározását és hatékony megvalósítását. A legcélszerűbb bizonyos iteratív megközelítés: különféle szintű, kiterjedésű, részletezettségű architektúrák tervezése segíti leginkább a környezet változásaira leghatékonyabban válaszolni képes vállalat vagy egyéb szervezet kialakulását.