Překlady této stránky:

Toto je starší verze dokumentu!


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)

 Vrstvy a aspekty jazyka ArchiMate (The Open Group, 2017)

Aspekty jazyka ArchiMate

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.

Vrstvy a struktura diagramů v modelech

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ě.

Barvy prvků

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.11)

Doména Název barvy Definice barvy (RGB)
Červená (R) Zelená (G)Modrá (B)
Motivační Fialová 204 204 255
Strategická Okrová 245 222 170
Byznys Žlutá 255 255 175
Aplikační Tyrkysová 175 255 255
Technologická Zelená 175 255 175
Fyzická Zelená 175 255 175
Implementační a
migrační
Světle červená 255 224 224
Kompozitní Světle zelená 224 255 224
Bez barvy (bílá)- (255) - (255) - (255)
Oranžová 255 185 115

Tvary prvků

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í.

Vyšší verze specifikace ArchiMate

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.

Přehled prvků standardu ArchiMate 3.1 a jejich lokalizace

Doména Původní název Generický překlad Úprava pro NAR
Motivační Stakeholder Zainteresovaný
Driver Motivátor, vliv, driver Veřejná potřeba, hnací prvek
Assesment Zhodnocení vlivu Vyhodnocení potřeby
Goal Cíl Strategický cíl, politika
Outcome Výstup
Principle Princip Architektonický princip
Requirement Požadavek Klíčový architektonický požadavek
Constraint Omezení Omezující podmínka řešení
Meaning Význam
Value Hodnota Hodnota služby VS
Strategická Course of action Směr změny Směr změny, postup, iniciativa
Capability Schopnost Schopnost úřadu
Resource Zdroj
Value stream Hodnotový řetězec Scénář dodávky služby
Byznys Business interface (Byznys) rozhraní Obslužný kanál VS
Business actor Účastník/aktér Účastník interakce s VS
Business role Role Role ve veřejné správě
Business collaboration (Byznys) spolupráce Spolupráce ve VS
Business function (Byznys) funkce
Business process Proces
Business event Událost Životní událost
Business interaction Interakce Interakce ve VS
Business service (Byznys) služba Služba veřejné správy
Business object (Byznys) objekt Objekt VS
Contract Kontrakt
Representation Reprezentace
Product Produkt Produkt VS pro ŽS
Aplikační Application component (Aplikační) komponenta Aplikace
Application interface (Aplikační) rozhraní
Application collaboration(Aplikační) spolupráce
Application service (Aplikační) služba
Application function (Aplikační) funkce
Application interaction (Aplikační) interakce
Application process (Aplikační) proces
Application event (Aplikační) událost
Data object (Datový) objekt Logická data
Technologická Node Uzel
Communication network (Komunikační) síť Datová síť?
Device Zařízení
System software Systémový software
Technology collaboration (Technologická) spolupráce
Technology interface (Technologické) rozhraní
Path Cesta
Technology service (Technologická) služba
Technology function (Technologická) funkce
Technology process (Technologický) proces
Technology interaction (Technologická) interakce
Technology event (Technologická) událost
Artifact Artefakt Fyzická data
Fyzická Equipment Vybavení/Nástroj
Facility Budova
Distribution network Distribuční cesta
Material Materiál
Implementační a migrační Work package Balíček práce
Deliverable Předmět dodávky /plnění
Implementation event Implementační událost
Plateau Stav architektury
Gap Rozdíl
Kompozitní Grouping Seskupení
Location Lokace

Barevnost prvků v tabulce2) je 100% převzata z originální specifikace ArchiMate 3.1.

Přehled vazeb ArchiMate

Přehled a vysvětlení jednotlivých vazeb obsahuje následující tabulka3):

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ý4), 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ě).

 Základní redukovaný metamodel NA VC ČR v notaci ArchiMate.

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.

 Základní (redukovaný) výběr prvků metamodelu NA ze standardu ArchiMate 3.1 (bez specializovaných stereotypů).

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.

 Zjednodušený metamodel základních doporučených prvků

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 Map5).

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.

 Plný metamodel byznys vrstvy dle specifikace ArchiMate 3.1 (v souvislostech ostatních vrstev), zdroj: (The Open Group, 2017), překlad MV.

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.

 výběr ze specifikace byznys vrstvy dle ArchiMate 3.1, zdroj: (The Open Group, 2017), úprava MV.

 Minimální výběr z metamodelu byznys architektury dle ArchiMate 3.1, zdroj: (The Open Group, 2017), překlad MV.

Definice prvků metamodelu byznys architektury

Tabulka6) s definicemi prvků metamodelu byznys architektury

Název typu prvku Definice významu typu prvku Definice NAR
Byznys rozhraní A point of access where a business service is made available to the environment. Místo přístupu ke službám veřejné správy, také kontaktní místo nebo obslužný kanál (přepážky, CzechPOINT, Portál občana apod.)
Účastník/aktér A business actor is a business entity that is capable of performing behavior (ArchiMate).

A person, organization, or system that has one or more roles that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization (TOGAF).
Osoba, organizace nebo systém, který vystupuje v jedné nebo více rolích jako účastník aktivit (byznys funkcí, procesů nebo služeb).

Účastníky, aktéry, jsou všechny strany výkonu služby ve veřejné správě.
Role The responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event. (ArchiMate).

The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An actor may have a number of roles (TOGAF).
Role představuje přístup, resp. chování, konkrétní osoby nebo skupiny osob ve vztahu k výkonu služeb ve veřejné správě. Každá reálná osoba (aktér) vystupuje do, je aktivní v, jedné nebo více rolích, bere na sebe pro daný případ roli.

Obvyklá, nebo očekávaná funkce aktéra, nebo jeho části nebo cokoli hrající (účastníci se aktivně) v konkrétní akci nebo události.
Spolupráce (byznys) An aggregate of two or more business internal active structure elements that work together to perform collective behavior. Skupina nejméně dvou aktérů či rolí, kteří musí pracovat společně, aby mohli vykonat určité kolektivní chování.

Může nastat například při spolupráci více OVS na jedné službě.
Byznys funkce A collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), closely aligned to an organization, but not necessarily explicitly governed by the organization.. Funkce dodává business schopnosti. Funkce je úzce propojena s organizací (jejím členěním), ale není nezbytně touto částí organizace řízena / spravována.

Základní jednotka chování, konání úřadu, to, co musí úřad interně umět vykonávat, aby mohl vykonávat činnosti v agendě a poskytovat interní (v úřadu) i externí služby klientům.
Byznys proces A sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services (ArchiMate).

A process represents flow of control between or within functions and/or services (depends on the granularity of definition). Processes represent a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail).

Processes may also be used to link or compose organizations, functions, services, and processes (TOGAF).
Proces představuje specifický způsob řízení funkcí v jejich přesně daném pořadí.

Proces je tedy tvořen funkcemi a současně funkce (na jiné míře detailu je tvořena procesy.

Typickým výstupem procesu, tzv. procesním rozhraním je služba.
Událost /životní událost A business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization. Změna stavu, která je z procesního pohledu podstatná, může se vyskytnout vně nebo uvnitř organizace a vně nebo uvnitř organizace může být zpracována.
Interakce A unit of collective business behavior performed by (a collaboration of) two or more business roles. Jednotka kolektivního chování vykonávaná ve spolupráci dvou a více rolí.
Byznys služba veřejné správy An explicitly defined exposed business behavior (ArchiMate).

A service delivers or supports business capabilities through an explicitly defined interface and is explicitly governed by an organization (ie. has a SLA contract) - TOGAF.
Služba je specifickým způsobem řízení výkonu funkcí a procesů.

Podporuje podnikové dovednosti (business capabilities) prostřednictvím jednoznačně definovaného rozhraní a je jednoznačně formálně řízena organizací (například má SLA smlouvu).
Byznys objekt /

objekt práva
A concept used within a particular business domain. Byznys objekt je cokoli, co objektivně (hmotně i nehmotně) existuje v byznys doméně, je předmětem modelování a nehodí se pro to žádný specifický koncept BA.

Objekt je typicky pasivní, tj. je předmětem chování aktivních prvků (akterů a rolí), ve veřejné správě má mnoho společného s pojmem „objekt práva“, ale má širší význam.
Kontrakt A formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product (ArchiMate).

An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction (TOGAF).
Kontraktem (smlouvou) nazýváme jakoukoli formální nebo neformální dohodu mezi poskytovatelem a příjemcem služby, resp. celého produktu.

Produkty veřejné správy jsou upraveny zejména zákony, proto byl zaveden specializovaný typ prvků právní předpis, «Předpis», odvozený od kontraktu.

Pro řízení interních i externích služeb budou sloužit dohody o úrovni služeb (SLA7)).
Reprezentace A perceptible form of the information carried by a business object. Forma existence a možnosti vnímání byznys objektu a jeho informací, například eletronická, hlasová, listinná, materiální, apod.
Produkt VS pro ŽS A coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers (ArchiMate).

Output generated by the business. The business product of the execution of a process.
Produktem je kompozice výstupů byznysu, typicky služeb a zboží, doplněná o další součásti - pravidla, smlouvy a podmínky, data, nosiče a další.

Trendem VS bude transformovat povinnosti úředníků do podoby služeb nebo dokonce produktů veřejné správy, kompletně řešících životní situaci klienta.
«Agenda» Nemá, viz byznys funkce Ucelená oblast působnosti orgánu veřejné moci nebo ucelená oblast působení soukromoprávního uživatele údajů.

Je unikátně evidována v RPP.

Odpovídá široce pojaté byznys funkci, ale pro svébytné postavení ve VS ČR bude modelována jako specializovaný stereotyp.
«Agendová činnost » Nemá, viz byznys funkce Dílčí část agendy, opět odpovídá byznys funkci, alternativně i pro ni je navržen specializovaný stereotyp.

Je evidována v RPP.
«Organizace» Nemá, viz aktér (ArchiMate).

A self-contained unit of resources with goals, objectives, and measures. Organization units may include external parties and business partner organizations (TOGAF).
TOGAF na rozdíl od ArchiMate obsahuje samostatný typ prvku i pro aktéra v podobě osoby.

Zavedením specializovaného stereotypu pro právnické osoby se uvolní prostor používání typu aktér výhradně pro fyzické neboli přirozené osoby.
«Útvar» Nemá, viz aktér. Samostatně neexistující dílčí organizační jednotka úřadu (sekce, odbor, oddělení, skupina, tým, atp.)

Pro rozlišení od osob nadaných právní subjektivitou (fyzické/přirozené a právnické) může být vhodné využívat tento specializovaný stereotyp pro kolektivní aktéry bez vlastní subjektivity, součásti organizace.

Interpretace 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 aktivity8). 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.

 Metamodel datové architektury NAR

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.

 Plný metamodel vrstvy IS dle specifikace ArchiMate 3.1, zdroj: (The Open Group, 2017), překlad MV

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:

 výběr ze specifikace vrstvy IS dle ArchiMate 3.1, zdroj: (The Open Group, 2017), úprava MV

Definice prvků metamodelu aplikační architektury

Tabulka9) s definicemi prvků metamodelu aplikační architektury

Název typu prvku Definice typu prvku Definice NAR
Aplikační komponenta 1) An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces (ArchiMate).

2) An application is a deployed and operational IT system that supports business functions and services. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application (TOGAF 9.1).
1) Aplikační komponenta je zapouzdření funkcionality v souladu se strukturou implementace, která je modulární a vyměnitelná. Zapouzdřuje své chování a data, nabízí své služby a dává je k dispozici prostřednictvím rozhraní.

2) Aplikační komponenta je nainstalovaný a zprovozněný IT systém, který podporuje business funkce a služby. Aplikace používají data a jsou tvořeny technologickými komponentami.
Aplikační rozhraní A point of access where application services are made available to a user, another application component, or a node. Aplikační rozhraní je místo, kde jsou aplikační služby dostupné pro uživatele, jiné aplikace nebo technologické uzly.
Aplikační spolupráce An aggregate of two or more application components that work together to perform collective application behavior. Seskupení dvou a více aplikačních komponent, které pracují společněpro poskytnutí kolektivního aplikačního chování.

Aplikační spoluprací jsou takové skupiny integrovaných komponent, které nemohou poskytnout službu pro byznys funkci, pokud některá z komponent bude mimo provoz nebo nefunkční či nedostupná.
Aplikační služba An explicitly defined exposed application behavior (ArchiMate).

The automated elements of a business service. An information system service may deliver or support part or all of one or more business Services (TOGAF).
Aplikační službou je takové chování aplikace (funkce nebo interakce), které je dáno k dispozici uživatelům a je explicitně jako služba řízeno.

Aplikační služby jsou součástí digitálních služeb veřejné správy, realizují je.
Aplikační funkce Automated behavior that can be performed by an application component. Schopnost aplikace poskytnout podporu konkrétní byznys funkci nebo procesu. Aplikační funkce je vždy obsažena v nějaké aplikační komponentě a může být byznys funkci či procesu poskytována jako aplikační služba.
Aplikační interakce An application interaction represents a unit of collective application behavior performed by (a collaboration of) two or more application components. Aplikační interakcí je takové chování, které může být vykonáno výhradně ve spolupráci dvou a více aplikačních komponent.
Aplikační proces A sequence of application behaviors that achieves a specific outcome. Aplikační proces představuje aplikační chování (funkce nebo interakce), které jsou řízeny specificky ve svém pevném pořadí (automatizovaně).
Aplikační událost An application behavior element that denotes a state change. Prvek chování aplikace, který označuje změnu stavu.
Datový objekt Data structured for automated processing.
«Informační systém»

Interpretace 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í.

Specializace konceptů aplikační architektury

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říklad rozšíření metamodelu aplikační architektury, zdroj MV dle podkladů MZe ČR.

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á10), 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 komponentami modelovat i objekty SW licence.

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.

 Plný metamodel technologické architektury

 redukovaný výběr ze specifikace technologické vrstvy dle ArchiMate 2.1, zdroj: (The Open Group, 2017), úprava MV

Definice prvků metamodelu technologické architektury

Tabulka11) s definicemi prvků metamodelu technologické architektury

Název typu prvku Definice významu typu prvku Definice NAR
Uzel A computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources. Výpočetní technologický uzel je počítačový nebo fyzický zdroj, který hostuje, manipuluje nebo interaguje s jinými výpočetními nebo fyzickými zdroji.
Komunikační síť A set of structures and behaviors that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video.Sada struktur a chování, které spojují počítačové systémy nebo jiná elektronická zařízení pro přenos, směrování a příjem dat nebo datové komunikace, jako je hlas a video.
Zařízení A physical IT resource upon which system software and artifacts may be stored or deployed for execution. Fyzický IT prostředek, na kterém lze systémový software a artefakty uložit nebo zavést k provedení.
Systémový software Software that provides or contributes to an environment for storing, executing, and using software or data deployed within it. Software, který poskytuje nebo přispívá k prostředí pro ukládání, spouštění a používání softwaru nebo dat v něm nasazených.
Technologická spolupráceAn aggregate of two or more nodes that work together to perform collective technology behavior. Souhrn dvou nebo více uzlů, které spolupracují při provádění kolektivního technologického chování.
Technologické rozhraní A point of access where technology services offered by a node can be accessed. Místo přístupu, kde lze přistupovat k technologickým službám nabízeným uzlem.
Cesta A link between two or more nodes, through which these nodes can exchange data or material. Spojení mezi dvěma nebo více uzly, prostřednictvím kterého si tyto uzly mohou vyměňovat data nebo materiál.
Technologická služba An explicitly defined exposed technology behavior (ArchiMate).

A technical capability required to provide enabling infrastructure that supports the delivery of applications (TOGAF).
Explicitně definované chování exponované technologie (ArchiMate).

Technická schopnost vyžadovaná k zajištění aktivační infrastruktury, která podporuje dodávání aplikací (TOGAF).
Technologická funkce A collection of technology behavior that can be performed by a node. Souhrn technologického chování, které může provádět uzel.
Technologický proces A sequence of technology behaviors that achieves a specific outcome. Posloupnost technologického chování, které dosahuje konkrétního výsledku.
Technologická interakce A unit of collective technology behavior performed by (a collaboration of) two or more nodes. Jednotka kolektivního technologického chování prováděná ve spolupráci dvou nebo více uzlů.
Technologická událost A technology behavior element that denotes a state change. Prvek technologického chování, který označuje změnu stavu.
Artefakt A piece of data that is used or produced in a software development process, or by deployment and operation of a system. Část dat, která se používají nebo vytvářejí v procesu vývoje softwaru nebo nasazením a provozováním systému.
Technologická komponentaAn encapsulation of technology infrastructure that represents a class of technology product or specific technology product (TOGAF only). Modeluje se jako Uzel (ArchiMate)

Interpretace 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.

 Metamodel fyzické infrastruktury.

Definice prvků metamodelu fyzické architektury

V tabulce12) 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.

Název typu prvku Definice typu prvku Definice NAR
Vybavení/

Nástroj
One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.Jeden nebo více fyzických strojů, nebo nástrojů, které mohou vytvářet, používat, ukládat, přesouvat nebo transformovat materiály.

Pro NAR zejména ne-IT aktivní technologické prvky (nábytek, regály apod.)
Budova A physical structure or environment. Fyzická struktura nebo prostředí.

Pro NAR zejména budovy (například datových center) a stavební a vybavovací technologie (výtahy, klimatizace,..).
Distribuční cesta A physical network used to transport materials or energy. Fyzická síť používaná k přepravě materiálů nebo energie.
Materiál Tangible physical matter or physical elements. Hmatatelná fyzická látka nebo fyzikální prvky.

Interpretace metamodelu komunikační a fyzické architektury

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

Specializace prvků metamodelu komunikační infrastruktury

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.

 návrh specializace objektů technologické vrstvy ArchiMate pro komunikační infrastrukturu, zdroj: MV s využitím (The Open Group, 2017)

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 TOGAF13) a tzv. motivační a strategickou14) 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.

 Plný metamodel strategické motivační architektury.

 redukovaný výběr ze specifikace motivačního a strategického rozšíření ArchiMate 3.1, zdroj: (The Open Group, 2017), úprava MV

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).

Definice prvků metamodelu architektury strategie a směřování

Tabulka15) s definicemi prvků metamodelu architektury strategie a směřování

Název typu prvku Definice typu prvku Definice NAR
Zainteresovaný The role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture. Jednotlivec, tým nebo organizace, která má zájem na přínosu architektury.
Motivátor, vliv An external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them. Externí nebo interní vlivy, které motivují organizaci k definování cílů a k implementaci změn pro jejich dosažení.
Zhodnocení vlivu The result of an analysis of the state of affairs of the enterprise with respect to some driver. Výsledek analýzy stavu úřadu vzhledem k dopadu určitého motivátoru.
Strategický cíl A high-level statement of intent, direction, or desired end state for an organization and its stakeholders (ArchiMate).

A high-level statement of intent or direction for an organization. Typically used to measure success of an organization (TOGAF).
Formulace zájmu, směru nebo cílového stavu na vysoké strategické úrovni používaný ke sjednocení přístupu organizace a zainteresovaných. Typicky se užívají k měření úspěchu organizace.
Výstup / Výsledek An end result that has been achieved. Konečný výsledek, kterého má být dosaženo pro naplnění strategického cíle.
Princip A qualitative statement of intent that should be met by the architecture (ArchiMate).

A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance (TOGAF).
Kvalitativní tvrzení, které by mělo být naplněno implementovanou architekturou. Princip obsahuje zdůvodnění a míru důležitosti.
Požadavek A statement of need that must be met by the architecture (ArchiMate).

A quantitative statement of business need that must be met by a particular architecture or work package (TOGAF).
Vyjádření potřeby, která musí být naplněna cílovou architekturou.
Omezení A factor that prevents or obstructs the realization of goals. Faktor, který brání nebo ztěžuje realizaci cílů.
Význam The knowledge or expertise present in, or the interpretation given to, a core element in a particular context. Znalost nebo odbornost obsažené v základním prvku architektury nebo jeho interpretace v konkrétním kontextu.
Hodnota The relative worth, utility, or importance of a core element or an outcome. Relativní hodnota, užitečnost nebo důležitost základního prvku nebo výsledku.
«Cíl, úkol»

(Objective)
A time-bounded milestone for an organization used to demonstrate

progress towards a goal (TOGAF only)
Časově ohraničený milník (úkol) pro organizaci sloužící k prokázání pokroku směrem k cíli (zatím pouze TOGAF).
Směr změny An approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve a goal (ArchiMate).

Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model (TOGAF).
Přístup nebo plán (iniciativa) pro zlepšení vybraných schopností a zdrojů organizace za účelem dosažení strategického cíle.
Schopnost An ability that an active structure element, such as an organization, person, or system, possesses (ArchiMate).

A particular ability that a business may possess or exchange to achieve a particular purpose. A business-focused outcome that is delivered by the completion of one or more work packages. (TOGAF).
Schopnost organizace nebo jejích částí vytvářet hodnotné výstupy.
Zdroj An asset owned or controlled by an individual or organization. Majetek ve vlastnictví nebo pod kontrolou jednotlivce nebo organizace.
Hodnotový řetězec A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user (TOGAF only). Reprezentace komplexní kolekce činností s přidanou hodnotou, které vytvářejí celkový výsledek pro zákazníka, zainteresovaného nebo koncového uživatele (zatím pouze TOGAF).

Interpretace 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í16)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 (KGI17), KPI18) (zejména TCO19)), PPI20), 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:

 Logický rámec výkonnosti, kvality a zodpovědnosti, zdroj: upraveno 2016 podle (Hrabě, 2013).

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.

Definice prvků metamodelu architektury výkonnosti

Tabulka21) s definicemi prvků metamodelu architektury výkonnosti

Název typu prvku Definice typu prvku Definice NAR
«Metrika»

(Measure)
An indicator or factor that can be tracked, usually on an ongoing basis, to determine success or alignment with objectives and goals (TOGAF only).Ukazatel nebo faktor, který lze sledovat, obvykle průběžně, k určení úspěchu nebo souladu s cíli a cíli (pouze TOGAF).
«Kvalita služby»

(Service Quality)
A preset configuration of non-functional attributes that may be assigned to a service or service contract (TOGAF only). Přednastavená konfigurace nefunkčních atributů, které mohou být přiřazeny ke smlouvě o službě nebo službě (pouze TOGAF).
Ukazatel výkonnosti PI, KPI, PPI Není obsažen v jazyce ArchiMate
Znak kvality Není obsažen v jazyce ArchiMate
Nejakost Není obsažen v jazyce ArchiMate
Opatření

Interpretace 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

 Doménový model ISSRM, zdroj: The Open Group (Band, et al., 2015)

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:

 Metamodel bezpečnostní architektury v ArchiMate, zdroj: The Open Group (Band, et al., 2015)

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ích22) prvků architektury úřadu je nezbytným předpokladem a vstupem její bezpečnostní architektury.

Přehled potřebných prvků bezpečnostní architektury a jejich lokalizace

Tabulka23) s definicemi prvků metamodelu bezpečnostní architektury

Původní název Generický překlad
Threat Hrozba/ohrožení
Threat agent / actorProstředek/aktér hrozby/ohrožení
Threat event Událost hrozby/ohrožení
Loss event Událost ztráty
Risk/security driverBezpečnostní motivátor/vliv
Risk Riziko
Vulnerability Zranitelnost
Control objective Kontrolní cíl
Security principle Bezpečnostní princip
Control measure Opatření
Security domain Bezpečnostní doména

Definice prvků metamodelu bezpečnostní architektury

Tabulka24) s definicemi prvků metamodelu bezpečnostní architektury

Název typu prvku Definice typu prvku Definice NAR
Hrozba/Ohrožení A Threat is a negative scenario you want to avoid. Hrozbu/ohrožení lze považovat za negativní scénář, kterému se chcete vyhnout.
Prostředek hrozby /ohrožení The term Threat Agent is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company.

The the person, actor, entity, or organization that is initiating the given threat scenario.

Threat agent is modeled with the business actor construct, but other active structure element can be used (e.g. business role, application component, etc.)
Pojem „Prostředek hrozby/ohrožení“ se používá k označení jednotlivce nebo skupiny, která může znamenat hrozbu. Je zásadní určit, kdo by mohl chtít využít aktiv organizace, a jak by je mohl použít proti ní.

Osoba, aktér, entita nebo organizace, která spouští daný scénář hrozby.

„Prostředek hrozby/ohrožení“ je modelován pomocí typu prvku „byznys aktér“, ale lze použít i jiný aktivní prvek struktury (např. byznys role, aplikační komponenta atd.)
Událost znamenající hrozbu /ohroženíA Threat (event) is a negative event that can lead to an undesired outcome, such as damage to, or loss of, an asset. Threats can use—or become more dangerous because of—a vulnerability in a system.

Threat event (event with the potential to adversely impact an asset) as well as loss event (any circumstance that causes a loss or damage to an asset) are modeled with the business event construct and are considered as a specialization of it.
Hrozba/ohrožení (událost) je negativní událost, která může mít nežádoucí dopad, jako jsou např. škody na majektu či jeho ztráta. Útočník může využít zranitelnost systému a díky této zranitelnosti může být hrozba/ohrožení ještě nebezpečnější

Událost znamenající hrozbu/ohrožení (tj. událost s potenciálem nepříznivého dopadu na aktivum) i událost ztráty (jakákoli okolnost, která způsobí ztrátu nebo poškození aktiva) jsou modelovány pomocí typu prvku byznys událost, resp. jeho specializace.
Událost ztráty A Loss Event is a circumstance that produces the loss and harm impacts from actual events and reflect the organisation's own experience. “Událost ztráty“ je okolnost, která způsobí ztrátu nebo škody a odráží vlastní zkušenosti organizace.
Bezpečnostní motivátor /vliv Risk / security driver are the criteria by which risks are analyzed and are represented with the driver construct. Bezpečnostní motivátor /vliv jsou kritéria, podle nichž jsou analyzována rizika. Je reprezentován prvkem typu motivátor.
Riziko A chance of something bad happening combined with how bad it would be if it happened. A Risk is a negative scenario you want to avoid, essentially the combination of its Probability and Impact.

Risk is also modeled with the assessment construct and considered as a specialization of it.
Pravděpodobnost, že dojde k něčemu nežádoucímu. Riziko je negativní scénář, kterému se chce organizace vyhnout. Jedná se o kombinaci jeho pravděpodobnosti a dopadu.

Riziko je modelováno pomocí typu prvku „hodnocení“ a je považováno za jeho specializaci.
Zranitelnost Vulnerabilities are simply weaknesses in the system, vulnerabilities are what make Threats possible and/or more significant.

Vulnerability is modeled as a specialization of an assessment in the ArchiMate language, because considered as the result of analyzing the weaknesses of elements in the architecture.
Zranitelnosti představují slabiny v systému, jsou tím, co způsobuje, že jsou hrozby možné nebo jsou významnější.

Zranitelnost je modelována pomoci specializace typu prvku Zhodnocení vlivu, protože je považována taktéž za výsledek analýzy slabin prvků architektury.
Kontrolní cíl Risk control objective and security control objective are specialization of the objective construct and aim at mitigating risks. They are designed from risks and risk/security drivers and further refined through security requirement and principle. Kontrolní cíle rizik a bezpečnosti jsou specializací typu prvku cíl, jejich úkolem je zmírňovat rizika. Jsou zpřesňovány pomocí specializovaných typů prvků bezpečnostní princip a bezpečnostní požadavek.
Bezpečnostní princip Security principle is considered here as a synonym of security policy and is modeled with the principle construct. Bezpečnostní princip je zde považován za synonymum bezpečnostní politiky a je modelován s pomocí typu prvku princip.
Opatření Security requirement and control measure are two specializations of the requirement construct, a control measure being more specific (i.e. close to the implementation) than a security requirement. Bezpečnostní požadavek a kontrolní opatření jsou dvě specializace typu prvku požadavek, přičemž kontrolní opatření je specifičtější (tj. blíže implementaci) než bezpečnostní požadavek

Interpretace 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 CSR25).

Metamodel shody s předpisy

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:

 Metamodel shody s předpisy

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.

Metamodel architektury standardizace

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:

 Metamodel architektury standardizace

Metamodel architektury dlouhodobé udržitelnosti

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.

Interpretace metamodelu architektury shody s předpisy, standardizace a dlouhodobé udržitelnosti

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í.

 Metamodel implementačního rozšíření dle specifikace ArchiMate 2.1, zdroj: (The Open Group, 2017), úprava MV

Definice prvků metamodelu architektury implementace a migrace

Tabulka26) s definicemi metamodelu architektury implementace a migrace

Název typu prvku Definice významu typu prvku Definice NAR
Balíček práce A series of actions identified and designed to achieve specific results within specified time and resource constraints (ArchiMate).

A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program (TOGAF).
Řada akcí identifikovaných a navržených k dosažení konkrétních výsledků pro naplnění jednoho nebo více cílů podniku, v rámci stanovených časových a zdrojových omezení Pracovní balíček může být součástí projektu, celým projektem nebo programem.
Předmět dodávky /plněníA precisely-defined outcome of a work package. Přesně (formálně, smluvně) definovaný výsledek pracovního balíčku.
Implementační událost A behavior element that denotes a state change related to implementation or migration. Prvek chování, který označuje změnu stavu související s implementací nebo migrací.

Typicky jde o klíčové milníky implementace.
Stav architektury A relatively stable state of the architecture that exists during a limited period of time. Relativně stabilní stav architektury, který existuje po omezenou dobu.

Přechodový (tranzitní) stav (Plateau) architektury, je takový stav, ve kterém byly dokončeny plánované architektonické změny a architektura opět přináší byznys hodnotu.
Rozdíl/nedostatek A statement of difference between two plateaus (ArchiMate).

A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified (TOGAF).
Vyjádření rozdílu mezi stávající a cílovou (nebo přechodovou) architekturou.

Interpretace 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.

Definice kompozitních prvků metamodelu architektury

Tabulka27) s definicemi kompozitních prvků metamodelu architektury

Název typu prvkuDefinice typu prvku Definice NAR
Seskupení The grouping element aggregates or composes concepts that belong together based on some common characteristic.Prvek seskupování agreguje nebo komponuje prvky, které patří k sobě na základě nějaké společné charakteristiky.
Umístění/Lokace A location is a place or position where structure elements can be located or behavior can be performed. Místo je místo nebo pozice, kde mohou být umístěny strukturní prvky, nebo může být provedeno chování.

Interpretace kompozitních prvků metamodelu

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é.

Definice obecných prvků metamodelu architektury

Tabulka s definicemi obecných prvků metamodelu architektury.

Název typu prvku Definice typu prvku Definice NAR
Služba

(Service)
An element of behavior that provides specific functionality in response to requests from actors or other services. A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed. Services are defined for business, information systems, and platforms (TOGAF).Prvek chování, který poskytuje specifickou funkčnost v reakci na požadavky aktérů nebo jiných služeb.

Služba poskytuje nebo podporuje byznys schopnosti, má explicitně definované rozhraní a je explicitně řízena. Služby jsou definovány pro byznys, informační systémy a platformy.
Datová entita

(Data entity)
An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations (TOGAF only). Zapouzdření dat o něčem, co odborník na byznys doménu považuje za věc.

Logické datové entity mohou být spojeny s aplikacemi, úložišti a službami a mohou být strukturovány podle implementačních úvah.
Předpoklad

(Assumption)
A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example, it may be assumed that an existing application will support a certain set of functional requirements, although those requirements may not yet have been individually validated (TOGAF only). Prohlášení o pravděpodobné skutečnosti, která nebyla v této fázi v důsledku vnějších omezení plně ověřena. Lze například předpokládat, že stávající aplikace bude podporovat určitý soubor funkčních požadavků, i když tyto požadavky ještě nebyly individuálně validovány.

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.

Doporučené příklady vazeb

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

 Doporučené příklady vazeb mezi objekty modelu v jazyce ArchiMate.

Kompozice

Kompozici je možné vyjádřit jak mimo komponovaný prvek, tak i zanořením (hnízdovým diagramem28). 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.

 Příklady kompozitních vazeb.

Agregace

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í.

 Příklady agregačních vazeb.

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ě implementovatelnou29) 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í

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í.

 Příklady vazby přiřazení.

Realizace

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í).

 Příklady vazby realizace.

Slouží / obsluhuje

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říklady vazby slouží/obsluhuje.

Přístup

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.).

 Příklad přístupové vazby.

Ovlivnění

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.

 Příklad vazby ovlivňuje.

Asociace

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

 Příklad vazby asociace / souvislost.

Nedoporučené příklady vazeb

Vazba agregace a kompozice

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říklad problematické vazby aplikačních komponent.

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:

Název typu atributu Definice významu typu atributu
Sada: Stereotyp
Stereotyp
Sada: Identifikace prvku
Lokální ID prvku v modelu
Globální ID prvku v modelu
Lokální ID prvku v primární evidenci OVS Například inventární číslo v EkIS
Globální ID prvku v primární evidenci státuPokud na centrální úrovni VS ČR (EU) existuje, například číslo ze základních registrů z ISoISVS apod.
Sada: Obecný popis
Zkratka (kód) prvku
Název prvku
Popis prvku
Vlastník prvku
Stav prvku v modelu
Sada: Klasifikace prvku
Viz další části a samostatná Příloha č. 2.
Sada: Standardizace prvku
Standard Ano/Ne
Datum prohlášení standardu
Datum posledního přezkoumání standardu
Datum plánovaného přezkoumání standardu
Datum opuštění standardu
Vlastník standardu
Sada: životní cyklus prvku
Ve vývoji/ přípravě
Přechodná architektura
Datum od
Stav Ano/Ne
V užití
Po užití (výběhový)
Zastaralý

Práce s atributy v jednotlivých nástrojích modelování architektury, jejich přenos ve standardním formátu TOGAMEFF30) 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.

Vysvětlení pojmů Dodaný výstup architektury, Artefakty a Stavební bloky, zdroj: TOGAF (The Open Group, 2018), překlad MV.

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.

Přehled výstupů architektury a jejich lokalizace

První tabulka31) představuje jejich původní název, generický překlad a specifický název pro NAR:

Původní název Generický překlad Úprava pro NAR
Dodatelné výstupy dle TOGAFArchitecture Building Blocks Stavební blok architektury
Architecture Contract Architektonická smlouva
Architecture Definition Document Definiční dokument architektury Model architektury úřadu
Architecture Principles Architektonické principy
Architecture Repozitory Architektonické úložiště
Architecture Requirements Specification Specifikace architektonických požadavků
Architecture Roadmap Plán realizace architketury
Architecture Vision Architektonická vize
Business Principles, Business Goals and Business DriversByznys motivátory, cíle a principy
Capability Assessment Posouzení schopností
Change Request Změnový požadavek
Communications Plan Komunikační plán
Compliance Assessment Posouzení shody
Implementation and Migration Plan Plán implementace a migrace
Implementation Governance Model Model dohledu na implementaci
Organizational Model for Enterprise Architecture Organizační model pro EA
Request for Architecture Work Požadavek na architektonickou práci
Requirements Impact Assessment Posouzení dopadů požadavků
Solution Building Blocks Stavební blok řešení
Statement of Architecture Work Zadání architektonické práce
Tailored Architecture Framework Přizpůsobený architektonický rámec
Informační koncepce OVS
Žádost o stanovisko OHA

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.

Definice výstupů architektury

Druhá tabulka32) přináší vysvětlení významu a úlohy dokumentů:

Název typu výstupu Definice typu výstupu Význam pro NAR
Stavební blok architektury A constituent of the architecture model that describes a single aspect of the overall model. Složka modelu architektury, která popisuje jeden aspekt celkového modelu.
Architektonická smlouva Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture.

Successful implementation of these agreements will be delivered through effective Architecture Governance.
Smlouvy o architektuře jsou společné dohody mezi vývojovými partnery a sponzory o dodávkách, kvalitě a vhodnosti architektury.

Úspěšné provádění těchto dohod bude dosaženo prostřednictvím účinné správy architektury a dohledu na ni.
Definiční dokument architektury The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). Dokument definice architektury je kontejner pro hlavní architektonické artefakty vytvořené během projektu a pro důležité související informace. Dokument definice architektury zahrnuje všechny domény architektury (byznys, data, aplikace a technologie) a také zkoumá všechny relevantní stavy architektury (výchozí stav, přechod a cílový stav).
Architektonické principy Set of generic Architecture Principles, including:

■ Business principles

■ Data principles

■ Application principles

■ Technology principles
Sada obecných principů architektury, včetně:

■ byznys principů,

■ datových principů,

■ aplikačních principy,

■ technologických principů.
Architektonické úložiště The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties. Repozitář architektury slouží jako prostor pro všechny projekty související s architekturou v rámci podniku. Úložiště umožňuje projektům spravovat jejich výstupy, lokalizovat opakovaně použitelná aktiva a publikovat výstupy zúčastněným stranám a dalším zájemcům.
Specifikace architektonických požadavkůThe Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.

As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective.
Specifikace požadavků na architekturu poskytuje sadu kvantitativních prohlášení, která naznačují, co musí implementační projekt udělat, aby byl v souladu s architekturou. Specifikace požadavků na architekturu bude obvykle tvořit hlavní součást prováděcí smlouvy nebo smlouvy pro podrobnější definici architektury.

Jak je uvedeno výše, specifikace požadavků na architekturu je doprovodným dokumentem k definičnímu dokumentu architektury.
Plán realizace architektury The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. Plán realizace architektury (Roadmapa) uvádí jednotlivé pracovní balíčky, které realizují cílovou architekturu, a stanoví je na časové ose, aby ukazovaly postup od výchozí architektury k cílové architektuře. Plán architektury zdůrazňuje hodnotu jednotlivých pracovních balíčků pro úřad v každé fázi. Architektury přechodu, nezbytné k efektivní realizaci cílové architektury, jsou identifikovány jako přechodné kroky.
Architektonická vize The Architecture Vision provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.

The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome.
Architektonická vize poskytuje shrnutí změn v podniku, které vzniknou z úspěšného nasazení cílové architektury.

Účelem architektonické vize je poskytnout klíčovým zúčastněným stranám formálně dohodnutý výsledek.
Byznys motivátory, cíle a principy Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. Byznys principy, cíle a motivátory poskytují kontext pro práci na architektuře tím, že popisují potřeby a způsoby práce zavedené v úřadu.
Posouzení schopností Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise.

Typical contents of a Capability Assessment are:

■ Business Capability Assessment

■ IT Capability Assessment

■ Architecture maturity assessment.
Před zahájením podrobné definice architektury je užitečné porozumět výchozí a cílové úrovni schopností podniku.

Typickým obsahem posouzení způsobilosti je:

■ Posouzení byznys schopnosti

■ Posouzení schopnosti IT

■ Posouzení zralosti architektury.
Změnový požadavek During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution.

Change Request may be submitted in order to kick-start a further cycle of architecture work.
Během implementace architektury se mohou objevit další skutečnosti, které způsobí, že původní definice a požadavky architektury nejsou vhodné nebo nejsou dostatečné k dokončení implementace řešení.

Za účelem zahájení dalšího cyklu architektonických prací lze podat žádost o změnu.
Komunikační plán Enterprise Architectures contain large volumes of complex and inter-dependent information.

Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.
Architektury úřadů obsahují velké množství komplexních a vzájemně závislých informací.

Efektivní komunikace cílených informací správným zúčastněným stranám ve správný čas je kritickým faktorem úspěchu (CSF) pro architekturu úřadu.

Vývoj komunikačního plánu pro architekturu umožňuje tuto komunikaci provádět v rámci plánovaného a řízeného procesu.
Posouzení shody Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Periodic Compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives. Jakmile je architektura definována, je nutné tuto architekturu řídit a dohůlížet na průběh implementace, aby bylo zajištěno, že původní Vize architektury je náležitě realizována a že veškeré poznatky o implementaci jsou vráceny zpět do procesu architektury. Pravidelné kontroly prováděcích projektů poskytují mechanismus pro přezkoumání postupu projektu a zajištění toho, aby návrh a implementace pokračovaly v souladu se strategickými a architektonickými cíli.
Plán implementace a migrace The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. Plán implementace a migrace poskytuje plán projektů, které realizují cílovou architekturu. Plán implementace a migrace zahrnuje spustitelné projekty seskupené do spravovaných portfolií a programů.
Model dohledu na implementaci Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation.

The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance.
Jakmile je architektura definována, je nutné naplánovat, jak bude prováděn dohled na průběh implementace architektury.

Model dohledu na implementaci současně zajišťuje, že s přechodem projektu do implementace přechází do odpovídajícího dohledu na architekturu.
Organizační model pro EA In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different Enterprise Architecture practitioners and the governance relationships that span across these boundaries. Aby mohl být architektonický rámec úspěšně používán, musí být podporován správnou organizací, rolemi a povinnostmi v rámci úřadu.

Zvláštní význam má definice hranic mezi různými odborníky v oblasti architektury úřadu a vztahy správy a řízení, které přesahují tyto hranice.
Požadavek na architektonickou práci This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Toto je dokument, který je odeslán ze sponzorující organizace do útvaru architektury, aby spustil začátek cyklu vývoje architektury.
Posouzení dopadů požadavků A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes. Posouzení dopadů (nových) požadavků posoudí současné požadavky na architekturu a specifikaci za účelem identifikace změn, které by měly být provedeny, a důsledků těchto změn.
Stavební blok řešení Detailed description of candidate solution which conforms to the specification of an Architecture Building Block (ABB). Podrobný popis kandidátního řešení, které odpovídá specifikaci Stavebního bloku architektury (ABB).
Zadání architektonické práce The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services. Zadání definuje rozsah a přístup, které budou použity k dokončení cyklu vývoje architektury.

Zadání architektonické práce je obvykle dokumentem, podle kterého bude měřeno úspěšné provedení projektu architektury, a může tvořit základ pro smluvní dohodu mezi zadavatelem a dodavatelem architektonických služeb.
Přizpůsobený architektonický rámec Before the TOGAF framework can be effectively used within an architecture project, tailoring at two levels is necessary.

1) to tailor the TOGAF model for integration into the enterprise.

2) to tailor the framework for the specific architecture project.
Před tím, než lze rámec TOGAF efektivně využít v rámci architektonického projektu, je nezbytné přizpůsobení na dvou úrovních:

1) přizpůsobit model TOGAF pro integraci do úřadu,

2) přizpůsobit rámec pro konkrétní projekt architektury.

Interpretace výstupů architektury

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

Hlediska33) 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 34) 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:

 Klasifikace hledisek dle jazyka ArchiMate 2.1, zdroj: (The Open Group, 2017), překlad MsK

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:

 Přehled vztahu zainteresovaných, jejich zájmů a jejich pohledů na model, zdroj: P. Klučka, projekt MPO.

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 Zachman35) nebo z nejlepší praxe rámců jiných států, například GEA-NZ Nového Zélandu36).

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í (AoG37)), 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.

Hlediska převzatá z TOGAF

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

Hlediska převzatá z ArchiMate

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é) mapy39). 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é.

Hlediska převzatá z rámce Zachman

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.

Aktuálně doporučovaná hlediska NAR

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 (EIRA40)), 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.

 Přehled základních hledisek (definic pohledů) Národní architektury VS ČR, zdroj: MV ČR

 Přehled hledisek referenční architektury EIRA, zdroj: ISA2, překlad MV

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 ACF41), 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í úřadu42), 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 Přehledu služeb čtyřvrstvé architektury

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.

 Metamodel hlediska Přehledu čtyřvrstvé architektury, zdroj MV s využitím (The Open Group, 2017)

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

Úvodní hledisko

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

 Příklad možného znázornění úvodního hlediska, zdroj: (The Open Group, 2017) http:%%%%pubs.opengroup.org/architecture/archimate2-doc/ts_archimate_2.1_files/image131.png

Hledisko vrstev architektury

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.

Zjednodušené hledisko vrstev architektury

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:

 Příklad pohledu vrstev, zdroj: pilotní projekt MsK

Hledisko přehledu schopností úřadu

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.

 Metamodel hlediska přehled schopností úřadu (základní).

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.

 Kompletní metamodel hlediska schopností úřadu.

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.

 (Zástupný) příklad pohledu Přehled schopností, zdroj: Marc Lankhorst, Blog.

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 Map43) 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í.

 (Zástupný) příklad pohledu Přehled schopností, využitého jako Heat Map IT podpory, zdroj: Marc Lankhorst, Blog.

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í.

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

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.

 Metamodel motivačního hlediska, zdroj: (The Open Group, 2017), překlad MV

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

  • Katalog zainteresovaných stran44)
  • Katalog motivátorů45) a potřeb
  • Katalog strategických cílů46), proveditelných úkolů47) a jejich měřítek splnění
  • Katalog architektonických principů
  • Katalog klíčových architektonických požadavků48) 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ů

Hlediska architektury výkonnosti

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árnosti49) čerpání zdrojů pro veřejnou službu
    • Zvýšení účinnosti50) práce zdrojů při tvorbě výstupů
    • Zvýšení účelnosti51) 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.

Hlediska architektury bezpečnosti

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ů (PSA52)) 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.

Hlediska architektury shody s pravidly, standardizace a udržitelnosti

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

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í.

 Definice hlediska funkcí veřejné správy, zdroj: MV s využitím ArchiMate 2.1 a 3.1 (The Open Group, 2017)

Hledisko spolupráce aktérů

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

 Definice hlediska spolupráce aktérů, zdroj: MV s využitím ArchiMate 2.1 (The Open Group, 2017)

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ů

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

 Definice hlediska spolupráce byznys procesů dle specifikace ArchiMate 2.1, zdroj: (The Open Group, 2017), překlad MV

Hledisko organizační struktury

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.

 Metamodel organizačního hlediska dle specifikace ArchiMate 2.1, zdroj: (The Open Group, 2017), překlad MV

Příklad:

 Příklad organizačního pohledu, zdroj: pilotní projekt MsK

Produktové hledisko

 Metamodel procesního hlediska dle specifikace ArchiMate 2.1, zdroj: (The Open Group, 2017), překlad MV

Hledisko portfolia byznys funkcí a služeb (Mapa)

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í“.

 Metamodel hlediska portfolia byznys funkcí a služeb (Mapa)

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.

Hledisko struktury informací

 Metamodel hlediska struktury informací.

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.

Hledisko struktury aplikací

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.

 Metamodel definice pohledu struktury aplikací

Hledisko chování aplikací

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.

 Metamodel hlediska chování aplikací

Příklad:

 Příklad pohledu chování aplikací, zdroj: pilotní projekt MsK

Hledisko spolupráce aplikací

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.

 Metamodel hlediska spolupráce aplikací

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

 Příklad pohledu spolupráce aplikací (bez objektu rozhraní), zdroj: pilotní projekt MsK

 Příklad zcela zjednodušeného hlediska spolupráce aplikací, zdroj: Bernd Ihnen, [[https://bizzdesign.com/blog/practical-archimate-viewpoints-for-the-application-layer/|Blog]].

Hledisko využití aplikací

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.

 Metamodel hlediska využití aplikací

Příklad:

 Příklad pohledu využití aplikací, zdroj: pilotní projekt MsK

Hledisko aplikačního portfolia (Mapa)

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í.

 Metamodel hlediska portfolia aplikačních funkcí a komponent (Mapa)

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».

Hledisko realizace požadavků aplikacemi

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

 Metamodel hlediska realizace požadavků aplikacemi.

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 technologické infrastruktury - obecné

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).

 Metamodel hlediska (struktury) technologické infrastruktury

Příklad:

 Příklad hlediska technologické infrastruktury, zdroj: pilotní projekt MsK

Hledisko využití infrastruktury

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.

 Metamodel hlediska využití infrastruktury

Zjednodušené hledisko nasazení informačních systémů

 Metamodel hlediska nasazení informačních systémů

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.

Hledisko technologického portfolia (mapa)

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í.

 Metamodel hlediska technologického portfolia

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

Hledisko využití komunikační infrastruktury (specifické pro ČR)

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í.

  Metamodel hlediska využití komunikační infrastruktury

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.

Hledisko portfolia komunikační architektury (Mapa, specifické pro ČR)

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.

 Doporučený metamodel implementačního a migračního hlediska

Příklad:

 Příklad pohledu implementace, zdroj: pilotní projekt MsK

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.

 Vztah jazyka ArchiMate a notací pro detailní modely, příklad. Zdroj: Marc Lankhorst, [[https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-introduction/|Blog]].

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:

 Diagram procesu pořízení pizzy v ArchiMate, zdroj: Marc Lankhorst, [[https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bpmn/|Blog]].

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.):

 Proces objednání pizzy v BPMN, zdroj Marc Lankhorst, [[https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bpmn/|Blog]].

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.


1)
Tabulka - Definice barev prvků podle standardu ArchiMate 3.1, zdroj: MV podle (The Open Group, 2017).
2)
Tabulka - Přehled prvků standardu ArchiMate 3.1 a jejich lokalizace, zdroj: MV podle (The Open Group, 2017).
3)
Tabulka - Přehled typů vazeb standardu ArchiMate 3.0.1, zdroj: MV podle (The Open Group, 2017).
4)
Přestože se se pod společnou správou The Open Group oba standardy stále sbližují.
5)
Analytická technika z oblasti marketingu a péče o klienta, doslova Cesta klienta (úřadem).
6)
Tabulka - Přehled definic prvků metamodelu byznys architektury, zdroj: MV podle (The Open Group, 2017).
7)
Z angl. Service Level Agreement.
8)
z angl. Capability.
9)
Tabulka - Přehled definic prvků metamodelu aplikační architektury, zdroj: MV podle (The Open Group, 2017).
10)
z angl. deployable
11)
Tabulka - Přehled definic prvků metamodelu technologické architektury, zdroj: MV podle (The Open Group, 2017).
12)
Tabulka - Přehled definic prvků metamodelu fyzické architektury, zdroj: MV podle (The Open Group, 2017).
13)
Součást byznys vrstvy a fáze vývoje architektury dle TOGAF ADM.
14)
Dle Specifikace ArchiMate 3.0 byla strategická architektura přidána k dřívějšímu motivačnímu rozšíření jako nová samostatná vrstva, pravděpodobně kvůli zpětné kompatibilitě jazyka.
15)
Tabulka - Přehled definic prvků metamodelu architektury strategie a směřování, zdroj: MV podle (The Open Group, 2017).
16)
Z angl. Capability Based Planning.
17)
Z angl. Key Goal Indicator.
18)
Z angl. Key Performance Indicator.
19)
Z angl. Total Costs of Ownership
20)
Z angl. Process Performance Indicator.
21)
Tabulka - Přehled definic prvků metamodelu výkonnostní architektury.
22)
Z angl. Core.
23)
Tabulka - Přehled překladů prvků metamodelu bezpečnostní architektury.
24)
Tabulka - Přehled definic prvků metamodelu bezpečnostní architektury, MV podle (Band, et al., 2015).
25)
Z angl. Corporate Social Responsibility: Wikipedia.
26)
Tabulka - Definice prvků metamodelu architektury implementace a migrace, zdroj: MV podle (The Open Group, 2017).
27)
Tabulka - Definice kompozitních prvků metamodelu architektury, zdroj: MV podle (The Open Group, 2017).
28)
Z angl. Nested diagram
29)
V angl. doslova „deployable“
30)
Z angl. The Open Group ArchiMate Model Exchange File Format.
31)
Tabulka - Přehled výstupů architektury a jejich lokalizace, zdroj: (The Open Group, 2018) a MV.
32)
Tabulka - definice výstupů architektury podle TOGAF 9.2, zdroj: (The Open Group, 2018).
33)
Z angl. Viewpoint
34)
Z angl. View
35)
The Zachman Framework for Enterprise Architecture, Zachman framework.
36)
GEA-NZ 3.2 – přehledy výstupů: GEA-NZ-Framework (bohužel materiál byl přesunut, je k dispozici na OHA na vyžádání).
37)
Hodilo by se používat nějakou zkratku jako třeba tato z angl. All-of-Government.
38)
Z angl.. Architecture Content Framework
39)
Z angl. Landscape Map Viewpoint
40)
Z angl. European Interoperability Reference Architecture.
41)
Z angl. Architecture Content Framework
42)
Z angl. Enterprise Capability Map
43)
Zatím nemá adekvátní výraz v češtině, pracovně se říká „Semaforky“, kvůli typickým barvám zelené, žluté a červené.
44)
Z angl. Stakeholders
45)
Z angl. Drivers
46)
Z angl. Goals
47)
Z angl. Objectives
48)
Tím se myslí opravdu principiální požadavky na úrovni změn enterprise architektury, nikoli změny funkční, vyplývající z dílčích tzv. business nebo IT požadavků. Ty jsou evidovány pomocí technik ITSM (ITIL), nikoli zde.
49)
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.
50)
Úč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.
51)
Úč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.
52)
Z angl. Project Start Architecture
, 2024/06/04 11:18
Dobrý den,
v aplikačním plném metamodelu je použita vazba specializace mezi Spolupráce aplikací a Aplikační komponentou. Tato vazba ale není povolena mezi elementem spolupráce a elementem komponenta v rámci definice jazyka Archimate. Existuje, prosím, nějaký příklad, kdy je v reálu element spolupráce specializací komponent?
Děkuji.
S pozdravem
Vaněček František
, 2024/06/04 17:05, 2024/06/04 17:06
Dobrý den,

opravdu ve specifikaci není specializace přípustná https://pubs.opengroup.org/architecture/archimate3-doc/ch-relationships-Normative.html a to i přesto, že jak kolaborace, tak komponenta jsou samy specializací elementu vnitřních aktivních struktur v aplikační vrstvě https://pubs.opengroup.org/architecture/archimate3-doc/ch-Application-Layer.html. I proto to asi v předchozích verzích byla povolená vazba.

Takže nyní je toto využití nemožné, při příští aktualizaci to opravíme.

S pozdravem,
Tomáš Šedivec
, 2024/06/04 09:46
Dobrý den,
v plném metamodelu bysnys vrstvy je obráceně popis vazby u elementu Funkce / proces / interakce VS, je tam jmenovka "spouští" u vazby flow a "tok" u vazby triggering. V redukovaném metamodelu je to již správně.

S pozdravem
Vaněček František
, 2024/06/04 17:07
Dobrý den,

děkuji za připomínky, při příští verzi je zapracujeme.

S pozdravem,
Tomáš Šedivec
, 2023/08/22 10:13
Dobrý den,
jedna "kosmetická" připomínka. V definici barev chybí ten odstín modré pro "předpis", resp. standardizační doménu. A jedna k redukovanému základnímu metamodelu - neměl by tam přeci jen být i systémový software? Realizace aplikačních komponent s využitím systémového sw není předmětem zájmu (dbms, as, ..)?
David Knespl
, 2023/09/01 15:23
Dobrý den,

děkuji za připomínky. Ten předpis je možné modelovat jako součást byznys architektury. Ač současný stav NAR říká, že je to "aspekt" standardizace, tak akceptujeme i tuto variantu. Proto barvené spektrum je možné mít stejné jako byznys objekty.
Co se týče systémového SW, tak ten je součástí i zjednodušeného metamodelu.

S pozdravem,
Tomáš Šedivec
, 2023/08/10 06:46
Není chyba, že v obrázku https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#produktove_hledisko je uvedena vazba Kompozice mezi "Obslužným kanálem VS" a "Rolí ve VS"? Neodpovídá to metamodelu a ani to logicky moc nedává smysl, dle mého názoru.
, 2023/08/10 06:37
V https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_funkci_verejne_spravy by dle popisu mělo být "... hlavní byznys funkce organizace a vztahy mezi nimi." Nicméně přiložený obrázek neznázorňuje vztahy mezi byznys funkcemi, ale spíš přiřazení funkcí na role.
, 2023/08/09 08:26
Bylo by možné upřesnit větu "Podle NAR není přípustné společně s reálnými komponentami modelovat i objekty SW licence." v https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#interpretace_metamodelu_aplikacni_architektury. Není příliš srozumitelná.
, 2023/08/16 15:03
Dobrý den,

děkuji, upraveno, snad je to nyní pochopitelnější.

S podzravem,
Tomáš Šedivec
, 2023/08/09 08:12
V Redukovaném modelu v https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_byznys_architektury_ba je použit prvek "Proces veřejné správy", který je tu navíc (!) oproti Plnému metamodelu a navíc není ani uveden v tabulce https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#definice_prvku_metamodelu_byznys_architektury.
Má tento prvek v modelu opravdu být?
, 2023/08/16 15:01
Dobrý den,

pokud myslíte prvek "Funkce/proces/interakce VS", tak ten je vedený jak metamodelu, tak i zde v BA.
Nebo máte na mysli jiný?

S pozdravem,
Tomáš Šedivec
, 2023/08/09 08:04
Bylo by možné do navigačního seznamu na levé straně obrazovky vložit též hlavní sekce (kapitoly) z jednotlivých dokumentů? Usnadnila by se tím orientace a přístup k jednotlivým částem metodiky.
, 2023/08/16 14:58
Dobrý den,

bohužel nastavení levého ToC je globální a současná úroveň mi přijde pro přehlednost nejlepší.
Zkusím se ještě podívat, zda to jde kódově upravit.

S pozdravem,
Tomáš Šedivec
, 2023/08/09 07:59
Domnívám se, že zavedení "Zjednodušeného metamodelu" (https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#zjednoduseny_metamodel_zakladnich_doporucenych_prvku) nemá žádnou výraznou přidanou hodnotu a z metodiky bych jej odstranil (v rámci celkového zjednodušování). Nepřináší žádné zajímavé zjednodušení, naopak tam mohou chybět prvky, které se v praxi často hodí (typu Požadavek, Omezení, ...)
, 2023/08/16 14:17
Dobrý den,

rozumím vašemu názoru, přesto já mám spíše pozitivní zpětnou vazbu, že s takovímto omezením je to pro ně uchopitelnější a pro nás (formulář OHA) dostatečné.

S pozdravem,
Tomáš Šedivec
, 2023/08/09 07:47
Má nějakou přidanou hodnotu poslední obrázek v kapitole https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#zakladni_metamodel? Není zde zbytečný?
, 2023/08/16 14:12
Dobrý den,

zjednodušený s doporučenými prvky pokládám za potřebný. Respektive, dost to omezí množinu prvků, které musí lidé, kteří s architekturou třeba tolik nepracují, vstřebat.

S pozdravem,
Tomáš Šedivec
, 2023/08/02 08:11
Je úmysl, že v kapitole https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_technologicke_infrastruktury_-_obecne je použita vazba Specializace mezi Uzlem a Systémovým SW / Zařízením, kdežto v https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_vyuziti_infrastruktury je to vazba Agregace? Má tato odlišnost vazbu na uvedená hlediska?
, 2023/08/04 10:06
Dobrý den,

děkuji za tento dotaz. V době vzniku těchto hledisek bych si spíše tipnul, že šlo o nejednotnost, která neměla za cíl odlišit význam hledisek a vztahu mezi uzlem a SW či zařízením. Ve starší specifikaci byly všechny aktivní prvky technologické vrstvy specializací uzlu, to už nyní neplatí, takže by to stálo za předělání.

S pozdravem,
Tomáš Šedivec
, 2023/08/02 07:50
Bylo by možné podrobněji vysvětlit a ukázat na příkladech využití "třístupňové klasifikace prvků byznys/aplikační/technologické architektury"? Proč má být klasifikace právě třístupňová? Jsou někde definované standardní/jednotné hodnoty pro oblast/kategorii/skupinu?
, 2023/08/04 10:01
Dobrý den,

popis klasifikací je zde https://archi.gov.cz/nar_dokument:referencni_modely_a_klasifikacni_ramce. Pokud by byl nedostatečný, pokusíme se jej rozšířit.

S pozdravem,
Tomáš Šedivec
, 2023/08/02 07:39
Doporučuje NAR rozlišovat směr vazby Access na Read a Write? Uvedeno to zde není.
, 2023/08/04 09:55
Dobrý den,

zde jsem bohužel zaspali. NAR byl psán v době, kdy vazba access sice byla směrová, ale rozlišení funkce (R,W,RW) bylo pouze doménou architektonických nástrojů. Specifikace to nyní pro access umožňuje, proto bychom to měli doplnit.

S pozdravem,
Tomáš Šedivec
, 2023/08/02 07:36
V příkladu v kapitole https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_chovani_aplikaci je vazba Realizace mezi aplikační službou a aplikační komponentou. Podle mne je to z hlediska ArchiMate správně, ale neodpovídá to metamodelu, který je uveden nad příkladem. Podle něj by správnější byla Realizace mezi Službou a Funkcí.
, 2023/08/04 09:53
Dobrý den,

ano, nejčistší je vždy realizační vazba mezi interním chováním (např. funkcí) a externím chováním (tedy službou). Uvedený příklad bez bližšího vysvětlení používá derivovanou vazbu, tedy vynechání prvku vnitřního chování a rovnou jejího přenesení na vazbu mezi aktivní prvek a externí chování.

Doplním vysvětlení k příkladu.

S pozdravem,
Tomáš Šedivec
, 2023/08/01 10:35
Je obrázek v kapitole https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_spoluprace_byznys_procesu správný?
Nepůsobí dojmem, že by se na něm příliš řešila problematika "spolupráce byznys procesů".
, 2023/08/01 14:52
Dobrý den,

ano je. Spolupráce se zde vyznačuje rekurzí byznys procesů, které následně poskytují službu. Samozřejmě jsem ale přístupni návrhu na změny.
Ideálně ale nechceme používat prvek "kolaborace", pokládáme jej za zbytný.

S pozdravem,
Tomáš Šedivec
, 2023/08/02 07:33
Přijde mi, že problematika "spolupráce byznys procesů" je košatější, než přes triggering mezi procesy. Typické zde může být junction (ano, opět s využitím trigerring), smysl dává i flow (tok informací mezi procesy).
, 2023/08/04 09:44
Dobrý den,

junction se v hledisku nemusí vyskytovat, bereme ho jako grafické zjednodušení více vazeb stejného typu. Jediná logika je v tom, zda vstupy a výstupy do junction platí všechny naráz nebo alespoň jeden.
Váš návrh tedy spočívá v tom přidat do hlediska i tok mezi procesy? To by neměl být problém.

S pozdravem,
Tomáš Šedivec
, 2023/08/07 11:26
Ano, tok bych přidal.
, 2023/08/01 10:18
Nechybí v této kapitole obrázek?
https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_vrstev_architektury
Je zmíněn v textu ("Na Obrázku níže je tedy uveden pouze příklad ...")
, 2023/08/01 14:54
Dobrý den,

odkazuje se na stejný obrázek, jak následující podkapitola https://archi.gov.cz/_detail/nar-dokument:image69.png?id=nar_dokument%3Aramec_obsahu_a_vystupu_architektur

S pozdravem,
Tomáš Šedivec
, 2023/08/02 07:27
Nejsem si jist, jestli obrázek v další kapitole je reprezentativní - vzhledem k poznámce "Klíčové je střídání dedikovaných a servisních vrstev a užívání příslušných vazeb". To obrázek příliš nesplňuje.
, 2023/08/04 09:39
Dobrý den,

rozumím. Proberu to s Pavlem Hrabětem, zda není k dispozici lepší diagram. Pokud byste měl vlastní či návrhy na zlepšení, určitě je uvítáme.

S pozdravem,
Tomáš Šedivec
Vložte svůj komentář: