Architektúra eszköz - vállalati tudásbázis

Annak érdekében, hogy az enterprise architect (EA) tevékenység hasznos legyen és valódi üzleti értékkel rendelkezzen, az architektúra tervezés, fejlesztés, karbantartás, megvalósítás hatékony irányítást és megfelelő eszközöket igényel. Ha az üzleti környezet összetett, az IT megoldások komplexek és az EA dokumentumok menedzselése bonyolult, akkor mindenképpen speciális EA szoftver alkalmazása célszerű. A közelmúlt egyik tanácsadói projektében a megfelelő EA eszköz kiválasztásához piacfelmérés és az EA eszközkínálat összehasonlítása is része volt a megbízásnak, ennek kapcsán foglalom össze a szempontokat, tapasztalatokat az alábbiakban.

Az EA eszközök és platformok olyan szoftver alkalmazások, amelyeket arra terveztek, hogy támogassák az enterprise architekt és más architekt szakemberek és olyan érintettek munkáját, akik a szervezet stratégiájának megfelelő tervezést, elemzést végeznek.  Az EA eszközök a stratégiai és taktikai döntéshozatalt támogatják azzal, hogy információt és azok összefüggésit gyűjtik és kezelik az üzlet, az információs rendszerek és a technológia területén, a lényeges architekturális nézőpontoknak megfelelően.

Az EA eszközök piacán sokféle szállító megtalálható. Eszközeik az érintett architektúrákra vonatkozó információkat tárolnak, strukturálnak, elemeznek és megfelelően megjelenítenek. Olyan lekérdezéseket, riportokat, megjelenítést biztosítanak, amelyek az üzleti eredmények elérését segítik.

Az EA eszközök pozícionálásával és az alkalmazásuk, elterjedésük sebességével kapcsolatban a Gartner független elemző cég azt jelezte 2016 júliusában, hogy az EA eszközök iránti érdeklődés 40%-kal nőtt az elmúlt 12 hónapban. A vállalati licenc eladások növekedésének két legfőbb hajtóerejét az összetett üzleti transzformációk és a digitális üzlet kihívásainak segítésében látja a Gartner. Az IT költségcsökkentés, alkalmazás portfólió kezelés és racionalizálás problémái szintén arra ösztönzik a vállalatokat, hogy ha eddig nem tették, kezdjék el alkalmazni ezeket az eszközöket.

Ahogy az alábbi ábra szemlélteti, az EA eszközök már az úgynevezett „megvilágosodás emelkedőjén” találhatók a sokak által jól ismert hype-görbe öt fázisra közül, a Gartner értelmezésében 2016-ban. Ez azt jelenti, hogy az EA eszközök már nem az innovációs kezdeményezés vagy az azt követő magas elvárások csúcsán, illetve a szokásos relatív kiábrándulási fázison találhatók. A megvilágosodás emelkedője fázist általában az jellemzi, hogy egyre több vállalatnak jelent előnyt az adott technológia, második- és harmadik-generációs termékeket kínálnak a gyártók, egyre több vállalat finanszíroz pilotokat, de a konzervatív szervezetek továbbra is óvatosak.   

Forrás: Hype Cycle for Enterprise Architecture, 2016, Gartner, 79 oldal
 

Fontos szempont, hogy az architektúrák fejlesztése egységes és konzisztens módon történjen.  Az EA irányítási folyamatoknak és a testreszabott módszertanoknak kell biztosítani azt, hogy a különböző architektúra leírások, amelyeket különböző architektek vagy architekt csoportok készítettek, támogassák az architektúrák integrációját mind az egyes architektúra területeken belül (üzleti, adat, alkalmazás, technológia) mind pedig azok között is.

Bizonyos idő után az architektúra dokumentumok (EA artifaktok) olyan erőforrásokká válnak, amelyeket megfelelően kezelni, kontrollálni kell, különösen az újrahasznosítás szempontjából. Szükségessé válik olyan EA eszköz kiválasztása, amely lehetővé teszi ilyen architektúra modellek és nézetek generálását és folyamatos karbantartását.

Az enterprise architektek által használt személyes EA eszközök helyett egyre inkább vállalati szintű EA megoldásokra, platformokra van szükség. Ez a változás azt jelenti, hogy nem annyira az EA szakemberek személyes termelékenységét fokozó eszközöket, sokkal inkább vállalati szintű döntéseket és tervezést támogató platformot célszerű kialakítani.

Nem megfelelőek a széleskörű, jól megalapozott döntések támogatására olyan EA eszközök, amelyek:

• nem biztosítanak megbízható, nagy teljesítményű központi repozitóriumot (információ tárat), amely a munkatársak, csoportok ismereteit egyesíti egy helyen, konzisztens módon
• nem képes fejlett vezetői információkat és elemzéseket szolgáltatni
• nem rendelkeznek hatékony import-export funkcionalitással és olyan programozhatósági, szkriptelhetőségi lehetőséggel, ami az eszköz adaptálását, megfelelő EA folyamatok támogatását, szabályok kialakítását és artifaktok automatizálását teszi lehetővé
• nem biztosítanak fejlett webes megjelenítési eszközt az összes tartalom „laikus” felhasználók részére történő megjelenítésére, bizonyos esetben az összes munkatárs számára elérhető módon.

Az EA eszköz kiválasztása során természetesen célszerű megismerni az ehhez kapcsolódó független elemzői ajánlásokat, mint például a Gartner’s Magic Quadrant for Enterprise Architecture Tools és a The Forrester Wave™: Enterprise Architecture Management Suites vagy az olyan minősítő szervezetek listáit, mint a The Open Group TOGAF® 9 Tool Certification Register vagy például a The Open Group ArchiMate® Tool Certification Register. Ezek fontos információ források, de egymagukban nem elegendőek a megfelelő EA eszköz kiválasztásához már csak azért sem, mert nincsenek tekintettel az adott szervezet speciális helyzetére, EA érettségére, igényeire.

Kiválasztási szempontok

Természetesen feltételezhetjük, hogy minden olyan EA eszköz, amely rendelkezik valamekkora piaci részesedéssel, megfelel valamilyen helyzetre. A saját céljainkra leginkább megfelelő eszköz kiválasztását célszerű a helyzet világos megismerésével kezdeni. Egy korábbiblog bejegyzésben foglalkoztam az architekturális érettséggel és annak felmérésével. Amennyiben nincs pontos képünk a szervezet / vállalat architekturális helyzetéről, érdemes egy felméréssel kezdeni.

A megfelelő eszköz kiválasztásához tisztázni kell, mik a lényeges architekti funkciók a szervezetnél (pl.: EA, IT, információs architektúra vagy a folyamatok kialakítása), milyen szakemberek dolgoznak az architektúrákon (pl.: EA szakemberek vagy más kollégák másféle szakképesítéssel és ismeretekkel), milyen nagy az architekti funkció (mekkorák az architektúra modellek, milyen fajta projektek jellemzők) és persze hogy mekkora büdzsével lehet tervezni.

Természetesen a szabványok támogatása (mint például az ArchiMate, melyről már több blog bejegyzésben is írtam) szintén fontos szempont. Mindenesetre érdemes megjegyezni, hogy a megfelelő EA eszköz kiválasztása bonyolultabb dolog, mint ahogy elsőre tűnhet. Például a kiválasztásnál könnyen olyan jellemzőkre koncentrálhatunk, amelyek valójában nem is olyan lényegesek (mint például az architektúra komponensek hogyan néznek ki a megjelenítéskor). Ha sikerül a teljes képet megértenünk, végül már csak kis számú lehetőség közül kell választanunk. Nemrégen egy hazai vállalat számára készítettem javaslatot EA tool kiválasztásához és ott először 20 gyártó és termék szerepelt a listán és viszonylag rövid elemzés után ez egy 4 elemű listára rövidült.

Az EA eszköz által kezelt információknak tartalmazni kell az üzleti, az adat és alkalmazás, valamint a technológiai architektúrákkal kapcsolatos információkat is. Kezelnie kell a vállalati kockázat kezelés és a vállalati biztonság kezelés sajátos nézőpontjait is, melyek befolyásolják a jövő architektúráit.

Az EA eszköznek kapcsolódni kell más megoldásokhoz is, többek között:

• projekt és portfólió menedzsment
• irányítás, kockázat kezelés és megfelelőség
• IT szolgáltatás menedzsment
• pénzügyi menedzsment

A korszerű EA eszközöknek minimálisan az alábbi képességekkel rendelkezni kell a Gartner ajánlása szerint:

• legyen repozitórium alapú
• rendelkezzen modellezési képességgel az összes architektúra nézőpontra vonatkozóan
• támogassa a különféle érintettek megjelenítési nézeteit 
• rendelkezzen architekturális, üzleti tervezési és döntési területeken szükséges elemzési képességekkel
• rendelkezzen a szükséges megoldásokkal a felhasználói hozzáférési jogosultságok adminisztrálására, biztonsági szempontok érvényesítésére
• legyen konfigurálható különböző felhasználók és környezetek esetére
• támogassa a különböző szabványokat és keretrendszereket (jelölések, architekturális és iparági szabványok) és tegye lehetővé a felhasználók igényeinek megfelelő testreszabást is
• az összes jellemzőt és funkciót könnyen használható, intuitív módon biztosítsa

A végső döntéshez célszerű a kiválasztott legesélyesebb szállítók kínálatát még egy konkrét, a vállalati speciális igényekhez összeállított igény lista alapján összevetni. Legutóbbi ilyen jellegű tanácsadói munkám során egy közel száz kérdést tartalmazó kérdőívvel kerestük meg a kiválasztott szállítókat. A kérdőív az alábbi főbb kérdéskörökben mérte fel a megoldásokat:

1. Termék azonosítás
2. Termék pozicionálás
3. A szállító pozícionálása
4. Támogatás, oktatás
5. Referenciák
6. Licencek és költségek
7. Termék jellemzők: 

• Általános jellemzők
• Repozitórium
• Biztonság és naplózás
• Testreszabhatóság
• Kompatibilitás, együttműködési képesség és integráció
• Kommunikáció és kollaboráció támogatása
• Alkalmazási területek, EA információ kezelése
• Egyéb kiegészítő információk

Adatgyűjtés a naprakész EA repozitóriumhoz

Ha nincs folyamatosan frissítve, az EA modell nem használható, mert nem hozható megalapozott döntés ilyen adatok alapján.  A megfelelő adatgyűjtési és esemény-kezelési mechanizmus kialakítása érdekében az EA eszközhöz a megfelelő környezeti (kontextus) információkra is szükség van. Ilyen információk például az érintettek felelőssége, az elérhető adatforrások, a modell elemeinek forrása (kézzel felvett vagy adatforrásból származó), vagy például az adott elem utolsó módosításának ideje. Az ilyen környezeti információkat célszerű az aktuális EA modell elemeivel együtt tárolni.

Az EA modellekhez szükséges adatgyűjtés teljes automatizálása jelenleg nem lehetséges főleg az alábbi okok miatt:

• az EA adatok, különösen az üzleti architektúra területén, magas absztrakciós szinten kerülnek modellezésre és ez az absztrakció csak emberi döntéssel tehető meg
• nem minden adat szerezhető be automatizálható módon, meglévő adatforrásokból az adott szervezetnél
• adat inkonzisztencia előfordulása esetén, pl. duplikációnál, a feloldás gyakran csak emberi döntéssel lehetséges

Ezért nagy jelentősége van az emberek bevonásának az adatgyűjtésbe és minőségbiztosításba az EA működés szempontjából. Hosszabb távon természetesen az a cél, hogy a szakemberek bevonása az adatszolgáltatásból inkább a minőségbiztosításba helyeződjön át. Az automatikus adatszolgáltatásra képes adatforrások integrálása mellett fontos, hogy felhasználjuk azokat az eseményeket, amelyek emberi vagy automatizált tevékenységeket indíthatnak az EA eszközben. Ehhez megfelelő esemény-kezelő interfész kialakítása célszerű azok miatt az információs rendszerek miatt, amelyek ugyan nem képesek strukturált adatokat automatikusan szolgáltatni az EA eszköz számára, de képesek egy EA szempontból releváns változás tényét jelezni. Ilyen események például értesíthetik a megfelelő érdekelt személyt egy projekt lezárásáról vagy hasonló eseményekről. Ezzel kézi adatfrissítés kezdeményezhető közvetlenül az esemény bekövetkezése után.

Az alábbi ábra egy ilyen részben automatizált EA repozitórium adat frissítésének koncepcióját szemlélteti.

Összefoglalásul megállapíthatjuk, hogy bizonyos architektúra fejlettségi szintekhez elengedhetetlenül szükséges megfelelő EA eszköz használata. A viszonylag széles termék kínálat ellenére nem egyszerű feladat a legmegfelelőbb eszköz kiválasztása. Ehhez tisztában kell lennünk a szervezet EA érettségével, a tervezett felhasználás főbb jellemzőivel. Célszerű az elemző cégek információit is felhasználni, valamint a legesélyesebb megoldások szállítóit célzott kérdések, szempontok szerint összevetni. Ilyen jellegű tevékenységekben sokat segíthetnek gyakorlott tanácsadók.

EA érettségi felmérés tapasztalatokkal

Sok vállalat számára nagyon lényeges az EA (Enterprise Architect) működés bizonyos fejlettségi szintjének elérése, ráadásul általában viszonylag rövid időn belül, a szükséges környezeti elemekkel együtt (módszerek, eszközök, irányítás, stb.), tekintettel a vállalat méretére, a szolgáltatásainak és infrastruktúrájának összetettségére, a futó projektjei számára, a piaci verseny helyzetre.  

Általában azok a szervezetek, amelyek a változásokat hatékonyan képesek kezelni, jóval sikeresebbek, mint azok, amelyeknek gyenge a változáskezelési képessége. A fejlett EA gyakorlat a sikeres innováció és változás-kezelés egyik fő hajtóereje. Az erőforrások megfelelően összpontosított felhasználásához elengedhetetlen, hogy valóságos képünk legyen a vállalati architektúra állapotáról és fejlettségéről. 

Ebben a blog bejegyzésben a vállalat vagy szervezet architekti képességének érettség felmérésével kapcsolatos tapasztalatokról lesz szó egy közelmúltban lezajlott ilyen jellegű hazai felmérés apropóján.

A szervezet architekti képességének értékelése célszerűen egy speciális modell alapján történik azzal a céllal, hogy a lehetőségekhez mérten objektíven leírja a szervezet jelenlegi helyzetét és fejlettségi szintjét. (Lehetőség van arra is, hogy ezzel párhuzamosan felmérjük azt is, milyen szint jövőbeni elérését tartják célszerűnek a felmérésben résztvevő szakemberek.) A felmérési eredmények megmutatják, hogy az adott szervezet mennyire képes az EA területen a feladatok végrehajtására és rámutatnak azokra a gyakorlatokra, amelyekre célszerű a figyelmet összpontosítani, a lehetséges legnagyobb fejlődés és megtérülés elérése érdekében.

Amennyiben folyamatos értékelés céljából többször történik ilyen jellegű felmérés (például évente), az EA érettségi felmérés olyan tájékoztatást jelent, ami hasznos az EA program fejlődésének és hatásának értékelésére.

A felmérés módszere

Az érettségi modellek általában az adott szervezet különféle területeken kialakult folyamatainak felmérésére és javítására nyújtanak hatékony eszközöket.

Az említett EA felmérés kezdetén egy indító workshopot szerveztünk melynek hármas célja volt: ismerkedjünk meg személyesen is egymással, értsük meg jobban egymást (közös nyelv), és kezdjük el a közös munkát.

Ezután személyes interjúk következtek melyek során egy standard kiértékelő kérdőívet töltöttünk ki az interjú alany válaszai alapján. Ezek jó alkalmat teremtettek arra is, hogy az interjú alanyok a kérdésekhez kapcsolódóan kifejthessék a szervezet EA tevékenységével kapcsolatos személyes nézeteiket is.

Az említett kérdőív-alapú interjúk mellett olyan találkozókat is szereztünk, ahol további, főként vezető munkatársakkal beszélgettünk az EA fejlettséggel kapcsolatos területekről. Ezután a kérdőívek és az említett beszélgetések alapján készítettünk egy összefoglaló jelentést.

A bevezetőben említett felmérés fő célja az volt, hogy az adott vállalatnál az EA, mint vállalati funkció létrehozásával és fenntartásával kapcsolatos képességeket, erősségeket és gyengeségeket azonosítsuk.

Az érettség felmérés terén az eredeti SEI CMM a de-facto szabványos felmérő eszköz, ezért ez alapján került kialakításra az a speciális EA felmérési kérdőív, amit felhasználtunk.

A CMM (Capability Maturity Model) eredetileg egy fejlesztési modell volt, amely az USA védelmi minisztériumával szerződött szervezetektől begyűjtött adatok tanulmányozásán alapult, amit az említett minisztérium finanszírozott.

Az „érettség” kifejezés alapvetően a folyamatok formalizálásának és optimalizálásának mértékére vonatkozott, ami a teljesen ad hoc gyakorlattól a formálisan meghatározott lépések alkalmazásán és az eredmények mérésén át a folyamatok aktív optimalizálásáig terjedt.  A modell célja az volt, hogy a meglévő szoftverfejlesztési folyamatokat javítsa, de alkalmazható más folyamatokra is.

Az alkalmazott felmérési módszer az alábbi lépéseket tartalmazta:

• Előkészítés: Indító workshop
• Kezdés: Kérdőíves interjúk
• Feldolgozás: elemzés és meglévő referencia adatokkal való összevetés
• Befejezés: Az eredmények összefoglalása és átadása

A felmérés hasznos alapinformációkat tudott biztosítani a megrendelő szervezet számára az EA fejlesztési stratégiájuk kialakításához.

A kérdőív az alábbi 11 szekcióba csoportosítva összesen 41 kérdést tartalmazott:

• Az érdekelt felek elemzése
• Az architektúra folyamatok elterjedtsége
• EA fejlesztés
• EA irányítás
• EA kommunikáció
• Minőségbiztosítás
• Üzleti architektúra
• Információs architektúra
• Technológiai architektúra
• Alkalmazás architektúra
• Egyéb támogató területek

Az interjú alanyokat arra kértük, hogy minden kérdésnél válasszák ki az előre megadott válaszok közül azt, ami a saját személyes tapasztalatuk szerint leginkább kifejezi a vonatkozó gyakorlatot vagy állapotot a vállalatuknál.

Tapasztalatok

Nagyon kevés olyan szervezet van, amely mindegyik dimenzióban fejlettnek mondható és szintén kevés szervezet esetében van szükség az összes meghatározott dimenzióban a legfejlettebb állapot elérésére. Az a lényeges kérdés, hogy az adott szervezet EA erősségei összhangban vannak-e azzal, amire a szervezetnek szüksége van.

A kérdőíves eredményekkel kapcsolatban kialakulhat az a vélemény, hogy a számszerű összesített eredmények általánosságban egy érettebb EA gyakorlatot jeleznek, mint ami a valóságban jelenleg rendelkezésre áll a vállalatnál. Ennek az eltérésnek a főbb okai a következők lehetnek:

• Az a természetes emberi viselkedés, hogy a dolgokat sokszor jobbnak állítjuk be, mint amilyenek valójában, különösen olyan helyzetben, amikor tudjuk, hogy egy értékelés, mérés történik.
• A másik ok pedig az a helyzet, hogy a különböző interjú alanyok egymástól nagyon eltérő nézetekkel rendelkezhetnek az úgynevezett „Enterprise”-ról, vagyis a vizsgálat tárgyát képező (logikai) szervezetről. Például akik az éppen folyó legnagyobb fejlesztési projektben vesznek részt, természetes módon a projektben tapasztaltakat általánosították a teljes szervezetre. Vagy például a jogilag kiszervezett, de EA elemzés szempontjából mégis a logikai „Enterprise” részének tekintett funkcióban dolgozó interjú alanyok a maguk szervezeti egységének viszonyai alapján válaszolják meg a kérdéseket.

Azért, hogy a fenti hatásokat ellensúlyozzuk, egyrészt a válaszokból képezett átlag értékekkel célszerű dolgoznunk, másrészt pedig a következtetésekhez nem az értékek abszolút nagyságát célszerű alapul venni, hanem az egyes tényezőkkel kapcsolatban kialakult értékek egymáshoz viszonyított relatív eltéréseit.

A kérdőíves interjúk során nem csak a konkrét választásokat érdemes rögzíteni, hanem az adott kérdéssel kapcsolatban elhangzott megjegyzéseket is.

Végül álljon itt néhány, az említett közelmúltbeli felmérés eredményeit szemléltető diagramokhoz hasonló ábra. A kérdőív 11 kérdéscsoportjának megfelelően 11 darab úgynevezett radar diagram készült. Például az első kérdéscsoportra adott válaszok összesítését az alábbihoz hasonló diagram mutatta be, az érdekelt felek bevonásának mértékét szemléltetve.

A vizsgálati eredmények összefoglalásának végén egy összesítő diagrammal szemléltettük az adott vállalat érettségi szintjeit összehasonlítva korábbi EA ügyfeleink átlagolt értékeivel.

Az eredmények összesítésére az alábbihoz hasonló radar diagram készült, melyen összevethetőek az aktuális eredmények a korábbi ügyfeleink referencia adatbázisával.

Összefoglalva elmondhatjuk, hogy hasznos egy standard EA fejlettségi modellhez viszonyítva megvizsgálni a szervezet EA képességeit, amihez az alkalmazott kérdőíves technika jó módszert biztosít. A számszerű eredményeket önmagukban nem célszerű a teljes igazság egyedüli kifejezőjének tekinteni, sokkal inkább a felmérés során megismert helyzet alapján lehet a számszerű eredményeket értékelni. 

Mindenesetre hasznos a vezetők elé tárni egy olyan képet az EA működésükről, ami jó alapot adhat a fejlesztés tervezéséhez. A felmérési eredmények alapján lehetőség nyílik a fontosabb kockázati elemek azonosítására, a főbb EA stratégiai irányok kijelölésére és még olyan praktikus területen is hasznosak az eredmények, mint az EA munkát támogató eszközök célszerű kiválasztása.

Ú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.

Az IT, mint üzleti egység kezelésének gyártó független modellje - IT4IT

Az üzleti vállalkozásoknak egyre gyakrabban van szükségük jelentős változtatásokra a technológiai fejlődés, az üzleti modell váltások és hasonlók miatt. De szükség van-e ezek mellett a változások mellett új megközelítésre a szervezetekben működő IT üzleti menedzselésében is?

Az IT4IT kezdeményezés azt mondja, hogy a válasz: igen. Az IT4IT a The Open Group új megközelítési módja arra, hogy segítsen az IT-t, mint a szervezetnek olyan értékes eszközét és szolgáltatás közvetítőjét pozicionálni, amely segítséget nyújt a szervezetnek a gyorsan változó világban.

Ebben a blog bejegyzésben ezzel a gyártó független referencia architektúra víziójával foglalkozunk. Az IT4IT hivatalos ipari szabvány 2015. október 21. óta. A szabvány az IT-nek, mint üzleti egységnek a kezelését írja le. 

Az alábbiakban az AEA Magyar Tagozat (az Association of Enterprise Architects hazai tagszervezete) 2016. áprilisi rendezvényén tartott előadásom alapján adok egy rövid bevezetést az IT4IT szabványba. Ennek kapcsán megemlítem, hogy már két évvel korábban, a CIO.HU konferencián 2014-ben is ajánlottuk az akkor még szabványként nem publikált IT4IT v1.2 kezdeményezést a konferencián megjelent informatikai vezetők figyelmébe az akkori AEA előadáson.

Nagyvállalati IT vezetők csakúgy, mint a Gartner elemzői azt jósolják, hogy az IT4IT segíteni fogja a szervezeteket abban, hogy az egyre összetettebb IT területet még költséghatékonyabb módon tudják menedzselni. Mint minden új megközelítés esetében, a siker nagymértékben azon is múlik, hogy a megfelelő hatókör, megbízatás és gondolkodásmód kialakítható-e az IT4IT referencia modellt alkalmazni szándékozó szervezetekben.

Az IT4IT mint az IT üzleti működtetésének nyílt szabványa két lényeges részből áll: tartalmaz egy IT működési modellt és egy IT referencia architektúrát.

Az IT működési modell főbb jellemzői:

• Az IT működtetését értékláncként kezeli
• Összhangban van az IT vezetéssel
• Szolgáltatásokat és végfelhasználói értéket biztosít
• Együtt használható a legjobb folyamat gyakorlatokkal, mint pl. ITIL, COBIT,Prince2
• Egy súlyos iparági hiányosságot pótol
• Egyre több szállító csatlakozik a támogatók köréhez

Az IT referencia architektúra jellemzői:

• Biztosítja a teljes körű követhetőséget
• Folyamat, technológia és szállító független
• Szolgáltatás orientált és kompatibilis a Lean, Kanban menedzsment megoldásokkal is
• Az Open Group IT4IT Forum tagjai fejlesztik egy nyílt fejlesztési folyamat szerint

Az értéklánc megközelítés

Az értéklánc egy olyan menedzsment alapelv, ami az ipari gyártásban alapvető átalakulást jelentett. Az értéklánc olyan tevékenységek együttese, amelyeket egy gyártás-orientált szervezet végez annak érdekében, hogy piacra juttasson egy értékes terméket vagy szolgáltatást.

Az IT4IT az IT-t egy gyártás-orientált üzleti egységnek tekinti.

A négy értékáram

Nos, mit jelent ez az értéklánc, ami a termékeket úgy köti össze, hogy egy egységes menedzsment megoldás (az IT4IT) kialakuljon?

Ez először is és legfőképpen az ügyfél  nézőpontjából kezeli az IT alapvető tevékenységeit: tervezés – összeállítás – leszállítás – működtetés (Plan, Build, Deliver, Run).

Az első értékáram a stratégiától a portfólióig (S2P) terjedő szakasz. Itt annak a szolgáltatás portfóliónak a kiválasztása zajlik, amit az IT-nak működtetni kell. A tervezésnél figyelembe kell venni, hogy a meglévő szolgáltatások egy részét mikor és hogyan kell majd kivezetni vagy frissíteni újabb funkciókkal és milyen új szolgáltatásokat kell majd megvalósítani.  

Követelménytől az üzembeállításig (R2D) a második értékáram, ami a szolgáltatások összeállításával foglalkozik. Ekkor kell meghozni a döntéseket arról, hogy az előző, tervezéssel foglalkozó értékáram eredményeire építve hogyan fogjuk a magas szintű üzleti követelményeket olyan szolgáltatásokkal lefedni, amiket vagy házon belül állítunk össze, vagy kívülről fogunk beszerezni majd pedig üzembe állítani.

A harmadig értékáram a kéréstől a teljesítésig (R2F) terjedő szakasz, amely a szolgáltatásoknak minél korszerűbb, akadálytalan, fogyasztás centrikus és következetes módon történő leszállítására összpontosít. Az előző (követelménytől az üzembeállításig) szakaszban kifejlesztett vagy beszerzett szolgáltatásokat ebben a fázisban úgy tesszük elérhetővé a végfelhasználóink számára, hogy azt egy szolgáltatás katalógusból könnyen igénybe tudják venni. Ez a harmadik értékáram kezeli mindazokat a lépéseket, amelyek szükségesek a kezdeti felhasználói kéréstől a szolgáltatásnak a felhasználóhoz történő leszállításáig.

Az észleléstől javításig terjedő (D2C) értékáram, ami az ábra jobb oldalán szerepel, a szolgáltatás működtetésére összpontosít. Előre jelzi és megoldja a működéssel kapcsolatos problémákat. Ebben az értékáramban az üzleti szolgáltatás menedzsment az észlelésre, míg az IT szolgáltatás menedzsment a javítás részre összpontosít.

Szolgáltatás modell

A szolgáltatás modell az IT4IT referencia architektúrában szereplő központi fogalom.

A megfelelő minőség elérése érdekében a teljes értékláncot átfogó összefüggő szolgáltatás modell kialakítása célszerű. A szolgáltatásokkal a teljes értéklánc mindegyik szakaszában foglalkozunk, de más-más finomsággal: fogalmi, logikai illetve fizikai szintű szolgáltatásokat tervezünk. Először egy adott szolgáltatás tervezése úgy történik, hogy megértjük hogyan kell kinéznie a külső, üzleti felhasználó nézőpontjából, ami alapvetően még egy „fogalmi” szintű terv. Utána egy jóval konkrétabb, funkcionális specifikálás történik, ami majd az alapot biztosítja a szolgáltatás tényleges összeállításához. Ekkor a szolgáltatásnak még egy logikai modelljéről van szó, mint egy szolgáltatás sablonról, ami majd akkor válik fizikai modellé, amikor ez alapján szolgáltatás példányok jönnek létre és használatba kerülnek egy éles környezetben, üzembe állítjuk egy fizikai vagy virtualizált infrastruktúrán.    

A modell leírása az úgynevezett szolgáltatás gerincre (service backbone) összpontosít, vagyis azokra a kritikus adat artifaktokra, amelyek egybekapcsolják az elemeket, amelyek előírják a szükséges integrációkat és  az érintett menedzsment képességek kapcsolódási lehetőségeit. Miért célszerű ezt követni? Az üzleti igények megkövetelik a jó adatminőség és integritás biztosítását, amik alapján a teljes értéklánca vonatkozó betekintést tudunk biztosítani bármikor. Más szóval a szolgáltatásmodell gerinc összeköti az értékáramokat és lehetővé teszi a követhetőség, betekintés és tényeken alapuló mérések olyan szintű megvalósítását, ami szükséges az IT és a beszállítók megfelelő működéséhez.

Ami az IT4IT szabványban olvasható, az már nem egy elméleti, architekt megközelítés, hanem egy komoly részletes adatmodellezési munka eredménye, ami az Open Group nyilvános fórumának működéseként készült el a 2. szinten, majd pedig a 3-5 szinteken zajlott a HP Universal Data Model (UDM) kezdeményezésének részeként. A HP Universal Data Model 2.0 megfelel az IT4IT referencia architektúrának.

Az IT4IT referencia architektúra

Az IT4IT szabvány másik fontos komponense az IT4IT Referencia Architektúra, ami előírt útmutatókat biztosít, valós használati eseteket támogat és kiegészíti a meglévő folyamat keretrendszereket

A referencia architektúra négy alappillére:

• A szolgáltatás modell
• Az információs modell
• A funkcionális modell
• Az integrációs modell

A szolgáltatás modell lényege a fentebb már említett fogalmi, logikai és megvalósított (fizikai) szolgáltatás modellek összehangolt kezelése és a szintén említett szolgáltatás gerinc.

Az információs modell tartalmazza a szolgáltatás életciklus adat objektumait és azok kapcsolatait. Az adat objektumok jellemzői:

• Egy IT szolgáltatás egy bizonyos vonatkozását írják le
• Egy IT4IT funkcionális komponenshez vagy szolgáltatás életciklus fázishoz hozzárendelt be- vagy kimenetet jelentenek
• Egyedileg azonosítottak és saját életciklusuk van
• Olyan strukturált információt kezelnek melyek a kapcsolatok követését és automatizálást tesznek lehetővé

Az információs modell tartalmaz úgynevezett Kulcs adat objektumokat, Szolgáltatás modell objektumokat és Kiegészítő adat objektumokat.

A funkcionális modell kétféle funkcionális objektum típust tartalmaz:

• Az elsődleges funkcionális komponensek azok, amelyek kulcsszerepet játszanak egy megadott értékáram tevékenységeiben. Az adott funkcionális komponens nélkül az adat objektum integritása és így a szolgáltatás modell nem lenne konzisztensen és hatékonyan kezelhető. 
• A másodlagos (segéd) funkcionális komponensek valamilyen szintű függőséget vagy kölcsönhatást képviselnek egy értékárammal és annak adataival. Ezek bár kölcsönhatásban vannak egy értékárammal, nem jelentik annak a lényegi részét. Vagy egy másik értékáram számára elsődlegesek, vagy pedig támogató funkciók, vagy valamilyen képességet jeleznek.

Integrációs modell

Az IT4IT Referencia Architektúra az alábbi három kapcsolattípusból felépülő integrációs modellt határoz meg:

• System of Record (SoR): Hiteles forrás adatok kezelése rendszerek közötti interfészeknél. Ezek előírt kapcsolatok az IT4IT rendszer integritásának fenntartása érdekében.
• System of Engagement (SoE): Adat objektumok és emberek vagy funkcionális komponensek között kapcsolatok kezelőfelületen keresztül.
• System of Insight (SoI): Adat objektumok közötti kapcsolatok tudás, információ vagy elemzés generálása céljából.

Az IT4IT szabvány jelenleg elérhető v2.0 verziója a fentiek közül a SoR-okra helyezi a hangsúlyt. SoE kapcsolatok részben szerepelnek benne, a SoI kapcsolatok nincsenek definiálva ebben a verzióban.

IT4IT Referencia architektúra szintek

Az IT4IT Referencia Architektúra több absztrakciós szinten kerül megfogalmazásra, hasonlóan más referencia modellekhez, mint például a TM Forum eTOM modellje. Minden absztrakciós szint kiterjeszti, részletezi a magasabb szinteket. A felső szintek (1-3) szállító-függetlenek, és általános nézeteket tartalmaznak, amelyek alkalmasak stratégiai tervezés céljára. Az alsó szintek (4-5) több konkrét részletet tartalmaznak. A IT4IT Referencia Architektúra ötféle absztrakciós szintjét az alábbi ábra mutatja:

Az alábbi ábra az IT4IT™ referencia architektúra legfelső, első szintjét mutatja funkcionális komponensekkel, szolgáltatás modell objektumokkal és integrációs modell elemekkel.

                                                                                 

Enterprise architect szakismeretek, képességek

Egy közelmúltbeli konferenciára azzal kaptam meghívást, hogy többek között beszéljek arról, milyen jellemző tudásokkal, képességekkel, eszközökkel dolgozik az enterprise architect szakember. Nos, tekintsük át, mi minden merült fel ezen a téren.

Ha az elvárásokkal kezdjük, tény, hogy az emberek sokat várnak az architektől, úgy is fogalmazhatunk, elvárás, hogy az architekt legyen egy „biztos pont”, vagyis:

• Értse az ügyfél igényeket
• Segítsen abban, hogy versenyképesek legyünk, de azért csak biztonságosan (ne menjen pirosba a projekt!)
• Értelmezze, „fordítsa le” az elvárt üzleti eredményt
• Biztosítsa a kialakuló megoldás kiválóságát

Az architekt módszerek, bevált gyakorlatok maguk is segítenek a sikerhez vezető úton. Rögtön a kezdeti pánik legyőzésében is segíthetnek és a változások közepette stabilitást jelentenek, növelik a hatékonyságot: például többször segítettek olyan szűk idő korlátok között is eredményeket produkálni, ami ilyen módszerek, bevált gyakorlatok nélkül elképzelhetetlen lett volna.

Bármilyen területen is dolgozik az architekt, vannak a helyzeteknek tipikus, közös jellemzői. Amikor az összefüggésekkel, a megvalósíthatósággal, a portfólióval, a folyamatokkal foglalkozik, akkor az architektnek megbízhatónak, inspirálónak és kreatívnak kell lennie annak érdekében, hogy a csoportot segítse a siker irányába.

Összefoglalva az igazán jó architekt kiemelt jellemzője, hogy másokat vezet, inspirál, érdeklődik, utat mutat, kísérletezik, és hatékonyan kommunikál.

Hogy még plasztikusabban lássuk az architekt szakma kihívásait, álljon itt egy lista azzal a megjegyzéssel, hogy aki az alábbi felsorolás alapján magára ismer, az semmiképp ne vállaljon vállalati (enterprise) architekt munkát.

Az architekti munka kapcsán elvárás az állandó tanulási szenvedély, a komplexitás és többértelműség szeretete.

Az architektek számára szükséges ismeretek közül érdemes kiemelni az alábbiakat:

• A stratégia ismerete
• A portfólió ismerete
• A módszerek, folyamatok ismerete
• A teljes „technology stack” áttekintő ismerete
• Az iparág, üzleti prioritások ismerete
• Az irányítási folyamatok ismerete

Az ismeretek mellett ugyancsak fontosak olyan képességek, mint például:

• Jó kapcsolatteremtő képesség
• Hatékony kommunikáció képessége (szóban, írásban, prezentációban)
• Némi kereskedelmi véna is hasznos
• Megoldás keresés képessége
• Projekt életciklus tapasztalatok
• Minőségbiztosítási, értékelési képességek
• A felmerülő technológiai problémák üzleti nyelvezettel való kifejezésének képessége
• Kiterjedés és mélység egyensúlyban tartásának képessége

Végezetül hasznos tudni, hogy a szükséges architekt ismeretek, képességek módszeres összefoglalása megtalálható a TOGAF (The Open Group Architecture Framework) dokumentációban is ("Architekti képességek keretrendszere" fejezet). Ott az alább felsorolt ismeretek és képességek szükségességének mértékéről találunk információt.

A fenti lista minden eleméhez egy táblázat található a szöveg végén láthatóhoz hasonló formában, ami tartalmazza, hogy az adott képesség milyen mértékben szükséges az architekti munkán dolgozó csapat tagjai számára, akik tipikusan a következők:

• Az Architetekti Tanács tagjai
• Az architektúra szponzor
• Architektúra menedzser
• Architektek különböző architektúra területekre:

          - Enterprise Architecture

          (ami az alábbi táblázatok szempontjából úgy tekinthető, mint az
          üzleti, adat, alkalmazás és technológiai architektúra területek együttese)
          - Üzleti architektúra
          - Adat architektúra
          - Alkalmazás architektúra
          - Technológiai architektúra

•  Program és / vagy projekt menedzserek
•  IT Designer
•  és még sokan mások …

Itt egy példa a fentebb említett táblázatokra:

A 2016-os év kiemelkedőnek ígérkezik a TOGAF® Open Group szabvány szempontjából

Habár a vállalati architektúrák (Enterprise Architecture) tervezését, fejlesztését segítő legelterjedtebb keretrendszer, a TOGAF® (The Open Group Architecture Framework) első publikálása óta 20 év telt el jelentős fejlesztésekkel, mégis az idei 2016-os esztendő kiemelkedően fontosnak ígérkezik az architekt szakma és az azt használó szervezetek számára. 

A szakemberek két szinten szerezhetnek nemzetközi minősítést TOGAF ismereteikről. Ezek a TOGAF Foundation és a TOGAF Certified. A múlt hónapban meghaladta a kerek 50.000-es számot a világszerte TOGAF 9 minősítéssel rendelkező szakemberek összesített száma.

Lényeges változás, hogy amíg a múltban a TOGAF használata főként a szervezet belső informatikai rendszereinek átalakítását segítette, addig mára egyre inkább az üzleti transzformáció támogató eszközévé vált. A TOGAF fejlesztésén dolgozó szervezetek maguk is egyre inkább a digitális transzformációt támogató eszközt igényelnek. 

A szabványt a The Open Group Architecture Forum tagjai fejlesztik. Ebben a munkában ma már több mint 200 szervezet vesz részt a legkülönfélébb iparágakból az egész világból. Jelen vannak közöttük felhasználók, szállítók, tanácsadók, kormányzati és akadémiai, oktatási szervezetek is.

Nagy erővel folyik at TOGAF következő verziójának kidolgozása is. A jelenleg TOGAF NEXT munkanévvel ellátott új verzió megjelenésének még nincs hivatalosan kitűzött időpontja. Az várható, hogy az új verzió kapcsán külön dokumentumban jelenik meg a TOGAF keretrendszer magját alkotó fogalmak és módszertan leírása és ettől elkülönülve külön dokumentáció készül a használatot segítő eszközök és technikák leírására, valamint külön útmutatók lesznek elérhetőek például vezetőknek, egyes architekturális területeken dolgozóknak, biztonsági szakembereknek stb.

Jelentős esemény volt, hogy 2016. január 25-én megrendezésre került az első TOGAF® User Group Meeting San Franciscóban. A TOGAF fejlesztői eddig is rendelkeztek világméretű szervezettel: az említett Architecture Fórum erre szolgált. Hiányzott azonban a TOGAF felhasználóinak ilyen szintű közössége.

Itthon az AEA Magyar Tagozat a nemzetközi Association of Enterprise Architects (AEA) szakmai szervezet magyar tagszervezete évek óta foglalkozik a TOGAF népszerűsítésével, oktatásának támogatásával, a tapasztalatok megosztásával. A havonta megrendezésre kerülő hazai AEA Klub rendezvényeken rendszeresen visszatérő téma a TOGAF architektúra keretrendszer szabvány is.

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.