Rámec obsahu a výstupů architektur

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ů: