Architektúra változáskezelés

A legutóbbi blog bejegyzés az architektúra irányítás (governance) kérdéseivel foglalkozott általánosságban. Nos, az egyik legérdekesebb architekti terület az architektúra változások kezelése, így most erről lesz szó. A mai alkalommal nézzük meg a változások kezeléséhez javasolható megközelítési módot.  

Az architektúra változások kezelésének javasolt megközelítési módja

Célszerű, hogy már a szervezet architekturális alapelv gyűjteménye is tartalmazza a változáskezelési folyamat fontosságát az alábbihoz hasonló formában:

Megfelelően reagáló változáskezelés: A változáskezelés folyamatát úgy kell kidolgozni, hogy biztosítsa a megfelelő időben történő érdemi reagálást a változtatási igényekre a szervezet információs rendszereit illetően. 

A változáskezelés célja

Az architektúra változáskezelési folyamatok alapvető célja annak biztosítása, hogy az architektúra elérje eredetileg megcélzott üzleti értékét. Ez magában foglalja az architektúrák változásainak összefogott és megfelelően kialakított kezelését.

Magának az architektúra változáskezelésnek általában tehát az alábbi alapvető céljai vannak: 

• Az architektúrák teljes életciklusa megfelelő kezelésének biztosítása
• Annak biztosítása, hogy a szervezet architektúrái megfeleljenek az aktuális követelményeknek
• Az architektúra irányítási rendszer megfelelő működésnek biztosítása

Az architektúra változáskezelési folyamat egyik célja az is, hogy olyan architektúrák megvalósítását és támogatását segítse, amelyek bizonyos mértékig dinamikus architektúráknak tekinthetőek. Ez utóbbi azt jelenti, hogy olyan rugalmassággal kell rendelkezniük, melyek alapján a technológiai és üzleti változásokra válaszul viszonylag gyorsan továbbfejleszthetők legyenek. 

Megfigyelés

A változáskezelési folyamat a gyakorlatban célszerűen olyan dolgok folyamatos megfigyelését tartalmazza, mint például az architektúra irányítással kapcsolatos felmerült kérések, javaslatok, vagy például a technológia újabb eredményei, az üzleti környezet változásai. Ha változásokat azonosítunk, akkor a változáskezelési folyamat részeként meg kell határoznunk, hogy milyen mértékű architektúra változtatás szükséges: csak kisebb korrekciókat kell elvégezni, vagy szükségessé válik egy új architektúra fejlesztési ciklus elindítása.

A változáskezelési tevékenységeknek egyik fontos része az üzleti növekedések és visszaesések megfigyelése is. Az nem lehet jó megoldás, ha az üzlet egy olyan architektúrával kell, hogy működjön, ami egy korábbi időszaknak ugyan megfelelő volt, de a szervezet jelenlegi és jövőbeni szükségleteihez már nem tudja a megfelelő képességeket biztosítani.

A változáskezelésnek fontos részét képezi a kapacitás mérés és a tervezési ajánlások megfelelő használata is. Általában az eredeti alkalmazás architektúra kialakítása egy meghatározott kapacitásokat igénylő, stabil állapotú üzleti architektúrára alapozva történt (annak életciklusára legalábbis). Később a használattal kapcsolatos igényekben tapasztalható változásokat folyamatosan figyelni kell azért, hogy a lehetséges legnagyobb üzleti érték elérhető legyen.

Amennyiben az architektúrák fejlesztésének korábbi fázisaiban a teljesítménykezelés és riportkészítés már beépült a megvalósításokba, akkor az architektúra változáskezelés ezek hatékony használatával történhet. Ha további monitorozás és jelentések szükségesek, akkor a változáskezelési folyamatok részeként kell ezeket is megoldani. A helyzet az adott szervezet architekturális fejlettségi szintjétől függ ebben az esetben is: az architektúra változáskezelés jóval egyszerűbb magasabb architekturális fejlettségi szint esetén.

Az is gyakran megtörténik, hogy maga az architektúra még továbbra is megfelelne, de az alatta lévő konkrét megoldások (alkalmazások) már nem megfelelőek, azokon változtatások szükségesek. Az architekteknek tisztában kell lenniük az ilyen típusú változáskérésekkel is és ezeket az architektúra állandó megújítása fontos részeként kell kezelniük.

Olyan esetekben, amikor egyes megoldás-architektúrák (alkalmazások) nem skálázhatók bizonyos határon túl, avagy más megoldások gazdaságosabbak lennének növekedés esetén, lehetséges, hogy a vállalati architektúra specifikációk maguk ugyan nem változnak, de a megoldások (alkalmazások), vagy azok működési környezete változtatásra szorul.   

Módosítás vagy újratervezés

A megfelelően kialakított változáskezelési folyamatnak alkalmasnak kell lennie azoknak a körülményeknek a meghatározása, amelyek esetén a bevezetett architektúra változása megengedett, és meg kell határozni azt a folyamatot, amelyik szerint a változtatás meg fog történni. Ugyancsak alkalmasnak kell lenni azoknak a körülményeknek a meghatározására is, amelyek esetén az architektúra fejlesztési ciklus újra inicializálásra kerül és egy új architektúra kialakítása történik meg.

Az architektúra változáskezelés szempontjából lényeges, hogy az erre jogosult irányítási testület világos kritériumokat fogalmazzon meg azért, hogy a változáskezelési folyamat során eldönthető legyen, hogy a változtatási kérés csak egy viszonylag egyszerűbb architektúra frissítést jelent, vagy pedig egy újabb architektúra fejlesztési ciklus elindítását kívánja. Különösen fontos a véget nem érő, örökké tartó, de igazi értéket nem termelő fejlesztések ("creeping elegance" hatások) megelőzése. Az irányító testületnek olyan változtatásokra kell irányítania a figyelmet, amelyek közvetlen üzleti értékhez köthetők.

További megjegyzések a változáskezeléshez

Az architektúra változáskezelési folyamat szorosan kapcsolódik egyrészt az szervezet általános architektúra irányítási folyamataihoz, másrészt a – célszerűen elkészítendő - úgynevezett architektúra megállapodásokhoz. Ez utóbbiakat az szervezet üzleti felhasználói és az architektúra tervezési, bevezetési feladatokkal megbízott vállalati funkció (vagy külső szereplő) között célszerű rögzíteni (formalizáltan, vagy nem kifejezetten ebben a formában rögzítve, implicit módon).

A változáskérések esetén szükséges architektúra megfelelőségi jelentéseknek világosan tartalmazniuk kell, hogy a változás megfelel-e az aktuális architektúrának. Ha nem felel meg, felmentés adható érvényes indokok esetén meghatározott időszakra. Ha a változás nagy hatást gyakorol az architektúrára, akkor ki kell dolgozni a megfelelő stratégiát a hatás kezelésére.

Ezeknek a követelményeknek a pontos meghatározása nehéz általános ajánlásokat megfogalmazni, ezek az adott szervezet kockázatkezelési sajátosságaitól nagymértékben függnek. Ha a megfelelő architekti képességek és gyakorlat az adott szervezetében kialakításra került, akkor a TOGAF ADM (Architektúra fejlesztési módszer) szerinti működés hatására az irányító testület is egyre gyakorlottabbá válik és a követelmények egyre jobban illeszkednek az szervezet szükségleteihez. 

Következő blog bejegyzésben majd a változások okaival, a jellemző hajtóerőkkel folytatjuk.

Összefoglalás

Az architektúra változáskezelés megfelelő folyamatainak megtervezése és az azoknak megfelelő működés kialakítása jelentős eredményekkel járhat a szervezet számára.

Mint az összes, architektúrákkal kapcsolatos folyamatra, így a változáskezelési folyamatokra is kiemelten igaz, hogy a szervezet architekturális fejlettségi szintjétől erősen függ ezeknek a folyamatoknak a megfelelő kialakítása. A folyamatok részletes kidolgozását célszerű egy olyan projekt keretében elvégezni, ami kifejezetten az szervezet architekti működésének kialakítását célozza, annak minden vonatkozásával (működés, szervezet, felelősség, folyamatok, információk, stb.). Egy ilyen projekt részeként a folyamatok konkrét kidolgozása előtt mindenképp célszerű egy architektúra fejlettségi szint felmérést végezni és annak eredményeit figyelembe véve ajánlott a folyamatok részletes kidolgozása.

Architektúra irányítás - Architecture Governance

Az utóbbi időben több magyar vállalatnál, szervezetnél jól érzékelhetően megfogalmaztak enterprise architektúra (EA) célokat, elvárásokat és ezek pályázatokban, tenderekben is megjelentek különféle formában. Ez mindenképp örömteli hír az architektek, a szakma számára: a hosszas evangelizálás után most már megrendelői oldalról jelenik meg elvárásként valamilyen EA módszer használata, néhány helyen konkrétan a TOGAF keretrendszer ismerete, használata, szakemberek rendelkezésre állása, mint feltétel. Logikus, hogy elsőként a szállítók kiválasztásánál jelenik meg feltűnően az EA mint szűrő feltétel. Ami azonban a hazai érettséget még inkább jellemzi, az a tény, hogy több szervezet foglalkozik saját EA képességeinek, gyakorlatának kialakításával. Nos, néhány ilyen kezdeményezést látva, némelyekben közreműködve, azt gondolom, itt az idő az architektúra irányításról (architecture governance) írni ebben a blogban is.

Az alábbiakkal a cél egy rövid útmutatás, kiindulási szempontok bemutatása az architektúra irányítás (architecture governance) kialakításához. Ahol még nincs kialakult EA képesség, ott javasolt egy kifejezetten az architekti megközelítési mód, az architektúra szemléletű működés megalapozására irányuló, annak legfontosabb elemeit kialakító, erre fókuszáló projekt indítása. Ennek során kialakítható a saját, testreszabott, legmegfelelőbb architektúra irányítás is.

Ehhez kiindulásul most az általános vállalati architektúra legjobb gyakorlatán, a TOGAF-on (The Open Group Architecture Framework) és néhány szervezet eddigi tapasztalatain alapuló megfontolások következnek.

Az architektúra irányítás természete, szintjei

Nézzük először az irányítás (governance) természetét általánosságban, valamint a lehetséges szintjeit.

Az architektúra irányítás alapvetően azt a gyakorlatot és hozzáállást jelenti, amivel az adott szervezet architektúráinak menedzselése és kontrollálása történik.

Közeli, rokon fogalmak a „governance”, vagyis az irányítás és a „management”, ami jobb magyar szó híján szintén a vezetés, intézés, irányítás tevékenységeit takarja. A most tárgyalásra kerülő „governace” elsősorban a szabályok betartásának felügyeletét, a szabályszerűséget, a szabályokkal összhangban történő működés számonkérését és ennek támogatását, elősegítését jelenti. Amennyiben a menedzsment a szervezet működtetését jelenti, akkor a governance arról szól, hogy figyelemmel kísérjük azt, hogy megfelelően működjön a szervezet.

A hatékony architektúra irányítás biztosítja egyrészt azt, hogy a problémákat korán azonosíthassuk, másrészt azt, hogy a környezet folyamatos változásai kontrollált formában zajlódhassanak.

Az architektúra irányítás nem elszigetelten létezik, több kapcsolódó irányítási struktúra hierarchiájában működik: a vállalatirányítás, a technológiai irányítás, az IT irányítása mind összefügg az architektúra irányítással is.

Mindezek az irányítási struktúrák másik dimenziót tekintve létezhetnek például vállalat-csoport vagy anyavállalat szinten és az adott szervezet, vállalat szintjén is és adott esetben földrajzi tagolásban is megjelenhetnek olyan szervezeteknél, amelyek több helyszínen működnek.

Az architektúra irányítás jellemzői

Az architektúra irányítás tehát a fentieknek megfelelően alapvetően azt a gyakorlatot és hozzáállást jelenti, amivel az adott szervezet architektúráinak menedzselése és kontrollálása vállalati szinten megtörténik. 

Az architektúra irányítás tartalmát legfőképpen az alábbiak alkotják:

• Ellenőrző rendszerek bevezetése

Ezek tárgya az architektúra komponensek és tevékenységek létrehozása és monitorozása. Céljuk az architektúrák hatékony bevezetésének, megvalósításának és fejlesztésének biztosítása.

• A szükséges megfelelőségeket biztosító rendszer bevezetése

Ennek fő célja a belső és külső szabványoknak és szabályozási kötelezettségeknek történő megfelelés biztosítása.

• Folyamatok bevezetése

Ez ügyben olyan folyamatok kialakítása szükséges, amelyek támogatják a fenti rendszer hatékony menedzselését, megállapított paraméterekkel.

• A felelősségre vonhatóság biztosítására

Biztosítani kell az adott szervezeten belüli és kívüli, pontosan meghatározott érdekelt felek felé a felelősségre vonhatóságot.

Az architektúra irányítás, mint vezetői felelősség

Az IT irányítás (a fenti governance értelemben) a legtöbb szervezetben már egyértelműen a vállalati felső vezetés felelőssége ma is az általános üzleti irányítás részeként. Az architektúra irányítás pedig kulcsfontosságú az informatika üzleti célú használatának eredményessége terén. Ilyen módon az architektúra irányítás is mindinkább felső vezetői szintű felelősséggé válik önmagában is.

Fontos feladat ezzel kapcsolatban az IT és az architektúra irányítás nyitottságának megteremtése, a működés átláthatóságának, kontrollálhatóságának javítása, azért hogy az üzleti terület ide kapcsolódó feladatait tisztázni és kezelni lehessen az architekturális tevékenységek terén is.

A TOGAF felhasználása az architektúra irányításban

A TOGAF a legelterjedtebb architektúra keretrendszer, amely összefoglalja a legjobb bevált gyakorlatokat és részletes módszertant, folyamat leírást tartalmaz új architektúrák meghatározása, az átmenet megtervezésére, valamint az új architektúrákat megvalósító implementációs projektek architekturális felügyeletének tevékenységeire. Külön fejezetben foglalkozik igen részletesen az architektúra irányítás ajánlott, bevált gyakorlatával is.

Az architektúra irányításnak csak az egyik területét jelenti az a fázis, amelynek során a megvalósítási projektek architekturális megfelelőségét szokás vizsgálni. Az architektúra irányítás számára egy olyan rendszert kell kialakítani, amely hatékony folyamatokat határoz meg, amelyek biztosítják azt is, hogy az architektúra irányítás üzleti felelőssége is hatékonyan kezelhető legyen. Ennek bevált formája egy vállalati architektúra irányítási rendszer kidolgozása. 

Architektúra irányítási keretrendszer

Az architektúra irányítás egyik fontos aspektusa a fentebb már említett implementáció-irányítás, de ennél szélesebb feladatköre van. Az irányításnak foglalkoznia kell az architekturális tevékenységek teljes körével, közte a fentieken túl többek között az új architektúrák tervezésével, az alapelvek, a követelmények folyamatos karbantartásával.

Az adott szervezet architektúra irányítási rendszerének kialakításához kiinduló pontként jól felhasználható a TOGAF-ban szereplő általános architektúra irányítási keretrendszer, amit az adott szervezet sajátosságainak megfelelően kell átalakítani. Ennek részeként hatékony működőképes folyamatokat kell meghatározni az architektúra irányítás területére, a vonatkozó szervezeti, felelősségi, képzési és egyéb szempontok figyelembevételével.

Az architektúra irányítás koncepcionális szerkezete

Az alábbi ábrában összefoglalt modell a már említett, a TOGAF részeként dokumentált, általános architektúra irányítási keretrendszer szerint ábrázolja az architektúra irányítás célszerű komponenseit.

Lényeges sajátossága az ajánlott modellnek a folyamatok különválasztása a hozzájuk kapcsolódó tartalmaktól. Amennyiben összevont dokumentumok írják le a legfontosabb architektúra irányítási folyamatokat a hozzájuk tartozó tartalmakkal, akkor minden változás (akár folyamatváltozás, akár bizonyos tartalmak változása) a teljes dokumentáció változtatását vonja maga után. A szétválasztás tehát a későbbi változások átvezethetősége miatt is hasznos. 

Összegzés

Azoknál a szervezeteknél, ahol az EA megközelítés igénye megfogalmazódott, de még a saját EA képességek kialakítása nem történt meg, ott ajánlott az EA irányítás megfelelő megtervezése. Ehhez jó kiindulópont lehet a TOGAF, azon belül is az architektúra képességek keretrendszere, az Architecture Capability Framework architektúra irányítással foglalkozó része. Mindenképpen érdemes mások bevált gyakorlatát megismerni ebben az esetben is.

CIO fegyvertár 2014

Sok szó esik manapság a vállalati informatikai igazgatók (CIO) szerepének átértékelődéséről. Egy közelmúltbeli konferencia beharangozója meglehetősen harcias nyelvezettel fogalmazott:

„Kihirdették az elemzők az ostromállapotot. Már nem is azt az öt-tíz éve egyébként elképzelhetetlennek tartott kérdést teszik fel, hogy fontos-e a belső IT, az IT szervezete a vállalatok életében, hanem egyenesen azt firtatják, hogy fontos-e az informatikai vezető, szükség van-e egyáltalán a CIO-ra.” (CIO.hu 2014 konferencia, Sümeg)

Nos, meghívást kaptam a konferenciára azzal az instrukcióval, hogy gyakorlati segítségre van szükség a CIO-k számára ebben a helyzetben. Átgondolva, mit is ajánlhatok, végül is (a katonai szóhasználatnál maradva) 3 éles harci fegyvert és egy hasznos tapasztalatokkal rendelkező reguláris csapatot ajánlottam a résztvevők figyelmébe.

Enterprise Architecture
Az első harci fegyver a vállalti informatikai vezetők számára egy alapállás, megközelítési mód, egy elterjedt módszertan átvétele, adaptálása volt. Ez pedig az Enterprise Architecture (EA) és annak legelterjedtebb, nemzetközi, gyártó független keretrendszere a TOGAF® (The Open Group Architecture Framework).

A TOGAF segít megtalálni a legmegfelelőbb utat a stratégiától a megvalósításig, a magas szintű elképzelésektől a konkrét fejlesztési, bevezetési projektekig.

A TOGAF architektúra fejlesztési módszertana, az ADM (Architecture Development Method) együttműködve más fontos módszertanokkal, mint a projekt menedzsment, a szoftver fejlesztés és az IT üzemeltetés bevált módszereivel, biztosítja a szervezet céljainak támogatását az átfogó szemlélet, a módszeres tervezési lépések révén.

A TOGAF négy terület összehangolt vizsgálatával, tervezésével foglalkozik: az üzlet-, az adatok-, az alkalmazások és a technológia architektúráját fedi le.

ArchiMate

A TOGAF a legelfogadottabb Enterprise Architekt keretrendszer, és módszertana az ADM elismerten a legkidolgozottabb ebben a műfajban. Megvannak azonban a TOGAF határai is: nem ad részletekbe menü útmutatást a javasolt dokumentumok (u.n. architekturális artifaktok) elkészítésének részleteihez. Vagyis nincs benne definiálva egy szabványos nyelv erre a célra. A célszerű lépések a keretrendszertől a módszertanon át egy pontosan definiált leíró nyelvhez vezetnek az alábbiak szerint.

A második harci eszköz ezért egy nyelv, egy grafikus tervező, modellező nyelv, ami kifejezetten a vállalati architektúrák meghatározására készült: ez az ArchiMate®.

Hogy hogyan is kapcsolódik az ArchiMate és a TOGAF, azt már részleteztem egy korábbi blog bejegyzésben. A lényeg az alábbi ábrából is látható.

IT4IT

A harmadik fegyver volt talán a legkevésbé ismert a CIO-k között: az IT4IT^TM. Ez (hasonlóan a TOGAF-hoz és az ArchiMate-hez) szintén egy Open Group szabvány, de az architektúra keretrendszerrel ellentétben eléggé új kezdeményezés. Hivatalosan a The Open Group konferenciáján Londonban 2014. október 20-23-án kerül nyilvánosan bejelentésre.

AEA Magyar Tagozat

Nos, utoljára maradt a beígért alakulat, a szervezett haderő. Az Enterprise Architekt szakemberek vezető szakmai szervezete a világon az AEA (Association of Enterprise Archiects), melynek pár éve már működik a helyi szervezete is, az AEA Magyar Tagozat. Ez utóbbi egyesület elnökeként ajánlottam a CIO-k figyelmébe a lehetőséget: csatlakozhatnak egy aktív szakmai közösséghez, melyben a problémák, kérdések megosztása, megvitatása is lehetséges a legjobb bevált gyakorlatok megismerése mellett.



Üzenet

Zárásul, azzal a napóleoni üzenettel búcsúztam a CIO-któl, mely szerint legjobb védekezés a támadás! Vagyis a CIO pozícióval szembeni kétségek, aggályok kezelésére legjobb megoldás az adott szervezetnél az Enterprise Architect megközelítés, és az ilyen típusú képességek kialakítása. A CIO pedig álljon a kezdeményezés élére, legyen az ügy élharcosa, ezzel váltson szerepkört is: akit eddig karmesterként a vállalati informatikai „zenekara” vezetőjének tekintettek, az legyen sokkal nyitottabb az IT-n kívül a szervezet üzleti tevékenységei irányába is és az EA módszertan révén egy szélesebb körű megközelítésben segítse a szervezet üzleti céljainak elérését.

Ehhez jelent azonnal használható fontos fegyvereket a TOGAF, az ArchiMate és az IT4IT, valamint az AEA Magyar Tagozattal való együttműködés is.

Az ArchiMate architektúra leíró nyelv és az UML

Ez a bejegyzés is úgy születik, mint több korábbi társa: olyan kérdést kaptam, amire a választ célszerűnek látszott mások számára is elérhetővé tenni. Nos, a napokban a régióban dolgozó architekt kollégáim számára tartottam egy bevezető előadást az ArchiMate architektúra leíró nyelvről és ennek végén kaptam az alább ismertetendő kérdést.

Korábbi tudás felhasználása

Az ArchiMate grafikus nyelvről beszélve egy lényeges sajátosság, hogy a nyelv jelölései hasonlóak az UML (Unified Modelling Language) és a BPMN (Business Process Modeling Notation) nyelvek jelöléseihez főként azért, hogy az architekt szakemberek által már korábban megszerzett tudás közelében maradjunk, annak elemeit felhasználhassuk.

Vannak azért a hasonló jelölések mellett lényeges különbségek is például az ArchiMate és az UML között. A különbségekkel kapcsolatos konkrét kérdés ismertetése előtt röviden szükséges néhány fogalom bevezetése.

Néhány fogalom a kérdés előtt

Egy egyszerű példa alapján azonnal érthető a nyelv úgynevezett strukturális és viselkedési elemeinek mibenléte: a „József könyvet olvas” helyzet modellezhető 3 elemmel:

• József mint szereplő (actor) egy szerkezeti elem,
• az olvas modellezhető egy folyamatot jelző elemmel (business process), ami példa a viselkedési (behavioral) elemekre,
• a példában a könyv mint objektum (business object) egy passzív elemként jelenhet meg.

Fontos fogalom még a nézőpont illetve nézet (viewpoit/view) is, hiszen minden érintett félnek lehetnek sajátos egyedi nézőpontjai egy adott architektúrával kapcsolatban.

Az ArchiMate lehetővé teszi a tervező számára, hogy az architektúra egyes nézeteinek kidolgozása során egy azon nézőpont tartalmazzon szerkezeti és viselkedési elemeket is. Az UML esetében viszont lényegesen megkülönböztetik a szerkezeti és a viselkedési diagramokat, a modellezés módja ott jóval szigorúbb.

ArchiMate – UML kérdés

És itt következik a kérdés: vajon az ArchiMate és az UML közötti fenti különbség elsősorban annak a következménye, hogy a két nyelv eltérő feladatokra született (különböző szintek modellezésére), avagy egyszerűen a nagyobb rugalmasság érdekében történt ezen a téren változás az ArchiMate létrehozása során?

Nos, az ArchiMate valóban eltérő megközelítést alkalmaz, mint az UML abban a vonatkozásban, hogy nincsenek előre elszeparálva a fogalmak külön diagramokba, hanem lehetővé teszi a teljes modellre (vagy annak bizonyos elemeire) vonatkozó nézetek elkészítését. Ez a rugalmasság szempontjából is szükséges, de megköveteli ezt a nézetek és nézőpontok (views és viewpoints) megfelelő támogatása is, hiszen ezek nagyon lényegesek az architektúrák definiálásánál. (lásd az IEEE 1471 / ISO 42010 szabványokat is)

Az ArchiMate használata során a tervező 18 előre definiált standard nézőpont közül választhat. Ezek közül némelyek hatóköre egyetlen rétegre vagy aspektusra van korlátozva. A nézőpontokhoz meghatározásra került, hogy mely nyelvi komponensek használhatók az adott nézőpont esetében. Például az úgynevezett rétegzett nézőpont (Layered Viewpoint) esetében egy adott architektúrának bemutatható több rétege és aspektusa is egyetlen diagramon. Ez a nézőpont például tartalmazhat mind szerkezeti mind viselkedési elemeket együttesen. Az alábbi képen erre láthatunk egy példát.

Természetesen a nézőpontoknak és nézeteknek sajátossága, hogy egyenként korlátozott jellegűek. Ezek mindegyike bizonyos korlátokkal mutatja be a teljes architektúrát, általában meghatározott aspektusokból. Ezért egyetlen nézet mindig csak korlátozott, nem teljes képet mutat a rendszerről. A nézetek összekapcsolódnak és sok esetben éppen azzal lehet a legjobban leírni és kommunikálni egy architektúra lényegét, ha bemutatjuk több nézet kombinációját és azok összefüggéseit. 

Akiket érdekel az ArchiMate architektúra modellező nyelv, azoknak ajánlom a nyelv "atyjának", Marc Lankhorst belga szakembernek, az Enterprise Architecture (EA) szakma nemzetközileg elismert szaktekintélyének Budapesten tartott előadását, melyben bemutatta az Enterprise Architecture modellezési szabványát jelentő ArchiMate történetét és fejlesztését és ismertette a szabvány hátterét, céljait és alapelveit is. Az AEA Magyar Tagozat által szervezett szakmai programon látott prezentáció letölthető az említett egyesület honlapjáról. 

TOGAF Gyakori kérdések

Néhány a TOGAF kapcsán többször elhangzott kérdésre az alábbiakban rövid válaszokat gyűjtöttem össze.

Mi az a TOGAF?

Egy menedzsment keretrendszer olyan architekt szakembereknek (kb. nagyvállalati tervezők), akik valamilyen vállalati átalakítási programot irányítanak. A betűszó jelentése: TOGAF = The Open Group Architecture Framework. A TOGAF tehát nem egy architektúra, hanem egy keretrendszer, ami felhasználható adott konkrét architektúrák fejlesztése során.

Vannak a TOGAF-nak verziói?

Igen, a TOGAF aktuális verziója a 9.1 és folyamatban van a következő verzió kidolgozása, melynek kódneve TOGAF NEXT.

Ki írta a TOGAF-ot?

Nincs sem egyetlen szerző, sem szerzők meghatározott csoportja. Ehelyett több száz önkéntes közreműködő írta sok év alatt. A TOGAF fejlesztését a The Open Group fogja össze.

Kiknek készült a TOGAF, kiknek érdemes használni?

Olyan Enterprise Architect szakemberek számára készült, akik több szervezetet érintő integrációval és szabványosítással foglalkoznak. A TOGAF nem a megoldás tervezőknek (Solution Architect), nem a szoftverfejlesztési folyamatban dolgozóknak és nem az IT üzemeltetőknek hasznos.

Hol van a TOGAF helye az üzlet és technológia közötti skálán?

A használatán múlik. A TOGAF eléggé általános és széles területet fed le. A használata során kell eldönteni, mi a határa annak a rendszernek, amire használni kívánjuk. Használható szűken csak üzleti változásokra fókuszálva, de ugyanúgy felhasználható például a technológiai infrastruktúra racionalizálásánál is.

Inkább stratégiai vagy pedig taktikai területen hasznos a TOGAF?

Nagyrészt inkább stratégiai szintű felhasználásra készült. Leginkább a több szervezetet érintő stratégiai vállalati architektúrák és IT architektúrák támogatására hasznos. A TOGAF részét képező ADM (Architecture Development Method) egy olyan magas szintű folyamatot ír le, amely egy stratégiai tervet állít elő, ami szerint általában több megvalósítási projekt ütemezése valósul meg. A megvalósítási projektekhez olyan architektúra megállapodásokat biztosít, amelyek megadják az architekturális célokat, az alapelveket, szabványokat, referencia modelleket és felhasználható építőelemeket.

Milyen szoftver eszközök használhatók a TOGAF felhasználása során?

Sok hasznos szoftver létezik. Maga a TOGAF dokumentum nem említ egyetlen konkrét terméket vagy gyártót sem. Van azonban egy termék tanúsítási programja is az Open Group-nak. Az éppen érvényes TOGAF tanúsítvánnyal rendelkező szoftverek listája elérhető az Open Group honlapján: http://www.opengroup.org/certifications/togaf9-program/ts-register Természetesen ezeken kívül is vannak jól használható programok mind a fizetős mind az ingyenesen elérhető kategóriában. A legmegfelelőbb eszköz mindig a konkrét architektúra projekt ismeretében választható ki. Vannak olyan architektúra projektek, melyek a szokásos irodai szoftverekkel jól lebonyolíthatók, de vannak, amelyek kellően összetett modellező képességeket vagy éppen nagy kapacitású fejlett repository szolgáltatásokat igényelnek.

Miért olyan hangsúlyos a TOGAF-ban a szállító függetlenség, technológia-függetlenség, integrálhatóság és az átjárhatóság?

A TOGAF mögött a The Open Group szervezet áll, melynek alapvető küldetése az említett szempontok szem előtt tartása.

Miért hangsúlyozza annyira a TOGAF a döntések indoklásának dokumentálását és a megoldásoknak a követelményekkel való összevetését?

Ez a hangsúly azonnal érthető, ha arra gondolunk, hogy az Enterprise Architecture nagyrészt azért fejlődött ki a kezdeti időben, hogy javítsa a kormányzati beszerzési folyamatokat és az üzlet és informatika harmóniáját.

Használható a TOGAF a megoldás-tervezés során is?

A használata lehetséges ezen a területen is, hiszen a TOGAF tartalmaz olyan ötleteket és technikákat is, amelyek a megoldás tervezők számára is hasznosak. Ilyen helyzethez a módszer testreszabása szükséges.

Használható a TOGAF a megvalósítás életciklusának menedzselésére?

Csak nagyon jelentős adaptáció után képzelhető el. Számos fogalom nem szerepel a TOGAF-ban, mely fontos az implementációs életciklus során (szoftver tervezés, tesztelés, konfiguráció kezelés, stb.)

Mi a kapcsolat a TOGAF és az ArchiMate között?

A TOGAF egy architektúra keretrendszer, mely tartalmaz egy architektúra fejlesztési módszertant (ADM). A módszer alkalmazásához hasznos egy elfogadott jelzésrendszer és jelentéstartalom, vagyis egy meghatározott nyelv használata. Nos, az ArchiMate egy ilyen architektúra leíró grafikus nyelv. A TOGAF és az ArchiMate nyelv nagyon közel állnak egymáshoz: a felhasznált fogalmak (az un. metamodell) közel azonos.

Mi a TOGAF viszonya a RUP-hoz?

A RUP a rendszerfejlesztési életciklussal foglalkozik. Ha össze akarjuk a kettőt kapcsolni, akkor a TOGAF ADM fázisok közül az A-F fázisokat tekinthetjük a RUP kezdeti fázisának. A TOGAF G fázis alatt futnak a szoftver implementációs projektek, így az tekinthető a RUP kidolgozás, megépítés és átmenet fázisai együttesének.

Lehet tanúsítást szerezni a TOGAF ismeretekről?

Igen, a TOGAF megismerésére mind oktatási, mind tanúsítási programok is rendelkezésre állnak. Vizsgát lehet tenni minden PROMETRIC vizsgaközpontban szerte a világon. Jelenleg két szintű vizsga tehető. Mindkettő számítógép előtt zajlik, angol nyelven. Oktatás terén is többféle lehetőség van. Ebben segíthet például az AEA Magyar Tagozat nevű hazai egyesület is: www.aeahungary.org 

ArchiMate és TOGAF

Annak, hogy az ArchiMate előkerüljön mostanában ezeken az oldalakon is, van egy konkrét apropója: nemrég jelent meg a legfrissebb verzió az ArchiMate v2.1, 2013. decemberben.

Na de kezdjük kicsit korábban: mi is az ArchiMate és mi köze van a címben szereplő TOGAF-hoz?
Hogy még messzebbről indítsunk: a TOGAF kapcsán a legtöbb kifogást azzal kapcsolatban hallom, hogy miért nem tartalmaz sokkal több praktikus, gyakorlatban azonnal használható elemet, miért nem határozza meg az ajánlott artifactok pontos formátumát, miért nem javasol konkrét szoftvert az architektek munkájához és hasonlók. Nos, ezek teljesen jogos igények a praktizáló architektek felől, azt viszont fontos pontosan látni, hogy az igényekből mi esik egy általános enterprise architecture (EA) keretrendszer illetékességi területére, és ami nem, azzal mi, hol foglalkozik.
TOGAF-tól az ArchiMate-ig

Mind a TOGAF, mind pedig az ArchiMate az Open Group terméke. Felmerül hát, hogyan könnyíti meg az architektek életét az egyik, a másik vagy a kettő együttes használata?

Azt, hogy mi a kapcsolat az architektúra keretrendszer a modellező nyelv között, az alábbi ábra szemlélteti. A kék dobozokban szereplő fogalmak (Keretrendszer, Módszertan, Nyelv, Eszköz) mellett példaként szerepel a TOGAF, az ADM (a TOGAF keretrendszerben található módszertan, az Architecture Development Method), az ArchiMate nyelv és az Archi szoftver neve.

Bármelyik komoly architektúra keretrendszert nézzük, annak tartalmaznia kell valamiféle architektúra fejlesztési módszert is. Van, amikor ez kifejezetten erős, domináns része a keretrendszernek (a TOGAF esetében ez a helyzet), míg más architektúra keretrendszerek esetleg jobban az architekti termékekre koncentrálnak. Ezért indul a fenti ábra az architektúra keretrendszerrel, ami vagy tartalmazza a saját architektúra fejlesztési módszertanát, vagy hozzá kell kapcsolni egy ilyen módszertant. Bármilyen módszertan szerint is dolgoznak az architektek, kell egy egyezményes nyelv, amit követnek a különböző artifaktok előállítása során. Nos, erre egy példa az ArchiMate. Végezetül a kiválasztott (és szükségszerűen testre szabott) keretrendszer és a kiválasztott, adaptált módszertan és jól definiált modellező nyelv mellett még szükség van (egy vagy a gyakorlatban inkább több) szoftver eszközre is, ami a fentieket támogatja. Erre egy példa az Archi, de ez egy olyan érdekes kérdéskör, ami majd megérdemel egy külön blog bejegyzést is.

A TOGAF és az ArchiMate, a két Open Group szabvány kapcsolatát jól összegzi az alábbi ábra:

 

Szabványos modellező nyelv

Az ArchiMate® tehát egy Open Group szabvány, egy grafikus modellező nyelv az enterprise architecture területre.

Az ArchiMate 2.1 specifikációról bőséges információ található az Open Group honlapján: http://www.opengroup.org/subjectareas/enterprise/archimate

Ha olyan valaki lát egy ArchiMate diagramot, aki ismeri az UML-t, azonnal felmerül a kérdés, mi az UML és az ArchiMate viszonya? Nos, mint ismert az UML egy jól definiált jelkészlettel és definiált jelentéssel jól alkalmazható sokféle artifakt előállítására magas szintű architektúra ábráktól egészen alacsony szintű sequence diagramokig. Ha az ArchiMate-ről beszélünk, röviden úgy jellemezhetjük, hogy ez szintén egy grafikus modellező nyelv, jól meghatározott grafikus elemekkel, de ez utóbbi sokkal inkább a magasabb absztrakciós szinteken használható eredményesen. Az ArchiMate által jól modellezhető világ pontosan az, ami az Enterprise Architect területen szükséges. Röviden fogalmazva az ArchiMate egy UML-szerű grafikus modellező nyelv, ami kifejezetten az EA modellezési igényekre készült.

TOGAF és ArchiMate

A TOGAF az architektúrákat 3 nagy területre csoportosítja. Foglakozik az üzleti, az alkalmazás/adat és a technológiai architektúrával. Az ArchiMate hasonló megközelítést tartalmaz, amikor három különböző réteget kezel, amelyek egymástól függenek. Itt tehát nagyfokú egyezést találunk.

Ahol kisebb mértékű eltérés van a két szabvány között az a következő. A TOGAF esetében van egy „keretrendszer a keretrendszeren belül”: egy Architektúra tartalom keretrendszer (ACF) írja le többek között azt a metamodellt, ami a modellezés során használatos fogalmakat és azok viszonyát dokumentálja, valamint felsorolja az architektúra fejlesztési folyamat egyes fázisai során előállítani javasolt artifaktokat is. Az ArchiMate valamelyest eltérő megoldást tartalmaz. Az ArchiMate külön metamodelleket tartalmaz az üzleti, alkalmazás és technológiai rétegekhez. A kisebb eltérések mellet az ArchiMate mindenképp többletet tartalmaz azon a téren, hogy definiál egy egyértelmű modellezési jelölést és ezzel határozottan plusz értéket ad a TOGAF-hoz. A TOGAF Architektúra keretrendszer használható, megvalósítható az ArchiMate jelrendszer alkalmazásával, azaz előállíthatók a TOGAF által ajánlott nézetek az ArchiMate használatával.

A fentiek alapján akár jogos lehetne a kérdés, miért nem lehet egyszerűen helyettesíteni a TOGAF ACF-et az ArchiMate-tel? Nos, a válasz röviden az, hogy nem lehet. Egyrészt azért sem, mert a TOGAF ACF szélesebb területet ölel fel, mint az ArchiMate (pl. az „E” fázisban implementáció specifikus követelményekkel foglalkozik). Ezen kívül a teljes TOGAF ADM leírás intenzíven hivatkozik a saját ACF elemeire, ezek nem lennének értelmezhetőek az ACF egyszerű kihelyettesítése esetén.

Az új ArchiMate verzió

Visszatérve a bevezetésben említett friss verzióra: az ArchiMate® 2.1 verzió egy úgynevezett „javított kiadás” (maintenance release), a 2012-ben megjelent ArchiMate 2.0 specifikációnak egy módosított kiadása.
A változások részben bővebb magyarázó szöveget jelentenek, részben ismétlések kihagyását, egységesítést, az ábrákon a szöveges résszel való egyezését biztosító módosításokat és hasonló pontosításokat.
A változások részletesebb leírása megtalálható az Open Group U312 számú dokumentumában (ArchiMate® 2.0 Technical Corrigendum) ami az alábbi internet címen érhető el: http://www.opengroup.org/bookstore/catalog/U132

Összegezve a TOGAF és az ArchiMate egymást jól kiegészítő két architekti szabvány, melyek kapcsolata, kölcsönös megfelelése egyre jobb lett az újabb verziókban. Ennek a harmonizációnak a története és pillanatnyi helyzete is egy izgalmas és a napi architekti munka szempontjából érdekes kérdéskör, de ez majd egy másik blog bejegyzésnek lehet a tárgya.