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 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.
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 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.
Ö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
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 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?
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.
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
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
Ö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.
