Modelování dle NAR

Domény se podle NAR dělí na základní horizontální domény (Core), tzv. vrstvy, které představují výkon veřejné správy a provozu OVS a k tomu potřebné zdroje. Vertikální motivační domény určují důvody, proč základní domény obsahují, co obsahují, nebo proč by se měly změnit. Nakonec doména Implementace a migrace podporuje modelování té části reality OVS, kterou představují plánované a realizované změny v základních vrstvách (i změny a balíčky práce-projekty jsou součástí reality OVS).

Detailně jsou architektonické domény NAR popsané přímo ve zdrojovém materiálu:

https://archi.gov.cz/nar_dokument:struktura_modelovanych_architektur#domeny_obsahu_architektur

Metamodel v ArchiMate slouží jako základní rámec pro modelování podnikové architektury. Definuje možné elementy a vztahy, čímž zajišťuje konzistenci a srozumitelnost napříč různými modely a organizacemi. Použití metamodelu zajišťuje kompatibilitu a snadné sdílení modelů vytvořených různými týmy nebo nástroji, což podporuje spolupráci a výměnu informací. Díky němu lze také automatizovat správu modelů a kontrolovat jejich kvalitu. Z pohledu modeláře je metamodel nejdůležitější referencí při tvorbě modelů.

Tento obecný dokument stanovuje „co je možné“ a neříká, které prvky je nutné použít. Informace o povinných využitých prvcích je popsaná v metodikách pro jednotlivá architektonická angažmá (případy užití).

Pro potřeby metodiky modelování architektury v DIA definováno několik úrovní metamodelu, podle očekávané míry detailu obsažených informací v daném modelu. Ukazují také, které elementy by měly být v jádru modelu (Zjednodušený metamodel) a které se hodí pro popis sloužitějších detailnějších konstrukcí (až po Maximální metamodel).

Maximální metamodel ukazuje celkovou množinu prvků a vazeb, použitelných při vytváření modelů pro DIA. Kromě prvků definovaných ArchiMate je tento metamodel rozšířený o prvky z TOGAF a o specifické prvky pro DIA.

Tento metamodel není doporučen k přímému použití ale spíše k vymezení možností v případě velmi komplexních modelů a edukovaných čtenářů.

Tento metamodel je oproti Maximálnímu zjednodušen do podoby, kterou lze očekávat, že bude využívána u modelů obvyklého rozsahu, zejména u tzv. povinných angažmá. Tato metodika modelování dále pracuje se základním metamodelem.

Zjednodušený metamodel ukazuje pouze zásadní elementy. Jeho účelem je hlavně pochopit hlavní myšlenky a koncepce modelů pro DIA.

Pro ilustraci je níže uveden Základní metamodel v podobě, v jaké je prezentován v NARu.

Základní metamodel dle NAR pro ilustraci

Detailně jsou metamodely na jednotlivých úrovních popsány v NARu:

https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#celkovy_metamodel_na_vs_cr

Každá doména v této metodice má vlastní detailní metamodel, který je ale vždy součást celkového metamodelu. Cílem je ukázat výčet elementů a vazeb použitelných pro modelování v dané doméně.

Kompletní informaci o jednotlivých metamodelech najdete v NAR: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#dilci_domenove_metamodely

Metodika NAR přebírá elementy a vazby ze standardu ArchiMate, přičemž ale tvoří jejich nadstavbu. U některých z nich upřesňuje český název a/nebo význam a dále definuje vlastní elementy, byť využívající jako základy typy dle ArchiMate.

Elementy a vazby, které mohou být využity v modelech postavených na metamodelu výše jsou specifikované v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#prehled_lokalizace_prvku_a_vazeb_standardu_archimate

Tato metodika respektuje definovaný vzhled, barevnost a pravidla vizualizace dle standardu ArchiMate. Tato pravidla je třeba dodržet. Obvyklé modelovací nástroje vizuální standard ArchiMate implementují a splňují, není v nich proto třeba v této oblasti nic specifického nastavovat.

Detailní popis použitého vizuálního standardu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#pravidla_pouziti_jazyka_archimate_pro_modelovani_na_vs_cr

Přehled výstupů v jednotlivých architektnických doménách dle NAR

Jak je popsáno v kap. 4.14.1, pracuje tato metodika s deseti architektonickými doménami. Níže je po jednotlivých architektonických doménách v NAR popsán způsob tvorby modelu a příslušných artefaktů. Předpokládá se situace, kdy je architekt jako modelář postaven před úkol zmapovat aktuální situaci v úřadu, tedy že systematický model ještě neexistuje. Na závěr kapitoly jsou uvedena pravidla pro přehledové a průřezové artefakty (katalogy a diagramy), výrazně se vymykající jednotlivým doménám a přesahující je.

Základní modelovaný obsah byznys reality OVS slouží pro lepší pochopení požadavků byznysu na aplikační podporu. Proto potřebujeme poznat a pochopit, jaké má úřad agendy a činnosti (funkce a procesy), jestli jsou vykonávány jako služby, a dále kým, pro koho a jak, kterým obslužným kanálem, s jakými daty a dokumenty.

Následující kapitoly vysvětlují, jak modelovat prvky reality, které se odlišují od komerčního užití jazyka ArchiMate a jsou typické pro veřejnou správu ČR.

Agendy a agendové činnosti jsou základními elementy pro modelování náplně práce úřadu. Jsou primárně definované a udržované v Registru Práv a Povinností¹⁾, kde je také uvedeno přiřazení k jednotlivým úřadům.

Je vhodné zmapovat agendy a činnosti nezávisle na RPP, aby byly dokumentované i neohlášené agendy, které v RPP nejsou, ale úřad je vykonává. Možným zdrojem informací může být Organizační řád úřadu a komunikace s příslušnými Ohlašovateli agend a referenty.

Agenda i agendová činnost jsou modelovány pomocí elementů „Agenda“ a „Agendová činnost“ (Business function dle ArchiMate). Při modelování je převzat oficiální název a identifikátor agendy a činnosti z RPP. Popis by pak měl obsahovat specifika realizace dané agendy či činnosti v daném úřadě, aby nedocházelo k duplikování informací z RPP.

Identifikace elementů a vazeb pro tuto oblast v metamodelu

Služby veřejné správy jsou detailnějším rozpadem agend. Popisují, jak agendy slouží klientům úřadu a jak jsou navázané na produkty, smlouvy, předpisy a jakými obslužnými kanály je poskytovaná.

Zdrojem pro výčet služeb je Katalog služeb veřejné správy²⁾, který je členěn i dle poskytovatelů služby (úřad, který danou službu poskytuje).

Je vhodné zmapovat služby nezávisle na KSVS, aby byly dokumentované i realizované služby neohlášených agend, interní služby poskytované úřady navzájem a služby pokrývané externími dodavateli (typicky služby IT podpory, správa budov, apod,).

Služby mají velmi různorodou granularitu a celkové množství služeb je značné, proto je vhodné některé menší služby seskupovat pod jeden element postihující celou množinu. Informaci o jednotlivých pokrytých službách pak je možné zadat do popisu.

Služby veřejné správy jsou modelované pomocí elementu „Služba veřejné správy“ (Business service dle ArchiMate). Při modelování je převzat oficiální název a identifikátor agendy a činnosti z KSVS. Popis by pak měl obsahovat specifika realizace dané agendy či činnosti v daném úřadě, aby nedocházelo k duplikování informací z KSVS.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Životní události a situace mají velký význam pro konzumenty služeb – klienty úřadů. Popisují významné změny a stavy v jejich životě a často bývají spouštěči či důsledky využití služeb úřadů. Při modelování jsou využité často jako vstupní body do interakcí občana s IS úřadů – tedy obvykle při návrhu řešení IS.

Pro modelování podnikové architektury ale obvykle zásadní nejsou, neboť pro identifikaci služeb a procesů jsou použité jiné stabilní zdroje informací.

Životní události jsou modelované pomocí elementu „Životní událost“ (Business event dle ArchiMate). Obvykle jsou napojené na procesy či funkce realizující jednotlivé obchodní služby, jako jejich spouštěče či důsledky. Mohou být případně navázané na samotné Služby VS pro evidenci jejich pokrytí.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Struktura organizace je vyjádřena stromovou strukturou útvarů, případně i konkrétních pracovních pozic. Při modelování podnikové architektury se tyto prvky používají pro mapování vztahu daného útvaru na služby, kanály, či jiné části, např. pro vyjádření vlastnictví, či účasti na provádění. Dále je vhodné využití pro vizualizaci komplexní organizační struktury a jejích částí, včetně umístění. Pro potřeby OHA se informace z organizační struktury využívají pro popis skladby projektového týmu.

Informace o organizační struktuře úřadu je primárně udržovaná v Organizačním řádu. Není tedy nezbytně nutné ji modelovat samu o sobě.

Organizační jednotky a pracovní pozice jsou modelované pomocí elementů „Útvar“, „Organizace“ či „Účastník interakce s VS“ (Business actor dle ArchiMate). Obvykle jsou napojené na Službu VS či Obslužný kanál VS.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Předpisy v různé podobě (zákon, vyhláška, vnitřní předpis, …) jsou často důvodem pro existenci dané služby či formují její fungování. Z toho důvodu je zajímavé je modelovat na úrovni podnikové architektury, zejména pak mapování na služby a produkty. Využití je pak právě pro gap analýzy při změnách příslušných předpisů. Primárním zdrojem je legislativa ČR, EU a sada vnitřních předpisů úřadu. Je vhodné striktně přenést název a identifikátor pro zamezení duplicit. Do popisu předpisu je pak vhodné uvést dopady do úřadu.

Předpisy jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Obvykle jsou navázané na Službu VS či Produkt VS.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Obslužný kanál popisuje rozhraní, skrz které klient či pracovník úřadu přistupuje k jeho službám. Kanál je často předepsán legislativně (typicky ze zákona o právu na digitální službu). Obslužný kanál je modelovaný pomocí elementu „Obslužný kanál VS“ (Business interface dle ArchiMate). Obvykle je vázán jako mezičlánek mezi Službu VS a Účastníka interakce s VS.

Procesy jsou obvykle nejdetailnější úrovní popisu obchodní vrstvy v podnikové architektuře. Cílem je identifikovat: znát jejich výčet a umět slovně popsat jejich význam. Dobrým zdrojem pro identifikaci procesů bývají vnitřní směrnice, případně jakákoli jiná dokumentace procesů, např. v BPMN.

Na této úrovni lze popsat i obchodní funkce. Obchodní funkce je obecnější pojem než proces. Proces je z pohledu NAR vnímán jako specifický druh obchodní funkce, který má charakteristiku procesu: má jasného vlastníka, je řízený jako proces a chová se jako proces.

Procesy i obchodní funkce jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Hlavní vazbou je realizace příslušné Služby VS. Pokud je to vhodné, je možné navázat funkci/proces na odpovídající objekty (sloužící jako vstupy či výstupy) a role, definující sadu vlastností, které má mít Účastník interakce s VS, aby mohl části procesu vykonávat. Jak bylo zmíněno výše, procesy často spouští vybraná Životní událost a naopak, výstupem procesu může být Životní událost u klienta úřadu. Pro takto velký detail je třeba mít opodstatnění, neboť významně zvyšuje množství potřebných informací a čas na modelování a dále se může již překrývat s dalšími úrovněmi modelování, jako je modelování procesů, či funkční analýza.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Důležitými čtenáři byznys architektury jsou business architekti, datoví/informační architekti a vlastníci produktů. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:

• Hledisko portfolia (klasifikace) byznys funkcí, procesů a služeb
• Hledisko funkcí veřejné správy
• Produktové hledisko
• Hledisko spolupráce byznys procesů
• Hledisko organizační struktury
• Hledisko spolupráce aktérů

Každý modelovaný typ elementu by měl mít vlastní katalog, jelikož společně s maticí představují výchozí předpoklad pro jeho správné grafické vyjádření. Nejdůležitější pro čtenáře výše bývají následující:

• Katalog agend, činností (funkcí a procesů)
• Katalog služeb a úkonů veřejné správy
• Katalog aktérů (jejich typů) a jejich rolí
• Katalog obslužných rozhraní veřejné správy
• Katalog typů subjektů a objektů (konceptuální sémantický katalog)³⁾

Dále to mohou být například:

• Katalog organizačních jednotek, útvarů a pozic
• Katalog životních událostí, uplatnitelných vůči OVS
• Katalog formulářů a výstupů OVS

Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.

Přesnou definici prvků a metamodel pro obchodní vrstvu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_byznys_architektury_ba

Architektura aplikací a dat je stěžejní částí architektonických modelů, neboť drtivá většina agend z byznys architektury je realizovaná právě službami aplikací. V této oblasti se zaměřujeme na zmapování portfolia aplikací v úřadu a způsob, jakým spolu aplikace interagují pomocí rozhraní a s jakými daty pracují. Dále nás zajímá mapování na prvky z úrovně byznys architektury, aby byl zřejmý důvod existence jednotlivých aplikací. Doporučená redukce metamodelu NAR pro aplikační úroveň je vyobrazená na následujícím schématu.

Doporučená redukce metamodelu aplikační architektury 

Aplikační komponenta je nejvýraznější element aplikační architektury. Reprezentuje jednotlivé IT systémy, aplikace, nebo jejich části (pokud je to z pohledu podnikové architektury zajímavý detail) v podniku. Katalog aplikačních komponent je základním prvkem podnikové architektury, neboť dnes je většina služeb realizovaných právě pomocí IT systémů. Je proto vhodné investovat úsilí do jeho vybudování a údržby.

Základními atributy aplikačních komponent by měly být:

• Název
• Identifikátor
• Vlastník z byznysu (tzv. Věcný správce ISVS, určuje účel aplikace a její funkčnosti)
• Technický vlastník (tzv. Technický správce ISVS, navrhuje řešení a stará se, aby aplikace fungovala)
• Kategorizace
• Kritičnost pro fungování podniku

Doporučených atributů, užitečných pro správu aplikačního portfolia jsou desítky, viz přiložený soubor. Soubor lze použít pro inspiraci pro identifikaci atributů či vazeb, které by mohly být u aplikační komponenty evidované.

media_image25.emf

Zdrojem informací o aplikačních komponentách je typicky portfolio udržovaných aplikací a systémů evidované provozními týmy IT.

Zásadní informace u aplikační komponenty jsou vazby na okolí:

• Jaké aplikační funkce a služby realizuje
• Jaká aplikační rozhraní poskytuje a konzumuje
• S jakými Datovými objekty pracuje

Situace je ilustrována na následujícím obrázku. Podrobněji je o těchto elementech a vazbách pojednáno níže.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Aplikační služba realizuje Službu veřejné správy skrze využití ve Funkci/procesu VS. Je hlavním pojítkem mezi aplikační a byznysovou vrstvou architektury. Aplikační služba je tedy vlastně opodstatněním pro existenci Aplikační komponenty.

Aplikační služby lze chápat jako požadavky na funkce IT aplikace, které definuje vlastník příslušných procesů a služeb na byznys úrovni. Aplikační služba je pak realizována sadou Aplikačních funkcí, které poskytuje příslušná Aplikační komponenta.

Aplikační služby by měly vyplývat z potřeb prováděných Funkcí/procesů VS, které definuje příslušný vlastník.

Fragment metamodelu NAR ilustrující kontext Aplikační služby

Aplikační rozhraní je bod, kde jsou aplikační služby zpřístupněny uživatelům, či jiným aplikačním komponentám.

Význam evidence Aplikačních rozhraní je hlavně v systematizaci komunikace mezi aplikacemi a vůči uživatelům. Díky zmapování rozhraní je možné identifikovat vzory komunikace mezi aplikačními komponentami a je snadné přepoužívat existující rozhraní s vědomím dopadu změny. Velmi důležitá je evidence rozhraní k aplikačním službám, které jsou sdílené externě (mezi úřady).

Obvyklým zdrojem informací o existujících rozhraních je obchodní proces, kde jej identifikované použití rozhraní na aplikační úrovni. Dále je možné identifikovat existenci rozhraní ze solution architektury a/nebo z technické dokumentace aplikací. Dobrým zdrojem je i celofiremní integrační komponenta typu ESB (Enterprise Service Bus), či podobná, kde jsou často využívaná rozhraní koncentrována.

Pokud mezi sebou organizace komunikují aplikačním rozhraním, pak je to realizace procesu, např. využití business služby. Proto je vhodné zanést tuto informaci do modelu pomocí vazby na příslušnou obchodní Funkci či Proces (viz obrázek výše s kontextem aplikační komponenty).

Aplikační rozhraní je vždy vlastněno vybranou aplikační komponentou, které jej poskytuje a je využíváno libovolným množstvím jiných aplikačních komponent.

K aplikačnímu rozhraní je možné namapovat Datové objekty, které jsou jím přenášené.

K aplikačním rozhraním je vhodné udržovat dle potřeby následující atributy:

• Technologie (REST, XML, proprietární, …)
• Typ komunikace (sync, async, batch)
• Reference na detailní dokumentaci k rozhraní

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Datové objekty reprezentují realizaci Objektů VS (Business Object) na aplikační úrovni, tj. Na úrovni obrazů skutečných věcí z BA v datech informačních systémů. Případně jsou to reprezentace jiných pasivních prvků evidovaných na úrovni aplikační architektury. Jejich granularita je obvykle jemnější než u Objektů VS, aby na ně bylo možno jednoznačně navázat dalšími prvky v aplikační vrstvě.

Zdrojem pro model Datových objektů jsou konceptuální a logické datové modely příslušných aplikací, ideálně získané z datového katalogu úřadu⁹⁾. Abychom předešli duplikaci informací mezi datovým katalogem a modelem podnikové architektury, je vhodné rozmyslet kde bude master pro tyto informace – zda datový katalog, nebo model EA a podle toho nastavit procesy replikace z masteru na ostatní umístění.

Modelujeme hlavně ty Datové objekty, které jsou reprezentací Objektů VS a jsou sdílené mezi aplikacemi. Je vhodné vždy rozmyslet, zda daný objekt potřebujeme v modelu mít, abychom předešli zvyšování komplexity modelu, přílišné náročnosti údržby aktuálního stavu a zaručili konzistentní granularitu napříč modelem.

Je důležité namapovat přenášené Datové objekty na Aplikační rozhraní – získáme tak podklad pro informaci o toku dat.

Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu

Důležitými čtenáři aplikační architektury jsou solution architekti, datoví/informační architekti a vlastníci aplikací a dále prakticky všechny role na úrovni Byznys a Technologické architektury (díky poloze AA mezi BA a TA). Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:

Každý modelovaný typ elementu by měl mít vlastní katalog, nejdůležitější pro čtenáře výše bývají následující:

• Katalog aplikačních komponent

Dále to mohou být například:

• Katalog aplikačních služeb
• Katalog rozhraní
• Katalog datových objektů

Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.

Matice zajímavé pro tuto vrstvu jsou uvedené níže.

Přesnou definici prvků a metamodel pro aplikační a datovou architekturu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_is_-_aplikacni_architektury_aa

Motto: „na čem to běží, kde to běží a jak si to spolu povídá“.

Tato oblast je jedna ze dvou, které se v této metodice věnují infrastruktuře. Cílem obou je popsat technické podhoubí, které umožňuje fungování podnikových aplikací a jejich komunikaci.

Vrstva technologické infrastruktury má za cíl ukázat, jaké technické platformy jsou v podniku k dispozici, kde se nacházejí a jaké technologické služby jednotlivé komponenty poskytují směrem k aplikační a byznysové vrstvě. Komunikační vrstva se pak soustředí na mapu umístění důležitých technologických prvků a identifikaci komunikačních cest mezi nimi (viz kap 4.6.4). Doporučená redukce metamodelu NAR pro úroveň technologické infrastruktury je vyobrazená na následujícím schématu.

Doporučená redukce metamodelu technologické infrastruktury

Technologická služba (Technology service v ArchiMate) popisuje požadavek na to, co by měla technologická vrstva umět a poskytovat směrem k vyšším vrstvám, zejména aplikační. Definuje se proto, aby byl zřejmý účel technologických prvků v podniku (realizují tech. službu). Tech. služby realizují podmínky pro fungování aplikací a procesů na aplikační úrovni. Zdrojem pro přehled Tech. služeb může být implementace strategické části metodiky ITIL v podniku. Očekává se, že na definici tech. služeb poskytovaných v podniku se podílí i podnikový architekt. Příklady tech. služeb jsou Internetová konektivita, VPN, Databázová služba, Souborová služba, apod. Služby lze zapouzdřovat dle úrovní detailu.

Technologické funkce (Technology function v ArchiMate) lze využít k popisu schopností nabízených na úrovni uzlů. Typicky se jedná o funkce jednotlivých datových center, jako např. Zajištění výpočetního výkonu, Virtualizace, Vysoká dostupnost, Zálohování, Archivace, Logování, apod. Funkce lze také zapouzdřovat, pokud je to vhodné a z dlouhodobého hlediska je množství informací takto udržitelné a potřebné pro potřeby podnikového architekta.

Tech. služby jsou realizovány Tech. funkcemi.

Příklad modelu technologické služby

Uzel (Node v ArchiMate) je základním prvkem modelu technologické infrastruktury. Reprezentuje typicky server či jiný fyzický prvek počítačového typu. Zařízení (Device v ArchiMate) je pak obvykle nějaká jeho fyzická součást a Systémový software (System software v ArchiMate) pak běží na daném zařízení, např. operační systém či DB server. Node tak reprezentuje platformu, kterou má podnik k dispozici.

Zařízení může figurovat jako samostatný prvek na úrovni uzlu, typicky pro specializovaná zařízení typu firewallu, či fileserveru.

Důležitým atributem v evidenci u Systémového software je jeho verze. Doporučujeme držet ji na úrovni podnikové architektury, aby bylo možné dělat přehledy dostupných platforem z hlediska konsolidace a aktualizace.

Příklad vztahu mezi uzlem, systémovým sofwarem a zařízením

Komunikační infrastruktura se modeluje elementem Síť (Communication Network v ArchiMate). Síť propojuje uzly. Typickými příklady komunikačních sítí jsou WiFi na úřadu, Lokální síť (LAN), Internet (WAN).

Uzly se k síti připojují pomocí vazby agregace.

Příklad propojení uzlů pomocí sítě LAN

Element Artefakt (Artefact v ArchiMate) reprezentuje datový prvek na úrovni tech. architektury. Element Artefakt použijeme tehdy, když chceme ukázat realizaci Datového objektu z aplikační vrstvy (viz kap. 4.6.2.1.4), např. za účelem zaznamenání jeho technického uložení či využití v uzlu. Rozhodně není vhodné snažit se pomocí Artefaktů modelovat DB tabulky, Artefakt reprezentuje ucelenou struktur údajů uloženou samostatně (např. celou databázi či schéma v ní). Pro potřeby detailních informací využijte technickou dokumentaci. Modelování Artefaktů je součástí pokročilého modelování datové architektury.

Realizace datového objektu několika artefakty v node (uzlu)

Čtenáři informací z oblasti technologické architektury jsou zejména Manažeři provozu (operations), Infrastrukturní inženýři a Architekti řešení (SAR). Obvykle je zajímá:

• dostupné portfolio technických platforem pro realizaci změn v aplikačním portfoliu
• způsob realizace technologických služeb
• propojenost uzlů pro komunikaci
• dostupnost technologických funkcí v jednotlivých umístěních

Relevantní hlediska NAR:

Doporučujeme formou katalogů evidovat všechny základní typy elementů:

• Katalog Technologických služeb (víceúrovňový)
• Katalog Uzlů (včetně Systémových SW a Zařízení)
• Katalog Sítí
• Katalog Technologických služeb
• Katalog Technologických funkcí

Mapa technologického portfolia

Mapa využití tech. služeb pro realizaci aplikační vrstvy pro vybranou aplikaci

Realizace aplikací pomocí SW a HW infrastruktury

Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.

Přesnou definici prvků a metamodel pro architekturu IT technologické infrastruktury najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_ict_technologicke_architektury_ta

Tato vrstva má za úkol popsat geografické umístění prvků infrastruktury a komunikační cesty mezi nimi. Využívá se tedy primárně pro model datových center a komunikačních okruhů. Důležitými elementy zde jsou Budova (Facility v ArchiMate) a Síť.

Pro potřeby modelování komunikačního kanálu mezi Budovami je možné efektivně použít elementu Komunikační cesta (Path v ArchiMate), případným s vyznačením, které sítě jej realizují.

Z hlediska podnikové architektury jsou zajímavými umístěními (lokacemi) datová centra, případně serverovny. Modelují se jako Budovy, které agregují prvky, jež jsou v nich umístěné. Součástí modelu může být, jaké daná lokace nabízí tech. funkce. Lokace jsou propojené Sítěmi.

Důležitou vlastností Budovy je označení vystihující geografickou polohu.

Příklad modelu infrastruktury s dvěma datovými centry

Čtenáři informací z oblasti komunikační a fyzické infrastruktury jsou zejména Manažeři provozu (operations), Infrastrukturní inženýři a Architekti řešení (SAR). Obvykle je zajímá:

• propojenost uzlů pro komunikaci
• dostupnost technologických funkcí v jednotlivých umístěních

Relevantní hlediska NAR:

• Nutno definovat v NAR

Zajímavé katalogy jsou:

• Katalog lokací (budovy, např. datová centra, serverovny, apod)

Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.

Analogicky jako v kap. 4.6.3.4.

Přesnou definici prvků a metamodel pro architekturu komunikační a fyzické infrastruktury najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_komunikacni_a_fyzicke_infrastruktury_ki

V této oblasti se díváme na změny architektury podniku v čase, zejména jako výhled do budoucnosti ve formě roadmapy migrace. Účelem je ukázat čtenářům postup transformace z aktuálního stavu architektury na cílový. Při tvorbě je výchozím bodem současný stav architektury, musíme jej mít tedy zmapovaný.

Migrací se myslí postup přechodu ze současné do cílové architektury přes potenciální dočasné (tranzientní) architektury.

Tým podnikové architektury vyjedná s ostatními zainteresovanými osobami podobu cílové architektury, která vyplývá ze strategických plánů a cílů (detailněji viz kap. 4.6.6) a stanoví cestu (roadmapu) k cílové architektuře. Přechodové architektury slouží jako záchytné body pro dokončení transformace vybraných oblastí.

Mezi každými dvěma stavy architektury je pak stanovena sada Rozdílů, které je nutné realizovat pomocí projektů, či programů (Balíčků práce) – viz diagram níže. Tento podklad je dále využit při plánování projektového portfolia podniku a při realizace konkrétních projektů. Během realizace projektu poskytuje podnikový architekt součinnost ve formě podkladů k daným Balíčkům práce a konzultací.

Po realizaci daného Balíčku práce (typicky release) musí podnikový architekt zaktualizovat aktuální stav architektury a roadmapu.

Změny v architektuře a její průběh v čase jsou reprezentovány několika elementy:

• Stavy architektury definují současné, cílové či přechodové podoby podnikové architektury. Nesou informaci o čase, v němž by měly být realizované.
• Stav architektury je kromě popisu doplněn odkazy na Základní elementy struktury z jednotlivých domén, které jsou jím ovlivněné. Vazba na Stav architektury určuje i období platnosti změny daného elementu.
• Mezi nimi jsou definované Rozdíly, které jsou pak zpracovány pomocí Balíčků práce (které mají zhruba velikost projektu a jsou podkladem pro projektového manažera při plánování projektu).
• Výstup projektu pak popisuje hlavní potřebné změny, nutné k dosažení daného Stavu architektury . Výstupem může být např. nová aplikační komponenta, zrušená stará technologie, či nový obchodní proces. Nejedná se o model cílového stavu, ale jednoduchý popis potřebných změn seskupených tak, aby bylo možné je realizovat projektem.

Níže je uveden metamodel včetně kontextu do návazných oblastí architektury.

Identifikace elementů a vazeb pro tuto oblast v metamodelu

Mezi dvěma Stavy architektury (Plateu v ArchiMate) jsou definované Rozdíly (Gap v ArchiMate) a jejich realizace probíhá pomocí Balíčků práce, které definují oblast prací, které se musí provést v určitém pořadí či čase, což je hodnotný podklad pro projektového manažera.

Ke Stavu architektury je vhodné pro ukotvení v čase přiřadit základní elementy z jednotlivých domén. Toto lze dobře řešit maticemi, kde je na jedné ose seznam Stavů architektury a na druhé sada elementů daného typu z vybrané domény.

Stav architektury v dané doméně (např. aplikační) je vizualizován přehledovými mapami architektury s vyznačením, které existující prvky v ní budou zastoupené i nadále, které přibudou a které naopak budou ukončené. Pro vizualizaci této informace na diagramu je používané barevné ohraničení elementu, např typu: červená=ukončení, zelená=pokračující, modrá=nový. Pozn. Nejedná se o vybarvení elementů dle vrstvy architektury, ale specifické bravy okrajů daných elementů na diagramu jako doplňková informace.

Typická podoba roadmapy migrace je na obrázku níže.

Příklad roadmapy se dvěma paralelními přechodovými architekturami

Pro účely přípravy realizace identifikuje podnikový architekt Balíčky práce (Work package dle ArchiMate), které je potřeba realizovat, aby došlo k přechodu mezi dvěma Stavy architektury, jak je popsané výše. Balíčkem práce na této úrovni bývá Projekt. Projekty mohou být seskupené do Programu. Pokud je to vhodné, může být identifikován i detailnější rozpad Balíčků práce v rámci Projektu. Balíčky práce mohou být označené i informací o potřebném pořadí realizace či vzájemné závislosti.

Architekt vytváří podklady pro věcné zadání projektu, samotný projekt je vytvářen a řízen projektovým managerem.

Výstupem je přehled projektů, které je nutné realizovat, aby došlo k nastolení cílového Stavu architektury. U každého projektu by měly být zřejmé jeho výstupy (Outcome dle ArchiMate), cíle a časování. Očekává se, že identifikované Balíčky práce budou navázané na skutečné rozběhlé projekty, řízené z podnikového týmu PMO (Project Management Office).

Diagram balíčků práce navázaných na konkrétní stavy architektury

Očekávanými čtenáři této oblasti architektury jsou lidé zodpovědní za strategii a směřování podniku (včetně podnikových architektů), role z oblasti řízení projektů a jejich portfolia, zejm. projektoví a programoví manažeři a solution architekti. Dále může být informace užitečná pro manažery provozu a správy, aby tušili, kdy je čekají jaké změny ve spravovaném porftoliu.

Pro ně zajímavá hlediska z NAR jsou:

• Hledisko implementace a migrace

Elementy primárně zařazené do této oblasti mají své katalogy:

• Katalog Stavů architektury
• Katalog Rozdílů
• Katalog Balíčků práce
• Katalog Výstupů

Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.

Ilustrační příklad: Pohled implementace a migrace

Příklad matice Mapování stavů architektury na měněné elementy

Přesnou definici prvků a metamodel pro architekturu implementace a migrace najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_implementace_a_migrace https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur

V této oblasti modelujeme důvod, proč úřad (jako podnik) existuje a proč vypadá tak jak vypadá. NAR v této oblasti kombinuje motivační a strategickou vrstvu (dle ArchiMate).

Chceme vědět, v čím zájmu je, aby úřad existoval a jaké jsou motivátory k jeho existenci a hlavním aspektům jeho fungování. Z těchto prvků jsou pak odvozené cíle, které je naplňují. Na tomto základě pak definujeme principy, které ovlivňují architektonické požadavky, vedoucí na realizaci vnitřku organizace a omezení, která je nutné brát v potaz. Dále by se v této oblasti měla nacházet odpověď na důvody, proč mají proběhnout / proběhly v organizaci změny.

Strukturu elementů a vazeb použitelných v této oblasti popisuje metamodel na obrázku níže.

Identifikace elementů a vazeb pro tuto oblast v metamodelu

Zainteresovaná strana odpovídá na otázku „V čím zájmu je, že jako úřad existuji a dělám to co dělám?“ Zainteresovanou stranou tedy bývá externí zřizovatel úřadu (vláda, ministerstvo?), a jeho nejvyšší interní představitelé (ředitel, ředitelé sekcí, …). Přehled zainteresovaných stran lze získat z organizační struktury úřadu. Důležité je nepoužívat konkrétní jména lidí, ale názvy jejich pozic či organizace. Identifikace Zainteresovaných stran je klíčová pro určení odpovědnosti za strategické směřování úřadu. Zainteresovanou stranu modelujeme pomocí elementu Stakeholder v ArchiMate.

Hnací prvky (též motivátory) představují interní, či externí vlivy, které v důsledku formují vnitřní podobu úřadu („Proč úřad vypadá, jak vypadá?“). Většinou se jedná o zájmy Zainteresovaných stran.

• Veřejné potřeby jsou takovým případem hnacích prvků. Obvykle jsou dlouhodobě stabilní a určují základní aspekty fungování organizace.
• Analýzy či Vyhodnocení potřeby jsou výsledkem zhodnocení naplnění daného motivátoru. Identifikují potřebu změny, aby byl motivátor korektně naplněn. Definují se častěji, obvykle periodicky jako důsledek kontroly stavu organizace a jsou iniciátorem transformačních aktivit.

Hnací prvky (vč. Veřejných zájmů) modelujeme pomocí elementu Driver v ArchiMate, Vyhodnocení potřeb/Analýzu pomocí elementu Assesment. Propojíme je vazbou asociace se Zainteresovanými osobami a Vyhodnoceními potřeb.

Strategické cíle naplňují Hnací prvky. Jsou často používány jako základní měřítko úspěšnosti fungování organizace. Do jaké míry/hodnoty budeme daný Cíl naplňovat, určuje Výstup. Strategický cíl identifikujeme z Hnacího prvku tak, že jím definujeme, jaké změny chceme v dané oblasti dosáhnout. Název Cíle by měl obsahovat slovo určující druh/povahu změny („zvýšíme“, „snížíme“, „dosáhneme“). Výstup pak doplňuje Cíl o konkrétní hodnotu, či míru na kterou Cíl naplníme. Výstup je pak skvělým podkladem pro identifikaci KPIs či akceptačních kritérií pro strategické projekty. Strategické cíle modelujeme pomocí elementu Goal v ArchiMate, Výstupy pak pomocí elementu Outcome. Typicky jsou Cíle navázané na Hnací prvky vzniklé z Vyhodnocení potřeb (např. audit či RACI analýza, viz výše) a dále jsou na ně realizační vazbou napojené Výstupy.

Architektonické principy definují sadu obecně platných pravidel, kterými se lze řídit při tvorbě podnikové architektury v dané oblasti. Jejich dodržováním se implicitně naplňují relevantní Strategické cíle. Při definici Strategických cílů je proto třeba brát v potaz jejich univerzálnost.

Architektonický princip by měl být definován např. následovně¹²⁾:

Pokud nejsme schopni danou část popisu principu naplnit, je pravděpodobné, že je princip nevhodně navržen. Architektonické principy je třeba členit dle oblastí či architektonických domén pro lepší přehlednost pro čtenáře z dané oblasti. Modelujeme je pomocí elementu Principle v ArchiMate. Architektonické principy jsou obvykle navázané na Strategický cíl či Výstup, jehož dosažení/udržení napomáhají.

Pozn.: V souladu s ArchiMate je možné označit sílu vazby pomocí ++/+/-/–.

Při přípravě projektu, který bude realizovat zajištění Cíle či naplnění Výstupu je možné definovat Klíčové požadavky, jejichž splnění toto zajistí. Klíčové požadavky na úrovni podnikové architektury zdůrazňují důležité aspekty, které je potřeba vzít v potaz, např. naplnění určitých Architektonických principů.

Omezující podmínky pak systematickým způsobem vymezují „hřiště“, na kterém lze řešení stavět. Např. povolenými technickými platformami, rámcem rozpočtu či časování. Opět se mohou odkazovat na příslušné Architektonické principy či konkrétní elementy v jednotlivých doménách.

Příklad hierarchie úrovní

Očekávanými čtenáři informací v této oblasti jsou samotné Zainteresované strany – obvykle vrcholoví manažeři odpovědní za strategii v dané oblasti, dále samotní podnikoví architekti, architekti řešení a manažeři projektového portfolia. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:

• Motivační hledisko strategického směřování

Toto hledisko může být případně rozdělené podle očekávaných čtenářů na:

• Hledisko zainteresovaných stran
• Hledisko architektonických principů

Doporučujeme tvořit následující katalogy elementů:

• Katalog Zainteresovaných stran
• Katalog Veřejných potřeb/hnacích prvků
• Katalog Strategických cílů
• Katalog Vyhodnocení potřeb/analýz
• Katalog Výstupů
• Katalog Architektonických principů
• Katalog Klíčových architektonických požadavků a Omezujících podmínek

Zajímavé diagramy pro tuto doménu jsou uvedeny v tabulce níže. Pro lepší přehlednost je na obrázku barevně znázorněno pokrytí elementů metamodelu v diagramech.

Umístění elementů na diagramy v této oblasti

V této oblasti nejsou definované žádné specifické matice. Pro lepší přehlednost je možné připravit matice ukazující důležité vazby, např. pokrytí Hnacích prvků pomocí Strategických cílů, či genezi Hnacích prvků od Zainteresovaných stran či z Vyhodnocení potřeb.

Přesnou definici prvků a metamodel pro architektura strategie a směřování najdete v NARu: https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_strategie_a_smerovani_mahttps:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_strategie_a_smerovani_ma

Následující oblasti architektury jsou průřezové a volitelné. Pro potřeby DIA je očekáván hlavně slovní popis situace.

Jedná o oblasti, kde není nyní metodika zcela detailní, proto u nich není popsán mechanismus modelování. Systematičtější přístup, který se pravděpodobně bude dlouhodobě rozvíjet a upřesňovat, je popsán v příslušných částech NAR.

Architektura bezpečnosti je důležitá průřezová disciplína, vyžadující díky své komplexitě vlastní metodiku. Přístup úřadů k této problematice je definován příslušnými předpisy a audity. Pro potřeby architektury je důležitá evidence vztahů jednotlivých aspektů bezpečnosti k prvkům podnikové architektury a zejména zajištění jejich průběžná aktualizace. Tento problém lze řešit např. využitím frameworku ESRM¹³⁾ od společnosti BizzDesign. Framework využívá vlastního rozšíření elementů jazyka ArchiMate v motivačním aspektu.

Základem frameworku je iterativní proces sestávající z 9 kroků, ilustrovaných na obrázku níže, které zajišťují systematické pokrytí bezpečnostních aspektů architektury.

Základní proces ESRM

Červené kroky představují fázi zhodnocení rizik, zelené pak fázi realizace opatření a mechanismů pro provoz, která pokrývá i realizaci prostředků a nástrojů pro fázi zhodnocení rizik.

https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_bezpecnostni_architektury_saInformace k architektuře bezpečnosti najdete v NARu zde: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_bezpecnostni_architektury_sa

Momentálně není poptávané modelování výkonnosti pro potřeby DIA. Úřady by ale měly zavádět a udržovat mechanismy umožňující měřitelnost výsledků provedených změn a jejich dlouhodobého provozování.

Jazyk ArchiMate nyní neobsahuje metriky ani jiné ukazatele výkonnosti, proto je zavádí NAR. Metodika v této oblasti však momentálně není striktně předepsaná.

Informace k architektuře výkonnosti najdete v NARu zde: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_vykonnostni_architektury_pa

Tato oblast zajišťuje korektní navázání elementů z ostatních architektonických domén (zejména Motivační) na konkrétní předpisy, standardy a kritéria udržitelnosti. Jedná se hlavně o popis toho jak jsou modelované tyto elementy a jak se na ně odkazovat ze zbylých částí modelu.

Předpokládaný způsob modelování je takový, že DIA/OHA bude vlastnit elementy reprezentující používané předpisy apod. a architekti úřadů na ně budou odkazovat pomocí vazeb z relevantních elementů – např. Hnacích prvků, Strategických cílů, Omezujících podmínek, apod., aby byl zřejmý jejich původ.

Informace k architektuře shody s pravidly najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_standardizace_shody_s_predpisy_a_udrzitelnosti