Tato kapitola stanovuje přesně, jaké objekty architektury úřadu jsou předmětem zájmu při sestavování modelu a jeho architektonických výstupů jako způsobu popisu obrazu architektury úřadu.

Kapitola se zejména zaměřuje na prvky metamodelu a na formální (předměty dodávky) a neformální (artefakty) architektonické výstupy.

Metamodel je předpis a logika používání jazyka pro modelování architektury v praxi. Při tvorbě Národní architektury VS ČR budou vytvářeny modely v jazyce ArchiMate podle předem schváleného metamodelu. Užití metamodelu je plně v souladu se specifikacemi jazyka ArchiMate a architektonického rámce TOGAF. Metamodel architektury jednoznačně definuje, jaké elementy ze specifikací rámce TOGAF a jazyka ArchiMate a jaké vazby mezi nimi, jsou použity.

• Celkový metamodel jazyka rámce TOGAF 9.2 a jazyka ArchiMate 3.1 – Představuje výčet všech prvků, jejich vazeb a definuje, jakým způsobem budou použity. Tento metamodel je příliš komplexní, a proto byl zredukován do celkového metamodelu této metodiky.
• Celkový metamodel této metodiky – Představuje výčet všech prvků a jejich vazeb, které byly do NAR převzaty z celkové specifikace jazyka ArchiMate ve verzi 3.1.
• Doménové metamodely – Doménové metamodely popisují určitou zájmovou oblast. Rámec TOGAF rozeznává 4 základní domény architektury: byznys architektura, architektura dat, architektura aplikací a technologická architektura. Proto byl vytvořen metamodel pro každou ze zmíněných domén architektury a postupně pro tzv. vertikální domény, které mají svůj původ v motivačním rozšíření ArchiMate a dalších rámcích, nejprve pro Strategické směrování, viz přehled domén v Struktura modelovaných architektur.
• Minimální metamodel – i výběr prvků ze standardů do celkového metamodelu je příliš rozsáhlý a pro úvodní angažmá obtížně použitelný. Proto je v této části doporučena i jeho minimalistická, redukovaná podoba, vhodná pro prvních několik typických architektonických angažmá úřadu.

Důvody a pravidla pro používání metamodelů při tvorbě konkrétních modelů jsou následující:

• Metamodel je abstraktním modelem modelování, důležitým pro správné zachycení a zvýraznění objektů a vazeb v modelu úřadu (co a jak modelovat),
• Metamodel podporuje určitou metodu nebo konkrétní postup tvorby modelů (předepisuje modelovací jazyk, použité elementy a možné vazby).

Modelovací jazyk ArchiMate je složen ze základních stavebních kamenů, kterým se říká elementy (prvky, koncepty). Byl navržen s oporou o několik základních principů, jsou to:

• tři základní architektonické vrstvy (byznys, aplikační a technologická) a tři rozšiřující (strategická, fyzická a implementační)
• čtyři aspekty (motivace, aktivní, chování a pasivní)
• interní a externí aktivní prvky a prvky chování modelu
• individuální a kolektivní aktivní prvky a prvky chování modelu
• specifické prvky Seskupení a Umístění (lokalita)

Jazyk je složen z prvků, které se člení do čtyř kategorií:

• aktivní,
• behaviorální,
• pasivní a
• motivační

V tomto dělení můžeme shledat podobnost s přirozeným jazykem, kde aktivní struktury odpovídají podmětu, behaviorální slovesu a pasivní předmětu. Aktivní elementy jsou definovány jako elementy provádějící nějakou činnost (příklad: business aktéři, aplikační komponenty a zařízení). Behaviorální elementy jsou definovány jako jednotka činnosti prováděná jedním či více aktivními elementy (příklad: proces). Pasivní elementy jsou definované jako objekty, se kterými je prováděna nějaká činnost.

K tomu se přidávají motivační prvky jazyka, které říkají proč je struktura hlavních (core) prvků jaké je a zejména proč by se měla měnit do své cílové podoby.

V diagramech je třeba rozlišit jednotlivé vrstvy (příp. strukturu) modelů pomocí vizuálního uspořádání. Základní elementy vrstev modelu (byznys, aplikační a datová, technologická, infrastrukturní) budou vždy odlišeny barevně. Jednotlivé elementy pohledů jsou i mezi vrstvami vertikálně (shora dolů a naopak) propojeny logickými vazbami.

Metodika předpokládá, že výraznou informací, obsaženou v pohledech na model je i umístění prvků modelu v jeho ploše, v tzv. mapách, také se hovoří o topologii prvků. Pro jednotnou logiku umisťování prvků v diagramech poslouží postupně sestavené referenční modely k jednotlivým vrstvám architektury a k jednotlivým pohledům na ně.

Specifikace standardu ArchiMate 3.1 barevnost prvků nepředepisuje, ale umožňuje ji s výhodou jednotně využít. Rozhodnutí o barevnosti ponechává na architektovi a jeho nástroji.

NAR jde v tomto dále a pro snazší jednotné čtení a interpretaci diagramů modelů předepisuje základní barevnost jednotlivých prvků v tabulkách níže. Barevnost podle RPG není povinná, ale doporučující.

Pokud architekt vyjadřuje v některých diagramech barvou nějakou klíčovou vlastnost prvku, například, že vzniká, mění se nebo zaniká, může použít i jiné barvy, ale vždy musí doplnit legendu barev.

Barevnost prvků podle aspektu

Pokud je potřeba v metamodelu zdůraznit příslušnost prvku k některému aspektu jazyka, učiní se tak pomocí odstínů šedé následovně:

• bílá – abstraktní prvky (kategorie), které nemají instance
• světle šedá – pasivní struktury
• středně šedá – chování
• tmavě šedá – aktivní struktury

Barevnost prvků základních vrstev (domén).

Definovaná struktura metamodelu ArchiMate je členěna na tři vrstvy, které jsou pro účely respektování čtyřvrstvé vize architektury eGovernmentu ČR rozšířeny na čtyři vrstvy. Každá vrstva má barevnou interpretaci dle doporučení originální ArchiMate specifikace, podle které lze určit, o jakou vrstvu se jedná. Tento barevný standard je nutno respektovat a dodržovat.

• Byznys vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou žluté,
• Aplikační a datová vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou tyrkysové,
• Technologická vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou zelené (případně světlejší zelené),
• Infrastrukturní vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou zeleně (případně tmavší zelené).

Komponenty obou technologických vrstev vize čtyřvrstvé architektury VS (IT technologické a infrastrukturní) mohou být v téže zelené, neboť ve skutečnosti tyto vrstvy jsou pouze speciálním rozdělením jednotné technologické architektury standardu ArchiMate pro české potřeby řízení zodpovědnosti za rozdílné technologické služby.

V souladu se specifikací ArchiMate nedoporučuje NAR používat barevné vzájemné rozdělení tzv. aspektů v jednotlivých vrstvách (aktivní prvky, chování a pasivní prvky) – barevné odlišení není nutné, a když, tak jedině stupni šedé.

Barevnost prvků domén motivační architektury

Poslední verze standardu ArchiMate 3.1 zavedla nové barvy pro nové domény (strategickou a fyzickou) a přesunula řadu prvků z byznys domény do strategické. Tím došlo k rozporu v barevnosti prvků vůči původnímu barevnému ladění domén NAR, viz Struktura modelovaných architektur.

Tento rozpor se ještě bude muset řešit. Problém je v tom, že na jedné straně NAR počítá s doménami a prvky, které ještě ve standardu ArchiMate nejsou a až se v něm (pravděpodobně) objeví, mohou mít jinou barvu, než nyní plánuje NAR. Současně je problémem efektivní užívání modelovacích nástrojů, kde nejjednodušší je ponechávat prvkům jejich originální ArchiMate barvu.

Tabulka definice barev dle standardu ArchiMate 3.1⁴⁸⁾

Elementy ve všech vrstvách budou zobrazeny tak, jak je jazyk ArchiMate definuje. Pro standardizované a povinné diagramy je nepřípustné upravovat jejich tvary dané standardem The Open Group.

Vedle toho (a navíc) je ale možné vytvářet na základě korektně zachyceného modelu úřadu libovolné a rozmanité tzv. laické diagramy, představující model netrénovaným čtenářům prostřednictvím intuitivních (často naivních a naturálních) ikon a animací.

Tato verze metodiky modelování a metamodelu v NAR vychází z aktuální verze specifikace ArchiMate, označované jako 3.1. Jelikož již jsou na rok 2019 ohlášena další rozšíření a nové verze, bude potřeba metamodel NAR průběžně aktualizovat. Očekává se ale, že nové verze specifikace budou velkou měrou tzv. zpětně kompatibilní a nebude tak mít zásadní dopad na v této metodice již vyjádřená pravidla a příklady.

Barevnost prvků v tabulce⁴⁹⁾ je 100% převzata z originální specifikace ArchiMate 3.1.

Přehled a vysvětlení jednotlivých vazeb obsahuje následující tabulka⁵⁰⁾:

Pojem	Popis	Symbol
Strukturální vazby
Kompozice (Composition)	Vztah kompozice značí, že prvek je složen z jednoho nebo více jiných prvků (bez nichž nemůže existovat a ony samy také ne). Na rozdíl od agregace může být komponovaný prvek součástí jen jedné kompozice. Kompozice je vždy dovolená mezi dvěma prvky stejného typu a jde o nejsilnější vazbu.
Agregace (Aggregation)	Vztah agregace značí, že prvek sdružuje jeden nebo více jiných prvků. Na rozdíl od kompozice může být agregovaný prvek součástí vícero agregací. Agregace je vždy povolena mezi dvěma prvky stejného typu a jde o druhou nejsilnější vazbu.
Přiřazení (Assignment)	Přiřazení vyjadřuje situaci alokace zodpovědnosti, výkonu chování nebo provádění činností. Vztah přiřazení spojuje prvky chování s aktivními prvky (např. role, komponenty), které je provádějí nebo role s účastníky, kteří je plní. Jde o třetí nejsilnější vazbu.
Realizace/ (Realization)	Realizace vyjadřuje situaci, kdy prvek vytváří jiný prvek. Typicky jde o vazbu mezi prvkem s vyšší mírou abstrakce k nižší míře abstrakce. Jde o čtvrtou nejsilnější vazbu.
Závislostní vazby
Slouží (Serving)	Obsluhuje/slouží vyjadřuje situaci, kdy prvek poskytuje svoji funkčnost jinému prvku. Jde o pátou nejsilnější vazbu.
Přístup (Access)	Přístup vyjadřuje situaci, kdy prvek chování nebo aktivní prvek konají nad pasivním prvkem. Jde o šestou nejsilnější vazbu.
Ovlivnění (Influence)	Ovlivnění vyjadřuje situaci, kdy jakýkoliv prvek ovlivňuje implementaci nebo dosažení některého motivačního prvku. Jde o sedmou nejsilnější, a tedy nejslabší vazbu.
Dynamické vazby
Tok (Flow)	Tok popisuje přenos informací z jednoho prvku k druhému, výměnu nebo transfer např. informace nebo hodnotu mezi procesy, funkcemi, interakcemi a událostmi. Jde o speciální dynamickou vazbu bez dalšího určení.
Spouštění (Triggering)	Vztah spouštění popisuje časové nebo příčinné vztahy mezi procesy, funkcemi, interakcemi a událostmi. Spouštění popisuje dočasné nebo občasné vazby mezi prvky. Typicky se využívá při znázornění procesů a jejich posloupnosti. Jde o speciální dynamickou vazbu bez dalšího určení.
Ostatní vazby
Specializace (Specialization)	Vztah specializace značí, že objekt je specializací jiného objektu. Specializace popisuje dědičnost mezi prvky. Specializace je vždy povolena mezi prvky stejného typu. Jde o speciální vazbu bez dalšího určení.
Asociace/souvislost (Association)	Asociace (souvislost) je nespecifikovaná vazba prvků používaná tam, kde není vhodné použití žádné jiné vazby dle ArchiMate.
Vazební konektory
Spojka ( (And) Junction)	Spojka se používá ke spojení vztahů stejného typu. Logický AND.
větvení (Or Junction)	Spojka se používá k rozvětvení vztahů stejného typu. Logický OR.

Při použití v modelech a jejich diagramech dostávají (mohou dostávat) jednotlivé instance těchto typů vazeb své výstižné názvy, obdobně jako je tomu u instancí konceptů (typů prvků metamodelu).

Jelikož metamodely a definice pohledů jsou základem pro tvorbu modelů a jejich interoperabilitu, jsou všechny zde uvedené definice dostupné na OHA a jeho webových stránkách také jako soubory ve formátech open source nástroje Archi a ve výměnném formátu The Open Group ArchiMate File Exchange Format.

Aktualizované metamodely budou vydány až jako výsledek ověření níže uvedených návrhů v praxi úřadů.

Maximální metamodel architektury úřadů jako součástí Národní architektury je pro první období jejího zavádění stanoven jako plný a nezměněný rozsah standardní specifikace ArchiMate 3.1, případně vyšší.

Protože metamodel ArchiMate a TOGAF ještě není vzájemně 100% shodný⁵¹⁾, přebírá NAR některé objekty metamodelu i z TOGAF, a to objekty Organizační jednotka, Logická a fyzická aplikační komponenta, Logická a fyzická technologická komponenta.

Vedle toho zavádí NAR nové koncepty pro objekty typické pro českou veřejnou správu, a to Právní předpis, Agendu a Informační systém (logický, ISVS).

Nad rámec standardní specifikace ArchiMate 3.1 jsou tedy pro metamodel NA VS ČR zavedeny následující specializované koncepty (objekty metamodelu), tzv. «stereotypy», postihující:

1. potřeby veřejné správy je to „právní předpis“ jako «Předpis», «Agenda» a «IS»,
2. obecně chybějící koncepty „organizační jednotka“ jako «Organizace» (dle TOGAF) a «Útvar », pro standardizaci «Standard»,
3. potřeby odděleně postihnout a vyhodnotit prvky komunikační infrastruktury jsou to volitelně «Komunikační služby», «Komunikační funkce» apod. (z čtyřvrstvé vize),
4. potřeby odlišit «Logické aplikační komponenty» a «Fyzické aplikační komponenty» (z TOGAF).

Není povinné specializovat prvky z doplněné vrstvy Komunikační a fyzické infrastruktury, ale je to přípustné.

Teprve praktická zkušenost ukáže, zda není výhodné některé objekty metamodelu pro zjednodušení úplně zakázat a jiné další jako specializace původních ještě doplnit.

Doporučený poprvé redukovaný (základní) metamodel je představen souhrnně na schématu uvedeném níže (vybrané prvky) a současně po částech vždy u jednotlivých doménových metamodelů (kompletně).

V jednotlivých typizovaných (a legislativním nebo metodickým předpisem upravených) architektonických angažmá, jako je právě seznámení OHA s plánovaným IT projektem (tzv. žádost) bude samostatným metodickým postupem doporučen pro zjednodušení ještě dále redukovaný metamodel.

Doporučené redukované (zjednodušené) metamodely jednotlivých vrstev architektury jsou uvedeny v následujících částech.

Celkový, již redukovaný základní (natož maximální) metamodel definující architekturu NA, obsahuje ještě stále značné množství vazeb a rozšiřujících oblastí. Pro přehlednost a lepší pochopení je na Obrázku níže schematicky znázorněn dále zjednodušený metamodel základních doporučených prvků. Z úplného metamodelu byly vybrány pouze nejzásadnější objekty a vazby z nerozšířeného standardu ArchiMate.

Každá z budoucích tzv. povinných organizací (OVS) bude pravděpodobně moci architekturu úřadu modelovat nad rámec povinného rozsahu, definovaného touto metodikou a udržovaného v centrálním architektonickém úložišti. Do něj však budou po kontrole přebírány pouze modely přesně stanoveného rozsahu.

Pro svoje interní účely smí OVS rozšiřovat metamodel architektury, jak v notaci ArchiMate specializací objektů, kdy vznikají nové tzv. stereotypy, tak provázáním objektů do detailních modelů v jiných notacích, např. UML, BPMN, DMN nebo Citizen Journey Map⁵²⁾.

Příkladem rozšíření specializací je sada specializovaných konceptů, odvozených jedním z úřadů z konceptu aplikační komponenty, viz Rámec obsahu a výstupu architektur.

Povinný rozsah modelů na úrovni Národní architektury VS ČR není stanoven souhrnně touto metodikou, ale je dán typy architektonických angažmá. Jim budou odpovídat dílčí metodické pokyny a rozšiřující metodiky typu „Jak na to?“. Například tabulky a vysvětlení ve formuláři a metodickém pokynu žádosti o stanovisko OHA k ICT projektům jednoznačně stanovují, které objekty modelů musí být zahrnuty.

V rámci této části je definován metamodel organizační architektury a to jak v plné, tak i redukované verzi a v minimální verzi.

Součástí metamodelu BA, jak je zobrazen, jsou i koncepty metamodelu patřící podle NAR nebo ArchiMate do jiných domén, protože jsou důležitou součástí celkového pohledu na výkon služeb veřejné správy (tj. Byznys). Myslí se tím koncepty:

• ze strategické domény: Schopnost úřadu, Scénář dodávky veřejné služby a Umístění
• z motivační domény: Hodnota produktu/služby VS a Význam objektu VS
• z domény shody s předpisy: Předpis.

Vedle lokalizovaných označení pro VS ČR, například „Účastník interakce s VS“, je možné pro zjednodušení v profesní komunitě vždy používat i originální označení, zde „aktér“. Některé zmíněné pro byznys důležité koncepty byly ve verzi 3.1 ArchiMate přesunuty do jiných domén, proto mají jiné barvy, ale zde jsou i nadále uvedeny.

Tabulka⁵³⁾ s definicemi prvků metamodelu byznys architektury

Systém úřadu má architekturu, ta se skládá z prvků a jejich vazeb. Celý úřad jako systém (enterprise) se dělí do menších částí až na nejmenší a dále nedělitelné schopnosti úřadu vykonávat aktivity⁵⁵⁾. Každá dílčí schopnost úřadu má svoji architekturu na všech vrstvách. Rozdělení úřadu do schopností a jejich vyhodnocení je součástí fáze architektonické vize, ale má klíčový význam pro porozumění byznys architektuře úřadu.

Aktivní prvky BA úřadu

Základním aktivním prvkem úřadu jsou interní aktéři (úřednici) a někteří externí aktéři (subjekty práva), kteří vstupují do vzájemných kontaktů (interakcí) v různých rolích, které na sebe dynamicky a dočasně berou.

Aktéři v rolích využívají obslužných kanálů pro poskytování a přijímání služeb veřejné správy. Pokud je pro realizaci služby potřebná spolupráce více poskytujících aktérů, s výhodou se modeluje jejich vzájemná spolupráce jako zvláštní typ aktivního prvku - spolupráce. Další specializovaný typ aktéra je organizační jednotka.

Aktéři se poznají podle toho, že mají vždy nějakou unikátní identitu, na rozdíl od rolí.

Prvky chování BA úřadu

Aktivní prvky struktury úřadu jsou nadány (dovedou, mají) interním chováním, mají svoji byznys funkci. Byznys funkce možné řídit v jejich přesném pořadí jako byznys proces, končící procesním rozhraním pro klienta – byznys službou, respektive produktem.

Zvláštním, kolektivním typem interního chování je tzv. interakce spolupracujících aktérů.

Zvláštním typem chování aktivních prvků, který nemá trvání, je událost. V systému úřadu se mohou dít interní a externí události. Některé externí události se dějí subjektům práva v rolích klientů a nazýváme je životními událostmi.

Specializovaným typem chování úřadu je jeho každá tzv. agenda, vyjádřená jako agregace všech funkcí, potřebných pro výkon agendy, evidovaných jako tzv. činnosti v agendě.

Navenek patrným prvkem chování a součástí produktů úřadu je jeho veřejná služba, která má hodnotu pro klienta.

Pasivní prvky BA úřadu

Vstupem a výstupem chování úřadu jsou fyzické a elektronické reprezentace věcí, o nichž se úřaduje, tzv. objektů práva. Ty mají pro účastníky chování svůj význam.

Zvláštním typem byznys objektu je kontrakt, reprezentující ujednání dvou nebo mnoha aktérů nebo podmínky, za nichž je vykonáváno chování a dodáván produkt. Specializovaným typem kontraktu je právní předpis různé právní síly (zákon, vyhláška, usnesení, metodika apod.), pro zestručnění zde nazývaný pojmem «Předpis». Svým charakterem koncept Předpis v NAR patří do jedné z motivačních domén, a to do domény Shoda s předpisy, standardizace a dlouhodobá udržitelnost, kterou ale jazyk ArchiMate nezná. Proto je použit specializovaný objekt z byznys vrstvy.

Všechny ostatní „věci“, které jsou součástí vnitřního nebo vnějšího prostředí úřadu a nemají svůj samostatný koncept v některé z domén, se modelují také jako byznys objekt ve vrstvě BA.

Kompozitní prvky BA úřadu

Kompozitním prvkem této vrstvy, který v sobě může zahrnovat řadu ostatních je tzv. produkt. Tento prvek přesně odpovídá marketingové definici produktu – až když je zboží nebo služba doprovázeno obchodními podmínkami (kontraktem, SLA), dokumentací, daty, servisem a dalšími součástmi, stává se produktem, který dokáže řešit potřeby klienta, v našem případě jeho situaci ve vztahu k veřejné správě, plynoucí z jeho nastalé životní události.

Datová architektura dle TOGAF v nemá jazyce ArchiMate vlastní vrstvu, její objekty jsou rozloženy ve všech třech základních vrstvách. Představují pasivní prvky, tedy o čem jsou systémy, s čím zachází. V podstatě se jedná o tři úrovně abstrakce.

Zatímco datové modelování hovoří o konceptuálních, logických a fyzických datových objektech, TOGAF hovoří o datových entitách, logických a fyzických informačních komponentách, používá ArchiMate následující vyjádření, viz následující obrázek.

Objekt / subjekt veřejné správy (orig. Business Object) představuje všechny věci, které v prostředí veřejné správy prostě jsou. A některé z nich jsou pro nás zajímavé do té míry, že si o nich vedeme datové záznamy. Objekt v modelu představuje konceptuální úroveň datového modelování.

Datový objekt je logickým obrazem skutečného objektu, promítnutého do vrstvy informačních systémů. Vypovídá o struktuře údajů vedených v IS a představuje logickou úroveň datového modelování.

Datový artefakt, tedy soubor, tabulka, záznam na disku je fyzickou reprezentací dat o objektu. Artefakt je také používán jako fyzická reprezentace SW, ať již aplikační komponenty nebo systémového SW.

Datová architektura má pouze pasivní prvky, nemá žádné aktivní ani vlastní kompozitní prvky a ani prvky chování. Může s výhodou využívat kompozitní koncept Seskupení.

V rámci této části je definován metamodel architektury aplikací a to jak v plné, tak i redukované verzi.

Struktura prvků metamodelu (konceptů) plně odpovídá základním aspektům jazyka ArchiMate, obdobně jako v ostatních základních vrstvách.

Předpokládáme, že v praxi bude užitečné redukovat jak počet typů prvků modelů, tak počet typů povolených vazeb. Aktuálně doporučenou redukci metamodelu AA, současně považovanou za minimální možnou, ukazuje následující schéma:

Tabulka⁵⁶⁾ s definicemi prvků metamodelu aplikační architektury

Aktivní prvky AA úřadu

Základním aktivním prvkem aplikační architektury informačních systémů je aplikační komponenta. Nejméně jedna skutečně instalovatelná aplikační komponenta je součástí Informačního systému.

Aplikační komponenta obsahuje aplikační funkce (funkční specifikace, FS, n-FS) a aplikační rozhraní (GUI a API). Pokud aplikační komponenta disponuje funkcemi a dodá službu výhradně ve spojení s jinou komponentou, pak tyto komponenty tvoří tzv. aplikační spolupráci.

Aplikační rozhraní je přiřazeno aplikační službě, resp. služba je dostupná na rozhraní. Aplikační rozhraní slouží a) jiné aplikační komponentě (službě, funkci) respektive b) slouží aktérovi v jeho roli, čí realizuje byznys rozhraní.

Prvky chování AA úřadu

Základem chování aplikačních komponent, jejich rozhraní a spoluprací jsou (interní) aplikační funkce. Aplikační komponenta má libovolnou granularitu (hierarchii) funkcí.

Kolektivní interní funkce aplikační spolupráce se nazývají aplikační interakce. Charakter aplikační interakce má služba, která v sobě pod jedním společným řízením zahrnuje funkce z více aplikačních komponent - nemůže být poskytnuta, pokud některá z komponent bude mimo provoz nebo nefunkční či nedostupná.

Aplikační funkce, interakce a dílčí procesy lze realizovat a řídit jako automatizované aplikační procesy a workflow. Pro jejich modelování se mohou uplatnit typy prvků aplikační událost a aplikační proces.

Externím projevem chování a výsledkem aplikačních funkcí, interakcí nebo procesů jsou aplikační služby pro jiné aplikace, ale zejména pro prvky chování byznys vrstvy.

Pasivní prvky AA úřadu

Pasivním prvkem aplikační architektury a současně logickým prvkem datové architektury informačních systémů je datový objekt, který v modelu reprezentuje realizaci informačního (datového) obrazu byznys objektu nebo libovolného jiného prvku architektury.

Kompozitní prvky BA úřadu

Aplikační architektura nemá specifický kompozitní prvek, ale pro kategorizaci a seskupení výskytů ostatních prvků používá prvek Seskupení.

Metodika NAR dále předpokládá, že některé úřady budou chtít / potřebovat význam některých konceptů, prvků metamodelu, upřesnit, tzv. specializovat, a tím si rozsah metamodelu naopak pro svoji potřebu rozšířit.

Takovým příkladem je praxe jednoho z ministerstev, které specializovalo prvek aplikační komponenty do čtyřech kategorií, z nichž dvě představují virtuální agregační úrovně nad originálním významem aplikační komponenty (Informační systém a komponenta IS) a jedna naopak menší logickou jednotku aplikační komponenty (tzv. aplikační modul). Z této zkušenosti zatím je navrženo zahrnout do standardu NAR stereotyp Informační systém (logický), ostatní typy prvků zatím do standardu převzaty nejsou.

Jiným příkladem z téhož zdroje je rozdělení aplikačního rozhraní do více specializovaných rozhraní.

Při budoucím sehrávání modelů úřadů do centrálního repozitory s využitím výměnného formátu The Open Group ArchiMate File Exchange Format, který přirozeně tyto specializace nezná, budou tyto nahrazeny zpět prvkem aplikační komponenta. Je otevřenou metodickou otázkou, která se prakticky vyřeší až při implementaci centrálního repozitory, zda to bude v závazné metodice přípustné nebo bude nutno model pro export filtrovat tak, aby byly přeneseny pouze prvky jednotného významu a granularity, v tomto případě tedy tzv. „Aplikace“, ve významu existující aplikační komponenta.

Z tohoto důvodu doporučujeme při specializaci prvků a rozšiřování metamodelu úřadu značnou zdrženlivost.

Přitom je potřeb zdůraznit rozdíl mezi použitím kompozitní a agregační vazby mezi specializovanými komponentami. Pokud by specializované komponenty byly obrazem fyzických instancí (stavebních bloků řešení - SBB), pak se mezi nimi uplatní vazba kompozitní, protože například jeden fyzický modul může být součástí pouze jedné aplikace a komponenty, pouze jednoho IS.

V případě, kdy budou zastupovat logické prvky architektury (architektonické stavební bloky – ABB), pak se mezi nimi může uplatnit kompozitní i agregační vazba, protože jeden vzorový prvek může být ve výsledku použit ve více výskytech, ve více nadřazených prvcích.

Dále je povšimnutí hodné, že podle standardu ArchiMate je «Informační systém» de facto/prakticky spíše Aplikační spoluprací (colaboration), protože pokud nebudou aplikace systému spolupracovat, pravděpodobně nenaplní svůj / jeho účel.

Také je potřeba zdůraznit, že TOGAF ani ArchiMate neznají pojem Aplikace (Application) jako podstatné jméno ve smyslu aktivního prvku (podmětu), nýbrž pouze jako přídavné jméno, například aplikační služba (Application Service) nebo jako podstatné jméno slovesné (aplikování – něčeho někde).

Pokud je tato „Aplikace“ samostatně instalovatelná a spravovatelná⁵⁷⁾, pak se podle ArchiMate jedná o aplikační komponentu. Pokud není samostatná, pak se jedná o aplikační funkci, libovolné úrovně podrobnosti.

Pokud by chtěl nějaký úřad vyjádřit «Aplikační modul», který však není schopen samostatné provozní existence, pak by měl jako východisko pro jeho specializaci použít aplikační funkci, nikoli aplikační komponentu.

Zatímco aplikačních funkcí může být uvnitř jedné komponenty libovolně hluboká (detailní) hierarchie, tak aplikační komponenty se takto řetězit nesmí, přinejmenším v modelu fyzických komponent ne. Ve skutečnosti totiž existuje pouze a právě jedna úroveň instalovatelné a provozovatelné komponenty, vše nad touto úrovní je buď Spolupráce (pokud komponenty musí spolupracovat) nebo Seskupení (pokud k sobě jen tak patří, například společně tvoří jeden ISVS. Vše pod instalovatelnou úrovní je aplikační funkce.

Hierarchie aplikačních komponent se může modelovat pouze tam, kde každá jako komponenta označená věc, splňuje skutečně všechny vlastnosti komponenty.

Podle NAR není přípustné společně s reálnými prvky typu Komponenta modelovat i virtuální prvky jako např. SW licence. SW licence je byznysový objekt, pokud je součástí např. nějakého produktu.

Tato otázka se definitivně vyřeší až s tím, jak se v souvislosti s další fází rozvoje ISoISVS v RPP rozhodne o evidování a unikátním označování existence dílčích součástí (aplikačních komponent a funkcí) ISVS.

V rámci této části je definován plný a zjednodušený metamodel technologické architektury.

Tabulka⁵⁸⁾ s definicemi prvků metamodelu technologické architektury

Typy prvků metamodelu technologické architektury zatím nemají interpretaci.

Metamodel komunikační infrastruktury je totožný jako metamodel jakékoli ostatní ICT technologické infrastruktury, v architektonických výstupech bude převážně představovat samostatný pohled nebo bude součástí pohledu čtyřvrstvé architektury eGovernmentu.

Po rozšíření standardu ArchiMate o prvky fyzického světa (non-IT) jsou tyto prvky součástí této architektonické domény NAR, neboť velmi blízce odpovídající jejímu původnímu účelu v rámci vize čtyřvrstvé architektury.

V tabulce⁵⁹⁾ jsou uvedeny pouze definice prvků metamodelu z vrstvy fyzické architektury ArchiMate, protože pro prvky komunikační architektury se v plné míře použijí koncepty technologické architektury z předchozí části, s výjimkou jejich případné specializace, viz níže.

Typy prvků metamodelu komunikační a fyzické architektury zatím nemají interpretaci.

Pokud bude potřeba zdůraznit na úrovni metamodelu odlišnost komunikační infrastruktury, budou moci být všechny použité koncepty metamodelu tzv. specializovány, viz obr. níže.

Pro běžné použití ve zde výše uvedených typech angažmá se ale specializace pro prvky technologické infrastruktury nepředpokládá a nevyžaduje.

Strategická architektura dle NAR je první, nejdůležitější a aktuálně nejobsažnější doménou z oblasti jednotlivých motivačních architektur – vertikálních domén.

Spojuje v sobě motivační architekturu dle TOGAF⁶⁰⁾ a tzv. motivační a strategickou⁶¹⁾ vrstvu dle ArchiMate. To je důvodem, proč jsou v metamodelu domény strategicke a směřování v NAR kombinovány prvky více barev.

Metamodel neobsahuje všechny možné vazby, protože každý prvek v motivačním rozlišení může být agregací/specializací prvku stejného typu (např. cíl se může agregovat na dílčí cíle).

Tabulka⁶²⁾ s definicemi prvků metamodelu architektury strategie a směřování

Metamodel domény strategie a směřování aktuálně neobsahuje koncepty pro všechny součásti strategického řízení. Takovými nyní ještě v NAR nezachycenými objekty jsou:

• Poslání organizace
• Vize organizace

Oba prvky jsou ryzí vnitřní motivací organizace, proto se více než k čemukoli jinému přikláníme k doporučení modelovat je pomocí prvku „Hodnota“, v tomto případě společná, sdílená hodnota pro všechny kategorie zainteresovaných v organizaci. Oba prvky ale představují pojem s jedinečným výskytem v každé organizaci (organizace poslaní a vizi formulovánu má nebo nemá), proto navrhujeme tyto objekty vůbec nemodelovat a do modelu z nich odvodit až prvky obsahově významnější, jako jsou cíle a principy.

Poznámka: Každá změna, v kterékoli z horizontálních domén architektury by měla mít svou motivaci, vycházet ze strategie a směrování, očekávané výkonnosti, nového rizika nebo nové regulace předpisem. Proto lze v modelu úřadu očekávat prvky vertikálních, motivačních domén rozdělené i podle horizontálních domén. Tak najdeme například aplikační drivery, aplikační cíle, aplikační směry aktivit, aplikační výstupy, aplikační principy a aplikační architektonické požadavky.

Koncept „Zdroj“ znamená v architektuře strategie a směřování „zdroj pro zajištění změny schopnosti“, nikoli zdroj pro rutinní výkon schopnosti.

„Schopnost“, jak je uvedeno v Modelující úřady a jejich architektur, není typickým doménovým typem prvku, tvořícího architekturu, nýbrž schopnost je nejmenší částí organizace, pro niž se architektura hledá a navrhuje. Mapa schopností slouží pro získání celkové přehledu o organizaci. Plánování schopností⁶³⁾je manažerská technika pro plánování zlepšování a plnění strategických cílů bez detailní znalosti o architektuře jednotlivých schopností.

Typ prvku „Hodnota“ má pro NAR dva nejdůležitější významy, oba významy zatím nejsou důvodem pro specializaci stereotypů, pravděpodobně budou v prvních obdobích užívání NAR využívány zřídka:

• Hodnota změny pro zainteresované
• Hodnota produktu / služby pro klienty

Typ prvku „Hodnotový řetězec“ je zatím pouze součástí standardu TOGAF, ale je očekáván i pro standard ArchiMate 3.1.

Výkonnostní architektura NA VS ČR zatím nemá definované žádné specifické prvky metamodelu. Předpokládáme, že v následujících verzích jazyka ArchiMate se objeví volnější použití objektu Metrika (KGI⁶⁴⁾, KPI⁶⁵⁾ (zejména TCO⁶⁶⁾), PPI⁶⁷⁾, PI) než je tomu v současnosti jakožto měřítko výsledku vyhodnocení potřeby, motivátoru, v motivační architektuře.

Doposud každý objekt modelu může mít metriky přiřazeny v profilu atributů. Typy ukazatelů výkonnosti se zatím nemodelují.

Architektura výkonnosti, kvality a zodpovědnosti by měla sloužit na podporu řízení výkonnosti, kvality a zodpovědnosti v orgánech veřejné správy. Řízení výkonnosti, kvality a zodpovědnosti ve veřejné správě je spojeno zejména se snahou organizace dělat správné věci správně, tj. kvalitně, efektivně, hospodárně a včas.

Základní tři sady ukazatelů se obvykle ukrývají pod akronymem 3E:

• Hospodárnost (Economy) – vztahuje se k nákladům na zdroje pro spotřebovávané vstupy. Metriky hospodárnost se používají k posouzení, zda za pořízení nezbytných zdrojů je placena odpovídající cena.
• Účinnost (Efficiency) – účinnost představuje vztah mezi vstupy a výstupy, je poměrem dosažených výstupů ke spotřebovaným vstupům. Účinnost je výrazem dimenze „dělat věci správně“ a ukazuje na výkonnost ve smyslu způsobu, jakým je činnost uskutečňována.
• Účelnost (Effectiveness) – je výrazem míry jakou produkované výstupy vedou k očekávaným výsledkům. Metriky účelnosti se zaměřují na sílu vztahu mezi provedenou intervencí a dosaženým výsledkem. Účelnost je výrazem dimenze „dělat správné věci“ a ukazuje na výkonnost ve smyslu volby činnosti, která je uskutečňována.

S tím souvisí i tzv. Logický model řízení výkonnosti, vypracovaný na základě podkladů Evropského účetního dvora a MF ČR:

Pro řízení výkonnosti, kvality a zodpovědnosti platí obdobné paradigma jako níže u bezpečnosti:

Není možné řídit výkonnost a kvalitu prvků systému úřadu a zodpovědnost za ně, bez toho, že bychom je dobře poznali a porozuměli jim, například prostřednictvím architektury úřadu.

Doména výkonnosti k základním objektům architektury úřadu přidává několik specifických prvků (cílů, ukazatelů, vyhodnocení, opatření). Ty jsou do značné míry modelovatelné pomocí konceptů byznys a motivační architektury, jejich specializací nebo do budoucna samostatných specifických konceptů, obdobně jako u bezpečnostní architektury.

Tabulka⁶⁸⁾ s definicemi prvků metamodelu architektury výkonnosti

Mnohé z prvků se budou opakovat z předchozí domény strategie a směřování, ale při svém použití v modelu budou mít jiný účel. Tak například Koncept „Zdroj“ znamená v architektuře výkonnosti, kvality a zodpovědnosti „zdroj pro zajištění činnosti“.

Bezpečnostní architektura NA VS ČR zatím nemá definované žádné specifické prvky metamodelu. Předpokládáme, že jimi budou později rizika a opatření spojená s hlavními objekty modelu.

Lze předpokládat podle Whitepaperu The Open Group a vývoje některých modelovacích nástrojů, že jazyk ArchiMate a standard TOGAF v budoucnu přidá tyto koncepty

Specifické koncepty bezpečnosti a řízení rizik se dají v aktuálním standardu ArchiMate modelovat s pomocí konceptů byznys a motivační architektury nebo jejich specializovaných stereotypů, viz schéma:

Diagram mimo jiné zdůrazňuje základní princip bezpečnostní architektury:

Vše, co je součástí systému organizace a co modelujeme v ostatních doménách, může být ohroženo a je potřeba to chránit, ale současně téměř vše z toho je současně pro jiné věci prostředkem takové ochrany.

Z toho také plyne, že dobrý model základních⁶⁹⁾ prvků architektury úřadu je nezbytným předpokladem a vstupem její bezpečnostní architektury.

Tabulka⁷⁰⁾ s definicemi prvků metamodelu bezpečnostní architektury

Tabulka⁷¹⁾ s definicemi prvků metamodelu bezpečnostní architektury

Typy prvků metamodelu bezpečnostní architektury zatím nemají interpretaci.

Oblast standardizace a udržitelnosti NA VS ČR zatím nemá v mezinárodních standardech definované žádné specifické prvky metamodelu. Předpokládáme, že dle potřeb budou využity specializované prvky byznys a motivační architektury, ve smyslu cílů, požadavků či omezujících podmínek.

Vedle toho bude obsah standardizace vyjadřován prohlášením každého jednotlivého prvku architektury nebo jejich kombinace za architektonický stavební blok (ABB), za stavební blok řešení (SBB) nebo za architektonický vzor (pattern).

Tato doména se v souladu se svým názvem zaměřuje na oblasti řízení, které regulují činnost úřadů (OVS), a to konkrétně:

• Shoda s předpisy. Podle Ústavy a ZLPS smí veřejné správy v oblasti výkonu veřejné moci konat jenom to, co je jí výslovně předepsáno zákonem, respektive podzákonnými předpisy.
• Standardizace. Veřejná správa omezuje prostor pro samostatné rozhodpování, a tím i komplexitu svého prosředí tím, že „dobrovolně“ vydává standardy (procesů, IT, služeb, bezpečnosti apod.) nebo přebírá nezávislé externí standardy (ISO, ČSN apod.).
• Udržitelnost. Veřejná správa si pro oblasti své regulace (agendy) i pro svoji vlastní organizaci a interní činnosti stanovuje kritéria (limity) udržitelnosti, a to v oblasti ekonomické, sociální a environmentální. Typickou iniciativou v této oblasti je CSR⁷²⁾.

Základním objektem shody s předpisy je objekt „právní předpis“. Tento objekt není standardní součástí specifikace ArchiMate, proto NAR navrhuje používat specializaci objektu „Kontrakt“ do podoby: «Předpis». Vše ostatní, co tvoří strukturu systému úřadu, musí být ve shodě s právními předpisy. Pokud by tomu tak nebylo, jde o nežádoucí stav. Míru shody není třeba vyjadřovat dalšími koncepty, v rámci NAR stačí objekty modelu, typicky agendy nebo služby, propojit asociační vazbou s objekty «předpis», viz následující obrázek:

Objekty předpis mohou být libovolně specializovány/agregovány, přes dílčí úrovně předpisu: článek, paragraf, odstavec, písmeno. Jinou specializací je struktura předpisů nižší právní síly (prováděcí právní předpisy, podzákonné právní normy či sekundární právní předpisy), tj. typicky vyhlášky a metodické pokyny. Pro tyto druhy specializace obsahu konceptu «předpis» je v této verzi NAR nežádoucí vytvářet další stereotypy.

V oblasti standardizace se vyskytují standardy dvou typů:

• Standard jako dokument, který vyjadřuje vůli signatářů (autorů standardu) definovat a užívat některé „věci“ jednotně stejně.
• Prohlášený standard, který vzniká tak, že nějakou existující věc (typicky typ výrobku, formát dat apod.) z modelu své vlastní architektury prohlásím standardem.

V metamodelu architektury standardizace je potřebné zachytit jediný nový prvek, a to objekt představující obraz standardizačního dokumentu, například ISO 27000. Pro takovéto objekty navrhuje NAR také specializaci konceptu jazyka ArchiMate „kontrakt“ do podoby «standard», viz následující obrázek:

Architektura dlouhodobé udržitelnosti pro NA VS ČR zatím nemá definované žádné specifické prvky metamodelu. Předpokládáme, že v následujících verzích jazyka ArchiMate se objeví volnější použití objektu Metrika (KPI) než je tomu v současnosti jakožto měřítko výsledku vyhodnocení potřeby, motivátoru, v motivační architektuře. Předpokládáme, že Metrika bude vhodným konceptem i pro architekturu dlouhodobé udržitelnost.

Dalšími vhodnými atributy mohou být například Architektonický princip, Architektonický požadavek nebo Omezující podmínka, případně jejich specializované stereotypy.

V této doméně zatím není připravena žádná další interpretace.

Na obrázku níže je znázorněn metamodel implementačního a migračního rozšíření.

Tabulka⁷³⁾ s definicemi metamodelu architektury implementace a migrace

Jako v základních (core) vrstvách architektury úřadu lze i v architektuře implementace a migrace (IM) rozlišit objekty podle jednotlivých aspektů jazyka ArchiMate, s výjimkou aktivních prvků.

Aktivní prvky IM úřadu

Architektura implementace a migrace nemá vlastní specifické aktivní prvky, těmi jsou prvky byznys architektury.

Prvky chování IM úřadu

Základním prvkem metamodelu architektury Implementace a migrace je Balíček práce. Je řazen mezi aktivní prvky a představuje libovolně velkou část aktivit, kterými se realizuje změna od stávající k cílové architektuře. Balíčkem práce je nejčastěji projekt, ale směrem „dolů“ to může být fáze projektu, podprojekt, jeho dílčí proud nebo jenom jedna aktivita.

Směrem „nahoru“ jsou projekty typicky seskupovány pro koordinovanou dodávku hodnoty benefitů do podprogramů a programů

Implementační událost představuje milník v projektově orientovaném implementačním snažení. Může být vázána na jinou událost v modelu systému úřadu.

Pasivní prvky IM úřadu

Základním pasivním prvkem je výstup projektového úsilí, tedy tzv. výstup či plnění (deliverable). Každý výstup je dílčím nebo celkovým naplněním jednoho nebo více zjištěných a plánovaných rozdílů mezi stávajícím a cílovým stavem nějakého základního prvku (gap), který představuje druhý pasivní prvek metamodelu.

Kompozitní prvky IM úřadu

Kompozitním prvkem této vrstvy, který v sobě zahrnuje řadu ostatních je tzv. stav architektury (plateau). V metodice TOGAF se jedná o tzv. cílovou nebo přechodnou architekturu, tj. o takovou kombinaci prvků a vazeb architektury systému, která je funkční a ve svém stavu přináší úřadu nějakou plánovanou byznys hodnotu.

Pokud projekt skončí nedodělaný, nejedná se v žádném případě o přechodnou architekturu. Přechodná architektura je stav řízený, plně funkční a uspokojivý i v případě, že by se již žádná další změna neuskutečnila.

Tabulka⁷⁴⁾ s definicemi kompozitních prvků metamodelu architektury

Základním použitím „Seskupení“ je vyjádřit úrovně zobecnění nějakých prvků, jejich typů, klasifikačních tříd, u nichž již nejsou naplněny přepoklady definice typu prvku.

Například kategorie Front-Office, Middle-Office a Back-office jsou nesmírně důležité pro procesní i aplikační dekompozici (Mapu) úřadu, ale nejsou ani procesem ani aplikační komponentou, proto jsou Seskupením - více např. v Referenční modely a klasifikační rámce.

„Umístění/ lokace“ představuje primárně umístění prvku v prostoru, tj. s odkazem na geografickou navigaci (adresní bod) nebo případně na navigaci uvnitř budouvy. Umístění je přirozeně (a neomezeně) hierarchické, od úrovně planety k nejmenšímu detailu (světadíl, stát, kraj/region, obec, ulice, dům atp.) dle potřeby.

Pro umisťování prvků (jako datových center či kontaktních míst) bude v jednolivých konkrétních, centrálně koordinovaných angažná požadováno umístění ve shodě s adresním bodem (ověřitelné v RUIAN).

V této části jsou uvedeny prvky, které nejsou předmětem standardu modelovacího jazyka ArchiMate, přesto jsou z pohledu standardu TOGAF nebo budoucího rozvoje NAR důležité.

Tabulka s definicemi obecných prvků metamodelu architektury.

Obdobně jako služba by se daly společně definovat i pojmy funkce, proces, událost, komponenta - všechny se vyskytující ve více vrstvách buď TOGAF, ArchiMate nebo obou. Je důležité vnímat jejich obecný charakter a význam bez ohledu na vrstvy a architektury, i jejich specifické použití uvnitř vrstvy architektury.

K definici služby je potřebné doplnit, že jakoukoli službu jakékoli vrstvy formálně poskytuje vždy zodpovědná fyzická nebo právnická osoba, nebo její část, která je k poskytování služby oprávněna, zmocněn zákonem nebo smlouvou nebo vnitřním předpisem. To platí i pro služby IS a technologií.

Pro dobré pochopení toho, co je vlastně služba, je přidána ještě definice obecné služby, upravené do pojmů veřejné správy, více tako v NAP:

Služba je funkce úřadu, pokud je poskytnutá konkrétním poskytovatelem konkrétnímu příjemci služby podle předem dané formální dohody (zákon, vyhláška, dohoda o úrovni služby - SLA) tak, že přináší příjemci vnímanou hodnotu, za kterou by byl ochoten zaplatit přiměřenou cenu (nebo platit daně).

Služba je určena vždy konkrétnímu klientovi, je výsledkem funkce nebo procesu. Služba veřejné správy je vždy spojena konkrétním právem nebo povinností klienta vůči veřejné správě a spočívá ve výkonu funkcí úřadu a úředníka, vedoucích k umožnění a usnadnění dosažení tohoto práva nebo splnění této povinnosti klientem.

Typy vazeb NA VS ČR se plně shodují s aktuálním standardem jazyka ArchiMate, viz Rámec obsahu a výstupu architektur.

Národní architektonický rámec povoluje použítí všech vazeb popsaných v této části, avšak v rámci zjednodušení doporučuje použití následujících vazeb:

• Kompozice
• Agregace
• Přiřazení
• Realizace
• Obsluhuje
• Přístup
• Ovlivnění
• Asociace

Kompozici je možné vyjádřit jak mimo komponovaný prvek, tak i zanořením (hnízdovým diagramem⁷⁵⁾. Komponovat je možné vždy prvky stejného typu a stejně tak i jiné, typicky rozhraní s aktivními prvky, či zařízení a uzel, protože jde o podtřídy. Komponovaný prvek může být součástí pouze jedné kompozice.

Agregaci lze podobně jako kompozici vyjádřit mimo agregovaný prvek, tak i zanořením. Agregovat lze vždy prvky stejného typu a stejně tak i jiné. Princip je podobný jako u kompozice s tím rozdílem, že agregovaný prvek může být součástí vícero agregací.

Ačkoli jazyk ArchiMate teoreticky připouští agregaci u libovolného typu prvku, z hlediska TOGAF to u některých nedává smysl, zejména u aplikací (zde je to tedy chybně). Jde o to, že aplikační komponenta dle TOGAF je samostatně implementovatelnou⁷⁶⁾ jednotkou aplikačního SW, říkáme, že jde zapnout/vypnout. Pokud by komponenta obsahovala zase komponentu, pak to není splněno, fyzicky to nejde. Proto agregaci komponent NAR nedoporučuje.

Přiřazení lze podobně jako agregaci a kompozici vyjádřit mimo přiřazený prvek, tak i zanořením. Přiřazení je vždy vazba mezi prvky chování a aktivními prvky s výjimkou aktérů a rolí.

Realizaci je možné také zanořit, ale vzhledem k vyjádření poskytování či vytváření jiného prvku je vhodnější ji mít vždy jako oddělenou. Nejčastěji se vazba využívá při vytváření služeb (vnějšího chování) z funkcí (vnitřního chování).

Vazbu slouží / obsluhuje není možné vnořit a využívá se primárně při přechodech mezi vrstvami, ale třeba také například mezi komponentami nebo službami na téže vrstvě.

Přístup není možné vnořit a využívá se pro vztah prvků chování k pasivním prvkům (přístup, čtení, zápis atp.).

Ovlivnění je vždy mezi prvkem motivace a jiným prvkem. Jako jediná vazba obsahuje míru své vlastní síly (pozitivní či negativní) a není možné ji vnořit.

Asociace/ souvislost je neurčitá vazba, kterou je možné využít mezi všemi prvky, pokud se nehodí žádná jiná vazba.

Pozor na kompozitní a agregační vazbu u věcí, které nejsou virtuálními, abstraktními pojmy, ale skutečně existují, mají svá evidenční a sériová čísla.

Příkladem je nevhodné použití agregační nebo kompozitní vazby u aplikačních komponent. U nich definice, zejména dle TOGAF, předpokládá, že komponenta existuje, lze ji instalovat, zapnout/vypnout. Takové komponenty se ale nemohu vkládat do sebe jako mističky, takto existovat může jenom jedna z nich, jinak by definiční podmínka nebyla splněna. Abstraktní logická, nadřazená komponenta už by měla být kategorií (Seskupením) nebo Spoluprací. Nižší prvek, obsah komponenty je její funkcí, představuje to, co komponenta dovede.

V obrázku je problematické jak vyjádření pomocí dvou „boxů“ a vazby, tak vlevo vyjádření prostřednictvím hnízdového diagramu (s neznámým typem vazby, resp. bez ohledu na typ vazby).

U každého výskytu prvku metamodelu, zachyceného v modelu architektury úřadu budou evidovány sady nebo také profily vlastností, tzv. atributů.

Některé atributy budou tzv. řídící atributy, tj. budou sloužit pro řízení a governance tvorby, správy a užití modelů. Příkladem řídících atributů je klasifikace modelů, pohledů a prvků, viz Příloha 1 – Seznam atributů prvků metamodelu a Příloha 2 – Klasifikace souborů, modelů a pohledů.

Všechny ostatní atributy budou tzv. věcné atributy, tj. budou sloužit na podporu užití modelů reálné architektury úřadů v praxi, zejména pro rozhodování a zlepšování. Například pro správu celého aplikačního portfolia úřadu. Model se pak díky atributům prvků stává nositelem inventarizačních Katalogových listů těchto prvků, více v Metodách řízení ICT VS ČR.

Mnohé atributy uvedené v NAR pocházejí z příloh standardu TOGAF, další z praxe pilotních projektů architektury VS, předcházejících vydání NAR.

Pilotních projektů, pracujících s atributy bohužel před vydáním první verze NAR neproběhl dostatek, není co zobecnit do nejlepší praxe - proto budou atributy jednotlivých typů prvků metamodelu publikovány postupně v dalších vydáních NAR.

Některé v NAR definované atributy objektů modelu budou pro modely architektury úřadů povinné, ostatní zde definované jsou volitelně doporučené a další atributy budou úřady moci podle své potřeby přidávat ve své místní úpravě architektonického rámce úřadu.

Všechny identifikované instance objektů architektury úřadu i s jejich atributy musí být zachyceny primárně formou katalogu prvků. Proto budou sady atributů představeny postupně u jednotlivých katalogů a souhrnně v samostatné Příloha 1 – Seznam atributů prvků metamodelu.

Všechny typy prvků metamodelu mají základní sadu atributů identickou, společnou:

Práce s atributy v jednotlivých nástrojích modelování architektury, jejich přenos ve standardním formátu TOGAMEFF⁷⁷⁾ a jejich užití v centrálním repozitory musí být ověřeny v praxi. Výsledky se promítnou do úpravy předepsaných sad prvků a pravidel pro práci s nimi v dalších vydáních NAR.

V průběhu procesu tvorby architektury (TOGAF ADM) vznikají „Dodávané výstupy“ či předměty plnění (orig. „deliverable“). Tyto výstupy jsou charakteristické tím, že jsou výslovně (smluvně) určené a následně formálně revidované, odsouhlasené a podepsané zodpovědným schvalovatelem. Výstupy představují výstupní produkty daného architektonického projektu a očekává se, že po dokončení projektu budou archivovány a/nebo převedeny do architektonického úložiště (orig. „repository“) jako referenční modely nebo jako záznamy daného stavu architektury v určitém časovém období.

Každý z dodaných výstupů obsahuje alespoň jeden artefakt, reálně však několik. Artefaktem, tj. výtvorem architekta obecně značíme produkt architektonické práce zaměřený na jeden aspekt architektury. Rámec TOGAF rozeznává tři hlavní třídy artefaktů, kterými jsou:

• Katalogy – představují jednorozměrné seznamy identifikovaných prvků architektury a případných budoucích stavebních bloků.
• Matice – zobrazují dvourozměrné tabulky závislostí mezi alespoň dvěma typy prvků architektury.
• Diagramy – zobrazují prvky architektury a jejich vztahy grafickým způsobem, který usnadňuje efektivní komunikaci vůči zainteresovaným stranám.

Výše uvedené třídy artefaktů popisují tzv. stavební bloky. Stavební bloky představují (potenciálně znovu-použitelné) byznysové prvky, IT prvky a určité schopnosti. Mohou být kombinovány s dalšími stavebními bloky za účelem dodání požadovaného architektonického řešení. Stavební bloky můžeme definovat na různých úrovních detailu.

Tato metodika modelování popisuje, jakým způsobem budou vytvářeny diagramy, viz následující Obrázek.

Během cyklu tvorby architektury ADM, v jeho jednotlivých iteracích podle typu angažmá, viz například Proces tvorby architektur, vzniká a dále se využívá celá řada formalizovaných výstupů (deliverables). Ze standardu TOGAF byly pro NAR vybrány následující z nich.

První tabulka⁷⁸⁾ představuje jejich původní název, generický překlad a specifický název pro NAR:

K vybraným výstupům dle TOGAF postupně doplňuje NAR v praxi české veřejné správy užívané a s architekturou související dodávané výstupy.

Druhá tabulka⁷⁹⁾ přináší vysvětlení významu a úlohy dokumentů:

NAR v této části iniciálně zavádí nové typy dodatelných výstupů / plnění, v podobě dokumentů nebo modelů v architektonickém úložišti.

Tyto budou postupně zpřesňovány na základě zkušeností z prvních projektů. Dále budou provazovány s ostatními dokumenty a zodpovědnostmi v materiálu Metody řízení ICT VS ČR, tak aby tvořily ucelený a vyvážený systém bez zbytečných překryvů, duplicit nebo naopak mezer.

Příkladem je nutnost provázání řady zde uvedených obecných dodatelných výstupů architektury s konkrétními výstupy jednotlivých angažmá, specifikovaných výše, jako Architektonická vize, Informační koncepce OVS nebo Žádost o stanovisko OHA.

Zde bude další vysvětlení obsahu, významu a vzájemných souvislostí dodávaných výstupů.

Hlediska⁸⁰⁾ vycházejí z myšlenky, že existuje několik různých skupin zainteresovaných lidí, kteří potřebují ke své práci pouze určitý typ informací a různou míru detailu. Kdyby jim bylo prezentováno více, model by se pro ně stával nepřehledným až nečitelným, případně nedisponují potřebnými znalostmi pro pochopení přílišného detailu. Dle definice uvedené v rámci TOGAF se hlediskem rozumí:

„Hledisko definuje perspektivu (úhel pohledu), ze které je možné vidět pohled ⁸¹⁾ na model. Jedná se o specifikaci konvencí pro vytvoření a použití pohledu. Zatímco Pohled je konkrétní diagram, tak Hledisko říká, jak má diagram vypadat a co má prezentovat uživateli.“

Tuto definici hezky doplňuje obrázek znázorněný níže, převzatý pro změnu ze specifikace ArchiMate 2.1:

Každé hledisko tedy odpovídá potřebám a možnostem jiné skupiny zainteresovaných osob a může sloužit k odlišným účelům. Z definice vyplývá, že hledisko je vlastně určitým dílčím metamodelem (má definovanou množinu relevantních typů prvků a jejich vzájemných vazeb), případně definicí pohledů, tj. návodem na grafické vyjádření topologie a barevnosti modelu.

V dalších částech proto budou vymezena použitá hlediska a stanoveny role zainteresovaných, odpovídající těmto hlediskům. Pěkným znázorněním kategorií zainteresovaných, jejich potřeb a jim odpovídajících typů pohledů na celek modelu, který ale v praxi sám celkové grafické vyjádření nemá, ukazuje následující ilustrace na Obrázek níže:

Každý ze zainteresovaných v obrázku výše obdrží svůj vlastní pohled (katalog, matici, diagram), odpovídající jeho potřebám a jeho hledisku. Celkový diagram, pokud je vůbec realizovatelný, využívá pouze hlavní architekt a správce modelu pro kontrolu modelu.

Za téměř synonyma a víceméně zástupné se považují pojmy „Hledisko“ a „Definice pohledu“. Zatímco „Hledisko“ může více hovořit o tom, odkud, s jakými potřebami a s jakými možnostmi vnímání modelu se zainteresovaný na model dívá, stanovuje „Definice pohledu“ jaké má mít „Pohled“ náležitosti (dimenze, prvky metamodelu, formu, jazyk, apod.), aby přinesl zainteresovanému hledícímu na model z určitého „Hlediska“ očekávaný užitek.

Obě definice architektonických výstupů, jako pohledy a jako kategorie artefaktů spolu úzce souvisí. Všechny tři kategorie artefaktů (katalogy, matice a diagramy) představují pohledy a musí odpovídat příslušným hlediskům zainteresovaných.

Vzhledem k tomu, že katalogy a matice jsou současně výchozím předpokladem pro správné grafické vyjádření, spojuje NAR pojem pohled převážně s artefatem typu grafický diagram pohledu na model.

Národní architektonický rámec v následujících částech přináší přehled všech známých hledisek a jim odpovídajících definic pohledů, které mohou být přínosem pro architekty veřejné správy při komunikaci jejich poznání pro zainteresované.

Hlediska a definice pohledů jsou převzata jak z klíčových standardů pro NAR, tj. z TOGAF a ArchiMate, tak z dalších de facto standardů jako je Zachman⁸²⁾ nebo z nejlepší praxe rámců jiných států, například GEA-NZ Nového Zélandu⁸³⁾.

Důležitým zdrojem hledisek je pro NAR architektonická praxe úřadů VS ČR. Teprve praxe ukazuje, kdo jsou v OVS typičtí zainteresovaní, jaké mají potřeby a jaké pohledy na EA úřadu se pro ně osvědčily. NAR bude postupně přebírat a zobecňovat do podoby nejlepší praxe osvědčená hlediska ze všech lokálních architektonických metodik, o nichž se OHA dozví.

Každý ze standardů a vzorů kategorizuje výstupy a artefakty, naplňující hlediska, z různých pohledů, dimenzí. Zatímco ArchiMate a GEA-NZ třídí primárně podle architektonických domén, u TOGAFu je to podle fází cyklu ADM a u Zachman je to podle průsečíků mezi světonázorovými otázkami (Kdo, Co, Proč, Kde apod.) a úrovněmi abstrakce.

NAR přebírá obě klíčová třídění hledisek, podle domén i podle fází, a přidává ještě třetí pragmatický přístup. V rámci něj uvádí NAR povinná, resp. doporučená hlediska a definice pohledů pro jednotlivé explicitně upravené druhy architektonických angažmá, viz Proces tvorby architektury. Ostatní, v následujících částech uvedená hlediska jsou pouze inspirací, ulehčující počátky modelování v úřadech.

Některá hlediska a definice pohledů z jednotlivých zdrojů se vzájemně překrývají. V takovém případě NAR tyto definice propojuje a vybírá do vlastní specifikace hlediska to podstatné z obou, ze všech zdrojů. Ve Znalostní bázi NA VS ČR je plánováno zveřejnit tabulku namapování doporučovaných hledisek NAR podle zdrojů (hlavně ArchiMate, TOGAF a Zachman, ale i dalších), ze kterých pocházejí.

U jednotlivých hledisek a definic pohledů, případně s nimi spojených dodatelných výstupů rozlišuje NAR související úroveň hierarchie veřejné správy, tj. zda se jedná o výtvory a výstupy, které jsou výlučně celostátní (AoG⁸⁴⁾), nebo mohou být i korporátní či se jedná výlučně o výtvory a výstupy jednotlivých úřadů.

Přehled výtvorů a výstupů současně upozorňuje, které katalogy a jim odpovídající grafické výstupy jsou pro rozvoj NA z pohledu NAR nové a naprosto klíčové:

• Mapa byznys schopností úřadu – co můj úřad všechno dovede a do jaké míry je to podporováno IT
• Mapa agend, služeb veřejné správy, případně procesů a funkcí – přesnější vyjádření schopností úřadu pomocí prvků jeho byznys chování.
• Mapa aplikačních komponent úřadu – jaké aplikace můj úřad používá a v jaké stavu jsou
• Mapa technologické infrastruktury úřadu – kde a v jakých platformách můj úřad provozuje svoje IS
• Mapa komunikační infrastruktury úřadu – jakými všemi způsoby můj úřad propojuje svoje vyýpočetní kapacity s vnějším světem
• Roadmapa změn (alespoň aplikační architektury) – kdy a proč budeme měnit, rozvíjet nebo ukončovat naše informační systémy
• Motivační mapa – přehled vlivů, cílů a očekávaných výstupů úřadu

Pro vnitřní potřebu zavedení tvorby, správy a užití EA je nutné vytvořit a užívat pohled na dílčí schopnost úřadu:

• Model řízení úřadu pomocí EA

NAR předpokládá, že pro každé portfoliové klasifikační hledisko typu Mapa bude k dispozici akcelerátor modelování v podobě referenčního modelu (RM). Aktuáně jsou k dispozici RM byznys architektury a aplikační architektury.

Přehled typových hledisek, definovaných v části TOGAF, zvané Rámec obsahu architektury (ACF⁸⁵⁾), vyznačení a intepretace hledisek převzatých do NAR se nachází ve Znalostní bázi NA VS ČR.

Jazyk ArchiMate ve verzi 2.1 definoval jakožto příklady možných hledisek celkem 18 základních hledisek a 9 hledisek patřících pod motivační a implementační rozšíření. Pro potřeby NAP bylo převzato 12 v ČR nejpoužívanějších konkrétních hledisek, která byla vybrána s výhledem na jejich další praktické využití. Jejich přehled se nachází ve Znalostní bázi NA VS ČR.

Vedle toho se ve specifikaci ArchiMate 2.1 uvádělo obecné hledisko představující grafické vyjádření matic a klasifikací architektury, zvané hledisko přehledové (krajinné) mapy⁸⁶⁾. V NAR je toto obecné doporučení rozpracováno pro každou z vrstev byznys, aplikační a technologické architektury a pro architekturu schopností ve strategické doméně. Tyto tzv. Mapy portfolia jsou nositeli grafického vyjádření klasifikace a topologie (rozmístění) prvků architektury v tzv. Referenčních modelech.

Pro NA VS ČR se jako základní hlediska vedle portfoliových map považují vždy dvojice hledisek, hledisko vnitřní struktury a hledisko vnějších služeb. Zatímco první hledisko se soustředí na modelování vnitřního fungování úřadu, jeho funkcí, aplikací a technologií, druhé hledisko se zaměřuje na užití těchto funkcí pomocí služeb pro konkrétní příjemce.

Z praktických důvodů přidává NAR v byznys vrstvě ještě hledisko organizační, ve vrstvě architektur IS hledisko struktury informací a hledisko spolupráce aplikací (komunikace, integrace).

V případě potřeby umožňuje NAR využít doporučená ArchiMate hlediska v motivační a implementační oblasti.

Z důvodu podpory strategie vize tzv. čtyřvrstvé architektury přidává NAR ještě hlediska komunikační infrastruktury, tj. pohledy zaměřené na ty prvky infrastruktury, které stojí vně technologických (datových) center a umožňují jejich vzájemné propojení a připojení na sdílené služby eGovernmentu KIVS/CMS. Z hlediska metamodelu a definic jsou pro tyto pohledy přiměřeně využity tytéž prostředky infrastrukturní (zelené) vrstvy jazyka ArchiMate. Proto či přesto, že se následně v diagramech individuálních architektur použijí dvakrát, pro IT technologie a pro komunikační infrastrukturu, není třeba i jejich definice zdvojovat a specializovat, ale je to přípustné.

Z architektonické rámce Zachman, verze 3.0, který je tzv. ontologií architektonických modelů, dosud nebyla převzata žádná hlediska jim odpovídající definice pohledů. Budou-li nově nějaká hlediska zařazena, pak bude jejich přehled a definice ve Znalostní bázi NA VS ČR.

Následující schéma představuje podmnožinu hledisek a jim odpovídajících definic grafických pohledů na model architektury úřadů (diagramů), vybraných ze souhrnu hledisek TOGAF, ArchiMate a z praxe a aktuálně zařazených do přizpůsobeného rámce Národní architektury tak, jak mají sloužit pro jednotnost zpracování a navigaci ve sdíleném architektonickém úložišti.

Dále je přehled doporučených hledisek předem rozšířen o hlediska tzv. Evropské referenční architektury pro interoperabilitu (EIRA⁸⁷⁾), verze 2.1.0.

Všechna dále ve schématech uvedená hlediska odpovídají grafickým diagramům, hlediska pro katalogy a matice nejsou uvedena, ale tvoří jejich předpoklady.

Obecně platí, že v těchto raných fázích implementace NA ve VS ČR je pro architektonická hlediska architektury úřadů povoleno využívat jakékoli typu katalogu, matice nebo diagramu s tím, že doporučovány jsou typy artefaktů podle ArchiMate a TOGAF ACF⁸⁸⁾, pokud v pokynu pro vybrané architektonické angažmá, viz Proces tvorby architektury Praktické příklady architektonických angažmá, není explicitně uvedeno jinak.

Pro všechny katalogy a matice, níže aktuálně zahrnuté do Národního architektonického rámce, budou postupně definovány evidované atributy objektů a ve Znalostní bázi NA VS ČR publikovány pracovní vzory, jak v tabulkovém editoru pro prvotní inventarizaci, tak ve výměnném formátu ArchiMate.

Mezi přehledovými hledisky je aktuálně definováno tzv. hledisko Přehledu služeb čtyřvrstvé architektury eGovernmentu. Toto hledisko udržuje kontinuitu s předchozími strategickými dokumenty eGovernmentu ČR a poskytuje zainteresovaným přehled o vzájemném předávání služeb mezi jednotlivými vrstva architektury. Hledisko odpovídá struktuře metamodelu ArchiMate a standardnímu hledisku vrstev architektury, ale z důvodu členění zodpovědnosti vyděluje zvlášť vrstvu architektury technologické komunikační (a stavební) infrastruktury a zdůrazňuje úlohu služeb.

Dále se zde uplatní dle potřeby standardní ArchiMate hlediska, tzv. úvodní hledisko a hledisko vrstev architektury.

Za přehledové hledisko je možné považovat i Přehled (Mapu) schopností úřadu⁸⁹⁾, která ukazuje rozdělení úřady na menší části (segmenty a schopnosti) podle toho, jaké byznys výstupy (interní a externí) dokáží poskytovat, ale bez ohledu na to, co obsahují uvnitř, ve své architektuře. Ve standardní specifikaci ArchiMate je toto hledisko součástí strategie, pro NAR bude plnit zejména úlohu nezbytného přehledu.

Hledisko služeb čtyřvrstvé architektury je skutečně zaměřeno na vyjádření vztahu mezi interním chováním (tj. zejména funkcí) aktivního prvku dané vrstvy a externím projevem tohoto chování (schopnosti) vůči prvku vyšší vrstvy, tj. službou.

Ostatní prvky metamodelu ArchiMate jsou pro zdůraznění hlavní myšlenky spolupráce vrstev záměrně vynechány.

Obsahuje všechny prvky jazyka v podobě zjednodušené grafické notace. Používá se především pro hrubý návrh, kdy ještě nejsou k dispozici informace potřebné pro detailní popis podnikové architektury. Lze jej tedy použít k velmi detailnímu až velmi obecnému hrubému návrhu, který je určen pro všechny zainteresované strany. Typické je pro vyjádření architektonické vize.

Rysem tohoto hlediska je, že se často v zájmu lepšího porozumění zainteresovanými odchyluje od striktní vizuální notace ArchiMate. Tak je to možné i v této metodice NAR.

Definice tohoto hlediska může vypadat například následovně:

Jak název napovídá, toto hledisko slouží ke znázornění několika vrstev architektury v rámci jednoho diagramu. Rozeznáváme 2 kategorie vrstev a to dedikované a servisní vrstvy. Do první kategorie vrstev řadíme účastníky, byznys procesy, aplikace a prvky infrastruktury. Do druhé skupiny vrstev se pak řadí služby. Kategorie vrstev se střídají. Přičemž je důležitý jejich vztah. Vrstva dedikovaných objektů realizuje servisní vrstvu (vztah „realizace“). Tato servisní vrstva je posléze využívána jinou dedikovanou vrstvou (vztah „slouží“). Tento pohled nám umožní odlišit interní strukturu organizace, která je vyjádřena dedikovanou vrstvou od externě rozeznatelného chování vyjádřeného v servisní vrstvě.

Počet vrstev není pevně stanoven. Metamodel tohoto pohledu vychází z celkového metamodelu jazyka ArchiMate 3.1. Na Obrázku níže je tedy uveden pouze příklad možného použití, nikoli úplný metamodel této vrstvy. (Klíčové je střídání dedikovaných a servisních vrstev a užívání příslušných vazeb).

V rámci NA VS ČR je z tohoto ArchiMate hlediska odvozeno specializované hledisko pro vyjádření naplnění tzv. vize čtyřvrstvé architektury eGovernmentu konkrétní architekturou úřadu, jeho segmentu nebo schopnosti.

V praxi se často setkáváme s potřebou vyjádřit objekty ve více vrstvám architektury, ale bez možnosti zdůraznit servisní vrstvy, například proto, že služby dané vrstvy (byznys, aplikační či technologické) nejsou v organizaci známy a udržovány, funkce aktivních prvků nejsou jako služby řízení, a proto je tak nelze ani modelovat.

Potom se uplatní tzv. Zjednodušené hledisko vrstev (bez rozdělení vrstev na dedikované a servisní). Příklad z praxe:

Hledisko přehledu schopností úřadu (Capability Map) se používá tehdy, je-li třeba na jedné ploše, jednom snímku PowerPointu představit zainteresovaný přehled všeho, co úřad dokáže. A to bez toho, že by již v této fázi bylo analyzováno, které to dělá oddělení, jakým procesem, na základě jakého zákona či s jakým informačním systémem.

Jde o strukturální model, ve kterém je přehled schopností úřadu vyjádřen hierarchickou strukturou objektu „Schopnost“, ať již v podobě hierarchického Katalogu schopností úřadu, nebo diagramu Přehled (mapa) schopností úřadu.

Schopnosti, zachycené v modelu jsou dlouhodobě stabilní, pouze se zlepšují. Mohou být složeny z dílčích schopností, přiřazených kompozitní vazbou.

Přestože schopnosti mohou být hierarchické, viz výše, je možné k modelování schopností přistoupit ještě dvojím způsobem a) podle struktury Enterprise dle TOGAF a podle příkladu klasifikačních map v ostatních doménách. Oba přístupy společně a ve vzájemném vztahu shrnuje Obrázek níže.

Podle dělení TOGAF je celý Enterprise považován za strategický, dále dělí na (vertikální, odvětvové) segmenty a tyto se teprve dělí na schopnosti (vertikální a průřezové, horizontální). Pro případné modelování segmentů úřadu je navrženo použít specializovaného stereotypu schopnosti, nazvaného «Segment úřadu», respektive jenom zkráceně «Segment». Oblasti na nejvyšší úrovni, které nejsou segmentem výkonu veřejné správy se modelují rovnou jako nespecializovaná Schopnost.

Je možné uvažovat pouze na schopnosti na nízké úrovni (větším detailu) a pro jejich seskupování (klasifikaci, třídění) nevyužívat schopnosti, nýbrž Seskupení, viz Obrázek výše (vlevo). Který ze způsobů modelování schopností se skutečně vžije, ukáže až praxe.

Obrázek - Přehled schopností úřadu, nebo také základní mapa úřadu je vynikajícím výrazovým prostředkem, do něhož lze promítnou vyhodnocení nějakého aspektu schopností v jednotlivých oblastech, například míru či kvalitu IT podpory výkonu schopností. Takovému vyjádření říkáme Heat Map⁹⁰⁾ a v NAR se vyskytuje opakovaně na více místech. Barvy v příkladu znamenají: modrá – průměr, zelená – nadprůměr, červená – podprůměr, potenciál pro zlepšení.

Ze všech čtyř vertikálních domén motivační architektury (strategické směrování, výkonnost, bezpečnost a shoda s pravidly) je ve shodě se standardem ArchiMate aktuálně pro NA VS ČR definován obsah diagramů pro tzv. Motivační hledisko - strategické směřování. Ve specifikaci ArchiMate odpovídá tzv. Motivačnímu rozšíření a v TOGAF odpovídá motivační části byznys architektury.

Pro ostatní domény motivace jsou definovány pouze katalogy, bez matic a grafického vyjádření.

Hledisko slouží ke znázornění zainteresovaných subjektů, interních a externích motivátorů změn a zhodnocení (ve smyslu silných a slabých stránek, příležitostí a hrozeb) těchto motivátorů. Rovněž může být použito k popisu vysokoúrovňových cílů.

Pohledy vytvořené podle tohoto hlediska postihují motivaci úřadu ke strategické změně a s ní spojené změně architektury. Hledisko nezohledňuje ostatní průběžné motivační aspekty, například motivaci k výkonu a kvalitě služby.

Pro modelování diagramů podle tohoto hlediska jsou předpokladem následující katalogy motivační architektury:

• Katalog zainteresovaných stran⁹¹⁾
• Katalog motivátorů⁹²⁾ a potřeb
• Katalog strategických cílů⁹³⁾, proveditelných úkolů⁹⁴⁾ a jejich měřítek splnění
• Katalog architektonických principů
• Katalog klíčových architektonických požadavků⁹⁵⁾ a omezujících podmínek

Celkové motivační hledisko může být při velkém množství motivačních prvků s výhodou rozděleno na:

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

Architektura výkonnosti aktuálně nemá definována žádná hlediska pro grafické diagramy, nemá ani specifický metamodel, přestože by bylo možno alespoň částečně využít objekt specializovaný typ prvků „Metrika“.

Pro výkonnostní architekturu jsou navrženy tyto katalogy:

• Katalog ukazatelů výkonnosti a kvality, kam se počítají ukazatele 3E, dělené na:
  • Zvýšení hospodárnosti⁹⁶⁾ čerpání zdrojů pro veřejnou službu
  • Zvýšení účinnosti⁹⁷⁾ práce zdrojů při tvorbě výstupů
  • Zvýšení účelnosti⁹⁸⁾ výstupů služby pro dosažení výsledků
  • Zvýšení úrovně a kvality předmětné služby, tj. hodnoty služby vnímané jejími spotřebiteli, klienty veřejné správy.
• Katalog výsledků, dopadů a multiplikačních efektů politiky (strategické iniciativy)

Pro výkonnostní architekturu aktuálně nejsou navrženy žádné matice ani diagramy.

Architektura bezpečnosti aktuálně nemá definována žádná hlediska pro grafické diagramy, nemá ani specifický metamodel, protože objekty typu „Riziko“ a „Opatření na zmírnění rizika“ nejsou dosud součástí standardní specifikace jazyka ArchiMate 3.1.

Připravuje se využití bezpečnostní architektury v duchu a na podporu zákona o kybernetické bezpečnosti (ZoKB), resp. ISO 27001. Tj. v duchu doporučení The Open Group budou pro tuto oblast vytvořeny prvky metamodelu (potřebné stereotypy) specializací jiných existujících prvků a jejich dedikováním pro aktivum, hrozbu, riziko, opatření, … tj. pojmy dle ZoKB. Vzhledem ke zdrženlivosti při rozšiřování metamodelu to nebude v nejbližší době a musí tomu předcházet pilotní projekty.

Pro bezpečnostní architekturu jsou zatím navrženy tyto katalogy:

• Katalog pasivní bezpečnostní architektury, tj. katalog prvků architektury úřadu, které vyžadují specifickou ochranu. Používá se zejména v architektuře připravovaných projektů (PSA⁹⁹⁾) pro zdůraznění nově implementovaných prvků hodných mimořádné ochrany, kterou úřad dosud nedisponuje.
• Katalog aktivní bezpečnostní architektury, tj. katalogů prvků úřadu, které svojí přítomností poskytují jiným prvkům mimořádnou (dodatečnou) ochranu. Používá se zejména v PSA (viz výše) pro zdůraznění nově implementovaných bezpečnostních prvků.

Pro bezpečnostní architekturu aktuálně nejsou navrženy žádné matice ani diagramy.

Architektura shody s pravidly, standardizace a udržitelnosti aktuálně nemá definována žádná hlediska pro grafické diagramy, nemá ani specifický metamodel.

Pro tuto architekturu jsou navrženy tyto katalogy:

• Katalog předpisů a norem
• Katalog standardů
• Katalog stavebních bloků architektury a řešení
• Katalog zásad a opatření dlouhodobé udržitelnosti úřadu

Pro architekturu shody s pravidly, standardizace a udržitelnosti aktuálně nejsou navrženy žádné matice ani diagramy.

Hlediska byznys architektury VS definují především několik zásadních katalogů, v nichž je inventarizováno vždy několik blízkých objektů. Jsou to:

• Katalog organizačních jednotek, útvarů a pozic,
• Katalog aktérů (jejich typů) a jejich rolí – konkrétní aktéři se obvykle neinventarizují (například fyzická osoba, občan, zaměstnanec), nahrazující se typem aktérů a odhadem počtu.
• Katalog funkcí a procesů
• Katalog služeb veřejné správy
• Katalog komunikačních (obslužných) rozhraní veřejné správy

Pro byznys architekturu výkonu služeb veřejné správy aktuálně nejsou navrženy žádné matice.

Pro byznys architekturu jsou v NAR aktuálně definována tato následující hlediska.

Hledisko funkcí veřejné správy znázorňuje hlavní byznys funkce organizace a vztahy mezi nimi. Byznys funkce se využívají k zobrazení hlavních činností, které podnik vykonává, bez ohledu na organizační změny nebo technologický vývoj. Proto také byznys architektury společností, které působí na stejném trhu, často vykazují podobnosti. Toto hledisko poskytuje podrobný pohled na provoz společnosti a lze ho využít k identifikaci nezbytných kompetencí nebo ke strukturování organizace podle hlavních činností.

Toto hledisko v nejjednodušší formě ukazuje vztah mezi dynamickým účastníkem (rolí) a bytostí nebo organizací, která na sebe role bere (aktér).

Podstatné je, že existence aktéra je trvalá, kdežto roli na sebe bere jenom v případě, že vstupuje do interakce (poskytuje nebo konzumuje funkci jako službu).

Případnou specializaci aktérů na organizace a útvary bude třeba nejprve ověřit v praxi.

Hledisko spolupráce byznys procesů slouží ke znázornění vztahu jednoho či více byznys procesů vůči ostatním procesům, případně jejich prostředí. Jednak může být použito k vytvoření vysokoúrovňovému znázornění byznys procesů spolu s nezbytným kontextem za účelem tvorby těchto procesů, rovněž může sloužit i jako prezentační pomůcka pro provozní manažery, kterým poskýtá nezbytný přehled závislostí jimi řízených procesů.

Hledisko byznys procesů se používá k podrobnému zobrazení struktury a složení byznys procesů. Kromě vlastních procesů hledisko obsahuje i jiné přímo související koncepty, jako jsou například:

• Služby poskytované byznys procesy navenek; zobrazují, jak proces přispívá k realizaci produktů společnosti
• Přiřazení byznys procesů k rolím, které vypovídají o zodpovědnostech přiřazených aktérů
• Další informace využívané byznys procesy prostřednictvím aplikačních služeb

Organizační hledisko slouží ke znázornění (interní) organizační struktury organizace, případně některé z jeho nižších organizačních jednotek. Rovněž jej můžeme použít ke znázornění sítě organizací (např. zřizovatel a organizační složky, příspěvkové organizace atp.). Model je možné prezentovat digramem ve formě vnořených bloků, nebo ve formě tradičního organizačního schématu.

Hledisko organizační struktury je užitečné při identifikaci kompetencí, pravomocí a zodpovědností v organizaci. Zejména u tohoto hlediska se doporučuje jednotlivé elementy vkládat do sebe. Čtenář tak obdrží přehlednou a velmi intuitivní organizační strukturu. Mírou detailu se jedná o vazební hledisko určené pro všechny zájmové skupiny.

Příklad:

Základem obsahu tohoto hlediska je třístupňová klasifikace všech prvků byznys architektury. S trochou nepřesnosti je možné říci, že jak byznys role, jejich funkce, procesy a jejich služby a s nimi spojené objekty VS lze jednoznačně klasifikovat, tj. každý zařadit právě do jedné z byznys oblastí, kategorií a skupin.

Současně jsou v referenčních modelech představena grafická vyjádření rozmístění klasifikovaných domén, jejich oblastí, kategorií a skupin, tj. jejich tzv. topologie. Důsledné využití topologie z referenčních modelů významně zrychlí tvorbu diagramů typu Mapa a výrazně usnadní jejich čtení a interpretaci.

NAR zde doporučuje používat pro vyjádření klasifikace a její topologie v modelech objekt „Seskupení“.

Naopak – tato metodika považuje za nevhodné, používat pro úrovně klasifikace objekty vyhrazené skutečně jsoucím prvkům architektury (byznys funkce, procesy nebo služby). Vlastní model architektury se tím ale stává nekonzistentním, neboť jsou v něm v jednom seznamu uvedeny komponenty, které skutečně jsou a jiné, které je jenom virtuálně zastupují v klasifikaci. Nad takovým modelem se pak nedá rozumně automatizovaně o architektuře reportovat.

Výjimkou jsou specializované koncepty jako tzv. «stereotypy», například «agenda» a «agendová činnost», které ale nejsou součástí diagramu Mapa portfolia, pokud nejsou klasifikovány společně a konzistentně s ostatními nespecializovanými byznys funkcemi.

Základem architektury informačních systémů a jejích artefaktů jsou katalogy klíčových objektů. Jsou to zejména:

• Katalog byznys a datových entit úřadu. V jednom katalogu lze zachytit jak byznys, tak datové objekty. Alternativně (v případě rozvinutější datové architektury) je účelné datovou architekturu rozdělit do několika katalogů a u obou typů entit evidovat rozdílné atributy (vlastnosti). Tedy zvlášť:
  • Katalog objektů / subjektů veřejné správy (úřadu)
  • Katalog datových objektů úřadu
  • případně Katalog datových artefaktů, fyzických souborů, tabulek a jiných úložišť dat.
• Katalog aplikačních komponent a funkcí. Tento katalog je možné v případě potřeby rozšířit ještě o prvky aplikační spolupráce a aplikační interakce
• Katalog aplikačních rozhraní
• Katalog aplikačních služeb, je odvozen od interních aplikačních funkcí, může mít jinou podrobnost a jiné evidované vlastnosti služeb, než u aplikačních funkcí.

Pro aplikační architekturu výkonu služeb veřejné správy aktuálně nejsou navrženy žádné matice.

Toto hledisko, stejně jako celý výše uvedený metamodel tzv. datové architektury dle TOGAF, pokrývá objekty napříč všemi třemi vrstvami architektury dle ArchiMate.

V rámci tohoto hlediska je možné v notaci ArchiMate použít „Objekty/subjekty VS“, tzv. Business Object, pro zachycení tzv. konceptuálního datového modelu klíčových objektů evidence.

Nebo je možné využít „Datové objekty“ pro zachycení diagramu logického datového modelu.

Velmi častá a doporučená je také kombinace obou typů, ukazující, jak skutečné objekty mají své obrazy v datových objektech.

Hledisko struktury informací je srovnatelné s tradičními informačními modely vytvořenými v rámci vývoje jakéhokoliv informačního systému. Zobrazuje strukturu informací využívaných v podniku nebo ve specifických byznys procesech či aplikacích ve formě datových typů nebo objektově orientovaných tříd. Hledisko může sloužit také k zobrazení způsobu, jak jsou byznys informace reprezentovány na aplikační úrovni ve formě datových struktur, a jak jsou namapovány na základní infrastrukturu například prostřednictvím databázového schématu.

Na zobrazení struktury informací v ArchiMate obvykle navazují detailní diagramy v dalších notacích - ERD, UML, viz také Rámec obsahu a výstupu architektur.

Toto hledisko se zaměřuje pouze na aktivní a pasivní prvky aplikační architektury, záměrně opomíjí jejich chování. Hledisko struktury aplikací zobrazuje strukturu jedné nebo více aplikací a komponent. Hledisko se využívá k navrhování či pochopení základní struktury aplikací nebo komponent a souvisejících dat; například lze rozebrat strukturu systému ve výstavbě nebo identifikovat komponenty starší aplikace, které jsou vhodné pro migraci či integraci.

Hlavním objektem a centrem zájmu tohoto hlediska je aplikační funkce. Cílem hlediska je co nejlepším způsobem postihnout, co aplikační komponenty nebo jejich spolupráce dovedou, tedy jakými funkcemi disponují.

Hledisko aplikační slouží ke znázornění vnitřního chování popisované aplikace, která může poskytovat jednu či více služeb. Primární využití spočívá při návrhu hlavních funkcí aplikací nebo při identifikování překrývajících se funkcionalit poskytovaných různými aplikacemi. Hledisko je detailní a určeno pro odborné pracovníky.

Příklad:

Těžištěm zájmu tohoto hlediska je postihnout, jak jsou spolu aplikační komponenty integrovány přes aplikační rozhraní. Hledisko spolupráce aplikací popisuje vztahy mezi aplikačními komponentami ve smyslu informačních toků mezi nimi a nabízených služeb včetně jejich využití. Hledisko je typicky využíváno k vytvoření přehledu o aplikačním vybavení organizace. Dále se využívá k vyjádření (interní) spolupráce či uspořádání služeb, které podporují vykonávání byznys procesů.

Toto hledisko primárně slouží k názornému až detailnímu zobrazení vazeb na aplikační úrovni.

Příklad (bez použití objektu rozhraní):

Hledisko využití aplikací popisuje, jak jsou aplikace využívány k podpoře byznys procesů, a také jak jsou využívány dalšími aplikacemi. Lze ho využít při navrhování aplikací prostřednictvím identifikace aplikačních služeb, potřebných pro byznys procesy nebo při navrhování byznys procesů popsáním dostupných služeb. Vzhledem k tomu, že se identifikují závislosti byznys procesů na aplikacích, hledisko mohou využít i provozní manažeři zodpovědní za tyto procesy.

Toto hledisko představuje logickou návaznost mezi byznys a aplikační vrstvou.

Příklad:

Základem obsahu tohoto hlediska je třístupňová klasifikace všech prvků aplikační architektury. S trochou nepřesnosti je možné říci, že jak aplikační komponenty, jejich funkce, jejich služby a s nimi spojené datové objekty lze jednoznačně klasifikovat, tj. každou zařadit právě do jedné z aplikačních kategorií.

Současně jsou v referenčních modelech představena grafická vyjádření rozmístění klasifikovaných domén, oblastí, kategorií a skupin, tj. jejich tzv. topologie. Důsledné využití topologie z referenčních modelů významně zrychlí tvorbu diagramů typu Mapa a výrazně usnadní jejich čtení a interpretaci.

Doporučení NAR je používat pro vyjádření klasifikace a její topologie v modelech objekt „Seskupení“.

Naopak – tato metodika považuje za nevhodné, používat pro úrovně klasifikace objekty vyhrazené skutečně jsoucím prvkům architektury (aplikační komponenty, funkce nebo služby). Vlastní model architektury se tím ale stává nekonzistentním, neboť jsou v něm v jednom seznamu uvedeny komponenty, které skutečně jsou a jiné, které je jenom virtuálně zastupují v klasifikaci. Nad takovým modelem se pak nedá rozumně automatizovaně o architektuře reportovat.

Výjimkou jsou specializované koncepty jako tzv. «stereotypy», například «logický IS».

Toto hledisko je příkladem a specializací obecného motivačního (strategického) hlediska Realizace požadavků.

Hlediska technologické architektury VS definují především několik zásadních katalogů, v nichž je inventarizováno vždy několik blízkých objektů. Jsou to:

• Katalog uzlů, zařízení a systémového SW

Pro technologickou architekturu výkonu služeb veřejné správy aktuálně nejsou navrženy žádné matice.

Pro technologickou architekturu v Národním architektonickém rámci aktuálně definována následující hlediska.

Všechna technologická hlediska je možno použít jak pro vyhodnocování a řízení technologií z hlediska jejich umístění do DC (topologie infrastruktury v lokalitách), tak z hlediska konsolidace využívaných technologických platforem.

Hledisko IT technologií obsahuje prvky SW a HW infrastruktury, které podporují aplikační vrstvu; jedná se o fyzická zařízení nebo systémový software (například operační systémy, databáze a middleware).

Příklad:

Hledisko využití technologické infrastruktury zobrazuje, jak jsou aplikace podporovány SW a HW infrastrukturou. Infrastrukturní služby jsou dodávány zařízeními; systémový software a sítě jsou poskytovány aplikacemi. Toto hledisko hraje důležitou roli v analýze výkonnosti a škálovatelnosti, protože se týká fyzické infrastruktury podporující logickou oblast aplikací. Hledisko je užitečné při určování požadavků na výkon a kvalitu infrastruktury, které vycházejí z požadavků jednotlivých aplikací využívajících danou infrastrukturu.

Z praktického užití architektury úřadu na MZe bylo do metodiky NAR převzato zjednodušené hledisko propojující technologické uzly, v nich uchovávané datové artefakty (soubory, databáze) a na nich provozované aplikační komponenty.

Základem obsahu tohoto hlediska je třístupňová klasifikace všech prvků technologické architektury. S trochou nepřesnosti je možné říci, že jak aplikační komponenty, jejich funkce, jejich služby a s nimi spojené datové objekty lze jednoznačně klasifikovat, tj. každou zařadit právě do jedné z aplikačních kategorií.

Další komentáře totožné jako u ostatních portfolií výše.

Specifický diagram na podporu vyjádření rozdělené zodpovědnosti poskytovatelů služeb výpočetního výkonu (datových center) a služeb komunikační infrastruktury.

Pro koncepty komunikační infrastruktury je možné využít běžné prvky technologické infrastruktury nebo zdvojené (specializované) objekty pro komunikační infrastrukturu. V architektuře konkrétního úřadu je možné modelovat IT technologie i komunikační infrastrukturu jednou sadou prvků metamodelu technologické vrstvy a až v tomto hledisku a v hledisku čtyřvrstvé architektury vyjádřit rozdělení technologické (zelené) vrstvy ArchiMate ve dvě, IT technologickou a komunikační.

Jak technologickou tak komunikační infrastrukturu je přirozené kombinovat s prvky vrstvy fyzické architektury, představující zejména další non-IT objekty datových center - budovy, klimatizace, zabezpečení apod.

Portfoliové hledisko oblasti komunikační architektury bude obdobné hledisku technologické mapy, ale není zatím specifikováno.

Toto hledisko se používá ke vztažení všech programů a projektů k částem architektury, kterou implementují. Pohled umožňuje modelování rozsahu programů, projektů a projektových aktivit a to v souvislosti s rovinou architektury nebo jednotlivých prvků, které jsou ovlivněny. Způsob, jakým se jednotlivé elementy ovlivňují, může být znázorněn vhodnou anotací jejich vazeb.

Příklad:

Popis hledisek a jejich praktického využití bude doplněn do další verze metodiky NAR.

Modelování architektury úřadu na úrovni Enterprise architecture, s využitím metodiky TOGAF a jazyka ArchiMate, obvykle na jedné straně předchází modelování strategie a tzv. byznys modelu a na druhé straně za nimi následuje podrobnější modelování architektur řešení a modelování design řešení.

K obojímu se využijí specifické metody a modelovací notace, například:

• Strategie: SWOT, PESTEL, Porter’s Five Forces, Balanced Scorecard, Business Model Canvas, Ecosystem model, Business Motivation Model, atp.
• Detail nebo speciality: UML, SysML, BPMN, DMN, ERD, Customer Journey Map, Business Outcome Journey Map, atp.

Důvodem, proč zde v NAR tyto metody a notace zmiňujeme, není snaha formulovat jejich národní specifikaci, nýbrž upozornit na to, že objekty v jazyce ArchiMate je nutné modelovat tak, aby na zachycení existence nějaké věci (procesu, služby, datového prvku apod.) v jazyce ArchiMate mohl navazovat její detailní model v jiné notaci.

Například při modelování chování úřadu v byznys vrstvě je vhodné prohlásit za proces jenom taková chování, která splňují atributy procesu a bude je následně možné modelovat jako bazén BPMN modelu. A naopak, všechno, pro co bude v BPMN modelován proces, podproces nebo volaná aktivita, by mělo mít i svůj odpovídající obraz v ArchiMate modelu.

Proto by modelování pro potřeby digitální transformace veřejné správy mělo být podpořeno integrovaným společným modelem úřadu na úrovni NAP i PMA3.

Pro úřady, které s výhodou využijí více modelovacích notací, doporučuje NAR tento fakt zdůraznit v zadávací dokumentaci k VZ na modelovací nástroj tak, aby bylo zajištěno nejenom jedno modelovací prostředí pro tyto různé notace, ale také možnost plynulého přechodu (navigace a trasování) mezi modely v různých notacích, viz příklad na obrázku níže.

Na vztahu těchto dvou notací je plně zřejmý rozdíl mezi architekturou úřadu na úrovni EA, kladoucí si zejména otázku „Co a proč je?“ a architekturou řešení (SA), kladoucí si otázku „Jako to funguje?“, zde na úrovni byznys vrstvy.

Model EA v ArchiMate pro příklad objednání pizzy zachytává jenom základní role zákazník a dodavatel a existenci všech klíčových procesních krků a hrubých vazeb mezi nimi, jak ukazuje následující diagram:

Naproti tomu digram v notaci BPMN v tomto příkladu zachovává 1:1 procesní kroky, ale přidávání dílčí zodpovědnosti (role) a prováděcí detaily (rozhraní, čekání apod.):

V běžné praxi je BPMN model ještě mnohem podrobnější, tj. pro každý jeden proces v ArchiMate je typicky modelován v BPMN jeden „bazén“ s mnoha procesními rolemi a mnoha kroky.