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.

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.

                                                                                 

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.

Architekti képesség kialakítása a szervezetnél

Az utóbbi időben több ügyfélprojekt során felmerült az adott szervezetnél meglévő architekti képességek fejlesztésének igénye. Ez többek között érintheti a kialakított folyamatokat, felelősségeket, a szabályozást, dokumentálást, képzést és más ehhez kapcsolódó területeket.

Az architektúra kifejezést most abban az általános értelemben használjuk, amely magában foglalja egyrészt az üzleti/szakmai, másrészt az információs rendszerek (adatok és alkalmazások) valamint harmadrészt az IT technológiai (hardver, szoftver) terület architektúráit is.

Vannak szervezetek, melyek már fejlett enterprise architecture (EA) képességekkel rendelkeznek, másoknál folyamatban vannak az ezzel kapcsolatos előkészületek és több helyen éppen a legcélravezetőbb módszert keresik a szervezet EA képességeinek kiépítéséhez. 

Az alábbiakban az EA képesség kialakításának célszerű módjával foglalkozunk.

Projekt indítás az EA képesség kiépítésére

Azoknál a szervezeteknél, amelyeknél még nem alakultak ki az architekti működéssel kapcsolatos fentebb jelzett elemek, célszerű egy speciális architektúra projektet indítani, éppen ezek kidolgozására. Egy ilyen projekt eredményeként előállnak többek között az architektúrák tervezésével, megvalósításával, felügyeletével kapcsolatos folyamatok, szerepkörök, a szervezet architektúra dokumentum tárának (repozitorium) kezdeti állapota, egy architektúra dokumentum sablon gyűjtemény, egy testreszabott saját architektúra fogalomtár (meta modell), egy meghatározott megoldás a követelmények kezelésére. Így a speciálisan az EA képességek kialakítására irányuló projekt eredménytermékei a tervezett egyéb fejlesztési projektek kapcsán már felhasználhatók lesznek azok megtervezéséhez, irányításához, követelmény kezeléséhez, átadás-átvételéhez, vagyis életciklus-menedzsmentjéhez.

A javasolt speciális EA projekt legfőbb célja az, hogy kialakításra kerüljenek a szervezet legfontosabb architekturális képességei. Ezen belül megszülessenek a döntések arról, mely képességek kialakítása és fenntartása célszerű a szervezetén belül és milyen feladatok, funkciók esetében célszerű a szervezeten kívüli erőforrások bevonása.

Az EA pozícionálása

Az alábbi ábra a vállalati architektúra tervezés (EA) terület helyét mutatja és kapcsolatát a stratégia menedzsmenttel és a projekt és portfólió menedzsmenttel.

Mint bármely más üzleti képesség bevezetése esetén, itt is lényeges a bevezetés módjának körültekintő tervezése. Erre a célra az alábbi javaslat a TOGAF (The Open Group Architecture Framework) architektúra keretrendszernek az idevágó, vállalati architektúra képesség bevezetésével foglalkozó részén alapszik. Ezáltal biztosítható, hogy valóban egy értéket termelő, ügyfél-központú, fenntartható architekturális képesség valósítható meg a szervezetnél, ami támogatja a szervezet alapvető működését, segít maximalizálni a befektetések értékét, proaktívan azonosítja a lehetőségeket és segít csökkenteni a kockázatokat. 

Az alábbi ábra a TOGAF architektúra keretrendszerben dokumentált architektúra fejlesztési módszer viszonyát mutatja a kapcsolódó egyéb módszertanokhoz. 

Az ábrán jelzett átfedések, kapcsolódások közül külön kiemeljük a projekt menedzsment és az architektúra fejlesztés módszereinek szoros kapcsolódását. Ez több szinten is megjelenik: például maga az architektúra fejlesztés is tipikusan projektként kezelendő, vagyis alkalmazandó egyszerre a szakmai módszertan (az EA) és a projekt menedzsment (PM) módszertan is. De más szinten is kapcsolódik ez a két terület, hiszen az architektúra fejlesztés esetén a tervezési fázisok után általában (egy vagy több) megvalósítási projekt indul a megtervezett architektúra megvalósítására, amit már PM vezetés alatt, de ugyanakkor architekti szakmai felügyelettel célszerű végezni. Tehát a jelen dokumentumban az architekti működésről leírtak szorosan érintik a projekt menedzsment területet is. 

Egyébként hasonlóan szoros átfedések és kapcsolatok vannak az architektúra fejlesztés és a konkrét megoldások fejlesztése és ugyanígy az üzemeltetés területével is.

Vállalati architektúra képesség kialakítása

Maga a vállalati architektúra képesség kialakítása nem kezelhető egy konkrét architektúra fejlesztési projekt egyik fázisaként, annak részeként, sokkal inkább célszerű egy olyan önálló projektként kezelni, ami előfeltétele annak, hogy a megvalósulása után a különböző, architektúra tervezéssel, fejlesztéssel foglalkozó projektek eredményesek lehessenek és az egyes projektek eredményei kölcsönösen felhasználhatóak legyenek.

A szervezet saját architektúráival kapcsolatos feladatai a gyakorlatban folyamatos tevékenységeket igényelnek, mégis célszerű a szükséges tevékenységeknek egy rögzített határidőre megvalósítandó részét egy jól meghatározott EA projektben elvégezni. Az ebben a projektben megfogalmazott lépések előfeltételei annak, hogy a jövőben a szervezet igazán hatékony architektúra fejlesztési projekteket legyen képes megvalósítani. Ebben a projektben azoknak az alapvető vállalati architektúra képességeknek a kiépítése a fő cél, amelyekre nagy szükség lesz a későbbi időszakok célzott fejlesztési projektjeihez.

A projekt előfeltételei

A projekt megvalósítás előfeltétele a projektindításhoz szükséges döntések meglétén kívül bizonyos input dokumentumok rendelkezésre állása is. Ezek hiánya esetén célszerűbb ezek pótlásáról még a javasolt EA projekt indítása előtt gondoskodni, mintsem a projekt tevékenységeit és ezzel időigényét ezzel megnövelni.

A legfontosabb nem-architekturális inputok között szerepelnek a vállalati stratégia, az üzleti tervek, az IT stratégia, az üzleti alapelvek és az üzleti célok. Amennyiben rendelkezésre állnak már bevezetett kapcsolódó egyéb módszertanok, keretrendszerek a szervezetnél (amennyiben vannak: pl. projekt menedzsment módszertan, ITIL, stb.) úgy azok is a fontos inputok között szerepelnek, csakúgy, mint az esetleges bevezetett irányítási, jogi keretek illetve már kialakított partner stratégia, megállapodások.

A legszükségesebb architekturális inputok pedig tartalmazzák a vállalati architektúrát érintő bevezetett szervezeti megoldásokat (ha vannak ilyenek), a bevezetett architektúra módszertant (vagy annak elemeit), ha rendelkezésre áll, valamint a szervezetnél már használatos EA módszereket, dokumentumokat, eszközöket, alapelveket, stb.

A projekt fő feladatai

Az architektúra képességek kiépítése érdekében indított EA projekt célszerűen foglalkozik a szervezet számára szükséges architekturális szakismeretek meghatározásával és tartalmaz megfelelő képzést az architekti módszertan elsajátítására valamint alkalmas támogató eszköz (szoftver) bevezetését az architekti munkához. Célszerűen a projekt feladatai közé tartozik az Architekti tanács létrehozása és az architekturális megfelelőséggel kapcsolatos folyamatok kialakítása valamint az alapvető architektúra megállapodások elkészítése is. Az architektúra irányítás főbb folyamatainak kialakítása és az EA dokumentum sablonok elkészítése mellett célszerű az architektúra fejlettségi modellek szerinti fejlettségi mérés elvégzése is a projekt keretében. Természetesen a projekt konkrét hatókörét, tartalmát a rendelkezésre álló idő és egyéb tényezők figyelembevételével egyedileg kell meghatározni.

Az architektúra képességek kiépítéséből kiemeljük az architektúra irányítás területét annak nagy jelentősége miatt. A vállalati architektúra irányítás nem csak az architektúrák fejlesztését és bevezetését kontrollálja és segíti, de kiterjed az implementált architektúrák működésére is.

Az architektúra képesség kiépítésre irányuló projekt sikere legpontosabban egy architekturális fejlettségi szint felméréssel fejezhető ki, amely elvégezhető a jelen állapotra majd pedig a projekt befejezése után ismételt felméréssel kimutatható a változás mértéke. Természetesen a cél nem az, hogy minden területen a lehetséges maximális szint elérése történjen meg ebben a projektben, de mindenképp cél hosszabb távon az iparági átlag fejlettség megközelítése architekturális területen.

Az EA projekt részeként fontosnak tartjuk a munkatársak képzését a vállalati architektúrák tervezésével, megvalósításával, felügyeletével kapcsolatos ismeretekből. Az érintettség illetve a munkaköri feladatokhoz való kapcsolódás miatt többféle megoldás együttes alkalmazása a legcélszerűbb: TOGAF alap képzés (szükség szerint vizsga is) a szakembereknek illetve egy rövidebb áttekintés vezetők részére. Ezen kívül célszerű egy testreszabott hosszabb workshop gyakorlatokkal,  valamint az on-the-job training (munka közbeni tanulás) az EA projektbe delegált munkatársaknak.

Szoftver eszköz bevezetése

A fentiekben vázolt EA képességek kialakításához szükséges a megfelelő IT támogatás, ami az architekti munkákhoz fejlesztett speciális célalkalmazás bevezetését is tartalmazza. A megfelelően kiválasztott és bevezetett eszköz segíti a szabványos architektúra dokumentumok elkészítését, támogatja a kiválasztott architektúra keretrendszer, módszertan követését (pl. TOGAF) és az architektúra dokumentumok csoportmunkában való készítését, továbbfejlesztését. Ezen kívül segíti a meglévő architektúra dokumentumok hozzáférhetőségét, felhasználását a munkatársak számára és az is hasznos, ha könnyen integrálható egyéb rendszerekhez (pl. műszaki nyilvántartó rendszer).

Az EA projekt által leszállítandó termékek

A javasolt EA projekt eredményeként célszerűen előáll a folyamatok, szerepkörök meghatározásán túlmenően az architektúra dokumentum tár (repozitorium) kezdeti állapota, egy architektúra dokumentum sablon gyűjtemény, egy testreszabott architektúra meta modell, és a követelmények kezelésére szolgáló megoldás is.

A javasolt EA projekt eredménytermékei a tervezett egyéb fejlesztési projekteknek a tervezéséhez, irányításához, követelmény kezeléséhez, átadás-átvételéhez, vagyis életciklus-menedzsmentjéhez már felhasználhatók lesznek. 

Összegzés

A szervezet architekturális fejlettségének optimális szintre történő emeléséhez célszerű egy erre dedikált speciális EA projektet indítani. Az architektúra képességek kiépítésének egyedi, testreszabott módszeréhez a legjobb kiindulópont a TOGAF (The Open Group Architecture Framework) architektúra keretrendszernek a vállalati architektúra képesség bevezetésével foglalkozó része. A megfelelően megalapozott EA képesség támogatja a szervezet alapvető működését, segít maximalizálni a befektetések értékét, proaktívan azonosítja a lehetőségeket és segít csökkenteni a kockázatokat.
 

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.