2021. május 24., hétfő

Tapasztalatok grafikus modellező nyelvekkel

A régi mondás szerint egy kép többet mond ezer szónál. Valóban, hogyan is lehetne hatékonyabban átadni az információt arról mi a teendő, ha nem ég a lámpa, mint az alábbi képpel:



A grafikus modellezési nyelvek már régen elterjedtek például a szoftveriparban. A modellező nyelveket alapvetően a szakemberek közötti kommunikáció megkönnyítése céljából fejlesztették ki. 
A szoftveripar esetében az alapvető mozgatórugó az volt, hogy a programozási nyelvek nem elég magas szintű absztrakciók ahhoz, hogy megkönnyítsék a tervek megvitatását. Más területeken is fontos, hogy a szükséges absztrakciós szinthez megfelelő grafikus modellező nyelvet használjunk. 
Sajnos, igen gyakori, hogy az elkészült modellek az alábbi két hiba valamelyikétől szenvednek:

  • A nyelv helytelen használata, például nem megfelelő típusú elemek és kapcsolatok alkalmazása, általában az adott nyelv megfelelő szintű ismeretének hiánya miatt. Ezeknek az ábráknak a készítői gyakran egy PowerPoint diagramként hozzák létre az ábrát dobozokkal és nyilakkal. Ezt a problémát egyszerűen meg lehet oldani a modellezők képzésével és a modellek ellenőrzésével.
  • Másik hiba lehetőség a modellezési nyelv helytelen megválasztása. Ez már nehezebb probléma. Gyakran használhatatlan és félrevezető modelleket eredményezhet, még akkor is, ha a modellező jól képzett az adott nyelvből. Nagyon fontos a megfelelő nyelv kiválasztása egy adott cél érdekében. Ez nyilvánvalónak tűnhet, de van rá példa, hogy az ArchiMate segítségével készítették el egy megoldás részletes tervét vagy a BPMN-t használták egy végrehajtási sorrend modellezéséhez. Ezek a modellező nyelvek nem erre valók.

Később aztán a diagramok, a fenti első ábrához képest, komplexebbek lettek, mint például az alábbi, ami egy alkalmazás architektúrát mutat.


Azért az architektúra alapvetően, mint dobozok együttese jelenik meg itt is. Az alábbi egyszerűbb példa is dobozokkal mutat be egy vállalati architektúrát.



A munkánk során aztán a magas szintű dobozok belsejét részletesebb diagramokkal ábrázoljuk, gyakran olyanokkal, mint ami az alábbi példában szerepel:


Végül is egyre részletesebb információt tartalmaznak a diagramok, de még mindig dobozokat rajzolunk. Ennyi lenne a vállalati architektúra? 
Egy hasznos metafora szerint: az Architektúra az dobozok és vonalak összessége, plusz még valami, ami az egészet összetartja: a ragasztó. Nos valóban az architekt szakember mindig rendelkezik további információkkal is, nem csak a dobozok és nyilak fontosak, az architekt az igazi „ragasztó”.

Út a rajzoktól a modellekig

A legtöbb esetben az architektúra tervezés valamilyen rajzok készítésével indul, amik eleinte nem követnek semmilyen szabványt, nem valamilyen rögzített grafikus nyelveken készülnek. Később felmerül az igény az egyértelmű, mindenki számára világos, újrahasznosítható diagramok iránt és ezért valamelyik szabványosított grafikus nyelven készülnek a diagramok. Ahogy ezek mennyisége megnő, gyakran dokumentum-kezelő rendszerekben helyezik el ezeket a biztonságos központi tárolás, verzió követés, hozzáférés szabályozás és hasonló előnyök miatt. Az architekturális fejlettség növekedéssel egyre több, vagy akár az összes architektúra domain tervezése kapcsán, az egyes területek közötti kapcsolatok ábrázolásának igénye is erősödik (üzleti-adat-alkalmazás-technológia területek). Így változik meg a helyzet a dokumentumok (legtöbbször diagramok) készítésétől a modellek kialakításáig. A látszat, a felszín hasonló: rajzolhatunk például ArchiMate vagy BPMN diagramokat, mint dokumentumokat és kezelhetjük azokat önálló dokumentumokként, vagy pedig felépíthetünk egy egységes vállalati architektúrát egy erre alkalmas szoftver eszköz adatbázisában, aminek a technikája nagyon hasonló: ebben az esetben is készülhetnek mondjuk ArchiMate vagy BPMN diagramok. A különbség abban van, hogy a modellezés esetében a diagramokon megjelenő komponensek egy egységes gyűjtemény elemei (model repository) és ilyen módon követhetők az összefüggések például a domain-határokon túl is. Nem is beszélve a nagy méretű modellek későbbi módosításainak lehetőségeiről.

Az így készülő architektúra modellek sokkal nagyobb értéket biztosítanak az adott vállalat, szervezet számára, mint ha csak önálló diagramok, mint dokumentumok tömege készült volna el.


 


A modellezéshez kell tehát egy közös nyelv!



 

A legfontosabb indokot a közös nyelv használata mellett az jelenti, hogy a „zavaros ábrák” helyett egyértelmű, tiszta kommunikációra van szükség, félreérthetőség, kétértelműség nélkül. 
A nagy számú diagram kapcsán fontos a következetesség, az összefüggőség biztosítása. 
Nyilván elvárás az igényes vizuális megjelenítés is. 
És (mint példákon is látni fogjuk) a gépi elemzés lehetősége is biztosított.
Mindezekre a megoldás a létező nemzetközi szabványok követése. 

Ha szabványos modellező nyelvekkel dolgozunk, akkor természetesen azonos fogalmakat kell használnunk. Több szinten foglalkozhatunk az architektúra tervezés kapcsán a szükséges fogalmakkal, ahogy azt az alábbi ábra mutatja. 
Most itt a második szintet, az Enterprise Architecture egységes fogalomrendszerét vizsgáljuk.


A szabványos modellező nyelvek használata lehetőséget teremt az elkészült modellek számítógépes feldolgozására, elemzésére is. Nézzünk néhány gyakorlati példát gépi feldolgozásra, elemzésre.


Összehangolatlanság azonosítás vállalati architektúra modellek (ArchiMate) elemzésével 

Ebben az esetben ArchiMate nyelvű architektúra diagramok elemzése történt meg számítógépes algoritmusokkal.

Az alábbi képen két ArchiMate diagram látható mint példa valamint az elemzés eredményeként azonosított néhány tünet szerepel. Erről a konkrét munkáról egy AEA klub keretében részletes beszámolót hallgathattunk meg. További információk a látott prezentáció letöltési linkjével itt érhetők el: http://www.aeahungary.org/a/aeahungary.org/aeahungary/hirek/2018-as-hirek/architekturaelemzesreepuelostrategiaioesszehangolasvizsgalatnagyvallalatikoernyezetben  



Forrás: ŐRI Dóra Ph.D. SZABÓ Zoltán Ph.D.: MISALIGNMENT TÜNETAZONOSÍTÁS VÁLLALATI ARCHITEKTÚRA MODELLEK ELEMZÉSÉVEL, AEA klub előadás


Komplexitás mérőszám és költség egyenértékese

A másik példa szintén egy korábbi AEA klub előadás tartalmához kapcsolódik, amiben a komplexitás méréséről volt szó. A vállalati architektúrák komplexitása nyilvánvalóan fontos kérdés az enterprise architect szakemberek számára. Az előadásban ismertetett mérésekhez szabványos modellező nyelveken készített architektúra tervek szolgáltathatnak bemenő adatokat. További részletek az előadásról itt: http://www.aeahungary.org/a/aeahungary.org/aeahungary/hirek/2021-es-hirek/komplexitasmeroszameskoeltsegegyenertekese-aeaklub 

 

Forrás: Nacsák Tamás, Komplexitás mérőszám és költség egyenértékese, AEA Klub előadás 


Grafikus modellező nyelvek

Sokféle grafikus modellező nyelvet fejlesztettek ki az idők során, az alábbi ábrán néhány ismertebb nyelv szerepel a teljesség igénye nélkül.

A fenti elterjedt grafikus modellező nyelvek közül a továbbiakban az ábra felső részén látható három nyelvvel foglalkozunk részletesebben.


 

A három nyelv rövid bemutatása:

  • Az ArchiMate egy szabványos grafikus modellező nyelv vállalati architektúrák (Enterprise Architecture) modellezésére.
  • A BPMN (Business Process Modeling Notation) egy szabványos modellező nyelv folyamatok modellezésére.
  • Az UML (Unified Modeling Language) egy szabványos modellező nyelv eredetileg a szoftver rendszerek modelljeinek meghatározására, vizualizálására és dokumentálására.

Fontos megállapítanunk, hogy a modellező nyelvek nem kötődnek egy bizonyos szoftver eszközhöz vagy tervezési folyamathoz. Jegyezzük meg azt is, hogy egy modellező nyelv nem módszertan! Inkább egy „szótár” és „nyelvtan”, ami sokat segíthet. Általában egy modellező nyelvhez szükség van még egy módszertanra is, hogy hogyan használjuk az adott nyelvet.


Vegyünk néhány példát a fenti nyelveken készült diagramokra!

Nézzük meg például az alábbi ábrát. Vajon mindkettőn ugyan az szerepel, csak más alakzatokkal? Vagyis mindegy lenne, hogy BPMN vagy ArchiMate nyelvet használunk?


Bár a két diagram (a konkrét nyelvi jelek különbözőségétől eltekintve) valóban nagyon hasonló, mégis félrevezető lenne arra a következtetésre jutni, hogy mindegy is a nyelv, bármelyiken elkészíthetjük ugyan azt a diagramot.
 
Figyeljük meg az alábbi ábrán az ArchiMate lehetséges kombinálását a BPMN nyelvvel! Ugyan arról a valós folyamatról (pizza vásárlás) az ArchiMate diagram magas szintű információkat tartalmaz (egyszerű diagram, kevés doboz) még a BPMN diagram a folyamatnak sokkal több részletét mutatja be, ezért több doboz és nyíl szerepel rajta. Egy szervezet működése során vannak olyan helyzetek, amikor inkább magas szintű modellek segítenek, míg más helyzetekben a részletek pontos feltárására van szükség.

Nézzünk egy egyszerű példát az UML Activity Diagram és ArchiMate nyelv használatára is! Az alábbi ábra azt mutatja, hogy mindkét említett nyelven elkészíthetjük egy biztosítás kötés folyamatának diagramját és a két ábra valójában nagyon hasonló egymáshoz. Azt mutatná ez, hogy az UML és az ArchiMate lényegében helyettesíthetik is egymást?
Nos, az előbbi ArchiMate diagramot természetes módon kiegészíthetjük további komponensekkel az architektúra rétegek vagy tartományok kombinálásával az alábbiak szerint. Ezzel több információhoz jutunk: látjuk a folyamat során felhasználásra kerülő alkalmazás-szolgáltatásokat és még azokat az üzleti alkalmazásokat is, amelyek ezeket a szükséges szolgáltatásokat biztosítják.


 


Foglaljuk össze, alapvetően mire való az ArchiMate?

  • Vállalati architektúrák modellezéséhez való
  • Technológia és platform független
  • A vállalati architektúrák modellezése magas szinten történik
    • A figyelem az építőelemeken van, nem azok működésén
      • Pl. fontos, hogy milyen folyamatok vannak, hogy kapcsolódnak egymáshoz, de hogy azokat pontosan hogyan végzik a munkatársak, az itt nem fontos
    • Az is lényeges, az IT hogyan támogatja az üzleti működést

  • Az EA modellezése mindig a stratégián alapul
    • Motivációs és stratégiai elemek szolgálnak erre az ArchiMate-ben
    • Más modellező nyelvekből ez hiányzik!
  • Üzleti szolgáltatások leképezésére az IT és szoftver szolgáltatásokra, az IT infrastruktúrára
  • Az implementáció és migráció tervezését is támogatja


Most azt is nézzük meg, mire nem való az ArchiMate?

  • Az ArchiMate-nek nem célja a folyamatok részletes szintű modellezése
    • Maga a szabvány azt mondja: használja a BPMN modellezési nyelvet!
  • Az ArchiMate-nek nem célja egy rendszer vagy alkalmazás belső architektúrájának részletes modellezése
    • Erre a célra ott van az UML és annak kiterjesztései
  • Az ArchiMate nem alkalmas információs architektúra (részletes) modellezésére
    • Sokféle vélemény van: egyesek szerint ez elegendő a felső szintű modellezéshez, mások szerint nem
    • Az üzleti fogalmak és a közöttük lévő "durva" kapcsolatok megtalálhatók, a "specifikátorok" azonban nem
  • A fogalmaknak, vagyis az adattartalomnak nincsenek attribútumai
    • Különösen a tényleges adatmodellek nem modellezhetők az ArchiMate segítségével, nincs meg a szükséges részletesség

Viszont jegyezzük meg, hogy nagyon hasznos az ArchiMate az összes fenti tevékenységhez szükséges inputok biztosítására.


Nézzük meg azt is, hogy a BPMN mire jó és mire nem?

  • A folyamat diagramoknál a hangsúly a tevékenységeken van és azon, hogy ki cselekszik
  • Az információ- vagy anyagáramlás kevésbé érdekes
  • Egy szervezet belső folyamatainak modellezésére és szervezetek közötti műveleti folyamatok modellezésére egyaránt használható
  • Koreográfiák modellezésére is használják

  • Mit nem tartalmaz a BPMN?
    • A szervezeti struktúrák vagy erőforrások modellezése
    • A funkcionalitás lebontásának vagy elemzésének modellezése
    • Alkalmazások szerkezetének modellezése
    • Információs és adatmodellek modellezése
    • A stratégia modellezése
  • Az üzleti irányelvek modellezése
  • A BPMN megmutatja az üzenetfolyamokat, valamint az adatobjektumok és a tevékenységek közötti kapcsolatot, de ez nem adatfolyam-diagram


Végül arra is térjünk ki röviden, hogy mire való az UML és mire nem?

  • Az UML eredetileg a szoftverfejlesztés különböző termékeinek modellezésére szolgál
    • A követelmények specifikációjától a tervezésig
  • Alkalmazási architektúra modellezésére is használják
  • Activity diagramokat használnak az üzleti folyamatok modellezéséhez
  • Az UML általános kiterjesztési mechanizmusai révén sokféle további célra is használható
  • Ha az, amit modellezünk, nagyon technikai, például egy beágyazott rendszer, akkor az UML kommunikációs ereje nem elég
    • A SysML-t az UML alapján fejlesztették ki
  • Nincsenek eszközök az üzleti folyamatok elemzésére az UML-ben
  • Nincsenek eszközök a stratégia és az üzleti motivációk modellezésére, amelyekre a vállalati architektúrákban szükség van


Az alábbi ábra a három említett grafikus modellező nyelv nagyvonalú pozícionálását mutatja: milyen területekre és milyen szintű tervezésre célszerű az egyes nyelveket használni.

Ha már a legmegfelelőbb nyelvet kiválasztottuk az adott helyzetnek megfelelően, akkor még az is fontos, hogy mindig meghatározott céllal modellezzünk. A leggyakoribb háromféle célt az alábbi ábra mutatja.



 


Összegzés

A grafikus modellező nyelvek használatával kapcsolatban a legfontosabb tanulság:

mindig úgy válasszunk modellezési nyelvet, hogy nézzük meg, mire van szükségünk!

Ugyanis sok modellező nyelv áll rendelkezésre, ugyanakkor nincs olyan modellező nyelv, ami mindenre egyformán alkalmas. Az is igaz, hogy általában senkinek nincs szüksége arra, hogy egy modellező nyelv összes képességét kihasználja.

2020. október 14., szerda

Új Open Agile Architecture szabvány

A különböző szervezetek a világ minden részén egyre inkább agilis módszereket alkalmaznak az innováció, az ügyfelek megszerzése és megtartása érdekében, működési hatékonyságuk növelése és a változó gazdasági és szabályozási körülményekre való gyors reagálás érdekében. Az architekt szakmának fejlődnie kell az ilyen eredmények támogatása és ösztönzése érdekében. Ennek jelentős lépése egy új szabvány megjelenése.

A mai üzleti környezetben, ahol minden digitális, fontos a szervezetek agilitás működése. Az agilis csapatok a digitális átalakulást ösztönzik a szervezeteken belül például új üzleti modellek kialakításával, kiváló ügyfélélmény biztosításával, digitális termékek és erősen automatizált működési modellek felépítésével. Mégis, sok esetben az agilis módszerek széleskörű elterjedése az architektúrák rovására megy és számos üzleti szempontból hátrányos helyzetet okozhat. A vállalati architektúra döntő fontosságú az agilis, digitálisan működő kultúrára való áttérés szempontjából - és az átalakulási folyamatok során nagy figyelmet kell hogy kapjon.

A vállalkozások átalakulnak a digitális korban folyó verseny érdekében, új munkamódszereket, új irányítási rendszereket és új szervezeti struktúrákat keresnek. Az Open Group új szabványa meghatározza az üzleti élet és az informatika tervezésének legjobb gyakorlatait és szabványait a digitális korszak számára. Az agilis architektúrák lehetővé teszik a vállalkozások számára, hogy új kínálattal és képességekkel jelenhessenek meg gyorsan és hatékonyan piacon.

Az Open Group nemrég közzétette az Open Agile Architecture™ szabványt (röviden az O-AA™), amely az alapvető architektúra-gyakorlatok átfogó felülvizsgálata - frissítve a modern, digitális működési modellek és agilis fejlesztési módszerek figyelembevételével. Célja, hogy segítse mind a vállalkozások digitális átalakulását, mind azok agilis átalakulását.

Az AEA Magyar Tagozat szokásos AEA klub rendezvényén már foglalkoztunk korábban is ezzel a kérdéskörrel. „Tűz és víz? Agilis architektúra a digitális korszakban” címmel tartottam előadást 2019. február 28-án arról, hogy az agilitás és a precíz architektúra menedzsment egyáltalán nem zárják ki egymást. (Részletek és letölthető prezentáció itt

Az O-AA szabvány munkaközi „pillanatkép” állapota 2019. júliusában jelent meg, mely még csak a tervezett első részt tartalmazta. Ezután folyt a szabvány továbbfejlesztése, hogy teljes mértékben lefedje a vállalatok digitális és agilis átalakítását.

Maga az O-AA a dokumentum moduláris felépítésű, és két fő részből áll: az O-AA core leírja az agilis architektúra alapvető fogalmait, míg az Az O-AA építőelemek rész részletesebben bemutatja az O-AA építőelemeket.

Példák és esettanulmányok szemléltetik a szabvány megértését. A példák és esettanulmányok nem képezik a szabvány normatív részét, ezért nem tartalmaznak követelményeket.


1. rész: Az O-AA core ismerteti a keretrendszer alapfogalmait és bemutatja annak felépítését, még mielőtt elmagyarázná, miért van szüksége a vállalkozásnak kettős, digitális és agilis átalakításra. Ez a rész megalapozza az agilis architektúra ismereteket

2. rész: Az O-AA építőelemek fejezet részletesebben kifejti az 1. részben bevezetett témákat, olyan fejezetekkel, mint például az agilis stratégia, az agilis szervezet és a szoftver architektúra. Szerepelnek itt tartalmak olyan nézőpontból is, hogy mit csinál a vállalkozás, élménytervezés, journey mapping és hogy mi maga a vállalkozás, például a termék architektúra és a működési architektúra.

A dokumentum célközönsége a következő:

  • Agilis módszereket használó szakemberek, akiknek meg kell érteniük az architektúra fontosságát egy Agile at scale modell felé való elmozduláskor és akik architekti ismereteket akarnak elsajátítani
  • Enterprise architektek, megoldástervezők, biztonsági architektek és szoftvertervezők, akik relevánsak szeretnének maradni egy Agile at scale világban, és akiknek új architekti ismereteket kell elsajátítaniuk a digitális korban
  • Üzleti vezetők és felsővezetők, akiknek meg kell érteniük az architektúra fontosságát és befolyásolniuk kell az architekturális döntéseket

Dokumentum információk:

  • The Open Group referencia azonosító: C208
  • US ISBN: 1-947754-62-1
  • Megjelenés ideje: 2020. szeptember 29.
  • Oldalszám: 226 oldal
  • Korábbi dokumentum, amit helyettesít: S192
  • Típusa: szabvány
  • Tárgya: Agile Architecture

Az Open Agile Architecture Standard letölthető a The Open Group weboldalairól.

Aki nem a The Open Group vagy egyik tagszervezetének az alkalmazottja, az regisztrálhatja magát az O-AA Standard kiértékelési vagy kereskedelmi licenc alapján történő letöltéséhez. A kiértékelési példány (evaluation copy) a regisztráció befejezésével azonnal letölthető. 

Link: https://publications.opengroup.org/c208

2020. június 26., péntek

TOGAF® minősítési mérföldkő: 100 000 minősítés


A TOGAF® 9 tanúsítási programban megszerezhető tanúsítványok száma gyorsan növekszik, és most 2020 júniusban meghaladta a 100 000-et. Ez a szám 149 országból tartalmazza a tanúsítványt szerzett szakembereket. A legtöbb tanúsítvánnyal az Egyesült Királyságban, az Egyesült Államokban, Indiában és Hollandiában rendelkeznek.


Lakosság arányosan tekintve Magyarország a 32. helyen áll a 147 ország között (az első 22%-ban vagyunk az év eleji adatok szerint)

A TOGAF szabvány, a The Open Group szabványa, egy bevált vállalati architektúra (Enterprise Architecture - EA) módszertan és keretrendszer, amit a világ vezető szervezetei használnak az üzleti hatékonyságuk növelésére. A legfrissebb TOGAF 9.2-es verzió, az iparág legjobb gyakorlataként ismert. A TOGAF szabvány a folyamatos fejlődésével rugalmas marad, hogy megfeleljen a mai vállalkozások változó igényeinek. Ahogy egyre több szervezet mozdul el az agilis módszertanok felé, a TOGAF jól alkalmazható ehhez a változáshoz is. Eközben a keretrendszer használható az agilis alapelveket nem követő szervezetekben is. A módszertan méretezhető, testreszabható és könnyen használható bármilyen méretű és szerkezetű szervezet számára. Sok munkáltatónál szerepel a TOGAF az álláshirdetésekben mint javasolt tanúsítás. A TOGAF megerősítette státuszát szállító-semleges és világszerte elismert programként.

Az agilis digitális vállalkozások új igényeinek teljesítése és a relevancia megőrzése érdekében az architekt szakemberek szerepe gyorsan változik és szolgáltatásnyújtási modell felé mozdul el. A TOGAF keretrendszer folyamatos tanulást, különféle eszközökhöz való hozzáférést, valamint folyamatosan frissített tudás-ökoszisztémát kínál az  architekteknek ebben a folyamatban. Az architekt szakemberek számára a tanúsítások most még fontosabbak, mint korábban úgy az üzleti vezetőkkel kialakított megbízható kapcsolatok fenntartásában, mint karrierjük továbbépítésében. A tanúsítás további előnye az AEA (Association of Enterprise Architects) tagság lehetősége. Ezáltal virtuálisan és személyesen is kapcsolatba kerülhetnek szakmai társaikkal és ötleteket, aktuális gondolatokat és bevált gyakorlatokat cserélhetnek egymással.

A COVID-19 világjárvány miatt fontos, hogy a tanúsításhoz vezető virtuális TOGAF tanfolyamok elérhetők magyar nyelven is élő, internetes tréningek formájában.
 
A tanfolyamokról további információ és jelentkezés:

2020. február 22., szombat

TOGAF artifakt minta gyűjtemény ArchiMate nyelven

Sokan megismerkedtek már a The Open Group nemzetközi szabványosító szervezet architektúra keretrendszerével, a TOGAF 9.2 szabvánnyal. Ennek része a tartalom keretrendszer (Content Framework) ami többek között tartalmazza a vállalati architektúrák leírására ajánlott artifaktok ismertetését is. A gyakorló vállalati architektek ennek egy testreszabott változatát használják amennyiben a TOGAF szerint végzik a tevékenységüket.
A szabvány nem írja elő azt, hogy milyen ábrázolási móddal, milyen jelölésekkel készítsük ezeket a dokumentumokat. Ebben segít az ArchiMate architektúra modellező grafikus nyelv, ami szintén a The Open Group szervezet szabványa.
A hazai vállalati architektek munkájának segítésére összeállítottunk egy artifakt gyűjteményt, ami tartalmaz a TOGAF tartalom keretrendszerben szereplő valamennyi diagramra egy-egy egyszerű példát. Mindez ArchiMate nyelven készült és a GitHub szerveren található egy olyan repozitóriumban, aminek tartalma az ingyenes, nyílt forráskódú Archi programmal szerkeszthető.

Egy minta repozitórium a TOGAF Content Framework alapján

A cél egy magyar nyelvű diagram gyűjteményt tartalmazó architektúra repozitórium létrehozása volt, ami mintaként használható. Ezzel együtt egy olyan struktúra létrehozása is cél volt, ami újrafelhasználással munkát takarít meg az ArchiMate nyelven történő architektúra tervek készítésekor a hazai gyakorló architekteknek.

Mintegy 40 darab ArchiMate nézetet (View) tartalmaz ez a repozitórium.
Ezek nagyon egyszerű példák az összes diagramra, amely a TOGAF 9.2 szabvány Content Framework fejezetében szerepel.

A minta gyűjtemény legfőbb előnye:

  • gyártó független nemzetközi szabványoknak megfelelő (TOGAF 9.2, ArchiMate 3.1)
  • teljes a gyűjtemény: a TOGAF Content Framework összes diagramjára van benne példa
  • magyar nyelvű rövid leírást tartalmaz minden diagram típusról
  • könnyen újra felhasználható: az ingyenes Archi alkalmazással szerkeszthető, tovább felhasználható

Az Archi alkalmazásban az alábbiak szerint jelenik meg a GitHub-on publikált repozitórium tartalma:

A gyűjteményben minden nézetnél a célszerű ArchiMate Viewpoint van kiválasztva, így a palettán már csak azok az elemek jelennek meg, amelyek az adott nézeten használhatók. A Documentation mező tartalmaz egy pár mondatos magyar nyelvű leírást is az adott nézetről. A nézetek tartalma minden esetben minimális, csak a szemléltetéshez elengedhetetlenül szükséges néhány elem és azok kapcsolatai szerepelnek a nézeteken. Újrafelhasználás esetén ezek könnyen törölhetők és a valódi tartalmak rögzíthetők.



Egyes esetekben a nézeteken szereplő elemekhez megfelelő jellemzők (Properties) is szerepelnek szemléltetésül, mint például az érintett fél (Stakeholder) esetében az alábbi példában.
Hasonló példa a követelmények katalógusa az alábbi képen.

A teljes repository megtalálható a GitHub.com szerveren, az Archi programmal szerkeszthető formában. Használatához először telepíteni kell az ingyenes Archi alkalmazást, mely rendelkezésre áll Windows, macOS, Linux platformokon is. Letöltési oldal: https://www.archimatetool.com/download/
A telepítés után szükség van még arra az Archi bővítményre, ami lehetővé teszi a GitHub repository közvetlen elérését az Archi program menü sorából. Ez a coArchi – Model Collaboration for Archi. Letölthető innen: https://www.archimatetool.com/plugins/

A bővítmény telepítése után jelenik meg a Collaboration menű:

A GitHub webes felületén az említett repozitórium az alábbi tartalommal látható:

A bemutatott minta repozitóriumnak illetve az abban szereplő tartalmaknak a felhasználása esetén kérjük, jelölje a forrást: "Virágh Tamás (2020): TOGAF artifakt minta gyűjtemény ArchiMate nyelven,  https://github.com/viraghtamasjozsef/togaf-cf-in-archimate.git "

Az itt ismertetett ArchiMate példákat tartalmazó teljes repository letöltése és felhasználása az AEA Magyar Tagozat tagjai számára díjmentesen biztosított. Ha ön tagja az AEA Magyar Tagozatnak és el kívánja érni a repository tartalmát, jelezze igényét a repository@aeahungary.org email címen. A hozzáféréshez szükséges információkat emailben fogja megkapni.
Az AEA Magyar Tagozathoz történő csatlakozás módjáról itt olvashat: http://www.aeahungary.org/csatlakozzon-a-magyar-tagozathoz   

2020. február 11., kedd

Architektek a vállalati kockázatok csökkentéséért


Egyes vállalati architektúra (EA = Enterprise Architecture) képességek hiánya vagy alacsony szintű érettsége szoros kapcsolatban áll bizonyos azonosítható kockázatokkal.
Vállalati architektúra menedzsment érettségi felméréseket végezve azt tapasztaltam, hogy sok hasonlóság van a vállalati architektúrák kezelésével összefüggésbe hozható kockázatokat illetően az egyébként különböző tevékenységet folytató szervezeteknél is. Az alábbiakban néhány olyan kockázatról lesz szó, melyek az architektúra menedzsment érettségével, akár hiányos architektúra irányítással, például nem jól kialakított megfelelési folyamattal hozhatók összefüggésbe.

A „kockázat” szó tartalma a mindennapi szóhasználatunkban meglehetősen negatív, miközben nem csupán fenyegetést jelent („negatív kockázat”), hanem lehetőséget is kifejezhet („pozitív kockázat”). A kockázat azt is jelentheti, hogy elkerülhető egy potenciálisan nagy lehetőség. A kockázatkezelés olyan összetett kérdés, amivel érdemes foglalkozni.
A kockázatkezelés a vállalati architektúra menedzsment szerves része. A gyakorló vállalati architekteknek alapvetően célszerű a szervezetüknél alkalmazott kockázatkezelést használni és szükség esetén azt kiterjeszteni az alkalmazott enterprise architect módszertan útmutatása alapján.
A kockázatkezelési folyamat szokásos lépései:
  • azonosítás 
  • értékelés
  • kezelés vagy reagálás
  • jelentéstétel
  • ellenőrzés, megfigyelés
Ez a blog bejegyzés csak a vállalati architektúrájával kapcsolatos területekre és azokkal kapcsolatban is csak az első két lépésre összpontosít.

A kockázatok kezelése

Minden architektúrális (különösen az üzleti architektúrát érintő) átalakítás kockázatokkal jár. Kiemelten igaz ez az olyan dinamikus iparágakban, mint a távközlés vagy éppen az IT szolgáltatás. Fontos a kockázatok azonosítása, osztályozása és enyhítése minden jelentős változás megkezdése előtt, úgy hogy azok nyomon követhetők legyenek az átalakítás során.
Az enyhítés folyamatos erőfeszítés, és gyakran a kockázatok kiváltói kívül esnek az átalakulás tervezőinek hatáskörén (például a gazdasági környezet változása, csoportszintű döntések, egyesülés, akvizíció), így a tervezőknek folyamatosan figyelemmel kell kísérniük az átalakulás kontextusát.
Fontos megjegyezni, hogy egy vállalati architekt ugyan azonosíthatja a kockázatokat és enyhíthet egyes kockázatokat, ám a kockázatot először az irányítási keretrendszernek kell megfelelően fogadni, majd kezelni.
A továbbiakban konkrétabban a vállalati architektúra menedzsmenttel kapcsolatos kockázatokkal foglalkozunk.

A vállalati architektúra menedzsmenttel kapcsolatos legfontosabb kockázatok

A vállalati architektúra menedzsmenttel kapcsolatban számos fenyegetést azonosíthatunk a kockázatok szokásos négy fő területén:
  • Megfelelőségi fenyegetések – ezek a politikából, törvénykezésből, szabályozásból vagy vállalatirányításból származnak
  • Működési fenyegetések - befolyásolják a vállalkozás folyamatait, rendszereit, az embereket és az általános értékláncot
  • Stratégiai fenyegetések - az ügyfelekkel, a versenytársakkal és a befektetőkkel kapcsolatosak
  • Pénzügyi fenyegetések - a piacok és a reálgazdaság ingadozásaiból fakadnak
A vállalati architektúrák kezelésének fontos célja a kockázatok kezelésének elősegítése: ám bizonyos esetekben érdekes módon az architekti működés maga is új kockázatokkal jár.
A kockázatokkal és az architektúra menedzsmentnek a főbb kockázatok kezelésének elősegítésében játszott szerepével kapcsolatban fontos megjegyezni a következőket:
  • Rövid távon az architekti munka fő értéke a bonyolultság csökkentése, a változtatások könnyebb megvalósíthatósága és a technológiai beruházások jobb megtérülése lehet. Ezek mind működési fenyegetésekkel kapcsolatosak.
  • A fejlett vállalati architekti képességek hosszú távú fő előnye ezen túlmenően az, hogy a működési fenyegetések enyhítésén túl a stratégiai fenyegetések elkerülését is támogathatja az architekti munka.
Sok vállalati architekt úgy véli, hogy valójában csak egy vállalati architektúra kockázat létezik: annak a kockázata, hogy az architekti módszereket nem alkalmazzák megfelelően a vállalkozásban. Az igazság az, hogy a vállalati architektúra menedzsment maga is tartalmaz kockázatokat. A hiányzó vagy nem megfelelően használt vállalati architektúra azonban valóban még nagyobb kockázatot jelent.
A vállalati architektúra menedzsmenttel kapcsolatos kockázatok közül néhány kiemelkedően fontossal foglalkozunk a következőkben.

Biztonsági sérülékenységek és kitettségek

A vállalati architektúra menedzsmenttel kapcsolatba hozható kockázatok között a biztonságot kell először megemlítenünk. A vállalati architektúrának közös biztonsági keretet kell biztosítania, mely csökkenti a biztonsági kockázatokat. Fennáll annak a veszélye, hogy biztonsági rések jönnek létre a vállalati architektúra menedzsment képességek hiánya miatt. A biztonság kiemelten fontos minden szervezet számára. Az architektúra nagy változásai még fontosabbá teszik ezt a témát. Olyan népszerű architektúra megközelítés, mint például a SOA (szolgáltatás orientált architektúra), bonyolíthatja a biztonságot és új kockázatokat vethet fel.
A vállalati architektek nem biztonsági szakértők, de az általuk alkalmazott módszertan és az általuk követett biztonsági alapelvek alapján ők kell hogy ellássák az összekötő szerepét a biztonsági szakértők, a tervezők és a fejlesztők között. A biztonság fontos szempont, és természetesen ugyan így a teljesítmény, a minőség és az innováció is. Amikor egy szervezet fejleszteni akarja ezeket, akkor jól meg kell értenie ezek szerkezetét és viselkedését (architektúráját). Ebből a célból fontos integrált eszköz a vállalati architektúra menedzsment, olyan kiegészítő területekkel, mint az ESRM (Enterprise Security & Risk Management, vállalati biztonság és kockázatkezelés).

A kritikus eszközök láthatósága

A szervezeteknek tisztán kell látniuk, mivel rendelkeznek és mit terveznek beszerezni vagy kialakítani a jövőben.
Nagy kockázatot jelenthet akár egy olyan egyszerű probléma is, hogy a szervezetnek nincs egy olyan központi hiteles nyilvántartása, amely integráltan tartalmazza az összes használt kiszolgáló számítógépet, az összes hivatalosan működő alkalmazást, azt, hogy mely alkalmazás-összetevők futnak a kiszolgálón, milyen interfészeken működnek együtt, mely üzleti folyamatokban használják az adott szolgáltatást, stb.
Ez a probléma a szükségesnél magasabb informatikai költségeket eredményez, és instabil alapot jelent a jövőbeni fejlesztések tervezéséhez is. Az SLA és az OLA (szolgáltatási illetve működési szint megállapodások) megfelelő tervezhetősége szintén korlátozott a fenti helyzetben.

A személyzet

Tapasztalt, motivált, jól képzett szakemberek nélkül nem lehet használható vállalati architektúra-képességet kiépíteni. Az architekt szakemberek helyzete gyakran eltérő az egyes architektúra területeken még adott szervezeten belül is.
Gyakran a technológia területén valóban tapasztalt architektek vannak, az alkalmazási tartomány viszonylag jó szinten kezelt, de például az információs architektúra tartomány igen sokszor nincs megfelelően tervezve, modellezve.
Nem egyszerű a megfelelő vállalati architektúra menedzsment képesség kialakítása. Az érintettek időnként panaszkodhatnak, hogy az architekti működés nehézkes. A találkozók, a dokumentumok áttekintése és a képzés elvonhatja a kritikus alkalmazottakat alapvető üzleti felelősségüktől. Ha az architekti működés nem megfelelően célirányos és eredményközpontú, akkor az akár a vállalat erőforrásainak pazarlásához is vezethet.

Alacsony elfogadási arány

Sok szervezetnél az egy valós kockázat, hogy a jó vállalati architektúra terveket figyelmen kívül hagyják. Sokkal könnyebb meghatározni a vállalati architektúrát, mint végrehajtani az ahhoz szükséges irányítást.
Az architekti működés egyik fő kockázatát gyakran az érdekelt felek támogatásának alacsony szintje jelenti.
A vállalati architektúra gyakorlatának túl szűk vagy túl széles hatóköre szintén kockázatot jelenthet. A szűk hatókör nem biztos, hogy nyújt elegendő értéket, míg a túlságosan széles hatókör nem működhet az eltérő érettségi szintek miatt. Előfordulhat például, hogy az üzleti architektúra rosszul vagy hiányosan van definiálva, miközben a technológiai architektek „minden bitet” modelleznek.
Az is kockázattal jár, ha túl nagy architektúra hatókört és részletezettséget igyekszik fenntartani a szervezet. A modell karbantarthatatlanná válhat, az információ ezután nem megbízható, haszontalan. A meghozandó döntéseknek megfelelő részletezettségi szinthez ragaszkodni kell.

Megoldások költségei

A közös megoldások használatával a cél általában a dolgok egyszerűsítése. A fejlett vállalati architektúra menedzsment képesség támogathatja az ilyen kezdeményezéseket. Ez jelentősen csökkentheti a megoldások költségeit.
Fennáll azonban annak a veszélye is, hogy egy olyan vállalati architektúra programot alakít ki a szervezet, amely a túltervezés miatt nem optimális. Architektúrális előnyök túlhangsúlyozása (skálázhatóság, újrafelhasználhatóság stb.) más szempontok rovására mehet. Az architektúrálisan ideális megoldások ezen kívül gyakran drágák. Az architektúra irányítási folyamatoknak kell az egyensúlyt biztosítani.
A legrosszabb a „rosszul használt IT költség”, vagyis a valós üzleti célok támogatása nélküli költés. Hasznos, ha az architekti működés beépül a stratégia kialakítása és a projekt megvalósítása közé, ezzel segítheti a megoldások költségeinek optimalizálását is.

Felhasználói elfogadás

Fennáll a veszélye, hogy egyre több siló megoldás alakul ki a szervezeten belül. Egyes részlegek olyan informatikai megoldásokat és szolgáltatásokat választanak, amelyek a szervezeten belül egyediek, nem használhatók más területen. Az architekti módszerek a közös megoldásokra összpontosítanak. A közös megoldásokra való törekvés azonban további felhasználói elfogadási kockázatokat vezethet be.
A felhasználók panaszkodhatnak, hogy a közös megoldások kevésbé igazodnak üzleti egységük igényeihez. A silómegoldásaik felett az egyes részlegek teljes ellenőrzést élvezhetnek, míg ha kénytelenek átváltani a közös megoldásra, elégedetlenek lehetnek. A közös megoldások több szempontból a leghatékonyabbak, de általában nagyobb a felhasználói elutasítás kockázata. Jól kialakított architektúra irányítással lehet ezt a hatást csökkenteni.

Függőségek létrehozása

Az érett vállalati architektúra képesség eredménye lehet olyan függőségek tudatos kezelése, amelyek ma részben rejtetten maradhatnak.
Az első nagy lépés mindenképpen egy architektúra repozitórium (információs adatbázis) felépítése. Architektúra-tartományon belüli kapcsolatokon kívül a tartományok közötti függőségek is fontosak. A közös megoldások új függőségeket vezetnek be az üzleti egységek között:
  • A több üzleti egységet érintő változási kérelmeket prioritásként kell kezelni
  • Az üzleti egységek különböző üzleti ciklusokkal rendelkezhetnek, és eltérő változtatási ablakokat kérhetnek
  • A módosítási kérelmek ütközhetnek egymással
Kockázatot jelenthet a szervezeti egységek közötti ellenségeskedés, ami akár a változáskezelési folyamat teljes felborításához is vezethet. A jó architektúra irányítási gyakorlattal ezt kezelni kell.
Rejtett függőségek lehetnek a projektek között: a projektek megváltoztathatnak közös architektúra komponenseket. Az architektúra komponensek sokféleképpen kapcsolódnak egymáshoz. Az ilyen kapcsolatokkal a projekteket közvetetten kapcsolják egymáshoz architektúra elemek függőségei révén.

Projekt csúszások

Az esetleg előforduló projekt határidő csúszások általában veszélyesek a szervezetek számára. Az architektúra irányítási folyamatok további projekt-ellenőrzési pontokat, például megfelelőségi felülvizsgálatokat vezethet be. Ezek során a megoldás architektúra validálásával segítheti az architekti működés a megvalósítás útjában álló akadályok elkerülését.
Az architektúra menedzsment folyamatok azonban bizonyos estekben késleltethetik is a projekteket, és akár túlzott mértékű fölösleges adminisztrációt is eredményezhetnek. Ezért létre kell hozni egy jól használható architektúra irányítási keretet a szükséges ellenőrzési pontok biztosítására, úgy, hogy az ne okozzon felesleges túlterhelést. Megfelelő architekti eszközök központi repozitóriummal és az együttműködés fokozott támogatásával segíthetnek ebben.
Fejlett tervezéssel és jó kommunikációval, megfelelő architektúra repozitórium használatával, tudásbázisok, közös struktúrák (fejlett architekti szolgáltatások) felhasználásával felgyorsítható a projektek kezdeti szakasza, amikor például kevesebb erőforrásra van szükség a jelen (as-is) helyzet felderítéséhez.

Gondos mérés

Tipikus helyzet sok szervezetnél, hogy tervek készülnek, de az előrehaladást nem követik megfelelően és nem határoznak meg ez alapján intézkedéseket sem.
Az architektúra terv gyakran tartalmaz üzleti teljesítmény mutatókat. Amikor ezeket a mutatókat csoportok és munkatársak értékelésére használják néha ebből váratlan és ellentétes eredmények származnak. Amikor az emberek tudják, hogy méréssel értékelik őket, az drasztikusan megváltoztathatja viselkedésüket.
A vállalati architektúra programok általában nyomás alatt állnak, hogy kézzelfogható üzleti eredményeket mutassanak. Mégis a vállalati architektúra programnak általában nem az a legjobb megoldása, ha a mérőszámokat teszi a legfontosabb, vagy akár egyedüli értékelési szemponttá.
A metrika önmagában jó dolog. A metrikák teljes hiánya veszélyes. Biztosíthatják az üzleti átláthatóságot, és kiemelhetik az operatív szűk keresztmetszeteket és problémákat. A mutatók azonban további kockázatokat vezethetnek be, ezért ezeket óvatosan célszerű használni.
Az architekti gyakorlatok elsősorban a tervezésre összpontosítanak, és fennáll a veszélye annak, hogy elveszítik a „valóság alapjukat”. A jelen (as-is) és a jövő (to-be) helyzetek megfelelő kapcsolatát folyamatosan kezelni kell, az átmenetet tervezni kell, hogy elkerüljük a haszontalan tervek létrehozását.

Kommunikáció

A hatékony és stabil működés egyik kulcsfontosságú tényezője a jó kommunikáció. A jó kommunikációhoz közös nyelvre van szükség, amelyet a különböző felek megértenek. A helyes vállalati architektúra menedzsmant gyakorlatnak meg kell határoznia ezt a közös nyelvet (fogalmak, modellek, tudásbázis), és biztosítania kell a szükséges csatornákat (fórumok, találkozók, eredmények, stb.) a felek között.
Ugyanakkor fennáll annak a veszélye is, hogy nem hatékony, értelmetlen rendszeres találkozókat, „architektúra fórumokat” stb. határoznak meg, amelyek haszontalan architekti tevékenységeket eredményezhetnek. Ezért az architektúra program kommunikációs tevékenységeit szigorúan kell megtervezni, moderálni és összpontosítani az emberek idejének tiszteletben tartására.

Összegzés

A fejlett vállalati architektúra menedzsment képesség sokat segíthet egyes felmerülő kockázatok csökkentésében. Igaz, hogy maga az architekti módszertanok használata, az architektúra menedzsment kialakítása is hozhat be újabb kockázatokat a szervezet életébe, de mégis a legnagyobb kockázatot az jelenti, ha egy olyan szervezet, ahol nagy méretű, összetett architektúrák vannak, melyek ráadásul eléggé gyorsan változnak is, nem alakítja ki a fejlett vállalati architektúra menedzsmentet és nem hasznosítja az architekti munka eredményeit.

2019. július 17., szerda

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

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

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

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


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

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

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

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

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

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

2018. október 3., szerda

Szükség van még vállalati architektúra tervezésre a felhő megoldások terjedése idején?

Milyen hatása van a felhőalapú megoldások terjedésének a vállalati architektúrákra? Kell-e még egyáltalán vállalati architekt? Ilyen és ehhez hasonló kérdések merülnek fel manapság, melyek kapcsán érdemes elgondolkozni az architekti munka változásain.


Mivel egyre több nagy szervezet egyre kevésbé támaszkodik a korábban megszokott saját hatalmas, monolitikus vállalati megoldásaira, csábító azt gondolni, hogy a fenntartható vállalati architektúra (EA – Enterprise Architecture) létrehozásának kemény munkája is lassan feleslegessé válik. Ahogy sok vállalat költözik a felhő alapú megoldások világába, úgy is gondolhatják, hogy jórészt az EA-val kapcsolatos problémától is sikeresen megszabadultak. De valóban ez lenne a helyzet? 


A felhőalapú átalakítások lehetőséget teremtenek új üzleti modellekre, innovációra és a vevői elégedettség fokozására is. A felhő már nem csak egy informatikai varázsszó, az üzleti stratégia meghatározójává kezd válni. A felhő megoldásokra épülő átalakítások megvalósítása nem könnyű: jelentős, megfelelő időben történő erőfeszítést igényel. Új üzleti jövőképet, az igényeket és az ezekhez kapcsolódó kultúrát is meg kell határozni.
Minden szervezet eltérő felkészültségi szinttel rendelkezik a felhő megoldások felhasználására vonatkozóan, és ez meghatározza az első lépéseket és a várható előnyöket a felhő felhasználásra történő átállás folyamatával kapcsolatban. Érdemes ezek ismeretében alaposan megfontolni, hogy mely alkalmazások és infrastruktúra elemek kerüljenek a felhőbe. Célszerű áttekinteni az üzleti és az alkalmazás életciklusokat, az alkalmazás architektúrát, az adatokat és a vonatkozó technológiai megfontolásokat.

Sok éve bebizonyosodott, hogy a jó vállalati architektúra kulcsfontosságú tényező a szolgáltatásorientált architektúrák (SOA) hatékony bevezetéséhez. Sok szervezet megtapasztalta már az EA átvilágítás, egy fajta "due diligence" hiányát projektek bukása vagy részbeni sikertelensége esetében. Hiszen a vállalati architektúra egyszerűen fogalmazva egy áttekintő kép, az üzleti folyamatok és az informatikai szolgáltatások közötti kapcsolatokról. Ehhez szorosan kapcsolódóan szükség van még egy mindennapos irányítási mechanizmusra is, amely szintén egy jól megtervezett vállalati architektúrával jön létre. Mind ezek elmaradhatatlan részei egy olyan megoldásnak, ami biztosítani tudja, hogy a megfelelő technológia képes legyen támogatni az üzleti működés átalakítását.

Cloud használata esetén még inkább szükség van EA-re, mint valaha

A felhő szolgáltatásokra átálló számos szervezet tevékenységét (különösen a nyilvános felhővel próbálkozókét) gyakran sorozatos kisérletek és hibák jellemzik. Egy idő után általában rájönnek, hogy létrejött a lábnyomuk a felhőben anélkül, hogy megnézték volna, hogyan illeszkedik mindez a stratégiájukba és az üzleti igényekhez.
Mára a vállalati architekt tevékenységet több szervezetben kezdik szükségtelennek tekinteni. Ezzel szemben a hibrid informatikai környezet megteremtése a változó üzleti igények kielégítése érdekében pont a vállalati architekt szakemberek munkáját igényli, ami biztosítja az alapvető kapcsolatot az üzleti és az informatikai szolgáltatások között.


Mert mire is van szükség? Meg kell érteni az üzleti igényeket, meg kell határozni a funkcionális követelményeket, meg kell hozni a technikai döntéseket és meg kell határozni a megvalósítási terveket az üzlet és az IT összehangolása érdekében. Egy kis létszámú vállalati architekt csapat létrehozása jó befektetést jelent a szervezet számára. Ezzel elkerülhető a rossz döntések meghozatalának frusztrációja, a helytelen tervek végrehajtása, és hogy állandóan a változó és nem várt üzleti igényekhez kelljen alkalmazkodni. Minden érintett fél érdekeit az szolgálja leginkább, ha összejönnek és megpróbálják megérteni a jövőre vonatkozó elképzeléseket, aztán a tervezést ennek megfelelően végzik. Ezzel egy közös jövőkép alakulhat ki valamint az az érzés is, hogy részesei vagyunk az átalakulás formálásának.

A cloud computing önmagában nem helyettesíti a vállalati architektúrát. Nem nyújt "végtelen skálázhatóságot", nem igaz, hogy „fillérekbe kerül", és az sem, hogy "egy óra alatt megvalósítható" és még sok más problémára sem nyújt önmagában megoldást.
Ez egy izgalmas technológia, amely valóban megvalósíthatja azt az ígéretet, hogy eredményes és hatékonyabb, rugalmasabb számítástechnikai platformokat biztosítson, de napjainkban a felhő nem képes kielégíteni a túlfeszített várakozásokat.

Felhőszolgáltatások integrálása a vállalathoz EA segítségével

Amikor felhő felhasználásáról van szó, valójában szolgáltatásokkal foglalkozunk, csak úgy, mint a klasszikus SOA architektúrák tervezésénél. Egy megfelelő vállalati architektúra modell (célszerűen a szabványos ArchiMate nyelven) pontosan leírhatja a szolgáltatásokat és a szolgáltatások megvalósítását. Ez jól illeszkedik a felhőmodellhez.
Az SaaS-t jól le lehet írni olyan alkalmazási szolgáltatásokként, amelyek az üzleti folyamatokat támogatják. Hasonlóan a PaaS-t mint technológiai szolgáltatást (vagy szolgáltatáscsomagot) modellezhetjük egy adott alkalmazás komponenseinek és adatainak támogatásához.
 Az SaaS követelmények meghatározásához tipikusan szükség van az alábbiakra:
  • Az érdekelt felek motivációja
  • Az üzleti modell, amelyet támogatnia kell
  • Együttműködés más alkalmazásokkal
  • A felhő és a házon belüli rendszerek közötti összeköttetést igénylő szolgáltatások igénybevétele az ügyfél technológia szintjén
  • A megoldás nem funkcionális szempontjai

A hibrid felhőplatform a vállalkozásoknak segítséget jelenthet a saját tulajdonú hardverrel / szoftverrel járó korlátoktól történő megszabadulásban. Olyan környezetet teremt, ahol az üzleti felhasználók gyorsan hozzáférhetnek az általuk igényelt erőforrásokhoz. Ez az automatizálással járó költségeket csökkentheti. Lehetővé teszi a fejlesztők számára az agilis szállítást. Segít az „árnyék IT” megszüntetésében is.
A vállalati architektek közreműködése a felhő megoldásokra való vállalati áttérés esetén a fentiek szerint döntő fontosságú. Az enterprise architect módszerek, bevált gyakorlatok felhasználása minden lényegtes vállalati változás kapcsán előnyös, de a cloud szolgáltatásokra történő átállás kapcsán különösen hasznos a sikeres tervezés és megvalósítás érdekében.