Překlady této stránky:

Národní architektonický rámec

Úvod

Informační koncepce České republiky (také jako "IKČR" nebo "Informační koncepce ČR") je základním dokumentem, který stanovuje na základě zmocnění podle § 5a odst. 1 zákona 365/2000 Sb., o informačních systémech veřejné správy, cíle České republiky v oblasti informačních systémů veřejné správy (také jako "ISVS") a obecné principy pořizování, vytváření, správy a provozování informačních systémů veřejné správy v České republice na období 5 let.

IKČR v navazujícím dokumentu č. 1: Metody řízení ICT veřejné správy ČR definuje pravidla, včetně orgánů a rolí odpovědných za jejich uplatňování, v celém životním cyklu ICT služeb informačních systémů veřejné správy, tedy definuje pravidla strategického řízení IT, plánování, přípravy a implementace ICT projektů, provozu ICT služeb, řízení ekonomiky a bezpečnosti ICT služeb a pravidla kontroly a auditu (governance) ICT. IKČR v této příloze současně definuje základní požadavky na řízení a rozvoj orgánů veřejné moci a jejich útvarů informatiky tak, aby byly lépe schopny naplňovat cíle rozvoje služeb informačních systémů veřejné správy a řídit jejich životní cyklus.

Aby bylo možno tyto cíle efektivně realizovat, IKČR zavádí Národní architekturu VS ČR, Národní architektonický rámec a Národní architektonický plán VS ČR jako prostředky pro popis architektury orgánů veřejné správy a architektury informačních systémů veřejné správy a jako základní nástroje pro formulaci cílů a principů Informační koncepce ČR a informačních koncepcí jednotlivých orgánů veřejné správy a pro řízení realizace změn podle těchto koncepcí.

IKČR v navazujícím dokumentu č. 2: Slovník pojmů eGovernmentu zavádí jednotný výklad pojmů a jejich případných synonym z platné legislativy i z praxe, potřebných jako jeden z nástrojů koordinovaného budování eGovernmentu podle Národního architektonického plánu a pro koordinované řízení informatiky veřejné správy.

IKČR v navazujícím dokumentu č. 3: Národní architektonický rámec (NAR, tento dokument) zavádí závaznou metodiku modelování, udržování a používání popisu architektury orgánů veřejné správy.

IKČR v navazujícím dokumentu č. 4: Národní architektonický plán (NAP)orgánům veřejné správy – správcům informačních systémů - poskytuje jasnou a konkrétní představu toho, jak bude vypadat informatika VS ČR ve stanoveném horizontu 5 let, které prvky informatizace veřejné správy budou centrální a sdílené, které lokální prvky musí být jednotné podle předložených vzorů a které mohou být libovolné, jejich vzájemné vazby a návaznosti při současném dodržení stanovených architektonických principů.

Orgány veřejné správy podle IKČR a jejích navazujících dokumentů vytvářejí svou informační koncepci a další dokumenty.

Tom Graves: „Věci fungují lépe, když fungují společně za nějakým účelem“.

Na místo správy jednotlivých dílčích činností úřadů a jejich informačních systémů samostatně, takříkajíc s klapkami na očích, je třeba zavést nový přístup, který umožní zodpovědným manažerům s pomocí analytiků vidět úřad jako celistvý socio-ekonomicko-technický systém, který má strukturu prvků, jejich vazeb a chování (tedy architekturu), a v němž všechny „věci“ vzájemně souvisí.

To pro úřad znamená nutnost poznat a popsat svou architekturu s využitím postupů a prostředků stanovených NAR a rozhodovat o jejím dalším vývoji ve shodě s IKČR a s NAP. To prakticky znamená například mít a používat místo excelů transparentní a sdílené modely.

Tento dokument obsahuje popis závazné metodiky pro tvorbu a správu modelů architektury kteréhokoli úřadu veřejné správy ČR (OVS, orgánu veřejné správy) a přiměřeně odlišnému charakteru činností také kteréhokoli státního, národního nebo samosprávou zřizovaného podniku či organizace.

Původní pojem podniková architektura1) byl pro účely veřejné správy nahrazen pojmem architektura úřadu, ale původní význam zůstal zachován. Všude tam, kde se v tomto materiálu hovoří o architektuře úřadu, mohou si ostatní organizace a podniky odpovídajícím způsobem představovat podnikovou architekturu.

Účelem tohoto dokumentu je poskytnout architektům v úřadech a organizacích širokou znalostní bázi a návod, jak modelovat architekturu úřadu tak, aby se všechny jednotlivě vzniklé modely úřadů vzájemně doplňovaly a společně vytvořily Národní architekturu (NA) a Národní architektonický plán VS ČR.

Dokument je východiskem pro navazující metodiky a doporučení typu „Jak na to?“, které v užším smyslu poskytnou praktické návody, například pro to, jak modelovat architekturu úřadu pro vytvoření Informační koncepce úřadu nebo pro žádost o stanovisko OHA2).

Účelem metodiky v širším slova smyslu je být východiskem pro modelování architektur úřadu pro jakékoli použití při plánování a rozvoji služeb úřadů a jejich informační podpory.

Pro rozvoj všech schopností a dovedností veřejné správy, včetně rozvoje digitálních služeb VS, je nezbytné řídit veřejnou správu jako propojený komplexní systém služeb, poskytovaných orgány veřejné správy, s nadhledem a v celkových souvislostech3). Protože většina transformačních kroků státu je stejně jako u podnikových korporací v současné době umožněna jen s pomocí ICT, je celková architektura orgánů veřejné správy, jejich úřadů a veřejnoprávních korporací, současně prostředkem vývoje a řízení transformačních změn a současně prostředkem dlouhodobého řízení a rozvoje ICT na podporu těchto změn.

Ve standardu TOGAF4) má “architektura” dva doplňující se významy podle kontextu (The Open Group, 2018):

  1. Formální popis systému nebo plánu systému na úrovni jeho prvků, jako vodítko pro jeho implementaci
  2. Struktura prvků, jejich vzájemných vazeb a principů a návodů řídících jejich návrh a vývoj v čase.

Následují vlastní definice NAR VS ČR:

Architektura veřejné správy jako socio-ekonomicko-technického systému je souborem prvků, které tvoří strukturu systému, jejich vzájemných vazeb, jejich chování (fungování) a principů a pravidel jejich vzniku a vývoje v průběhu času.

a současně:

Architektura úřadu (EA5)) jako manažerská metoda je prostředkem celostního poznávání organizace na podporu rozhodování, zejména při plánování strategických změn, ale také na podporu řízení výkonnosti, kvality a zodpovědnosti.

Představuje popis struktury a chování úřadu (kdo jsme), plánovaných změn (odkud a kam jdeme) a jejich informatické podpory (k čemu nám je a má být ICT jako celek a jednotlivé informační systémy veřejné správy).

Zavedení tzv. Národní architektury veřejné správy (NA) a Národního architektonického plánu jejího rozvoje (NAP) prostřednictvím následných dokumentů IKČR vychází z nutnosti systematicky popsat současný a budoucí stav architektury VS tak, aby její popis podporoval řízení reforem VS i změn její ICT podpory.

Národní architektura VS ČR (NA) je souhrn architektur a popisů architektury všech jednotlivých úřadů veřejné správy, včetně všech centrálních sdílených prvků eGovernmentu.

Národní architektonický plán (NAP) bude tvořit popis současného stavu jednotlivých úřadů veřejné správy a centrálních prvků eGovernmentu6), popis návrhů jejich cílového stavu7), z nich plynoucí rozdíl, tedy rozsah očekávaných změn a plán, jak budou tyto změny realizovány8).

NAP je také soubor architektonických dat (modelů) a diagramů, udržovaných společně OHA a jednotlivými OVS, členěný na:

  • architektury úřadů
  • architektury sdílených služeb.

Pro všechny modely a další dokumenty, popisující stávající a cílovou Národní architekturu VS a postup cesty k ní bude využíván společný název Národní architektonický plán (NAP).

Pro popis architektury VS bude prostředí NA VS ČR obsahovat návody, postupy, předlohy a vzory tvorby, údržby a užití popisu architektury, tedy Národní architektonický rámec architektury úřadů9). Architektonický rámec obsahuje rady pro:

  • Popis architektury: jak zachytit jednotlivé obrazy architektury podle potřeb zájmových skupin
  • Metodu tvorby architektury: cyklus tvorby architektury, rozděleného do fází, organizovaného podle domén, s rozdílnými výstupy.
  • Organizaci architektonického týmu: jaká má být struktura týmu, jeho dovednosti, znalosti, způsob řízení a kontroly.
  • Uspořádání architektonického úložiště: ve vzájemném vztahu úložiště úřadu a na úrovni ČR

Národní architektonický rámec (NAR), jako metodický a myšlenkový rámec pro jednotný a koordinovaný popis Národní architektury VS ČR, obsahuje návody, postupy, předlohy a vzory tvorby, údržby a užití popisu architektury.

Národní architektonický rámec vychází z mezinárodně uznávaných standardů tvorby a údržby architektury úřadů TOGAF10) a ArchiMate, spravovaných The Open Group11) a užívaných jako východisko pro architekturu veřejné správy ve většině zemí.

NAR vydá a bude aktualizovat OHA, který bude v souladu s NAR koordinovat vznik a aktualizaci součástí NAP a zabezpečí jejich centrální uložení a prezentaci vybraných znalostí z NAP, tj. například modelů a akčních plánů jednotlivých OVS, ve společné znalostní bázi a portálu NAP.

Další základní pojmy jsou definovány v mnoha kapitolách tohoto dokumentu. Zkratky, pojmy a definice a v následném dokumentu IKČR č. 2 - Slovník pojmů eGovernmentu.

V této první kapitole jsou uvedena základní vysvětlení k dokumentu.

  1. V kapitole 2 - Modelující úřady a jejich architektury - je definováno jaké celky a části úřadů a veřejné správy jakožto systémů jsou předmětem modelování architektury, a to zejména z pohledu zodpovědnosti za tvorbu, údržbu a užití architektury. Je zde tedy zejména řečeno, kdo modeluje.
  2. V kapitole 3 - Struktura modelovaných architektur - je definováno, pomocí jakých abstrakcí, kategorií, pojmů a úrovní detailu se modelují jednotlivé součásti architektury úřadu. Je zde tedy zejména řečeno, co se modeluje.
  3. V kapitole 4 - Proces tvorby architektur - je definováno jakým postupem, s jakými kroky a jakými pomůckami se vytváří, udržují a užívají modely architektury. Je zde zejména řečeno, jak se architektura řídí.
  4. V kapitole 5 - Rámec obsahu a výstupů architektur - je definováno, jakým jazykem, tj. jakými pojmy a symboly se vyjadřují jednotlivé prvky a vazby architektury a pomocí jakých výstupů se prezentují výstupy popisu architektury úřadu. Je zde tedy zejména řečeno, jak a do čeho se modeluje.
  5. V kapitole 6 - Referenční modely a klasifikační rámce - je definováno, jakým způsobem usnadnit a sjednotit tvorbu modelů a diagramů pomocí sdílených tzv. referenčních modelů, zobecňujících nejlepší praxi z architektur úřadů. Je zde tedy řečeno zejména, co jsou a jak se užívají referenční modely.
  6. V kapitole 7 - Pokyny a techniky pro tvorbu architektury - jsou definovány pokyny, sloužící jako návod pro přizpůsobení architektonického rámce podmínkám a potřebám konkrétního úřadu a techniky, představující návody a pomůcky pro dílčí postupy tvorby a údržby architektury. Je zde tedy řečeno zejména, jak si upravit a usnadnit tvorbu architektury.
  7. V kapitole 8 - Architektonické dovednosti, útvary a orgány - je definováno jaké znalostní, personální a organizační předpoklady je nezbytné v úřadu vytvořit, aby byl schopen vytvářet, udržovat a užívat popis své architektury na podporu rozhodování. Je zde tedy zejména řečeno, jaké jsou nezbytné předpoklady (zdroje) pro management a governance architektury.
  8. V kapitole 9 - Architektonické úložiště a nástroj - je definováno jakým a jak strukturovaným vybavením pro ICT podporu procesů správy a užití své architektury musí úřad disponovat. Je zde tedy zejména řečeno, jaké jsou potřebné nástroje pro modelování.

Tento následný dokument Informační koncepce ČR je povinný pro všechny povinné osoby podle zákona č. 365/2000 o Informačních systémech veřejné správy, ve znění pozdějších předpisů a pro povinné osoby podle Usnesení vlády ČR č. 86/2020 k dalšímu rozvoji informačních a komunikačních technologií služeb veřejné správy.

Národní architektonický rámec bude OHA průběžně aktualizován na základě vývoje v oblasti řízení architektury ICT a zpětné vazby jeho uživatelů.

Materiál NAR Navazuje a je v souladu s právními předpisy a se strategickými materiály ČR v oblasti digitální transformace veřejné správy ČR k eGovernmentu a oblasti dlouhodobého řízení informatiky a informačních systémů ve veřejné správě ČR.

Některá ustanovení Digitálního Česka - Informační koncepce ČR a jejích navazujících dokumentů, včetně toho budou teprve promítnuta do odpovídajících novel příslušných prováděcích předpisů.

Navržená metodika vychází ze dvou základních pilířů používaných v oblasti návrhu moderní ICT Architektury:

  • TOGAF - je mezinárodně uznávaný rámec pro řízení tvorby Enterprise architektury ve společnostech využívajících prostředků informačních technologií. Původní koncept vznikl v USA, ale již více než deset let se používá po celém světě včetně České republiky. Oficiální dokumentace standardu TOGAF (The Open Group, 2018) se nachází na adrese http:%%//%%pubs.opengroup.org/architecture/togaf9-doc/arch/index.html.
  • ArchiMate - je nezávislý grafický modelovací jazyk. O jeho správu se stará konsorcium Open Group, které ArchiMate vyhlásilo jako standard pro popis Enterprise architektury. Obecné standardy pro modelování v jazyce ArchiMate (The Open Group, 2017) jsou dostupné na adrese http:%%//%%pubs.opengroup.org/architecture/archimate3-doc/toc.html.

Metodika NAR, jakožto metodika tvorby, údržby a užití architektury, představuje v každé organizaci závazný a opakovatelný návod, popisující relevantní procesy k danému životnímu cyklu architektury. Východiskem pro její návrh je rámec TOGAF, respektive jeho část popisující procesy cyklu ADM. U těchto procesů se předpokládá, že bude upravována na míru dané organizaci v dokumentech, jako je tento. Říká nám, co tvoříme a kdy to tvoříme. Jinými slovy klade požadavek na vytvoření jednotlivých úrovní architektury (např. byznys architektury, aplikační architektury a datové architektury), tj. výstupů relevantních pro každou její fázi. Výstup každé fáze musí být zaznamenaný. Aby došlo k snadnému porozumění, je potřeba definovat si společný komunikační prostředek neboli modelovací jazyk.

Vhodným kandidátem je modelovací jazyk ArchiMate. Ten je vymyšlen takovým způsobem, aby klíčové fáze TOGAF ADM cyklu tj.: fázi B (byznys architekturu), fázi C (architekturu informačních systémů – datovou a aplikační architekturu) a fázi D (technologickou architekturu) dokázal znázornit. Některé oblasti TOGAF ADM cyklu nejsou v jazyce ArchiMate obsaženy. Je to pochopitelné, protože TOGAF je rámec a má mnohem širší záběr než ArchiMate, který je jazykem pro modelování architektury. Návaznost je schematicky znázorněna na obrázku níže.

Na otázky po příčinách architektonických změn odpovídá tzv. Motivační rozšíření ArchiMate, které koresponduje s fází A (architektonická vize) a částí fáze B (byznys architektura) TOGAF ADM cyklu.

Dále existuje Implementační a migrační oblast rozšíření ArchiMate, která koresponduje s TOGAF ADM fázemi. Jmenovitě se jedná o fázi E (příležitosti a řešení), fázi F (plánování migrace) a fázi G (zavedení řízení).

Aktuálně byly do jazyka ArchiMate ve verzi 3.0 doplněny ještě prvky vrstvy Strategie a Fyzické architektury, které nemají přímý protějšek v TOGAF, ale jeho objekty vhodně doplňují a NAR s vybranými z nich aktivně pracuje.

 Schématické znázornění vztahu TOGAF ADM cyklu a modelovacího jazyka ArchiMate

Více o základních principech metodiky architektonického rámce TOGAF a architektonického modelovacího jazyka ArchiMate v odpovídajících kapitolách a v přílohách.

TOGAF je obecný, technologicky nezávislý rámec, který je určený pro užití v rozličných prostředích. Díky tomu je flexibilní a rozšiřitelný a může být použit sám o sobě, nebo může být doplněn jinými standardními rámci jako je například ITIL, COBIT a PRINCE2.

NAR, stejně jako TOGAF, je připraven být implementován do jednotlivých OVS s velkou měrou přizpůsobení vůči všem k němu doplňkovým, v úřadu již zavedeným a osvědčeným metodám, například řízení projektů, řízení změn nebo řízení kvality.

Autoři následných dokumentů k IKČR předpokládají, že v jejich následujících aktualizacích budou vydány i příklady integrace NAR na případné další standardní (centrálně jednotné) metody řízení, například projektového řízení, až tyto vzniknou.

Více také v dokumentu Metody řízení ICT VS ČR.

Úloha architektury při řízení změn

Architektura úřadu jako manažerská metoda sehrává klíčovou roli zejména v jednotlivých stupních a fázích řízení transformačních změn, jak představuje následující Obrázek níže.

 Úloha architektury při řízení změn v organizaci, v kontextu ostatních manažerských metod, zdroj: (Hrabě, 2015).

Celková znalost úřadu, získaná pomocí EA je předpokladem pro tvůrčí postupy formulování vlastní strategie úřadu.

Následně musí být stanovené strategické směřování rozpracováno do konkrétní představy proveditelných změn, v podobě cílové architektury úřadu a implementačního plánu projektů pro její dosažení.

Po úspěšné realizaci transformačních projektů jsou znalosti architektury úřadu velmi výhodné i pro účinné mechanismy provozního řízení (například řízení služeb) a trvalého zlepšování kvality.

Vztah architektury úřadu a IT manažerských standardů a knihoven (ITIL, COBIT, IT4IT)

Vazba TOGAF a ITIL

Information Technology Infrastructure Library (ITIL, norma ČSN/ISO 20000) je rámec pro řízení IT služeb. Základní princip ITIL je postaven na řízení životního cyklu IT služby a řízení hodnoty, kterou informační technologie poskytují zákazníkům – tj. odběratelům IT služeb. ITIL obsahuje soubor praxí prověřených konceptů a postupů.

Úložiště pro podporu procesů vedených podle ITIL včetně správy konfiguračních prvků souvisí s architektonickým úložištěm TOGAF (dominantně v oblasti Řízení požadavků) a měly by se vzájemně doplňovat. Architektura vytvořená pomocí rámce TOGAF poskytuje vstupy do procesů ITIL a využívá jejich výstupy.

Vazba TOGAF a COBIT

Control Objectives for Information and related Technology (COBIT) je rámec pro správu a řízení IT (IT Governance). Jedná se o soubor praktik, které by měly umožnit dosažení strategických cílů organizace díky efektivnímu využití dostupných zdrojů a minimalizaci IT rizik. COBIT byl ve své páté verzi upraven tak, aby byl plně kompatibilní s rámci TOGAF, ITIL a PRINCE2, a vytváří tak zastřešující rámec („umbrella framework“).

COBIT pokrývá většinu aktivit definovaných rámcem TOGAF. V rámci plánování a organizace definuje přímo proces Řízení Podnikové Architektury, čímž dochází k propojení obou rámců. COBIT dále obohacuje aktivity rámce TOGAF o:

  • vztahuje je k obecným IT cílům a doprovodným metrikám,
  • přidává architektonicky-specifické procesní cíle a doprovodné metriky,
  • definuje zodpovědnosti za aktivity TOGAF formou matice přiřazení zodpovědnosti (RACI).

COBIT dává TOGAF do kontextu tím, že propojuje procesy architektury s ostatními procesy organizace, řízením změn projekty a poskytováním ICT služeb.

Vazba TOGAF a IT4IT

Rámec IT4IT byl významnými IT společnostmi, členy The Open Group vypracován na podporu řízení procesů správy IT. Tento rámec byl vytvořen s využitím prostředků TOGAF a ArchiMate a soustřeďuje se na taxonomii a klasifikaci aplikačních komponent a jejich funkcí, potřebných na podporu všech nejlepších praxí při řízení informatiky, včetně EA samotné. Více o možnostech aplikace IT4IT ve veřejné správě se nachází v Metodách řízení ICT VS a ve Znalostní bázi NA.

Vztah architektury úřadu a dalších manažerských metod – řízení projektů, kvality, výkonnosti, bezpečnosti a dalších

Vazba TOGAF a PRINCE 2, PMBoK a dalších rámců řízení programů a projektů.

Správa architektury úřadu a projektové řízení změn jsou dvě zcela neoddělitelné manažerské disciplíny, bezpodmínečně nutné pro úspěšné zavedení strategií definovaných transformačních změn.

NAR v řadě pasáží předpokládá využití projektového řízení jak pro vlastní architektonické úlohy (angažmá), tak přirozeně pro řízení realizace definovaných balíčku práce na cestě k cílové architektuře.

V těch OVS, kde není profese projektového řízení dostatečně zralá a opřená o nějaký uznávaný standard, nabízí NAR nezbytné minimum projektově orientovaných aktivit. Naopak tam, kde projektové řízení kvalitně zavedeno je, transparentně přenechává NAR tyto úlohy příslušné užívané metodě. Cílově by měl být NAR doplněn a provázán s Národní metodikou projektového řízení ve veřejné správě.

Vazba TOGAF a CAF, EFQM, TQM, 6Sigma a dalších rámců kvality

NAR je stejně jako TOGAF zaměřen zejména na podporu nalezení a zavedení zásadních transformačních změn. Spolu s nimi a v návaznosti na jejich uskutečnění ale přichází otázky provozního řízení, řízení menších změn, kvality, výkonnosti, udržitelnosti a trvalého zlepšování. Proto NAR podporuje zavedení metod řízení změn a řízení kvality jako jsou výše uvedené a je připraven se jim přizpůsobit a na ně navázat, pokud již jsou v úřadu úspěšně zavedeny.

Zcela obdobný, jako u rámců metod řízení kvality, je vztah architektury úřadu a řízení výkonnosti.

Zjednodušeně řečeno je přeci nutné identifikovat, pojmenovat, poznat a dobře porozumět všemu, co je třeba v úřadu zlepšovat, čeho kvalita a výkonnost má být řízena. A přesně tento předpoklad naplní zejména architektura úřadu, doplněná o další, detailnější metody jako je například procesní modelování, správa pravidel nebo správa služeb.

Modelující úřady a jejich architektury

Pro stanovení rozsahu modelování architektury úřadů je klíčové stanovit, kdo modeluje, tj. která organizace, jakou část organizace a pro jaký účel modeluje.

V následující kapitole Struktura modelovaných architektur je vysvětleno, jaké typy modelů a jejich domén, s jakou mírou závaznosti dle účelů použití je možno modelovat. Tato kapitola představuje pohledy a přístupy, jak zodpovědnost za tvorbu architektury v OVS správně rozdělit a řídit.

Základní pravidlo NAR stanovuje, že individuální (skutečné) architektury se modelují zásadně a výhradně pouze pro nějaký úřad, OVS, a to na libovolné úrovni hierarchie veřejného sektoru. Výjimkami jsou možnosti využití metodiky architektury úřadu pro modelování:

  • samostatných klíčových centrálních sdílených informačních systémů eGovernmentu ČR,
  • vybraných klíčových prvků architektury EU jako jsou společné procesy, služby a aplikační nebo platformové komponenty na úrovni EU
  • architektury na straně obecného (typové) klienta veřejné správy. Zde nejde o individuální, ale o typový, referenční model.

Úřadem se z hlediska metodiky modelování podnikové tzv. architektury úřadu myslí kterýkoli subjekt veřejného sektoru, který čerpá veřejné prostředky, je oprávněn poskytovat veřejné služby (nebo obdobné i podnikatelské činnosti) jménem státu s výdaji ze státního rozpočtu, nebo vlastním jménem a na vlastní účet a činí rozhodnutí o použití veřejných prostředků12). Převážně se úřadem myslí orgány veřejné moci, a to zejména ústřední správní úřady a jimi zřizované organizační složky státu a státní příspěvkové organizace, nebo územní samosprávné celky a jimi zřizované příspěvkové a obchodní organizace.

Každý úřad VS ČR bude vytvářet až tři samostatné modely individuální (skutečné) architektury, rozdílného rozsahu (záběru) z hlediska velikosti modelovaného enterprise. A to v případě, že se ukáže jako potřebné, aby tyto modely rozličného rozsahu a účelu mohly existovat a být sdíleny samostatně. Každý z vytvořených a spravovaných modelů úřadu a každý z modelu odvozený artefakt13) bude muset být klasifikován právě jednou ze tří hodnot klasifikace rozsahu modelu úřadu a to:

  • VLST - Vlastní model architektury úřadu (OVS)
  • SPOL - Společný model úřadu a všech jím kontrolovaných (a metodicky vedených) organizací (resort, krajská korporace atp.)
  • ROZS – Rozšířený model s prvky od spolupracujících organizací, úřadů, kdekoli v systému veřejné správy (případně soukromé sféry).

Přitom modely většího rozsahu (SPOL a ROZS) budou částečně přebírat některé prvky modelu menšího rozsahu (VLST) a dále budou přebírat prvky modelů podřízených nebo spolupracujících úřadů a jiných organizací. Jak bude technicky zajištěna kontrola (governance) vícenásobně modelovaných prvků a jak výrazná bude podpora znovupoužití a sdílení již namodelovaných prvků, bude upřesněno po pilotních zkušenostech, ale zejména v souvislosti s projektem vybudování centrálního úložiště modelů NA VS ČR a dle jeho technických možností.

Důležité je, že každý model, vytvořený pro úřad (OVS) je jednoznačně identifikován kódem organizace VS, pod kterým je evidována v RPP, tzv. „Identifikátor OVS “, viz https:%%//%%rpp-ais.egon.gov.cz/AISP/verejne/domu.

Celý systém klasifikace modelů úřadů a jejich pohledů se nachází v Referenční modely a klasifikační rámce.

Metodika TOGAF, ze které koncepce NA VS ČR důsledně vychází, rozlišuje tři úrovně podnikové architektury v každém úřadu (enterprise), jsou to:

  • STR - Strategická architektura
  • SGM - Segmentová architektura
  • SCH - Schopnostní architektura, architektura schopností14)

Toto členění platné a povinné na všech a na kterékoli úrovni úřadu (velikosti, pozici v hierarchii VS), od úrovně celé ČR po například dílčí příspěvkovou servisní organizaci malého města na úrovni ORP. Je ale přípustné některý stupeň nemodelovat, pokud neodpovídá realitě (např. organizace nemá identifikovatelné segmenty) nebo potřebě (neexistuje manažer, který by využil diagramy odpovídající úrovně). Modelující architekti ale musí vždy vědět, na jaké úrovní architektury se nacházejí a modely i artefakty odpovídajícím způsobem klasifikovat.

 Dělení architektury úřadu na strategickou, segmentové a schopnostní architektury, zdroj: TOGAF (The Open Group, 2018), překlad MV

Strategická architektura se vyznačuje tím, že za každou cenu (třeba s omezením míry detailu) vždy obsahuje v modelu celý úřad (u VLST i SPOL). Strategická architektura, věrna svému názvu, slouží ke strategickému plánování rozvoje úřadu a jeho informatiky (například cestovní mapy aplikací a infrastruktury), vždy za celý úřad nebo jeho celou zodpovědnost na několik let dopředu.

Segmentová architektura slouží ke společnému modelování částí úřadu (vlastního nebo s kontrolovanými organizacemi), které mají společné mechanismy fungování nebo budou předmětem společné změny (realizace strategické iniciativy, implementace nové politiky). Pro účely členění obsahu architektur uvnitř úřadů (enterprise) libovolné velikosti a úrovně veřejné správy bylo identifikováno několik vzájemně kolmých dimenzí segmentace, jejichž kombinací vznikají individuální dílčí segmenty. Jsou to tyto dimenze segmentace:

  • Segmentace dle kategorie funkcí/procesů veřejné správy
  • Segmentace dle skupiny agend veřejné správy
  • Segmentace dle odvětví (sektorů) veřejné správy
  • Segmentace dle velikosti úřadu veřejné správy

Všechny dosud identifikované segmentace architektur jsou pro NA VS ČR podstatné zejména z hlediska definice segmentů VS s podobnými vlastnostmi z hlediska (1) tvorby a užití tzv. Referenčních modelů, návodů a vzorů, obsahujících nejlepší praxi segmentu a (2) tvorby a uplatnění závazných standardů architektur, které se mohou segmentově lišit.

Jednotlivé způsoby segmentace nejsou, kromě agend, dány právními předpisy a nemají závazně definované pojmy ani číselníky přípustných hodnot. Segmentace je zatím vnitřní (analytickou) součástí architektonické metodiky a bude postupně zpřesňována dle zkušeností z pilotních a navazujících projektů. Klasifikace pro segmentaci vznikne a bude publikována prostřednictvím kombinace dokumentů NAR a NAP.

Architektura schopností představuje dílčí architekturu úřadu, sloužící pro podrobnější porozumění určité oblasti úřadu nebo jeho segmentu, jeho skupině externích, nebo interních, agendových (vertikálních) nebo průřezových (horizontálních) schopností. Například schopnosti přidělovat a spravovat identitu občanů, schopnosti provozovat nemovitosti úřadu nebo schopnosti spravovat dokumenty, spojené s kteroukoli jinou hlavní schopností.

Architektura schopností je nejčastěji vytvářena ve spojení s nějakou předpokládanou, ve vyšších architekturách identifikovanou změnou, kterou je potřeba na úrovni architektury úřadu rozpracovat do příležitostí a plánu změn dříve, než budou zahájeny práce na hledání detailní architektury možných řešení. Tato architektura je vytvářena na úrovni úřadu a útvaru, který je nositelem změny, bude financovat, schvalovat nebo řídit projekt zavedení této změny, včetně její IT podpory. Tato úroveň je vytvářena ve všech případech přípravy projektů jako základní enterprise architektura projektu15), jemuž daná schopnost (Capability) odpovídá a kterou projekt rozvíjí/mění.

Příkladem schopnostní architektury je enterprise architektura konkrétní agendy, oblasti ERP nebo správy dokumentů, apod., velmi často také EA spojená s jedním ISVS.

Schopnost není základním prvkem architektury, ale naopak je nejmenší částí organizace, které má architekturu (strukturu a chování), kterou lze zkoumat a modelovat.

Další (detailnější) architektury

V celkové pyramidě architektur organizace (úřadu) na tyto úrovně STR (Strategická), SGM (Segmentová) a SCH (Schopnostní) architektury úřadu navazují tzv. architektur řešení16), popisující fungování hledaného řešení a tzv. design řešení17), popisující konstrukci a „výrobní“ postup implementace řešení – zavedení procesu, naprogramování nebo parametrizace aplikace apod., viz Struktura modelovaných architektur.

Každý úřad musí mít pouze (právě) jediný schválený model vlastní strategické architektury (VLST; STR) a právě jediný schválený model strategické architektury společně s kontrolovanými organizacemi (SPOL; STR). Vedle toho bude mít odpovídající počet (jeden nebo více) segmentových a schopnostních pohledů na architekturu vlastní, společnou i rozšířenou. Podle rozdělení zodpovědností za architektury úřadu budou tyto pohledy na jiné než strategickou architekturu modelovány jako vizualizace k jednomu centrálnímu modelu úřadu nebo k několika dílčím modelům úřadu, s odlišnou zodpovědností a životním cyklem.

Přirozeně může mít úřad mnoho navazujících modelů architektur řešení a designu řešení. Ty ale metodika NAR neupravuje.

Každý z výše uvedených výseků architektury úřadu je možno vyjádřit artefakty - tabulkami (Katalogy a Matice) nebo graficky (Diagramy) na libovolné úrovni podrobnosti. Předchozí verze NAP 201418) používala tři stupně podrobnosti diagramů – přehledovou, základní a detailní, viz také Struktura modelovaných architektur, tato logika bude je jako doplňková také zachována.

Ve velkých organizacích korporátního charakteru, jako jsou ministerstva (rozpočtové kapitoly), krajské korporace nebo velká města, bude řada lidí, mnohdy v různých týmech, odpovídat za různé úrovně, domény a segmenty architektur. Přirozeně hrozí, že se jejich pravomoci a zodpovědnosti budou překrývat nebo naopak nepokryjí celou potřebu.

Pro zajištění řízení a governance19) těchto architektur je nezbytné v předpisech každého úřadu stanovit a průběžně aktualizovat zodpovědnost útvarů, týmů a jednotlivců za tvorbu a údržbu jednotlivých architektonických modelů a odpovídajících výstupů.

U každého úřadu jsou zodpovědnosti za údržbu (editaci, aktualizaci) modelů architektury úřadu a pohledů na ně rozděleny přinejmenším následovně:

  • kdo a co si modeluje sám?,
  • za koho modeluje Architektonická kancelář (AK) úřadu?
  • zda všichni modelují celé architektury svého úřadu, nebo má někdo konkrétní přidělen konkrétní segment nebo schopnost?

Pro zachycení těchto vzájemných vztahů architektonický modelů a výstupů ve federované struktuře musí vzniknout řídící model, architektura architektur korporace. Její nedílnou součástí je:

  • Hierarchie federovaných architektur korporace
  • Matice zodpovědností za jednotlivé architektury, jejich modely a artefakty.

Struktura modelovaných architektur

Jestliže v kapitole Modelující úřady a jejich architektury je vysvětleno „Čí architektura se modeluje“, co je to z pohledu architektury úřad (enterprise), segment a schopnost, pak dále je v této kapitole vysvětleno „Co se pro tyto jednotky modeluje a proč“.

Vycházíme z faktu, že úřady a podniky ve veřejné správě architekturu, tj. strukturu prvků, jejich vazeb a chování, mají, jde jen o to ji poznat, popsat, porozumět jí a komunikovat ji. To se v různých částech úřadu, pro různé účely děje do různé podrobnosti a různou formou.

Pokud v této metodice pracujeme zejména s popisem architektury pro účel řízení návrhu a implementace změn v úřadu, pak jednotlivé úrovně popisu architektury tvoří pyramidu podle jejich míry poznání následujícím způsobem, viz také Obrázek 4:

  • Vrstvy (enterprise) architektury úřadu
    • Architektonická vize
    • Celostní modely architektur úřadu/podniku – mapa schopností, ontologie a slovník pojmů
    • Segmentové, schopnostní a doménové modely architektur úřadu/podniku
  • Vrstva architektur řešení v úřadu
    • Doménové a projektové průřezové architektury řešení
  • Vrstva návrhu konkrétních řešení
    • Design a konstrukce realizace dílčích prvků řešení

 Model vrstev architektur podniku/úřadu podle rozdílné míry detailu obsahu, zdroj: (Hrabě, 2014)

Architektonická vize je vrstvou agregovaných informací, sloužících k předání základních poselství o poznání organizace, jejího stávajícího a zejména častěji cílového stavu. Vrstva nemusí souviset přímo s jednotlivými poznanými dílčími prvky organizace. Modely vize představují vizualizaci vybraných odpovědí na strategické otázky Kam? a Proč? se organizace vydává.

Druhá a třetí vrstva spolu s vizí představují podnikovou architekturu, architekturu úřadu (EA). V těchto vrstvách je zachycena inventarizace, vizualizace a porozumění tomu, co všechno se v organizaci nachází a v jakých vazbách. Modely těchto vrstev představují odpovědi na otázky Co? a Jaké prvky? organizaci tvoří. Při popisu budoucího stavu tyto vrstvy představují informaci o tom Co? a Proč? strukturu systému organizace do budoucna tvořit má.

Celostní architektura úřadu je nositelem celostního pohledu na úřad / podnik. Představuje výčet všech typů objektů (konceptů), které se v organizaci vyskytují, ať již jsou dále v strategických, segmentových a schopnostních architekturách modelovány či nikoli. Tento přehled typů objektů je základem pro slovník pojmů, spojovaných s architekturou, tedy se strukturou a chováním organizace.

Současně je tato struktura organizace vyjádřena jejím úplným meta-modelem, nebo jinak zvaným ontologickým modelem. Tato vrstva enterprise ontologie20) a pojmového slovníku by také mohla být označena jako meta-architektura úřadu. Z tohoto ontologického modelu organizace jsou postupně vybírány objekty (například proces, služba aplikace, organizační jednotka atp.), které jsou předmětem inventarizace současného stavu a plánování stavu budoucího.

Součástí celostní vrstvy je i rozdělení organizace na menší jednotky, jejichž výstupy společně tvoří chování, život organizace. Hovoříme o tzv. mapě schopností21), poskytující úplný přehled o organizaci v jednom diagramu. Seskupení schopností v mapě současně ukazuje logiku a význam tzv. segmentů činnosti organizace, např. segmentů typů veřejných služeb. Zde každá jednotlivá schopnost představuje nejmenší jednotku organizace, jejíž vnitřní architektura nás na této úrovni plánování nezajímá, ale kterou můžeme v nižších, podrobnějších vrstvách dále zkoumat a poznávat.

V celostní vrstvě se nalezené objekty zachycují společně, modely se nedělí na segmenty ani na domény.

Průřezová nebo doménová architektura úřadu (strategická, segmentová nebo schopnostní) je třetí vrstvou architektury úřadu, představující těžiště obsahu popisu architektury v jednotlivých tradičních (červeně orámované) i v méně obvyklých doménách, viz následující Obrázek.

Poznání je v této vrstvě zaměřeno výhradně na existenciální aspekty všech prvků architektury úřadu a jejich vazeb (že existují, jak jsou staré, odkud pocházejí, kdo za jejich existenci odpovídá, jak dlouho budou ještě k dispozici apod.).

 Pyramidální model architektur úřadu / podniku podle účelu a míry podrobnosti informací, zdroj: (Hrabě, 2014)

Tento obrázek představuje kombinaci šedého pyramidálního modelu a barevného doménového modelu, představeného společně s podrobnějším popisem domén architektury úřadu v následující části.

Architektura řešení22) již není považována za součást tzv. (enterprise) architektury úřadu, ale do velké míry na ni navazuje. Architektura řešení představuje vrstvu architektury vysvětlující, jak prvky tvořící organizaci fungují, jaká je jejich vnitřní výstavba, jak společně reagují na konkrétní potřebu (řeší ji). Její modely tedy představují vizualizaci odpovědí zejména na otázku: Jak funguje?, respektive: Jak to má fungovat?. Architektury řešení musí vyhovovat architektonickým principům architektur úřadu / podniku z vyšších vrstev pyramidálního modelu.

Architektury řešení jsou obvykle dílčí, pokrývající část řešených problémů a změn organizace (program, projekt), které odpovídají jednotlivým dílčím potřebám a příležitostem ke změně. Architektury řešení jdou často napříč více architektonickými doménami, ale mohou být i uvnitř jediné z nich. Jsou typicky platné pro dílčí část segmentu nebo pro schopnost veřejné správy a již nemusí být a nebývají celo-úřadové. Nebo pokrývají skupinu prvků architektury, majících něco společného, třeba jsou řešeny aplikacemi na jedné platformě. Do vrstvy architektury řešení patří i doménové architektury, které jsou svojí mírou detailu popisu dotaženy až na odpovídající úroveň podrobnosti. Často takto vzniknou postupně, složením příspěvků jednotlivých projektů řešení.

Domény architektur řešení mohou přesně odpovídat doménám architektury úřadu, viz následující Obrázek, kde modře orámované domény představují detailní rozpracování tradičních domén TOGAF. Domény architektur řešení v řadě případů budou odpovídat dílčím manažerským disciplínám, jako je BPM23), EPM24) nebo QM25) a budou využívat odpovídající nástroje a notace.

Design řešení26) představuje vrstvu architektury přinášející detailní poznání o tom, jak lze dílčí prvek architektury vytvořit, vyrobit, jak uvést do provozu jednotlivý konkrétní prvek architektury úřadu. Může jít o návrh změny pracovního postupu (proces), zadání programování SW komponenty, vzorec pro výpočet ukazatele výkonnosti apod. Modely designu řešení představují vizualizaci odpovědí na otázku Jak je to udělané?, respektive Jak to má být udělané?. Tyto konstrukční dokumenty sice již nepředstavují artefakty architektury, ale tvoří spolu s nimi jednotnou soustavu znalostí o úřadu/podniku a i ony by měly být vytvářeny v souladu s poznatky a povinnými náležitostmi vyšších vrstev architektur úřadu.

Zaměření a obsah národních architektur v jednotlivých zemích se vzájemně liší a časem se mění. Pro Národní architekturu VS ČR je navrženo již od počátku zahrnout do rámce NAR následující architektonické domény, viz také následující Obrázek.

Horizontální (hlavní, klíčové27)) domény architektur vyjadřují všechny základní prvky existence organizace, tj. její fungování a její zdroje (zde stále zaměřené převážně na IT zdroje). Tedy koncepty poskytující odpověď na otázku Co tvoří naši organizaci?:

  • Byznys architektura – tedy architektura všech součástí výkonu veřejné správy a podpůrných provozních funkcí, zejména zaměřená na procesy, služby, organizaci, role a zodpovědnosti.
  • Architektura informačních systémů, členěná na:
    • Informační (datovou) a
    • Aplikační architekturu
  • Technologická architektura, pro potřeby VS ČR dělená dle čtyřvrstvé vize architektury na:
    • architekturu IT technologií, také zvanou platformovou a
    • architekturu komunikační infrastruktury

Vertikální domény motivační architektury, doplňují a protínají horizontální architektury a poskytují odpovědi na otázku Proč je naše organizace taková, jaká je?, respektive Proč by měla být jiná než je?:

  • Architektura strategie a směrování, původně také zvaná jenom motivační architektura
  • Architektura výkonnosti, měřící dosahování strategie i provozní efektivity
  • Architektura rizik a bezpečnosti – postihující specifické bezpečnostní aspekty napříč doménami
  • Architektura shody s pravidly, standardizace a dlouhodobé udržitelnosti

V tomto rozdělení je navrženo mimo jiné to, že do samostatné domény architektury strategie a směrování jsou z byznys architektury dle TOGAF přesunuty koncepty motivace. Z oblastí, které například TOGAF považuje za součást obsahu metamodelu obsahu (ACF28)), ale nemodeluje je jako architekturu, byly ve shodě s ArchiMate do domény architektury „Shody s pravidly29)“ převzaty některé negativně motivující (limitující) koncepty jako jsou omezení a předpoklady. V případě architektury pro VS ČR se zejména jedná o zákony formulující obsah tzv. agend. Následně jsou v téže doméně umístěny formulované (prohlášené) závazné standardy architektury. Třetí součástí jsou, u organizací, které se zabývají udržitelností (CSR30), TUR31), MA2132)) pravidla kritéria udržitelnosti.

Tento návrh struktury domén architektonického rámce je pro NA VS ČR výhodný zejména proto, že jako kombinace dvou ve veřejných správách nejvíce užívaných standardů TOGAF a FEAF (v nejnovější modifikaci pro GEA-NZ 3.2) usnadňuje prvotní zavedení podnikové architektury do praxe veřejné správy ČR a podpoří její první cíl, kterým je efektivní správa ICT VS. Následně je toto rozvržení domén otevřené do budoucna pro rozvoj dle potřeb užití NA VS ČR stále větší měrou pro vlastní reformu VS.

 Rozvržení domén obsahu architektonického rámce NA VS ČR, zdroj MV, s využitím (Hrabě, 2014)

Barevnost rozvržení domén NA VS ČR, viz předchozí Obrázek, není náhodná. Barvy tradičních vodorovných domén (vrstev) dle TOGAF/ArchiMate přebírají barevnost vrstev jazyka ArchiMate (Lankhorst, et al., 2009), barvy vertikálních domén jsou převzaty ze schématu referenčních modelů GEA-NZ 3.2 (Deleu, 2014).

Tabulka33)) definice barev prvků v doménách dle NAR

Doména Název barvy Definice barvy (RGB)
Červená (R) Zelená (G)Modrá (B)
Strategické směrování Fialová 204 204 255
Výkonnost Oranžová 255 212 175
Bezpečnost Šedá 192 192 192
Standardizace a shoda s předpisyModrá 175 212 255
Byznys Žlutá 255 255 175
Aplikační Tyrkysová 175 255 255
Technologická Zelená 175 255 175
Fyzická a komunikační Zelená 175 255 175
Implementační a
migrační
Světle červená255 224 224

Ve vztahu k barvám motivační a strategické domény ArchiMate vzniká konflikt. Dočasně bude řešen tak, že prvky vertikálních (motivačních) domén si ponechají barvy konceptů z jazyka ArchiMate, jimiž nebo jejichž specializacemi jsou vyjádřeny. Tak, jak poroste význam a rozsah konceptů zejména v bezpečnostní a standardizační doméně, lze předpokládat, že se jejich barevnost vyřeší i na úrovni světových standardů, jinak bude vyřešena v dalších verzích NAR.

Zvláštní pozici ve struktuře architektonických domén zaujímá tzv. Datová architektura. Pro TOGAF je jednou ze dvou rovnocenných složek architektury IS, ale jazyk ArchiMate ji vůbec nezná (specificky ji neformuluje). Stejně tak vize čtyřvrstvé architektury eGovernmentu s datovou architekturou nepracuje. Ve shodě se všemi těmito předpoklady metodika NAR datovou architekturu většinou považuje za implicitní součást architektury IS, ve vybraných případech ji zdůrazňuje samostatně, viz například Rámec obsahu a výstupu architektur a předcházející Obrázek.

Světle červená oblast v předcházejícím Obrázeku představuje tzv. Doménu implementace a migrace, odpovídající Implementačnímu a migračnímu rozšíření ArchiMate, a umožňující vizualizovat také balíčky práce, projekty, programy a jimi dosahované změny stavů architektury (přechodné a cílové). I zde můžeme hovořit o doméně modelu organizace, zaměřené na dynamické, projektově orientované objekty řízení úřadu, resp. jeho změn.

Prací centrálních i místní architektů veřejné správy bude vznikat celá řada modelů různého významu při řízení úřadů. Některé modely slouží jako definiční nebo podpůrné při tvorbě architektur úřadů, jiné jsou výsledkem vlastní práce úřadů a představují jejich unikátní soubor poznání. Aktuálně rozlišujeme tyto kategorie modelů:

  • Metamodel
  • Referenční modely
  • Společné (sdílené) modely, včetně modelů povinných vzorů
  • Zobecněné (anonymizované) příklady
  • Individuální modely

Některé výstupy architektury, například standardy protokolů komunikace IS nebo standardy porovnávání výkonnosti procesů VS, budou závazné napříč celou veřejnou správou, jiné budou závazné například jenom pro výkon státní správy, ale už nikoli pro územní samosprávy. Některé části obsahu architektury nebudou závazné nikde a budou mít pouze popisný a doporučující charakter. Takové koncepci se v zahraničí říká „federativní architektura“ a povinnosti dané zákony jsou v ní dobře patrné.

Z hlediska obecnosti, jednoty a účelu jednotlivých modelů bude obsah architektury členěn na:

  • Referenční modely (RM) - vyjadřující zobecnění nejlepších praxí aplikovaných na realitu české VS a klasifikační hierarchie jednotlivých domén na úrovni celého národního rámce. Na této úrovni se nevyskytují žádné konkrétní obsahy architektur (ani As-Is, ani To-Be). Tato vrstva je povinně referenční na meta-úrovni, tj. přináší povinné klasifikace a povinné formy vyjádření modelů. Zkráceně jde referenční klasifikaci a formu modelování.
  • Společný (sdílený) obsah - modely zahrnující ty součásti architektonických modelů, které organizace na různých úrovních veřejné správy musí nebo mohou sdílet, nebo je musí implementovat identicky. Tato vrstva je povinně i dobrovolně referenční pro obsahy To-Be architektur a je prostředkem zajištění konzistence celkové To-Be architektury veřejné správy. Zkráceně jde o referenční obsah architektury.
  • Individuální modely (IM) – nejdůležitější modely v úložišti úřadu, tj. vlastní modely vyjadřující koncepce rozvoje jednotlivých organizací VS, vytvořené s metodickou podporou NAR, podle povinných referenčních informací z hlediska formy i obsahu a v souladu s Národním architektonickým plánem (NAP) a jeho harmonogramem.

Všechny tři podoby a míry referencovatelnosti architektur jsou platné napříč všemi vrstvami pyramidy struktury i všemi doménami NA VS ČR, jak upozorňují obě ikony vpravo v každém řádku schématu, viz následující Obrázek.

 Členění obsahu NA VS ČR z hlediska referencovatelnosti, zdroj: (Hrabě, 2014), aktualizace MV

Výše uvedenou strukturu modelů doplňují ještě tzv. modely modelování - metamodely a pro akceleraci zavedení EA velmi žádané praktické příklady:

  • Metamodel a slovník pojmů – definiční modely (modely modelů) přináší tato metodika a předpokládáme, že v úložišti modelů každého úřadu budou uchovávány pro informaci o metodice NAR. Ten ale předpokládá, že vedle závazného metamodelu, pro celostátní výměnu modelů, bude možné si v jednotlivých úřadech metamodely rozšiřovat tzv. specializací, viz například Rámec obsahu a výstupu architektur.
  • Zobecněné příklady – s postupem úspěšných pilotních projektů bude přibývat modelů a diagramů tak kvalitních, že budou sloužit jako příklad. Svým charakterem jsou to individuální modely, ale mnohdy budou zobecněné, anonymizované, takže už u nich nebude patrný konkrétní modelovaný úřad. Tyto modely nejsou pro nikoho závazné, slouží pro inspiraci jako nositelé praktické zkušenosti. Takové se budou šířit jak centrálně směrem od OHA, tak komunitně mezi úřady navzájem.

Vyjádření změn architektur v průběhu času a sledování vývoje architektur od plánovaného stavu k jeho dosažení je obtížnou architektonickou úlohou, pojatou v TOGAF dvěma různými myšlenkovými koncepcemi a nepodporovanou přímo žádnou součástí specifikace ArchiMate.

TOGAF v metamodelu rozlišuje mezi tzv. Logickými a Fyzickými komponentami u aplikační a technologické architektury, ne tak již u byznys architektury nebo datové architektury. Logické komponenty jsou obecné, předpokládané, existující jenom nehmotně jako součást koncepce. Fyzické komponenty jsou konkrétními instancemi logických, mají svá jména, dodavatele, verze, měřitelné atributy apod.

Vedle toho doporučuje TOGAF dělit architektonické poznání do tzv. stavebních bloků, určených pro opakované využití v návrzích i v realitě. Zatímco architektonické stavební bloky (ABB34)) předepisují, jaký typ komponenty (nebo funkce, služby apod.) má být použit pro typový účel, pak stavební blok řešení (SBB35)) ukazuje, jak již je to konkrétně uděláno a co je možno znovu použít.

Za architektonický stavební blok (ABB) je možno označit primárně tzv. logickou komponentu, a za stavební blok (SBB) řešení tzv. fyzickou komponentu. Komplikovanější je to u konceptů (objektů), u nichž metamodel TOGAF fyzické/logické nerozlišuje.

V praxe české veřejné správy ukázala potřebu používat společně v modelech a diagramech architektury úřadu architektonické stavební bloky i stavební bloky řešení, a to i přesto, že to notace ArchiMate nepodporuje, pouze od verze 3.0 doporučuje své koncepty tomuto přístupu přizpůsobit tzv. specializací do stereotypů. Záměrem je dostat obojí do týchž diagramů, aby mohly být mezi sebou porovnávány jejich plánované a skutečně dosažené atributy.

Návrh metodiky NAR se tak v této části obrací k doporučením „Enterprise Continua“ dle TOGAF, zpočátku pro jeho vertikální členění na ABB a z nich plynoucí SBB, bez ambice klasifikovat zleva doprava podle míry obecnosti36).

Doporučuje se pohlížet na ABB a SBB trojím pohledem a realizovat je v modelu třemi způsoby:

(1) pomocí stereotypů core objektů ArchiMate, zejména u konceptu aplikace, které jsou předmětem takovéto klasifikace,

(2) pomocí sady atributů těchto objektů, které jsou odlišné u ABB (obecnější) a u SBB (konkrétnější), přičemž jeden a týž objekt (instance konceptu) může nakonec nést obě takové sady (profily),

(3) prostřednictvím katalogu, seznamu, do něhož lze vyfiltrovat prvky, označené příznakem jako ABB nebo SBB a ukázat přehledně jejich atributy – tedy výpis z Enterprise Continua.

ABB velmi výrazně odpovídají v TOGAF uváděným „logickým aplikačním komponentám“, kdežto SBB se velmi shodují s „fyzickými aplikačními komponentami“. Podle TOGAF by v jednom modelu mohly být oboje, v ArchiMate to bez „zdvojení“, tj. specializace objektů metamodelu není možné.

Podle NAR v jednom modelu (nikoli jen v diagramu) ArchiMate musí být každá v realitě úřadu existující „věc“, například aplikační komponenta, uvedena jenom jednou, tj. není přípustné zachytit „box“ jak pro ABB, tak pro SBB v jednom modelu. Proto ABB rozdělíme na dvě kategorie: kandidátské ABB a generické ABB.

  • Kandidátský ABB je předchůdcem, dočasným zástupcem cílového SBB v individuálním modelu v době, kdy ještě není znám dodavatel a jeho řešení. Představuje logickou komponentu, dokud není k dispozici fyzická. Proto může být součástí modelu individuální (ostré) architektury úřadu. V průběhu implementace se mu budou měnit statusy a nakonec se tento prvek ArchiMate stane SBB, ale ponese se si i předchozí profil ABB (bude možnost srovnání).
  • Generický ABB je vzorem pro více implementací (SBB) a/nebo má být vizualizován i po jejich implementaci. Takový prvek modelu v ArchiMate může být modelován samostatným Boxem, ale výhradně v modelu referenční architektury, tj. v samostatném modelu (package). V žádné inventurní sestavě aplikačních komponent úřadu z EAM repozitory tak nebudou „vyjíždět“ oba, ABB i SBB. Nebude (nesmí) tak vznikat mylný dojem jiného počtu a struktury aplikací, než je skutečný.

V případě potřeby je možno vytvořit diagram, čerpající objekty z obou modelů současně, tj. z individuálního i referenčního, a tak i graficky vyjádřit potřebné srovnání.

Vedle použití pojmu stavebního bloku z TOGAF pro obecné řízení architektury se v NAP tento pojem používá v užším a přesnějším vymezení jako Stavební blok eGovernmentu:

Stavebním blokem eGovernmentu nazýváme takový funkční celek (nebo případně jeho část), který:

a) poskytuje centrální sdílené funkce (jako služby) všem (více, mnoha) aktérům (účastníkům) eGovernmentu, nebo mnoha ostatním funkčním celkům, nebo

b) představuje mnohokrát opakovatelný vzor jednotných lokálních funkčních celků

c) vždy je spravován s centrální zodpovědností (governance).

Každý z výše uvedených výseků či přehledů architektury úřadu je možno vyjádřit pohledy, tj. tabulkami (Katalogy a Matice) nebo graficky (Diagramy) na libovolné úrovni podrobnosti.

Pro zachování zpětné kompatibility k prvotní koncepci modelování projektu konsorcia e2020 z roku 2014 a předejití pojmovým konfliktům při použití referenčních modelů tohoto projektu je v této kapitole uvedeno modifikované vysvětlení původních tzv. úrovní „Agregačních úrovní“ L0, L1 a L2“, upravené s respektem k definicím TOGAF, záměrně v přehozeném pořadí:

  • L1Základní úroveň pohledu na architekturu úřadu - běžná úroveň pohledu na příslušnou strategickou, segmentovou nebo schopnostní architekturu modelovaného úřadu. Podstatou pohledu úrovně L1 je, že naplňuje základní účel architektury úřadu, tedy vizualizuje všechny inventurou nalezené nebo do budoucna projektované výskyty určitých konceptů (prvků) modelu a vazby mezi nimi. Obvykle se však v této své celistvosti zaměřuje pouze na několik vybraných konceptů (prvků metamodelu) architektury úřadu. Například na aplikační komponenty, jejich služby a rozhraní.
  • L0Přehledová úroveň pohledu na architekturu úřadu - nejvyšší úroveň pohledu na modelovaný úřad jako celek. Tato úroveň pohledu na model organizace představuje vyjádření principu nebo přehledu modelu. Jejím typickým rysem je, že pro zdůraznění strategického principu vyzdvihuje pouze podstatné výskyty určitých konceptů modelu a ty méně podstatné vynechává. Případně místo vizualizace konkrétních výskytů (instancí) vizualizuje princip (přehled) pomocí nadřazených klasifikačních kategorií referenčních modelů a pomocí skupin objektů.
  • L2 - Detailní úroveň pohledu na model architektury úřadu - Úroveň L2 rozvíjí do ještě většího (plného) detailu přidáním dalších konceptů metamodelu a jejich atributů strategický, segmentový pohled ale zejména schopnostní pohled na jednotný celostní model architektury úřadu. Například v aplikační architektuře přidává spolupráci aplikací a více úrovní vnitřních funkcí aplikací.

Aktuální metodika nepředepisuje povinnou míru podrobnosti diagramů, výše uvedené úrovně jsou do praktického ověření pilotními projekty pouze doporučeny. Praxe pilotních úřadů ukazuje, že používání různých úrovní podrobnosti pro jinak totéž hledisko (definici pohledu) je i nadále účelné.

Všechny i dílčí modely úřadu musí být vytvářeny a všechna architektonická rozhodnutí činěna s vědomím informací o architektuře prostředí, jehož je úřad součástí, tzv. v jejich kontextu.

Velmi často budou v úřadu modelovány dílčí segmentové a schopnostní architektury nebo čtyřvrstvé architektury funkčních celků ISVS (tzv. full-stack). Úrovně, obálky či slupky jejich kontextů lze definovat na následujících úrovních:

  • Kontext celkové architektury vlastního úřadu nebo organizace VS
  • Kontext architektury veřejnoprávní korporace (resortu, kraje, ORP), pokud je úřad jejich součástí, zejména korporátních sdílených služeb (i potenciálních)
  • Kontext architektury prvků centrálních sdílených služeb eGovernmentu ČR
  • Kontext architektury prvků centrálních sdílených služeb eGovernmentu EU
  • Kontext architektury na straně typových klientů a partnerů při dodávce veřejné služby.

Vybrané základní kontexty pro běžný úřad graficky znázorňuje následující Obrázek.

Pro OVS v roli ohlašovatele agendy v přenesené působnosti jsou důležité kontexty architektur všech jednotlivých nebo typových úřadů, na něž svou působnost přenáší. To se projeví v jeho tzv. rozšířených modelech (ROZS).

Pro každý OVS, který je správcem nějaké samoobslužné digitální služby, je důležitý kontext architektur typových klientů této služby.

 Širší kontexty modelů architektury úřadu, zdroj: (OHA MV ČR, 2016).

Proces tvorby architektur

Poté, co předchozí kapitoly definovaly Co?, tedy v jaké organizaci a jaké součásti architektury úřad modeluje, stanovuje tato kapitola Jak? přesně se u toho má postupovat v celém životním cyklu architektury.

Z dvojice disciplín 1) management architektury a 2) governance architektury se tato kapitola zaměřuje na procesy obou, ale struktury, orgány a vybrané funkce obou jsou v samostatné kapitole.

Pro proces tvorby architektur převzala metodika NA VS ČR cyklus z metodiky TOGAF ADM (The Open Group, 2018). Ten je rozdělen na fáze a ty dále na kroky, vysvětlené v popisu jednotlivých fází. V každé fázi je třeba vždy kontrolovat, zda výstupy a výsledky fáze odpovídají očekávání celého angažmá a metodickým požadavkům na danou fázi. V cyklu metodiky ADM se nacházejí následující fáze:

Předběžná fáze (Preliminary Phase), která popisuje přípravu a zahájení činností potřebných pro promítnutí byznys potřeb do architektury, včetně přizpůsobení architektonického rámce a definice principů a okrajových podmínek.

Fáze A: Architektonická vize (Architecture Vision) popisuje úvodní fázi architektonického cyklu. Zahrnuje definici rozsahu, poznání zájmových skupin, vytvoření architektonické vize a získání souhlasů k architektonickému záměru.

Fáze B: Byznys architektura (Business Architecture) popisuje vývoj architektury podnikání, poslání organizace na podporu dosažení stanovené vize.

Fáze C: Architektura IS (Information Systems Architectures) popisuje postup vývoje architektury IS, zahrnující aplikační a datovou architekturu.

Fáze D: Technologická architektura (Technology Architecture) popisuje vývoj architektury IT technologické infrastruktury.

Fáze E: Příležitosti a řešení (Opportunities & Solutions) provede počáteční plánování implementace a identifikaci prostředků dodávky architektonických změn, definovaných v předchozích fázích.

Fáze F: Plánování přechodu (Migration Planning) představuje detailní plánování potřebných implementačních kroků.

Fáze G: Kontrola (řízení) implementace (Implementation Governance) představuje architektonický dohled nad průběhem implementace.

Fáze H: Řízení architektonických změn (Architecture Change Management) ustavuje procedury pro řízení změn architektury.

Správa požadavků (Requirements Management) představuje vazbu procesů řízení IT požadavků a procesů řízení změn architektury. Fáze Správy (architektonických) požadavků je průběžná. Výstupy jedné fáze mohou (nebo dokonce mají) být upraveny fázemi následujícími.

 Přehled fází tvorby architektury dle TOGAF ADM, zdroj: (The Open Group, 2018), překlad MV

ADM je postaveno na iteraci mezi jednotlivými procesy. Cílem těchto iterací je vybudovat optimální architekturu. Každá iterace je uvozena rozhodnutím o tom, co by mělo být pokryto daným architektonickým angažmá, jaká úroveň detailu je požadována a v jakém časovém výhledu by se mělo dojít k cílové architektuře (výsledku iterace). Pochopitelně je zároveň specifikováno, jakých architektonických standardů (komponent) bude využito a za jakých omezujících podmínek.

 Seskupení fází cyklu ADM vývoje architektur, podle (The Open Group, 2018) návrh MV

Metodika TOGAF ADM předpokládá, že bude upravována na míru organizace, což platí i pro českou veřejnou správu. Úprava ADM pro NA VS ČR je popsána níže.

Před zahájením každé dílčí architektonické práce v úřadu je třeba znovu provést níže uvedená rozhodnutí a nastavit parametry tohoto angažmá.

Metodika ADM je iterativní proces, s iteracemi mezi fázemi i uvnitř každé fáze. Pro každou iteraci v ADM, pro každé jednotlivé nové architektonické zadání (angažmá) v úřadu/ podniku musí být předem, v Požadavku na architektonickou práci37), viz vzor ve Znalostní databázi, stanoveno (The Open Group, 2018):

  • šířka pokrytí úřadu/podniku architektonickým angažmá, jak z pohledu částí úřadu (enterprise) - STR/SGM/SCH, tak z hlediska kontextu architektury v korporaci a řetězci dodávky veřejných služeb - VLST/SPOL/ROZS
  • požadovaná míra (hloubka) modelovaného detailu (EA nebo SA, asi nikoli SD) a (L0-přehled/L1-základ/L2-detail)
  • časový horizont cílové architektury (např. typicky 1 rok a 5 let)
  • modelované domény (motivační a BADT38)) a jejich koncepty
  • architektonické vstupy, ať již to jsou výsledky předchozích fází nebo předchozích cyklů v úřadu nebo architektonické materiály odkudkoli, třeba referenční modely z OHA MV nebo ze světa.

Nad rámec standardu TOGAF stanovuje tato metodika NA VS ČR, aby již v předstihu před zahájením angažmá byly v Požadavku na architektonickou práci specifikovány:

  • Základní zainteresovaní (stakeholders) vedle sponzora, který se k nim řadí automaticky, jejich potřeby a základní architektonické artefakty a výstupy, kterými mohou být naplněna jejich očekávání.

Definitivní a závaznou specifikaci výstupů přinese vždy až schválené tzv. Zadání pro architektonickou práci39), které je odpovědí týmu architektury úřadu na Požadavek na architektonickou práci a skutečným zadáním následujícího projektu tvorby architektury.

Primárně se jedná o rozhodnutí, zda na požadovaný záměr zadavatele odpovídá architektura uvnitř úřadu/ podniku (enterprise) nebo jeho části (segmentu, schopnosti), anebo společně s externími partnery, dodavateli a úřady bude modelován tzv. rozšířený úřad/podnik. Je tedy podstatné, zda je v daném architektonickém angažmá bude jednat o VLST40), SPOL41) nebo ROZS42).

Při každém architektonickém zadání pro individuální modely uvnitř úřadu (enterprise) je třeba rozhodnout, zda se bude jednat o celostní, strategickou architekturu nebo segmentovou či dokonce pouze schopnostní architekturu.

Vždy je ale důležité respektovat zásadu, že i jakkoli dílčí architektura se modeluje s vědomím plného architektonického kontextu úřadu. S prvními dílčími angažmá je nutné vytvořit i základní přehledové diagramy (mapy) jednotlivých vrstev architektury celého úřadu, jinak není možné plnohodnotné architektonické rozhodování.

Pro modely v rámci NA VS ČR platí, nebude-li v Požadavku na architektonickou práci specificky odůvodněno jinak, že pro každé architektonické angažmá dle rozsahu v předchozím bodu se modeluje tzv. architektura podniku/úřadu. Tedy úroveň podrobnosti „Enterprise Architecture“, modelující všechny výskyty schopností, procesů, aplikací, platforem apod. dle metamodelu NA VS ČR, které se v daném rozsahu organizace (celku, segmentu nebo dílčí schopnosti) aktuálně nacházejí nebo cílově mají nacházet. Tedy z hlediska podrobnosti diagramu je standardně očekávána tzv. úroveň L1 – Základní. U každého inventarizovaného nebo projektovaného objektu se ale model ptá pouze po jeho existenci a po několika s existencí zásadně spojených atributech, například zda je aplikační komponenta zakoupena nebo naprogramována, od koho, kdy vznikla a kdy bez podpory zanikne, případně zda je součástí strategické infrastruktury státu atp.

Podle potřeby ze zadání angažmá je možno základní diagramy modelu doplnit přehledovými-L0 a detailními L2 diagramy.

Pouze pro v architektuře úřadu identifikované vybrané příležitosti pro změny nebo pro potřeby zpětné dokumentace existujících řešení mohou následně v dalším architektonickém cyklu (se samostatně specifikovaným zadáním) vznikat architektury řešení úřadu, s úrovní podrobnosti „Solution Architecture“. Ty u změn určených k realizaci odpovídají na otázku: „Jak to má fungovat (uvnitř - funkce a vně - služby)?“ a představují v podobě úplných funkčních i ne-funkčních specifikací, katalogů služeb a dalších detailních architektonických artefaktů zásadní podklady pro výběr a uzavření smlouvy s interním nebo externím dodavatelem realizace změn (vč. implementace informačních systémů).

Konkrétní návrh konstrukce a výrobního postupu řešení „Solution Design“ se již v zodpovědnosti útvarů architektury úřadu nikdy netvoří. Výjimkou jsou situace, kdy povinný vzor (pattern) musí z důvodů stanovených OHA sahat až na úroveň detailního vzoru designu řešení. Pak musejí architekti úřadů být schopni prokázat, že i na této úrovni byl povinný vzor dodržen a musí se zabývat návrhem nebo kontrolou (při návrhu ze strany dodavatele) designu řešení ve spojení s tímto vzorem.

Při každém architektonickém angažmá je třeba rozhodnout, v jakém časovém horizontu (za jak dlouho) se má nacházet cílová navrhovaná architektura. Délku požadovaného horizontu na jedné straně prodlužuje požadavek dlouhodobé stability návrhu, na druhé straně ji zkracuje přirozená neschopnost predikovat cokoli na dobu delší cca tří let (zejména pak v IT oblasti).

Skutečná délka časového horizontu architektonického angažmá vyplývá z potřeby zvládnout splnit požadavky zadavatele (manažerského sponzora změny). Přirozeně se ve VS horizont odvozuje od politicko-hospodářských milníků, ty představují tzv. horizont pevný (absolutní). Pro aktuální NA VS ČR je v souladu s evropskými i národními strategickými dokumenty takovým absolutním pevným horizontem rok 2020, následně rok 2023 (5 let IK ČR) a rok 2030.

Vedle toho je třeba, aby architektura úřadu vždy přinášela dostatečný informační předstih a podklad pro rozhodování. Proto tato metodika stanovuje, že jako další milník cílové architektury se musí používat horizont klouzavý (relativní), stanovený na dobu 5 let od předložení architektury ke schválení. To platí zejména pro celkovou architekturu úřadu vytvořenou pro účely aktualizace jeho Informační koncepce OVS, která je taktéž na 5 let.

Realizace architektur se děje po krocích, odpovídajících rozvojovým programům a projektům. Každý z nich po úspěšném završení posouvá stávající stav do nejbližšího projektovaného budoucího stavu architektury. Takovým časovým řezům architektur se říká přechodové (stavy) architektury. Vzhledem k přetrvávajícímu ročnímu řídícímu (a rozpočtovému) cyklu ve VS ČR a k omezené míře předvídatelnosti věcí budoucích, je stanoveno, že cesta k cílovému horizontu architektury úřadu (2020, 2023, 2030 nebo 5 let) musí být povinně rozdělena přinejmenším do přechodových architektur odpovídajících 1. a 2. roku jejich realizace. Vedle toho musí být možné prezentovat z architektonického modelu v úložišti úřadu (nebo posléze v centrálním národním úložišti) projektovanou přechodovou architekturu úřadu ke každému milníku dokončení realizačního projektu či programu.

Pro všechny architektury úřadu/podniku v rámci NA VS ČR platí, že budou s týmž klouzavým (relativním) horizontem (5 let, odpovídajících rozpočtovému výhledu) aktualizovány na úrovni strategické architektury úřadu pravidelně každý rok tak, aby identifikované (a upřesněné) transformační projekty na následující rok mohly sloužit jako kvalifikovaný podklad pro vyjednávání o struktuře a výši rozpočtu.

Pro modely architektury pro jednotlivá architektonická angažmá v úřadech se v rámci koncepce NA VS ČR předpokládá, že budou vždy obsahovat popis architektury (modely a artefakty) ve všech jejích doménách, viz Struktura modelovaných architektur. To platí bez výjimek přinejmenším pro pravidelně aktualizovanou celkovou strategickou architekturu úřadu.

Ne vždy budou úřady disponovat dostatečným časem, schopnostmi, kapacitami či prostředky na to, aby navrhly (nebo si nechaly navrhnout) všechny dílčí architektury ve všech doménách. Proto pro segmentové a schopnostní architektury, spojované s dílčími reformními nebo IT změnami není nutné navrhovat všechny domény architektur úřadu, pokud to není potřebné pro naplnění požadavků sponzora, zadavatele architektonického angažmá. Nenavrhované domény je však vždy třeba mít alespoň okrajově na zřeteli.

Příklad: Je-li zadáním sponzora navrhnout, které technologické platformové komponenty mohou být přesunuty do dvou cílových virtualizovaných datových center kraje a které dokonce do jednoho z NDC (eGC), pak IT technologická vrstva a komunikační vrstva musí být úplné, ale aplikační vrstva stačí jenom naznačena a datová, byznys, motivační a výkonnostní vrstva nemusí být modelována vůbec, protože se jako součást zadání angažmá předpokládá, že aplikační služby a data vůči byznys a vyšším vrstvám se změnou technologických vrstev nesmí změnit.

Tato metodika ve svých aktualizacích stanovuje postupně narůstající sadu povinných a doporučených akcelerátorů (vzorů, taxonomií a referenčních modelů, návodů, příkladů). Ty podle míry závaznosti musí nebo mohou být použity ve všech odpovídajících angažmá.

Pokud je možnost volby nebo pro dané angažmá odpovídající akcelerátory koncepce ještě nepřináší, je potřebné, aby zadání každého angažmá bylo zpřesněno i odkazem na pro něj stanovené vstupy.

Obdobně to platí i pro již existující architektonické artefakty. V každém zadání angažmá by mělo být stanoveno, na jaké dřívější architektonické artefakty a výstupy má navázat, zpřesnit je nebo nahradit.

Již před zahájením architektonického angažmá musí být v Požadavku na architektonickou práci identifikovány klíčové zájmové skupiny43), jejich požadavky a potřeby a architektonické artefakty (pohledy na model), jimiž je možné tyto potřeby naplnit, pokud to nevyplývá ze závazných podkladů pro některá angažmá, jako je například Žádost o stanovisko OHA nebo tvorba Informační koncepce OVS.

Zejména jde o to, že manažeři úřadu budou muset v souvislosti s architektonickým angažmá (na základě jeho výsledků) činit investiční rozhodnutí o realizaci změn a výstupy architektonické práce musí tato jejich rozhodování podpořit a usnadnit.

V této části je vysvětleno, které fáze metodiky ADM se uplatní, v jakém rozsahu a jak přizpůsobené v konkrétních situacích, kde se již po úřadu vyžaduje, aby doložil své znalosti o architektuře úřadu a dílčí architektuře odpovídající připravovanému řešení. Aktuálně jsou to tyto typy architektonických angažmá:

  • Návrh architektonické vize úřadu
  • Enterprise architektura projektu (PSA)
  • Podklady pro žádost o stanovisko OHA k ICT projektu
  • Aktualizace Informační koncepce orgánu veřejné správy, jako rozpracování a konkretizace Informační koncepce ČR (schválené vládou 3. 10. 2018 na základě novely zák. č. 365/2000 S.).
  • Architektura řešení (SA)

Více v následujících částech.

Zde bude doplněn návod nebo odkaz na samostatný dokument.

 Podpora žádosti o stanovisko OHA fázemi TOGAF ADM, zdroj MV s využitím (The Open Group, 2018)

Zde bude doplněn návod nebo odkaz na samostatný dokument.

Zde bude doplněn návod nebo odkaz na samostatný dokument.

V této části budou do níže uvedené struktury postupně doplňována a zde vysvětlována přizpůsobení, rozšíření a úpravy cyklu tvorby, údržby a užití NA, podle TOGAF ADM.

Aktuálně jsou takto potřebám NA VS ČR přizpůsobeny formulář tzv. Požadavku na architektonickou práci, část přípravné fáze a Architektonické principy, jako součást a nástroj fáze A cyklu. Ostatní části zatím nesou prázdnou strukturu dle originálního TOGAF ADM.

Cíle

Cílem této fáze je vykonat všechny přípravné aktivity potřebné pro zahájení jakékoli architektonické práce v úřadu. Proto se tato fáze obvykle provádí pouze jednou, na počátku budování architektonické schopnosti úřadu, případě při zásadních změnách podmínek pro architektonickou práci.

Přípravná fáze má tyto hlavní cíle:

1. Určit požadovanou architektonickou schopnost (dovednost) úřadu:

  • Ověřit organizační kontext pro budování enterprise architektury úřadu.
  • Identifikovat a určit rozsah organizací úřadu, zapojených do tvorby architektury.
  • Identifikovat už zavedené manažerské a řídící rámce, metody a procesy, které se prolínají s architektonickou schopností.
  • Stanovit cílovou architektonickou zralost.

2. Vytvořit (zavést, ustavit) architektonickou schopnost (dovednost a kapacitu):

  • Definovat a zřídit organizační model enterprise architektury.
  • Definovat a zřídit procesy a zdroje potřebné pro správu a řízení enterprise architektury.
  • Vybrat a implementovat nástroje pro podporu architektonické schopnosti.
  • Definovat architektonické principy.

Vstupy, kroky postupu a výstupy

Stanovení architektonických principů

Zde bude doplněn návod nebo odkaz na samostatný dokument.

Požadavek na architektonickou práci (PAP)

Po přípravě organizace a vybudování její schopnosti vytvářet architekturu přichází první architektonický úkol, tzv. angažmá, například sestavit architektonické podklady pro vyplnění žádosti o stanovisko OHA. Zahájení takových prací musí předcházet nalezení zadavatele (sponzora) a obdržení tzv. Požadavku na architektonickou práci architektonickým týmem. Více o Požadavku na architektonickou práci a o odpovědi na něj, tzv. Zadání pro architektonickou práci, v Proces tvorby architektur a po ní následujících.

Cíle fáze

Fáze architektonické vize zahrnuje definování rozsahu architektury, identifikování zainteresovaných (zájmových skupin44)) a vytvoření a schválení architektonické vize pro následující architektonický cyklus. Fáze A: Architektonická vize má tyto hlavní cíle:

  1. Vytvořit vysokoúrovňovou vizi schopností a hodnot, které budou dodány jako výsledek následně navrhované enterprise architektury úřadu.
  2. Získat schválené Zadání architektonické práce (ZAP), které definuje rozsah a přístup, který bude použit pro realizaci projektu architektury k rozpracování a naplnění architektonické vize.

Fáze začíná přijetím Požadavku na architektonickou práci (PAP) architektonickou kanceláří úřadu od sponzorující (požadující) organizace, oddělení.

Pro architektonickou práci AK úřadu budou využity veškeré dostupné referenční materiály, primárně poskytnuté OHA jako součást NAR a NAP, následně další zkušenosti a nejlepší praxe.

Vstupy, kroky postupu a výstupy

Architektonické principy

Architektonické principy jsou z cílů rozvoje eGovernmentu odvozená po široké diskusi odsouhlasená pravidla, která slouží primárně k tomu, aby byla plně dodržena při návrzích cílové architektury veřejné správy (a jejích informačních systémů), které tak největší měrou naplní reformní cíle strategie veřejné správy.

Rozsah uplatnění principů je stejný jako rozsah povinnosti modelovat architekturu úřadu, tj. s postupnými dalšími etapami zavádění Národní architektury VS ČR se rozšiřuje.

Pro účely NA VS ČR rozlišujeme tři kategorie principů, lišící se způsobem vlivu na návrh architektury:

  • Celkové45) principy – tedy principy, které ovlivňují reformní a investiční rozhodování a chování úřadu/podniku jako takového.
  • Architektonické principy – které určují, jaký má být správný obsah navrhované cílové architektury ve všech jejích doménách (byznys – procesní, aplikační, datové, IT technologické, infrastrukturní, bezpečnostní a posléze i výkonnostní).
  • Metodické principy – které stanovují základní pravidla postupu tvorby a užití architektury, podrobněji rozebíraná v celé koncepci NA VS ČR

Principy jsou určeny pro architekty úřadu (enterprise), architekty řešení úřadu, manažery informatiky a všechny další vedoucí pracovníky úřadů, pro politickou reprezentaci i širokou veřejnost. Principy mají zejména následující použití:

  • sada principů poskytuje informační základnu managementu úřadů pro rozhodování v oblastech eGovernmentu a řízení informatiky
  • jako kritéria pro rozhodování a hodnocení architektur řešení a výběru produktů
  • jako kritéria pro posuzování shody cílové architektury úřadu s požadavky a pro posuzování shody jednotlivých projektů
  • jako pomůcka při posuzování obojího – stávajících systémů i variant cílové architektury
  • zdůvodnění principů přináší vazbu mezi cíli, požadovaným stavem veřejné správy a nezbytnými architektonickými aktivitami
  • důsledky principů přinášejí výčet očekávaných změn, které se musí odehrát pro naplnění principů. Tento výčet může sloužit pro kontrolu, zda předložené projekty svým architektonickým obsahem a plánovanými aktivitami dostatečně vyhovují stanoveným principům.

Aktuální katalog principů Národní architektury VS ČR (a aktuálního Národního architektonického plánu NAP) byl zveřejněn jako součást vládou schválené Informační koncepce ČR, pod označeními P1 až P17. Tyto architektonické principy byly zařazeny také do formuláře žádosti o stanovisko OHA a výčet dopadů těchto principů, společně s podpůrnými kontrolními otázkami k nim, bude sloužit jako kontrolní seznam kritérií (Check-list) pro hodnocení shody předkládaných IT projektů s IKČR a NAP.

Vedle toho mají úřady možnost hledat a formulovat další principy, které jsou specifické pro jimi stanovené vlastní strategické cíle. Cílem předběžné fáze procesu tvorby architektury v každém jednotlivém architektonickém angažmá je tedy nalézt všechny současné platné a relevantní architektonické principy, pokud již existují, tj. byly formulovány - v IKČR nebo v IK OVS. Pokud nejsou dostatečné nebo aktuální, budou muset být v rámci fáze vytvořeny a aktualizovány.

Zdrojem informací pro architektonické principy v úřadu bývají vedle IKČR a IK OVS:

  • Strategie (politika) úřadu
  • IT Strategie
  • Směrnice
  • Postupy

Všechny principy jsou vzájemně provázány, musí být uplatněny jako celá sada. Občas si jednotlivé principy konkurují a vytvářejí tvůrčí napětí (například mezi širokou dostupností a důvěryhodností údajů). Výsledná rozhodnutí musí vycházet z podrobného vysvětlení požadavků a musí být vyváženým kompromisem.

Více o architektonických principech v Pokyny a techniky pro tvorbu architektury.

Analýza zainteresovaných

Zde bude doplněn popis nebo odkaz na samostatný dokument.

Návrh architektonické vize

Zde bude doplněn popis nebo odkaz na samostatný dokument.

Zadání pro architektonickou práci

Zde bude doplněn popis nebo odkaz na samostatný dokument.

Zatím nepřizpůsobeno pro NAR.

Cíle fáze

Cílem této fáze je vývoj byznys architektury služeb veřejné správy, jako rozpracování změn plynoucích ze schválené architektonické vize úřadu.

Fáze B – byznys architektura má tyto hlavní cíle:

  1. Vytvořit cílovou byznys architekturu, která popisuje, jak budou dosaženy byznys cíle úřadu, formulované prostřednictvím potřeb, strategických iniciativ (politik)46) a stanovených cílů (proveditelných úkolů).
  2. Definovat kandidáty na balíčky práce (projekty) pro architektonickou roadmapu, identifikované na základě rozdílů mezi výchozí (současnou) a cílovou byznys architekturou.

Vstupy, kroky postupu a výstupy

Zatím nepřizpůsobeno pro NAR.

Cíle fáze

Cílem této fáze je vývoj architektury informačních systémů v úřadu veřejné správy, zahrnující vývoje jejich datové a aplikační architektury.

Fáze C – architektura IS má tyto hlavní cíle:

  1. Vytvořit cílovou architekturu informačních systémů (dat a aplikací), která popisuje, jak IS umožní realizaci byznys architektury a architektonické vize.
  2. Definovat kandidáty balíčky práce (projekty) pro architektonickou roadmapu, identifikované na základě rozdílů mezi výchozí (současnou) a cílovou architekturou IS (datovou a aplikační).

Vstupy, kroky postupu a výstupy

Zatím nepřizpůsobeno pro NAP.

Cíle fáze

Cílem této fáze je vývoj technologické architektury, která zahrnuje HW, SW a komunikační infrastrukturu.

Fáze D – technologická architektura má tyto hlavní cíle:

  1. Vytvořit cílovou technologickou architekturu, která umožní realizaci logických a fyzických aplikačních a datových komponent a architektonické vize.
  2. Definovat kandidáty balíčky práce (projekty) pro architektonickou roadmapu, identifikované na základě rozdílů mezi výchozí (současnou) a cílovou technologickou architekturou.

Vstupy, kroky postupu a výstupy

Zatím nepřizpůsobeno pro NAP.

  • Cíle fáze

Cílem této fáze je identifikovat projekty, programy nebo portfolia, která efektivně dodají cílovou architekturu definovanou v předcházejících fázích.

Fáze E - Příležitosti a řešení má tyto hlavní cíle:

  1. Generovat počáteční (iniciální) úplnou verzi architektonické roadmapy, založené na rozdílových analýzách a kandidátských komponentách pro architektonickou roadmapu, definovaných ve fázích B, C a D.
  2. Určit zda je potřebný postupný přístup po krocích a pokud ano, pak definovat tzv. přechodné architektury, která zejména zajistí průběžnou dodávku byznys hodnoty.

Vstupy, kroky postupu a výstupy

Zatím nepřizpůsobeno pro NAP.

Cíle fáze

Cílem této fáze je definovat migrační plány, jak se dostat ze současné do cílové architektury.

Fáze F – plánování migrace má tyto hlavní cíle:

  1. Finalizovat architektonickou roadmapuimplementační a migrační plán.
  2. Zabezpečit, aby implementační a migrační plán byl koordinovaný s ostatními přístupy řízení a zavedení změn v organizaci.
  3. Zabezpečit, aby byznys hodnota, cena realizace a případné přechodové architektury byly pochopené klíčovými zainteresovanými.

Vstupy, kroky postupu a výstupy

Zatím nepřizpůsobeno pro NAP.

Cíle fáze

Cílem této fáze je architektonický dohled nad implementací architektury.

Fáze G – Dohled na zavedení má tyto hlavní cíle:

  1. Zabezpečit soulad výstupů implementačních projektů s cílovou architekturou (architektonický dohled).
  2. Vykonat příslušné governance architektury pro řešení a jakékoli implementací řízené architektonické požadavky na změny.

Vstupy, kroky postupu a výstupy

Zatím nepřizpůsobeno pro NAP.

Cíle fáze

Cílem této fáze je zavedení procedur pro řízení změn nové architektury.

Fáze H – Řízení změn má tyto hlavní cíle:

  1. Zajistit, aby architektonický cyklus byl udržovaný.
  2. Zajistit, aby rámec dohledu architektury byl naplňován.
  3. Zajistit, aby EA schopnost rostla v souladu s aktuálními požadavky.

Vstupy, kroky postupu a výstupy

Požadavek na architektonickou práci

Zatím nepřizpůsobeno pro NAP.

Cíl správy požadavků

Cílem této fáze je zavedení procesu řízení architektonických požadavků v průběhu vývoje architektury. Fáze: správa požadavků má tyto hlavní cíle:

  1. Zajistit, aby proces správy požadavků byl podporovaný a uplatňovaný pro všechny relevantní fáze metodiky vývoje architektury.
  2. Řídit architektonické požadavky identifikované v průběhu architektonického cyklu anebo fáze.
  3. Zajistit, aby relevantní architektonické požadavky byly dostupné pro každou fázi metodiky vývoje architektury.

Vstupy, kroky postupu a výstupy

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

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
Světle zelená 224 255 224
Kompozitní 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 tabulce48) je 100% přezata z originální specifikace ArchiMate 3.1.

Přehled vazeb ArchiMate

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

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ý50), přebírá NAR některé objekty metamodelu i z TOGAF, a to objekty Organizační jednotka, Logická a fyzická aplikační komponenta, Logická a fyzická technologická komponenta.

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

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

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

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

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

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

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

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

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

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

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

Tabulka52) 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 (SLA53)).
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 aktivity54). 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

Tabulka55) 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á56), 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

Tabulka57) 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 tabulce58) 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 TOGAF59) a tzv. motivační a strategickou60) 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í

Tabulka61) 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í62)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 (KGI63), KPI64) (zejména TCO65)), PPI66), 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

Tabulka67) 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í Není obsažen v jazyce ArchiMate

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

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

Doména Původní název Generický překlad Úprava pro NAR
BezpečnostníThreat 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

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

Název typu prvku Definice typu prvku Definice NAR
Ohrožení A Threat is a negative scenario you want to avoid. Hrozba je 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 Agent ohrožení se používá k označení jednotlivce nebo skupiny, která může projevit hrozbu. Je zásadní určit, kdo by chtěl využívat aktiv společnosti a jak by je mohl použít proti společnosti.

Osoba, aktér, entita nebo organizace, která zahajuje daný scénář hrozby.

Agent ohrožení je modelován s konstrukcí business actor, ale lze použít i jiný aktivní prvek struktury (např. byznys role, aplikační komponenta atd.)
Událost hrozby /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 (událost) je negativní událost, která může vést k nežádoucímu výsledku, jako je poškození nebo ztráta aktiva. Hrozby mohou použít - nebo se stát nebezpečnějším kvůli - zranitelnosti v systému.

Událost hrozby (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. ??
Bezpečnostní motivátor /vlivRisk / 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 rizika analyzována a jsou reprezentována 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.
Šance, že se stane něco špatného, v kombinaci s tím, jak byto bylo špatné, kdyby se to stalo. Riziko je negativní scénář, kterému se chce organizace vyhnout, v podstatě kombinace jeho pravděpodobnosti a dopadu.

Riziko je modelováno specializací typu prvku zhodnocení vlivu.
Zranitelnost Vulnerabilities are simply weaknesses in the systém, 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 CSR71).

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

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

Tabulka73) 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 diagramem74). 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ě implementovatelnou75) 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 TOGAMEFF76) 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í tabulka77) 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á tabulka78) 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ů.

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

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í (AoG83)), 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 (ACF84)), 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é) mapy85). 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 (EIRA86)), 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 ACF87), 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í úřadu88), 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 Map89) 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 stran90)
  • Katalog motivátorů91) a potřeb
  • Katalog strategických cílů92), proveditelných úkolů93) a jejich měřítek splnění
  • Katalog architektonických principů
  • Katalog klíčových architektonických požadavků94) 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árnosti95) čerpání zdrojů pro veřejnou službu
    • Zvýšení účinnosti96) práce zdrojů při tvorbě výstupů
    • Zvýšení účelnosti97) 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ů (PSA98)) 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í konstrukčních/provozních detailů - design.

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.

Referenční modely a klasifikační rámce

Není možné srovnávat a vyhodnocovat části architektur mezi sebou, pokud bychom si nebyli jistí, jestli ukazují vždy to samé, tu samou část úřadu, ten samý typ komponenty, tu samou kategorii procesů apod.

Bez toho není možné se snažit o sjednocování, konsolidaci, redukci, náhradu atp. Klasifikace prvků architektury je nezbytným předpokladem všech architektonických rozhodování. Proto tato kapitola přináší koncepci Národních klasifikačních systémů a na jejich bázi vytvořených referenčních modelů, platných vedle architektur ústředních správních úřadů v převážné míře i pro architektury kraje nebo ORP a jejich organizací.

V současné poradenské praxi, zaměřené na zlepšování řízení úřadů státní správy a samosprávy v ČR, se setkáváme s dvojím významem a rozsahem pojmu „referenční model“:

  • Referenční model integrovaného systému řízení úřadu (RM ISŘ)- se zaměřuje na představení a udržování znalostí a praxí ze všech vzájemně souvisejících metod manažerského řízení úřadu.
  • Referenční model architektury úřadu (RM A) - dále již také jenom jako RM, je vzorem, akcelerátorem a klasifikačním systémem dle nejlepších praxí pro architekturu úřadu.

Tento architektonický rámec se dále zabývá již jenom referenčními modely architektury úřadu, které jsou však v praxi cenným východiskem pro vybudování referenčních modelů Integrovaných systémů řízení.

Referenční model architektury úřadu by měl pokrývat všechny tzv. domény úřadu a jim odpovídající vrstvy a vertikály architektury.

Klasifikační systémy a referenční modely nemohou vzniknout tzv. „od stolu“, nýbrž zobecněním praxí nabytých zkušeností. A protože v české veřejné správě ještě žádná sdílená architektonická zkušenost neexistuje, na rozdíl od zahraničí, vznikají první verze klasifikačních systémů a referenčních modelů NA VS ČR jako kombinace zahraničních vzorů, místních ukončených či ještě probíhajících akademických výzkumů, zejména na VŠE, a pilotních projektů EA v orgánech veřejné moci ČR.

Jedním z inspiračních zdrojů pro budoucí referenční modely jsou také některé z dřívějších výstupů dodavatelského konsorcia e2020 (2014).

Z mezinárodních zdrojů jsou nejdůležitější taxonomie Nového Zélandu, které dále rozpracovaly aktuální taxonomie veřejné správy USA. K nim se řadí ještě prvky z referenční architektury VS Velké Británie.

Díky blízkosti Slovenské republiky a podobné stavu rozpracování obou národních architektur VS budou taxonomie a referenční model ČR vznikat ve spolupráci a se zohledněním slovenských zkušeností.

Do třetice díky příslušnosti ČR do EU a potřebě stát se součástí evropské architektury pro interoperabilitu bude EIRA99) představovat významnou inspiraci pro ty části Národní architektury, které jsou právě řešením problematiky interoperability. Ostatní lokální referenční modely EIRA nepokrývá.

Více informací, vlastního obsahu a odkazů k mezinárodním referenčním modelům a taxonomiím se nachází ve Znalostní bázi NA VS ČR.

Projekt e2020 přinesl mnoho set diagramů, vytvořených 1:1 k modelům, což není metodicky zcela správně. Mělo by se jednat o rozdílné pohledy (řezy) na konsolidované modely – co modelující jednotka to jeden model.

Modely jsou ale aktuálně jediným dostupným uceleným souborem architektonických artefaktů, vyjadřujících první představu významné skupiny architektů dodavatelského konsorcia e2020 o cílové podobě architektury českého eGovernmentu na konci roku 2019. A současně tak jsou jedinou dostupnou centrálně pojatou českou architektonickou zkušeností v oblasti enterprise architektury veřejné správy.

Za referenční v architektonickém slova smyslu, tzn., že mohou být předlohou při modelování lokální architektury úřadu, je z výstupů projektu e2020 možno považovat tyto skupiny modelů:

  • Modely ústředních správních úřadů (ÚSÚ) – 8 modelů, vždy dva za každou vrstvu architektury (byznys, aplikační, IT technologickou a infrastrukturní), z toho 4 pouze indikativní (úroveň 0) a 4 přesnější (úroveň 1). Kombinace obou úrovní podrobnosti do jisté míry představuje tehdejší návrh taxonomie architektury ÚSÚ.
  • Modely krajských samospráv, resp. pouze krajských úřadů (KRJ) – ve stejné struktuře jako ÚSÚ.
  • Modely statutárních měst a obcí s rozšířenou působností (STM a ORP) - ve stejné struktuře jako ÚSÚ, ale dvakrát v podstatě totéž, jen s drobnými odchylkami.

Tyto modely obsahují řadu drobných nekonzistencí mezi sebou vzájemně a neopírají se o žádný společný klasifikační systém komponent. Právě tyto skupiny tzv. referenčních modelů již byly publikovány na webu OHA a budou nadále součástí Znalostní báze NS VS ČR. Zpětné zhodnocení modelů proti praxi a proběhlému vývoji eGovernmentu za uplynulé období povede k případnému zohlednění zkušeností a k jejich promítnutí do dalších aktualizací níže uvedených referenčních modelů NAR a do jejich úprav pro jednotlivé úrovně hierarchie veřejné správy ČR.

Národní architektonický rámec usiluje o vytvoření a aktualizaci RM pro všechny vertikální i horizontální domény architektury. V nejbližším období ale budou dostupné pouze referenční modely pro klíčové objekty základních architektonických vrstev (BADT), z nichž referenční modely BA a AA již jsou představeny níže. Následovat by měly RM technologických vrstev, RM datové architektury a RM architektury strategického směřování.

Tato část je zaměřena na RM byznys architektury, tj. architektury výkonu veřejné správy a provozu úřadu, který je dále označován zkráceně jako RM-BA. Jediný tuzemský zdroj informací pro vytvoření hledaného RM je soubor prezentací a modelů vytvořených jako pracovní verze v OHA. K jeho vytvoření přispěly i dílčí zkušenosti z pilotních projektů tvorby architektury úřadu Ministerstva průmyslu a obchodu (2015), Moravskoslezského kraje (2017) a Města Benešova (2018 - 2019).

Model vzniká postupně tak, aby se následně, po verifikaci v projektech stal součástí Národního architektonického plánu a základní procesní dekompozicí pro projekt PMA3 (Procesní modelování agend).

RM-BA VS ČR byl vytvářen ve spolupráci s dalšími organizacemi, na základě diskusí s VŠE (prof. V. Řepa, M. Zimmermannová), neziskovou organizací CIEM (model CIMAF100), R. Fišer) a s Národní sítí zdravých měst (P. Švec, J. Boušková).

Z toho dále vyplývá, že není-li dostatek místních zdrojů, je nutné kvalitní výchozí referenční model sestavit s využitím zahraničních inspirací. Pro tento RM byly využity modely procesních a funkčních dekompozic (referenční klasifikace) samospráv z Nizozemí a USA a referenční model státní správy z Nového Zélandu, které se jeví jako nejvíce relevantní.

Základní zásady návrhu referenčního modelu:

  • Dělí architekturu po vrstvách a doménách ve shodě s NAR (kombinace standardů TOGAF, ArchiMate a architektonického rámce Nového Zélandu).
  • Ve vrstvě BA se zaměřuje na klasifikaci činností (chování), bez ohledu na to, zda jsou řízeny pouze jako funkce (z pracovních náplní), jako procesy (řízené sekvence funkcí) nebo jako služby (řízené výstupy procesů).
  • RM představuje referenční (vzorovou) klasifikaci resp. taxonomii výše uvedených prvků. Současně poskytuje vizuální referenci (topologii diagramů – co je dole/nahoře, vlevo/vpravo).
  • RM uznává, že je možné vytvořit více referenčních klasifikačních systémů, tento se zaměřuje na klasifikaci činností v dimenzi od poskytování individuálních funkcí (služeb) pro konkrétní jmenovité klienty na jedné straně až po základní provozní aktivity na druhé straně.
  • Každý z referenčních modelů využívá stejnou terminologii názvů pro klasifikační úrovně:
    • 1. úroveň – byznys (aplikační, technická) oblast
    • 2. úroveň – byznys (aplikační, technická) kategorie
    • 3. úroveň – byznys (aplikační, technická) skupina

Obsah referenčního modelu byznys architektury

Principiální diagram nejvyšší úrovně referenčního modelu byznys architektury VS ČR, viz následující obrázek:

 Principiální diagram nejvyšší úrovně referenčního modelu byznys architektury VS ČR, úroveň 1 - byznys oblasti, zdroj: (Hrabě, 2019).

Příkladem dalšího detailního rozpadu klasifikace mohou být provozní procesy. Ty mají tu vlastnost, že až na drobné odchylky (jiný účtový rozvrh, zákon o VZ, zákon o úředních, apod.) se tyto funkce, procesy a interní služby nijak neliší od týchž v libovolné komerční nebo neziskové organizaci. Proto je účelné i od těchto organizací přebírat nejlepší praxe.

 Oblast 5: Provozní procesy, úroveň 2 - byznys kategorie, zdroj: (Hrabě, 2019).

V téže procesní oblasti je představena i další úroveň klasifikace - byznys skupiny (funkcí, procesů, služeb), z důvodu zobrazení již rozdělené do dvou diagramů:

 Oblast 5: Provozní procesy, úroveň 3 - byznys skupiny, první část, zdroj: (Hrabě, 2019).

 Oblast 5: Provozní procesy, úroveň 3 - byznys skupiny, druhá část, zdroj: (Hrabě, 2019).

Referenční model BA může být postupně s podporou pilotních projektů dopracován ještě do větší podrobnosti a nabídnout referenční klasifikaci i pro procesy (funkce či služby) jednotlivých byznys skupin, jak je zde na příkladu z projektu Studie Benešov představeno pro skupinu Správy majetku obce.

V modelu a grafickém vyjádření identifikovaných úrovní 3 až 5 dekompozice byly zvoleny tyto objekty:

  • úroveň 3 – Skupina procesů (funkcí) – objekt ArchiMate Skupina
  • úroveň 4 – Proces nebo funkce (v tomto případě funkce) – objekt ArchiMate Funkce
  • úroveň 5 – Podproces, činnost (v tomto případě dílčí funkce) – objekt Funkce.

Klasifikační objekt Skupina je v následujících dvou schématech, na rozdíl od všech výše uvedených diagramů vyjádřen tradiční grafickou notací jako „kartotéční lístek“. Tím se chce zdůraznit rozdíl mezi poslední úrovní (abstraktní) klasifikace a první úrovní výkonných funkcí.

 Model funkční / procesní dekompozice oblasti správy majetku města Benešova, v úrovních 3 – 5., zdroj: (Hrabě, 2019).

Na následujícím obrázku je představen souhrnný referenční model byznys architektury veřejné správy ve variantě pro město (obec). Jenom s malým úsilím pilotních úřadů je možné RB-BA přizpůsobit také realitě kraje, ústředního správního úřadu nebo rozpočtové kapitoly.

 Klasifikační hierarchie a referenční model dekompozice byznys funkcí, procesů a služeb obce. Zdroj: (Hrabě, 2019).

Zatím jediný dostupný lokalizovaný referenční model pro aplikační architekturu NA VS ČR je k dispozici pro klasifikaci a vizualizaci mapy aplikačního portfolia, členěného podle účelu aplikací. Jedná se o referenční model vypracovaný na VŠE, který nemá, s výjimkou výše uvedeného britského modelu UK-RA101), ve světě srovnatelnou obdobu.

Všechny ostatní modely člení aplikace spíše podle způsobu získání (nákup, vývoj) nebo podle druhu technického řešení než podle účelu, například model CORA. Oba pohledy na aplikační portfolio je možno kombinovat, záleží na obsahu aktuálně kladených otázek, o nichž je třeba nad architektonickými modely rozhodovat.

Základní zásady návrhu referenčního modelu aplikační architektury

Na hledaný referenční model aplikační architektury byly kladeny následující požadavky:

  • Musí seskupovat aplikace podle byznys účelu a uživatelského způsobu použití, aby u aplikačních komponent v téže klasifikaci podpořil rozhodování o jejich konsolidaci či záměně nebo zřízení tam, kde pro byznys účel chybí.
  • Musí dávat smysl v kterékoli úrovni detailu (hierarchie) klasifikace aplikací, tento zjevný smysl musí být srozumitelný byznys uživatelům referenčního modelu a z něho odvozených individuálních modelů.
  • Musí být po úpravách použitelný ve všech segmentech a na všech úrovních hierarchie veřejné správy.

Referenční model byl vytvořen jako soubor zásad, příkladné obrázky, klasifikační hierarchie a šablona jazyka ArchiMate. Aktuální verze modelu, viz níže, je vytvořena jako generický model pro veřejnou správu, spíše zaměřený na segmenty úřadů s rozsáhlým kmenem klientů a s procesy hromadné obsluhy klientů. NAR a NAP předpokládá vytvoření klonů modelu i pro další segmenty veřejné správy, například zaměřené na projektově orientovanou správu liniové infrastruktury a další.

Obsah referenčního modelu aplikační architektury

První úroveň dekompozice dle RM-AA přináší dělení aplikačního portfolia podle dvou základních dimenzí, vertikální a horizontální. Vertikální dimenze modelu dělí aplikační architekturu podle míry blízkosti aplikací uživateli, jeho potřebám a managementu organizace na tzv. vrstvy, které odpovídají členění od technické integrace až po uživatelskou interakci. Model je tvořen šesti vrstvami:

 Přehled RM-AA, úroveň 1 - zdůraznění vertikálního rozměru od uživatelské interakce po techickou integraci, zdroj: (Hrabě, 2014).

Horizontální dimenze představuje členění aplikací podle jejich role v podpoře hodnotového řetězce organizace. Zjednodušeně říká, že zcela vlevo jsou aplikace podporující výkon činností, evidenci a komunikaci informací spojených s externími subjekty, zcela vpravo jsou aplikace podporující evidenci interních zdrojů a činnosti s nimi, uprostřed jsou aplikace, které oba tyto světy spojují, například účetnictví a logistika v ERP v transakční (IV.) vrstvě, resp. reporting a podpora rozhodování v analytické (III.) vrstvě.

Horizontální členění se uplatní zejména u aplikací s výrazným byznys obsahem, tj. u transakční a informační vrstvy, kde je zdůrazněno, jak ukazuje následující obrázek.

 Pohled na III. a IV. vrstvu RM-AA pro VS, úroveň 2 - zdůraznění horizontálního rozměru, zdroj: (Hrabě, 2014).

V modelu jsou aplikační oblasti a kategorie orámovány pojmy, odpovídajícími hlavním konceptům (Byznys Objektům), které jsou předmětem evidence v podnikových informačních systémech a současně jsou součástí prostředí podniku, s nímž systémy interagují. V generickém modelu to jsou tři klíčové kategorie externích zájmových skupin: vlastníci, zákazníci a dodavatelé, a dále tři základní podnikové zdroje: znalosti, zaměstnanci a majetek (technologie). V modelu pro veřejnou správu jsou dodavatelé převedeni zleva doprava, protože organizace veřejné správy nepovažují (dosud) dodavatele za partnery při tvorbě hodnoty a dodávce veřejné služby, ale považují je spíše za externí zdroj.

Jádrem modelu jsou prostřední dvě klíčové vrstvy transakcí a znalostí, které přímo podporují provádění funkcí, procesů a služeb úřadu. Jsou dále členěny podle horizontální dimenze do hlavních oblastí aktivit od vykonávání externích činností (výkon služeb veřejné správy) po správu zdrojů úřadu. Cílem těchto dvou vrstev je pokrývat ucelené (E2E102)) scénáře tvorby hodnoty, tedy pokrývat všech pět klíčových oblastí dekompozice RM byznys architektury, viz následující Obrázek, jenom jinak uspořádané.

Transakční operace vytvářejí množství dat, které slouží pro podporu rozhodování (uprostřed), dále doplňují spolu s dokumenty znalosti úřadu (vpravo) nebo představují informace pro vlastníky, politiky a veřejnost (vlevo). Spolu tvoří vrstvu znalostí a podpory rozhodování.

Pod transakční vrstvou se nachází vrstva všeobecných, průřezových IT a bezpečnostních služeb, které většinou nejsou spojeny s jedinou výlučnou byznys a aplikační funkcí, nýbrž slouží mnoha z nich (identity a oprávnění, monitoring, kancelářský balík, archivace, mapové aplikace apod.).

Nejspodnější vrstvu tvoří aplikační SW jednotlivých platforem, integrační, mobilní, komunikační a dalších, sloužících pro provoz a propojování aplikací.

Naopak nad vrstvami pro transakční zpracování a práci s informacemi se nachází vrstva pro orchestraci služeb z jednotlivých informačních sil do jednotlivých uživatelských rozhraní, také zvaná kompozitní vrstva nebo platforma.

Nejvyšší vrstvu, nejbližší uživatelům, tvoří všechny představitelné formy uživatelských rozhraní, od tradičního těžkého klienta, přes prohlížeč, mobilní aplikace až po tzv. Internet věcí nebo inteligentní oblečení. Tedy cokoli, co je uživateli schopno zpřístupnit aplikační služby nižších vrstev.

 Klasifikační hierarchie a referenční model aplikačního portfolia, verze rozšířená o aplikace prvků EIRA (oranžové).

Dělení aplikací do oblastí, kategorií a skupiny má velký význam pro stanovení pravidel řízení jednotlivých aplikací. Více informací o architektonických pravidlech pro jednotlivé oblasti a kategorie aplikační architektury se nacházejí v dokumentu NAP.

Hierarchické použití referenčního modelu aplikační architektury

Při úvahách o uplatnění referenčních modelů, například v této části u RM-AA platí, že celkový model aplikační architektury tvoří opakující se vzory, tzv. „fraktály“, pouze menší nebo větší, podle toho, kde v organizační hierarchii se referenční model uplatní.

Některé organizace veřejné správy mají korporátní charakter (typicky ministerstva, kraje nebo obce) a poskytují některé své funkce a aplikace i dalším organizacím z korporace. Každá ze samostatných jednotek této hierarchie by pro své vlastní řízení IT měla aplikovat a dle vlastní situace upravit referenční model aplikační architektury, představený výše.

Potom každá z výše v hierarchii postavených jednotek bude mít modely dva. Jeden elementární (individuální, IND), pokrývající IT podporu jejích vlastních procesů a druhý souhrnný (společný, SPOL), zahrnující v sobě na příslušných místech modelu vedle vlastních aplikací i aplikace, vyskytující se v podřízených nebo řízených jednotkách. Symbolicky to ukazuje následující diagram, viz následující obrázek, v němž jsou představeny souhrnné modely na různých úrovních architektury veřejné správy. V levé zelené části transakční oblasti je naznačeno, že každý vyšší (společný) model obsahuje i všechny aplikace evidované v nižším modelu.

 Hierarchický, federativní, resp. fraktálový charakter aplikační architektury, zdroj: (Hrabě, 2014)

Modely vyšší úrovně potom mohou sloužit například k rozhodování o konsolidaci (sjednocování) aplikační architektury a využití sdílených služeb, buď povinně u jednotek, kam dosáhne rozhodovací pravomoc vyšší jednotky, nebo dobrovolně, pokud vyšší jednotka nabídne té nižší aplikační pokrytí domény za výhodnějších podmínek, které by konsolidace a centralizace měla umožnit.

Z pohledu každé z organizací není rozhodující pro uvedení do aplikační mapy, zda aplikaci vlastní. Důležité je, že aplikační potřebu z určité oblasti má pokrytou řešením určitých kvalit, ať je jí vlastněné (modeluje jako aplikační komponentu), sdílí jej horizontálně s partnerskou organizací nebo jej přebírá od nadřízené jednotky (modeluje jako aplikační službu).

Není dosud definován na úrovni NA VS ČR.

Není dosud definován na úrovni NA VS ČR.

Není dosud definován na úrovni NA VS ČR.

Není dosud definován na úrovni NA VS ČR.

Pokyny a techniky pro tvorbu architektury

NAR v souladu s TOGAF rozlišuje mezi Pokyny103) a Technikami104). Zatímco pokyny slouží jako návod pro přizpůsobení architektonického rámce podmínkám a potřebám konkrétního úřadu, techniky představují návody a pomůcky pro dílčí postupy tvorby a údržby architektury.

Obsah NAR je pro všechny povinné osoby, viz výše, platný celý, tak jak je, vyjma ustanovení, která jsou pro konkrétní OVS prokazatelně nerelevantní.

Mezi základní pokyny pro adaptaci NAR do úřadu patří již výše uvedené:

Nad rámec NAR může OVS ve své místní Metodice tvorby, údržby a užití architektury úřadu přidat další pravidla, objekty metamodelu, jejich atributy, typy diagramů, dodatelné výstupy, role a zodpovědnosti a podobně.

Zde se v metodice správy architektury úřadu budou postupně objevovat praxí ověřené techniky podporující tvorbu, správu a užití architektur úřadu, popsané praktickým a návodným způsobem.

Takovými technikami mohou být například:

  • Byznys scénáře
  • Analýza rozdílů stávající a cílové architektury
  • Analýza a řízení rizik
  • Posouzení připravenosti na uskutečnění změn
  • Posouzení zralosti architektonické praxe a další

Aktuálně žádné pilotními projekty již ověřené techniky nejsou zdokumentovány a architektům úřadů jsou tak k dispozici pouze originální popisy technik v původní dokumentaci TOGAF.

Mnohé z technik NAR jsou současně obecnými technikami řízení ICT, které NAR (stejně jako TOGAF) s výhodou přebírá, a proto budou prezentovány především v dokumentu Metody řízení ICT VS ČR.

Při prvním budování nebo zlepšování architektonické schopnosti úřadu je vhodné využít techniku posouzení architektonické zralosti105).

Tato technika umožňuje pomocí otázek v dotazníku strukturovaném typicky do 8-10 kategorií zjistit, jak dobrý úřad je nebo by chtěl být v jednotlivých aspektech architektonické schopnosti. Aktuální pomůcka NAR, vycházející z TOGAF, nabízí po třech otázkách v každé z následujících oblastí:

Proces tvorby a údržby architekturyŠíření a komunikace architektury
Vývoj architektury Architektura & řízení IT
Vztah strategie a IT Architekti - lidé
Zapojení managementu Vliv a důsledky architektury

Tabulka - Kategorie pro posouzení architektonické zralosti.

Ukázka praktického použití hodnocení zralosti architektonické schopnosti.

Popis praktického postupu a akcelerátor (tabulka s dotazníkem a grafem) je součástí Znalostní báze NA VS ČR.

NAR stanovuje nezbytný rozsah a formu popisu architektonických principů ve struktuře:

  • Identifikátor
  • Název
  • Stanovisko (obsah)
  • Zdůvodnění
  • Důsledky
  • Výjimky
  • Vazby principů
  • Kontrolní otázky
  • Řídící údaje: Povinnost, Podmínka revize, Datum revize

Kvalita architektonických principů

Dobrá sada principů vyjadřuje skutečnou společnou víru a hodnoty společnosti. Principy jsou vyjádřeny srozumitelným a používaným jazykem. Principů by mělo být pouze málo, mají být orientovány na budoucnost, mají být podporovány a prosazovány skutečnými lídry.

Zde je sada pěti kritérií pomáhajících rozpoznat dobrou sadu principů:

  • Srozumitelné (Understandable) – každý je snadno pochytí a porozumí. Není sporu o jejich významu
  • Robustní (Robust) - umožňují dobré a snadné rozhodování ve věcech architektury i v případných kontroverzních situacích.
  • Úplné (Complete) – pokrývají všechny situace, které mohou nastat.
  • Jednotné (Consistent) – výklad jednoho principu nemůže být v rozporu s jinými. Musí být vyvážené.
  • Dlouhodobé (Stable) – principy mají být trvalé, ale mají být schopné obsáhnout i změny. Musí být ustaven pozměňovací proces pro dodatky, změny či náhrady principů, jakmile byly jednou přijaty.

Ve Znalostní bázi NA VS ČR budou publikovány podrobné popisy architektonických principů P1 - P17, formulovaných a schválených v IKČR, doplněné o kontrolní otázky a další interpretace a vysvětelní.

Současně zde bude k dispozici i vzorový formulář pro popis vlastního architektonického principu OVS a šablona dodatelného výstupu Katalog principů. Pokud nebude vytvářen samostatný Katalog principů jsou principy OVS formulovány, schváleny a zveřejněny prostřednictvím Informační koncepce OVS.

Architektonickým vzorem je podle NAR takový stavební blok architektury, který je úspěšným řešení nějaké konkrétní potřeby. Návod a akcelerátor pro práci a s architektonickými vzory je součástí Znalostní báze NA VS ČR.

Tam také budou tvorbou OHA postupně přibývat konkrétní architektonické vzory pro praktické použití v architekturách OVS.

Architektonické dovednosti, útvary a orgány

Pro zajištění architektonických funkcí v organizaci je nutné vytvořit příslušnou organizační strukturu, procesy, role, zodpovědnosti a znalosti. NAR, v návaznosti na tzv. Rámec architektonických schopností (ACF106)) z TOGAF poskytuje referenční model a návod, jak takové organizační změny provést. V těchto informacích je NAR ve shodě s odpovídajícími částmi Metod řízení ICT VS ČR.

Vybudování architektonické schopnosti je obdobně jako razantní zlepšení jakékoli jiné schopnosti jak jednorázový projekt, tak následná průběžná činnost, která poskytuje kontext, prostředí a zdroje k řízení udržitelné architektonické praxe.

I architektonická schopnost má svoji cílovou architekturu a její vybudování vyžaduje změny ve všech vrstvách architektury organizace, ve které se má tato schopnost zavádět.

Na úrovni byznys architektury je především zapotřebí ustanovit útvar architektury, vydefinovat jeho role, zodpovědnosti a činnosti. Dále je pak potřeba zajistit procesy správy architektonického úložiště. Nejdůležitější jsou ale role a zodpovědnosti pro užití architektury při řízení rozvoje úřadu.

Na úrovni datové architektury je potřeba stanovit strukturu architektonického úložiště a artefakty, které v něm budou uloženy.

Na úrovni aplikační architektury architektonické schopnosti je potřeba zvolit modelovací nástroj a architektonické úložiště a také podpůrné nástroje pro řízení architektury, správu a komunikaci architektonických znalostí.

Na úrovni technologické a infrastrukturní architektury je potřeba stanovit technologické komponenty a infrastrukturu pro podporu architektonických aplikací.

Také architektonická schopnost by měla mít model vertikálních domén své motivační architektury, členové týmu i vedení úřadu by měli sdílet znalost toho, čemu architektura slouží a co se od ní očekává.

Útvar architektury, jako statická součást liniového řízení úřadu představuje prostředek výkonu a managementu architektury.

Architektonická rada jako kolektivní kontrolní, rozhodovací a eskalační orgán, představuje zejména základní prvek governance architektury úřadu.

Útvar architektury je orgán, jehož hlavní náplní je zastávat nejméně těchto pět rozdílných, ale vzájemně se doplňujících a podmiňujících funkcí, zejména na úrovni veřejnoprávní korporace (rezortu, kraje nebo obce):

  • Kontrolní orgán předběžně kontrolující vybrané vlastnosti v rámci resortu předkládaných IT projektů vůči zásadám NAP a vůči vyhlášeným standardům architektury řešení.
  • Auditní orgán stanovující požadovanou úroveň architektonické zralosti jednotlivých organizačních jednotek úřadu nebo korporace, jejich architektonického oddělení a jeho procesů a governance a orgán kontrolující dosažení této úrovně v požadovaném čase a její zachování.
  • Enterprise a Solution architekt architektur (byznys, aplikačních, datových i technologických) centrálních sdílených (nebo jednotných) služeb a centrálních sdílených (nebo standardizovaných) systémů Governmentu (eGovernmentu) na úrovni úřadu nebo korporace.
  • Přirozený vzor a leader (metodik) tvorby Enterprise a Solution architektur v jednotlivých OVS v korporaci, tj. tvůrce a vykladač přizpůsobené metodiky, správce korporátních sdílených znalostí (vzory, návody, referenční modely a praktické příklady) a správce prostředků pro sdílení architektonických znalostí (architektonické úložiště, portál, wiki, diskusní fóra, …).
  • Lokální (interní) Enterprise Architekt úřadu a těch organizací resortu, které jej o to požádají a kde nepostačí předchozí role rádce.

NAR, ve shodě s TOGAF, zdůrazňuje roli útvaru architektury úřadu v rámci jednotlivých úrovní řízení plánování a realizace změn, úměrně tomu je potřebné v útvaru architektury úřadu v OVS vybudovat a držet dovednosti podle následujícího schématu:

Potřebné architektonické dovednosti, zdroj: //World-Class Enterprise Architecture, The Open Group, 2010

Zodpovědnosti útvaru architektury

Útvar architektury je typicky zodpovědný za dosažení následujících cílů:

  • Poskytnutí principů a standardů pro všechna rozhodnutí týkající se architektury
  • Zaručení aplikace nejlepších praxí na tvorbu architektury
  • Zajištění konzistence mezi architekturami
  • Určení znovupoužitelných komponent
  • Zajištění flexibility architektury (aby vyhovovala byznys potřebám, aby vhodně využívala nové technologie)
  • Vynucení souladu s architekturou
  • Rozvoj architektonické zralosti v organizaci

Z hlediska operativy je útvar architektury zodpovědný za:

  • Monitoring a kontrolu dodržení architektonického kontraktu projektů
  • Zajištění efektivní a konzistentní správy a implementace architektur
  • Řešení eskalovaných nejasností, problémů a konfliktů
  • Poskytování doporučení
  • Zaručení souladu s architekturami a udělování výjimek
  • Zaručení řízeného přístupu ke všem relevantním informacím pro implementaci architektury
  • Validace reportovaných SLA, úspor apod.

Z hlediska řízení je útvar architektury zodpovědný za:

  • Tvorbu použitelných řídících materiálů a provozování řídících aktivit
  • Poskytnutí základního kontrolního mechanizmu pro zaručení efektivní implementace architektury
  • Včasnou identifikaci odchylek (neshody) od architektury a naplánování aktivit pro nápravu
  • Vybudování vazby mezi implementací architektury, architektonickou strategií a cíli obsaženými v enterprise architektuře a strategickými cíli resortu

Role a kapacity v útvaru architektury

Očekávané funkce útvaru architektury je potřebné naplnit kapacitami zaměstnanců (i zlomkovými) s odpovídajícími schopnostmi, kteří budou vstupovat do níže uvedených rolí. Přičemž jeden zaměstnanec může plnit více rolí a některé role mohou být trvale či dočasně zajištěny externě.

  • Vedoucí (ředitel) útvaru architektury úřadu
  • Hlavní architekt úřadu (Enterprise Architect)
  • Metodik architektury úřadu (Enterprise Architect)
  • Doménový architekt úřadu (Enterprise Architect)
  • Byznys architekt úřadu
  • Aplikační architekt úřadu
  • Datový architekt úřadu
  • Technologický (IT) architekt úřadu
  • Bezpečnostní (IT) architekt úřadu
  • Hlavní architekt řešení projektů eGovernmentu a ostatních změnových projektů
  • Doménový architekt řešení (Solution Architect)
  • Byznys (procesní) architekt řešení
  • Aplikační architekt řešení
  • Datový architekt řešení
  • Technologický (IT) architekt řešení
  • Bezpečnostní (IT) architekt řešení
  • Architekt významných řešení – napříč doménami (Solution Architect), například:
    • Architekt pro všechny součásti související s eHealth
    • Architekt všech řešení na platformě xyz
    • Architekt průřezových IT služeb (DMS, Knowledge Management, Workflow apod.)
  • Specialista legislativy a analýz architektury eGovernmentu ČR a EU
  • Metodik architektonického vzdělávání, osobního rozvoje a sdílení arch. znalostí v resortu

Kompletní struktura útvaru architektury představuje většinou distribuovaný (virtuání) tým. Část týmu představuje hlavní architekt a enteprise architekti, souhrnně zkráceně architektonické kancelář úřadu. Tento tým (útvar) by měl být součástí poradních orgánů nejvyššího vedení úřadu, společně s projektovou kanceláří úřadu, interním auditem, managementem kvality, PR, právníkem apod. Tyto klíčové role strategického plánování a řízení transformačních změn musí být pokryty interními zaměstnanci úřadu, přitom jejich omezenou odbornou znalost nebo kapacitu je možné doplňovat externími odborníky, ale zodpovědnost a správa získaných a udržovaných znalostí musí být interní.

Druhou úroveň detailu architektury, tzv. architektury řešení typicky zajišťují specializované útvary IT architektury a byznys (procesní) architektury či analýzy.

Architektonická rada je sponzorem architektury v organizaci. Jedná se o exekutivní skupinu zodpovědnou za kontrolu a údržbu strategické architektury a všech jejích podřízených architektur. Pozice architektonické rady ve struktuře organizace a její vztah k ostatním útvarům je znázorněn na obrázku níže.

Přehled rolí a zodpovědností při tvorbě a užití architektury. Zdroj: TOGAF (2011).

Architektonická rada musí být ustanovena s jasně formulovanými

  • zodpovědnostmi a schopnostmi rozhodovat,
  • pravomocemi a jejími limity.

Velikost a složení architektonické rady

Doporučená velikost architektonické rady je 4 až 5 (ne více jak 10) stálých členů. Struktura architektonické rady by měla odrážet strukturu organizace. Rada může mít taktéž dočasné členy, z důvodů časového vytížení a neschopnosti trvalého úvazku, nebo z důvodu probíhajících projektů. Architektonická rada by měla reprezentovat všechny klíčové subjekty zainteresované v architektuře (stakeholder) a typicky sestává ze skupiny vedoucích pracovníků zodpovědných za dohled a údržbu celkové architektury z úhlu pohledu svých zodpovědností.

Architektonická rada musí mít člena z nejvyšší úrovně organizace (sponzora). Častým důvodem selhání vybudování architektonické praxe bývá právě absence exekutivní síly, která je schopna vydávat závazná rozhodnutí.

Pro všechny výše v uvedené role budou ve Znalostní bázi připraveny přehledy potřebných osobnostních vlastností a odborných dovedností, v kombinaci typu dovednosti a potřebné (doporučené) úrovně dovednosti.

Schopnost tvorby, údržby a užití architektury úřadu je schopností postavenou na znalostech, proto je jednou z povinností manažera týmu architektury řídit rozvoj znalostí svého jádrového i virtuálního týmu.

Architektonické úložiště a nástroj

Každý úřad má navrhnout a s OHA MV projednat, jaké vlastnosti má mít jeho „architektonické repozitory“ jako podmnožina „enterprise repozitory“ pro správu znalostí úřadu, jak bude na jedné straně sloužit jako sdílené úložiště pro ostatní organizace úřadu (resortu, krajské korporace, ORP) a jak (a kdy) bude na druhé straně integrováno na centrální národní architektonické úložiště veřejné správy.

Je připravován projekt centrálního architektonického repozitory Národní architektury, které na jedné straně bude konzistentním centrálním úložištěm modelů všech úřadů a na druhé straně umožní vybraným úřadům přístup k modelovacímu nástroji. Ostatní úřady mohou modelovat ve svých vlastních nástrojích, včetně Open Source nástroje ARCHI, který je zdarma. Podmínkou bude sdílet svoje modely s centrálním repozitory ve standardizovaném formátu The Open Group ArchiMate File Exchange Format, v rozsahu a obsahu podle povinných náležitostí jednotlivých typů architektonických angažmá.

Veškeré vytvořené modely a pohledy na ně budou, společně se všemi souvisejícími a navazujícími dokumenty, uloženy v architektonickém úložišti (repozitory), které je nedílnou součástí celkového úložiště úřadu/podniku (enterprise repozitory) a jeho mechanismů (procesů a systémů) správy znalostí. Z hlediska modelování je repozitory primárně úložištěm metamodelů, referenčních modelů, resp. povinných vzorů a individuálních modelů architektury úřadu a podřízených organizací. Tyto tři typy (balíčky) modelů se v případě potřeby dekomponují do větších detailů. Z modelů se odvozují pohledy, které zobrazují prvky a vazby z dílčích modelů dle nahlížené perspektivy.

Potřeba jednotně udržovat architektury jednotlivých OVS (tzv. lokální), společně s potřebou centrálně udržovat architekturu sdílených centrálních prvků a služeb eGovernmentu a společně s potřebou vyhodnocovat a řídit společně lokální i centrální architektury, vede k následujícím formulacím požadovaných vlastností jednotlivých architektonických úložišť.

Popisy architektur v úřadu tvoří systém výstupů, kategorizovatelný z mnoha úhlů pohledu, například podle účelu a míry podrobnosti modelů, viz Struktura modelovaných architektur.

Architektonické úložiště, národní i lokální, popisované v následujících částech slouží pro úroveň popisu „podniková architektura (Enterprise Architecture)“. V celkovém úložišti úřadu se však nachází společně s výstupy o všech dalších detailnějších úrovních popisu „architektura řešení“, „design (konstrukce) řešení“ a provozní dokumenty dodávky služeb. Optimálně jsou v cílové podobě všechny odpovídající a navazující dokumenty provázány odkazy.

Součástí úložiště pro úroveň „architektura úřadu/podniku“ musí být dle této metodiky NA VS ČR, s odkazem na standard TOGAF, prostředky pro ukládání výstupů (modelů, dokumentů) z následujících oblastí, jak je hrubě a podrobněji ukazuje následující Obrázek:

  • Architektonický rámec (orig. Architecture metamodel) - definice (dokumentace) upraveného architektonického rámce NA VS ČR, včetně metodiky pro architektonický obsah (slovník pojmů, metamodel, definice úhlů pohledu, apod.) a metodiky tvorby a údržby architektury (procesů a postupů dle fází, rolí a zodpovědností apod.).
  • Architektonické schopnosti úřadu (orig. Architecture Capability) – definice (dokumentace) všech náležitostí (strategie, org. struktury, znalostí, rolí, kontrolních mechanismů, atd.) oddělení architektury úřadu.
  • Knihovna individuálních architektur (orig. Architecture landscape) – dokumentace popisu vlastních individuálních architektur úřadu a jeho podřízených organizací, přes všechny domény a úrovně. Architektury jsou ukládány jako modely a artefakty (katalogy, matice a pohledy) odvozené z modelů i jako dokumenty, používající, komentující a rozšiřující tyto artefakty.
  • Referenční knihovna (orig. Reference Library) – obsahuje návody, klasifikační a referenční modely, předlohy a vzory výstupů, příklady a všechny další formy akcelerátorů pro usnadnění a urychlení tvorby a údržby popisů individuálních architektur úřadu.
  • Knihovna standardů (orig. Standards Information Base) – zahrnuje dokumentaci všech standardů a povinných návrhových vzorů, kterým navrhované individuální architektury úřadu a jeho podřízených organizací musí vyhovět.
  • Auditní záznamy (orig. Governance Log) – dokumentace všech aktivit, kterými se uskutečňovala architektonická governance, například výsledky posuzování architektury projektů, zápisy a rozhodnutí z architektonické rady, udělené výjimky apod.

Oblasti obsahu architektonický rámec, knihovna individuálních architektur, referenční knihovna a knihovna standardů, tedy první čtyři oblasti shora v následujícím obrázku, vzhledem k charakteru svého obsahu, vycházejícího z architektonických modelů, vyžadují IT podporu modelovacím nástrojem pro správu architektonických modelů (EAM – Enterprise Architecture Management).

Efektivní práce každé architektonické kanceláře, včetně OHA MV, musí být přirozeně doplněna ještě sadou dalších nástrojů pro správu, sdílení a komunikaci znalostí, například nástrojem pro správu dokumentů (DMS – Document Management System) a správu znalostí (KMS – Knowledge Management System), společnou údržbu a sdílení znalostí (Wiki), portál se sociální sítí apod. Přístup ke všem těmto systémům by pro uživatele znalostí (nikoli pro editory modelů) měl být umožněn interním portálem úřadu. V případě OHA hovoříme také o Knihovně nebo Znalostní bázi Národní architektury VS ČR jako české GEA BoK (Body of Knowledge).

 Architektonické úložiště v detailu a v kontextu celkového úložiště úřadu (Enterprise Repository) dle TOGAF, zdroj: (The Open Group, 2018)

Vzhledem k tomu, myšlenkově je Národní architektura konceptuálním základem dalších modelovacích disciplín veřejné správy, předpokládáme, že úložiště NAP se stane klíčovým prvkem souboru informačních systémů, představujících spolu meta-informační systém státu, jako jsou ISoISVS, RPP a IS Modelovací a další. Proto centrální EAM nástroj bude vedle povinné notace ArchiMate podporovat i navazující notace, a to určitě BPMN, ERD a klíčové modely UML. Ostatní modelovací notace zatím není plánováno používat a nemusí být centrálním nástrojem podporovány.

Všechny architektonické výstupy - modely, pohledy na ně a varianty těchto pohledů musí být v lokálních úložištích úřadů i v centrálním architektonickém úložišti NA VS ČR klasifikovány dle jednotné sady atributů.

Ať už je přístup k modelu v kterémkoli úložišti zprostředkován v menu nebo navigaci jakoukoli kombinací (pořadím) níže uvedených dimenzí, vždy musí být model povinně klasifikován všemi níže uvedenými atributy, pokud není v pravidlech pro některý atribut stanoveno jinak. Linearizovaný klasifikační řetězec modelu (pohledu) se může stát technickou, kódovou součástí jeho označení.

Organizace VS a jejich modely jsou pro účely řízení a governance NA VS ČR klasifikovány v těchto skupinách dimenzí:

  • Klasifikace modelovaných (modelujících) subjektů veřejného sektoru
  • Klasifikace architektonických modelů
  • Klasifikace pohledů na model

Zvláštní formou klasifikace úřadů a jejich modelů je jejich:

  • Segmentace úřadů a modelů podle podobnosti

Výčet definovaných klasifikačních a segmentačních dimenzí v jednotlivých skupinách se nachází v Příloze 2 a ve Znalostní bázi.

Různé druhy modelů, lišící se podle účelu v procesu tvorby, údržby a užití modelů architektury veřejné správy, se budou lišit také svojí možností, potřebou a povinností klasifikace podle výše uvedených dimenzí prostoru architektur. V této části jsou provedeny analýzy a návrhy výběru klasifikačních a segmentačních atributů podle druhů modelů, kterými jsou:

  • IM - Modely individuálních architektur úřadů
  • MM - Model s metamodelem a definicemi pohledů (úhly pohledu).
  • RM - Referenční modely
  • VM - Modely povinných a doporučených vzorů
  • PM - Modely teoretických a anonymizovaných praktických příkladů

Všechny druhy modelů mohou být označovány jedním společným řetězcem (Atribut1=hodnota;Atribut2=hodnota;…;AtributN=hodnota), přičemž u některých druhů modelů bude řada atributů nabývat hodnoty „0 – prázdný“

Příklady naplnění řetězce atributů hodnotami u různých druhů modelů a jejich vysvětlení obsahují následující části.

Jedno společné úložiště pro celostátní vizi a přehledové modely, pro sdílené prvky eGovernmentu a pro lokální architektury úřadů tedy bude obsahovat následující modely a pohledy na ně:

  • Celkovou hierarchii a navigaci v modelech NA VS ČR
  • Modely definic architektonického rámce NAR (metamodely, hlediska, metodická schémata, vzorové struktury modelů apod.)
  • Referenční modely rozmanitého účelu a rozsahu
  • Knihovnu standardů, stavebních bloků a architektonických vzorů
  • Modely individuálních (skutečných) architektur úřadů

Tato struktura se bude opakovat v modelech na jednotlivých stupních hierarchie veřejné správy, která je z podstaty federativní. To znamená, že obecnější celostátní referenční model pro například ÚSÚ nebo kraje si resort nebo krajská korporace musí převzít, bude-li publikován, ale mohou si k němu doplnit svoje specifika a takto upravený referenční model resortu nebo kraje uložit ve své (lokální) knihovně referenčních modelů. A to bez ohledu na to, zda resort nebo kraj budou využívat jediné společné centrální úložiště nebo budou moci / muset využívat pouze svůj lokální nástroje nebo oba.

Těžištěm výstupů architektonické práce je soubor individuálních modelů všech úřadů/podniků (enterprise) veřejné správy ČR, zahrnující současně architektury současného stavu (As-Is), budoucího stavu (To-Be), všechny identifikované potřebné přechodné architektury na cestě mezi nimi a v případě potřeby výjimečně i architektury minulého stavu (As-It was).

Metodika NAR předpokládá, že každý úřad/podnik VS (ve významu enterprise) bude muset mít pro korektní modelování a poznání architektury své vlastní a architektur organizací, za něž ve smyslu této metodiky odpovídá, ve svém vlastním lokálním úložišti (architektonickém repozitory) také objekty modelů a vybrané pohledy všech „architektonicky“ nadřazených (širších, vyšších, obecnějších) architektur veřejné správy. A to architektury těch nadřazených úřadů, jejichž sdílené nebo obecné prvky musí nebo může užívat v současném stavu či plánuje užívat kdykoli do budoucnosti ohraničené horizontem modelování.

Naopak se nepředpokládá, že by samostatně modelující jednotky (např. ministerstvo nebo kraj) měly ve svém úložišti objekty modelů ostrých individuálních architektur svých „sousedů“ na téže úrovni hierarchického segmentu (např. ostatních krajů) nebo dokonce úřadů, s nimiž nemají nic společného. S výjimkou případů, kdy úřad užívá (sdílí) prvky poskytované jiným úřadem – pak tyto prvky a modely těchto úřadů musí v nezbytné míře zahrnout i do hierarchie úložiště svých architektonických modelů. Přesný způsob a rozsah této „nezbytné míry“ bude nejprve ověřen pilotními projekty.

Obsah centrálního úložiště umožňují některé vyspělejší nástroje dělit nejenom na tzv. modely, ale tyto seskupovat do tzv. projektů nebo balíčků (package). Při potřebě načíst do editoru nějaký model, je potřeba otevřít a načíst celý projekt, package, v němž je dílčí model obsažen. Z toho pohledu je výkonově výhodnější rozdělit obsah úložiště do více projektů (package), například po jednom pro každý resort či krajskou korporaci, ad absurdum pro každý jednotlivý OVS.

Na druhou stranu všechny pohledy uvnitř jednoho projektu (package) mohou sdílet libovolně objekty ze všech modelů navzájem a každá změna objektu je okamžitě patrná ve všech pohledech, na rozdíl od integrace mezi projekty (cross-package), která je v nástrojích omezenější a obtížnější. Slovenský příklad demonstruje umístění architektur všech ÚSÚ jako jednotlivé modely do jediného společného package.

Doposud neexistuje veřejně dostupné a obsahem naplněné centrální úložiště NA a dílčí již vytvořené modely ještě netvoří ucelenou hierarchii. Ta bude postupně vznikat podle zde uváděných pravidel.

Model, použitý jako prostředek pro vytvoření ilustrací tohoto dokumentu, tj. definic meta-modelu a definici hledisek NAR, je uložen a veřejně k dispozici ve výměnném formátu ve Znalostní databázi NA VS ČR, kde bude také pravidelně aktualizován.

Z modelů referenční knihovny jsou aktuálně ve Znalostní bázi NA VS ČR k dispozici:

  • RM-BA, referenční model byznys architektury veřejné správy (obecný, neškálovaný pro jednotlivé kategorie OVS),
  • RM-AA, referenční model aplikační architektury veřejné správy (obecný, neškálovaný pro jednotlivé kategorie OVS).

Další modely zde budou přibývat v průběhu rozvoje NAP a aktualizace NAR.

V knihovně standardů a vzorů NAP (a celé NA VS ČR) je v současné době pouze sada modelů architektur řešení pro připojení AIS k centrálním prvkům eGovernmentu, zvaná Architektonické vzory sdílených služeb eGovernmentu.

V této části budou uvedeny příklady, jak by mohla/měla vypadat struktura repozitory ArchiMate modelů v lokálním EAM nástroji typických modelujících jednotek v hierarchii veřejné správy, nebo odpovídající výseky obsahu v centrálním repozitory, které, jak uvedeno níže, budou vzájemně synchronizovány. Existují první návrhy OHA, jak by struktura mohla vypadat, ale neproběhl žádný pilotní projekt, který by navrženou strukturu ověřil v reálném režimu sdíĺení modelů mezi lokálním a centrálním úložištěm.

Stávající úroveň poznání potřeb řízení NA VS ČR a možností EAM nástrojů vede OHA k rozhodnutí, že celková správa nástrojů pro správu NA bude kombinovaná, tj. v části povinných osob centrální, poskytovaná jako sdílená služba a v části distribuovaná, provozovaná lokálně, s modely periodicky nahrávanými do centrální databáze.

Centrální nástroj EAM budou mít k dispozici pro aktivní editaci modelů architekti OHA a architekti vybraných povinných osob, tj. OVS na úrovni ÚSÚ, KRJ a ORP s tím, že se počítá s postupným náběhem. Prvními uživateli centrálního EAM nástroje budou architekti kapitol (ministerstev), architekti správců centrálních sdílených služeb eGovernmentu, významných samostatných ÚSÚ a architekti krajských korporací, v počtu cca do 50 modelujících organizací. Následně se předpokládá, že bude nástroj postupně rozšířen jako volitelná možnost pro všechny organizace ústřední statní správy, krajské korporace a vybraná města v počtu cca 300 modelujících organizací. Pokud se centrální nástroj EAM vždy po každém rozšíření rozsahu nadále osvědčí, bude v této podobě nabídnut také všem zbývajícím ORP a dalším obcím a podřízeným organizacím krajských korporací a ORP.

Výhodou tohoto centrálního modelování je plně konzistentní používání centrálních sdílených prvků eGovernmentu v modelech jednotlivých organizací, podstatně snazší využívání předloh, sdílení modelů a governance tvorby architektury VS. Na druhou stranu to vyžaduje velmi výkonné centrální repozitory s efektivní podporou týmové práce.

U uživatelů centrálního EAM nástroje se předpokládá, že zejména strategické modely architektur úřadů budou minimálně v povinném rozsahu podle pravidel Národního architektonického rámce udržovat přímo vzdáleným přístupem v tomto nástroji. Respektive udržovat je mohou i lokálně, ale budou mít plnou zodpovědnost za „svůj“ modelovací obsah i v centrálním úložišti.

Díky plné kompatibilitě centrálního nástroje se standardem výměnného formátu The Open Group ArchiMate File Exchange Format budou moci svoje modely exportovat do XML a importovat je do svých lokálních nástrojů, pokud již nějaké mají nebo si budou chtít pořídit. A stejně tak i naopak, pokud upřednostní jejich lokání vývoj. Předpokládáme, že takto lokálně budou povinné modely rozšiřovat o další objekty evidované pro vlastní potřebu a zejména budou prohlubovat modely architektury úřadu (Enterprise Architecture) na podrobnější úrovně architektur řešení a designu řešení. K tomu budou pravděpodobně vedle notace ArchiMate užívat i centrálně nepoužívané notace jako UML a další.

Ostatní organizace veřejné správy než ty, které budou povinně nebo volitelně přizvány k využití centrálního EAM nástroje, budou pro modelování architektury svého úřadu využívat výhradně své lokální nebo vzájemně ve skupině úřadů sdílené EAM nástroje. A to s tím, že budou-li mít takovou povinnost, budou povinnou část svých modelů periodicky odesílat DS k „nahrávání“ do centrálního úložiště. Obě úrovně správy architektonického úložiště budou sladěny vzájemně, obousměrně. To znamená, že všechna lokální úložiště budou mít k dispozici a budou muset povinně využívat pro modelování všechny jim kontextově příslušné informace o obecných, centrálních a sdílených prvcích architektury NA VS ČR, referenčních modelech, standardech a povinných architektonických vzorech. Obráceným směrem budou všechna lokální úložiště povinně synchronizovat veškeré povinné výstupy tvorby a údržby architektury úřadu (vlastní, skupinové i rozšířené) v rozsahu a způsobem stanoveným aktuálními pravidly jednotlivých typů angažmá.

Distribuce architektonického úložiště NA VS ČR může (smí) být i více stupňová. To znamená, že organizace, zodpovědné za synchronizaci svých skupinových modelů „korporátní EA“ do centrálního úložiště, mohou svá lokání úložiště spravovat v lokálně-centrálním režimu a svěřit lokální správu dílčí části oblasti své zodpovědnosti podřízeným organizacím. Pak ale musí zajistit, že informace poskytované do centra NA VS ČR (a zpět) budou včasné, úplné a správné. To znamená, že musí své lokálně-centrální úložiště synchronizovat směrem dolů k podřízeným úložištím obdobně, jako je ono samo synchronizováno nahoru. A obráceně – modely vzniklé lokálně musí organizace s povinností centrálního modelování importovat do svých částí centrálního modelu, tam uplatnit všechny nástroje governance, tj. například jedinečným způsobem použít ve svých modelech již existující prvky eGovernmentu. Podstatné je, že organizace budou plně zodpovídat za správnost svých modelů v centrálním repozitory, ať již modely vzniknou manuální editací nebo importem.

Základním prostředkem synchronizace modelů bude jednotný a všemi účastníky respektovaný a jejich nástroji podporovaný XML formát výměny ArchiMate souborů, vyhlášený The Open Group jako standard v srpnu 2015107)108). Je pravděpodobné, že struktura tohoto XML standardu bude pro potřeby synchronizace údajů v rámci NA VS ČR o několik údajů rozšířena, čemuž budou muset být schopny se přizpůsobit všechny ve VS používané EAM nástroje. V pracovní skupině The Open Group ArchiMate forum byl v souvislosti novou verzí specifikace ArchiMate 3.0 vyhlášen přístup, že při certifikaci nástrojů je za shodný se specifikací prohlášen jenom takový nástroj, který bude plně podporovat export i import pomocí standardního výměnného formátu. Lze tedy předpokládat, že pak většina nástrojů, podporujících ArchiMate, přijme i výměnný formát.

Pro případ rozšíření EA ve veřejné správě, kdy povinně nebo dobrovolně modelujících organizací a jejich modelů bude velké množství a správa těchto modelů v aktivním úložišti centrálního EAM nástroje, tj. v jeho úložišti přímo určeném pro editaci grafických diagramů nad modely, bude již komplikovaná a málo výkonná, vzniklo tzv. pasivní (sekundární) centrální úložiště. Má podobu grafové databáze, ve které jsou všechny modely a jejich diagramy uloženy v objemově a pro rychlost vyhledání optimalizované indexované podobě. Součástí tohoto sekundárního repozitory bude, kromě již existujících funkcí, také na míru vytvořený obslužný program, který umožní podle lineární indexace (klasifikace) modelů a jejich objektů sestavit libovolný řez uloženými daty, vytvořit z něj soubor ve výměnném formátu TOGAMEFF, a tak jej převzít k vytvoření grafických diagramů v aktivní části centrálního úložiště, odtutd i publikovat a zase vrátit zpět. Například může jít o úlohu sestavit aplikační mapu všech typů ERP systémů nebo spisových služeb všech modelujících subjektů napříč celou VS.

Tento postup je důležitý zejména pro možnost využít analytických schopností centrálního EAM nástroje pro vyhodnocení atributů modelů přes řadu vazeb mezi objekty, což jedna z nejsilnějších stránek zvoleného modelovacího jazyka ArchiMate.

Řešení centrálního (primárního) úložiště s podpůrnou databází sekundárního úložiště) bylo navrženo pro ideální kombinaci a využití silných stránek obou prostřední, a to již od počátku. V takové databázi, která ukládá strukturu všech objektů a jejich vazeb, je možné ukládat hromadné kontrolní a statistické úlohy nad celým souborem modelů, které by v aktivním týmovém editačním nástroji a jeho prostředky byly obtížné nebo málo výkonné. Naproti tomu editační nástroj následně převezme svoji roli při zpracovávání identifikovaných rozporů v modelech, při společných projektech tvorby modelů nebo při přípravě manažerských analytických výstupů a grafů nad modely.

Na trhu existuje nejméně několik desítek komerčních i freeware nástrojů pro EAM, v ČR je běžně užíváno do deseti z nich. Každý z nich je vybaven jinou sadou funkčních a nefunkčních vlastností a de-facto nejsou vzájemně porovnatelné a vzájemně si konkurující.

Tato situace klade vysoké nároky na tým a manažera architektury úřadu, aby dobře posoudili, jaké mají a v budoucnosti budou mít požadavky na tvorbu, údržbu a užití modelů a diagramů architektury úřadu v notaci ArchiMate a detailnějších modelů v navazujících notacích (jako BPMN a ERD nebo UML). Nelze soutěžit komoditní nástroj na cenu.

NAR usnadňuje vedoucím architektů volbu lokálního nástroje několika pravidly a pomůckami:

  • EAM nástroj musí podporovat práci v notaci ArchiMate, včetně rozšíření specializovanými stereotypy podle NAR a včetně plné podpory výměnného formátu TOGAMEFF pro import i export modelů. A to nejlépe formou ověřené certifikace nástroje pro ArchiMate v The OpenGroup.
  • EAM nástroj musí vedle ArchiMate podporovat ještě nejméně notaci BPMN (potřebnou pro procesní modelování a optimalizaci) a notaci ERD nebo část UML (pro konceptuální a logický datový model úřadu).
  • Dodavatel EAM nástroje se musí smluvně zavázat k (automatické, neprodlené a v ceně investice a regulérní SW podpory zahrnuté) podpoře vždy poslední nejvyšší verze ArchiMate a přinejmenším ještě BPMN a ERD/UML.
  • Nástroj by měl disponovat podporou hromadných editačních operací, přinejmenším podporou importu a exportu modelů ve formátu Excel/CSV.

Další již volitelné požadavky může zadavatel vybírat z kontrolního seznamu a vzorové funkční a ne-funkční specifikace pro zadávací dokumentaci VZ, které jsou součástí Znalostní báze NA VS ČR.

Požadavky na nástroje centrální správy modelů NA VS ČR

Seznam požadavků pro výběr nástroje EAM v úřadu by měl umožnit vedoucímu architektovi úřadu posoudit, jaké jsou reálné potřeby jeho týmu vůči nástroji, přinejmenším v následujících kategoriích:

Kategorie požadavků Typ požadavku
Modelovací prostředí * Intuitivní navigace a editace,
* Opakované použití objektů z modelu a repository,
* Více metamodelů (ArchiMate, BPMN, TDM, …)
Podpora editace * Práce se šablonami,
* Hromadné operace s objekty i se vzhledem
Generování pohledů z modelu
(ze struktury, vazeb a atributů)
* Diagramy,
* Tabulky, Hierarchie,
* Roadmapy,
* Barevná rozlišení (Heat Maps)
Analytické možnosti * Intuitivní reporting pro zájmové skupin
Dokumentace, výstupy a publikace obsahu * Přílohy a odkazy,
* Výstupní zprávy do Excelu, PPT, Wordu a dalších,\\* Publikování k proklikávání v portálu (HTML 5.0 formátu) API pro čtení z dalších aplikací, portálů
Import / Export * Z a do různých zdrojů a formátů
Podpora týmové práce * Řízení oprávnění,
* Zamykání modelů Verifikace a uvolňování verzí (red-lining)
Úložiště (Repozitory) * Lokální soubory Sdílené soubory Databázový server Cloud
Další funkce * Modelování strategie,
* Správa portfolií (vč. správy informačních aktiv pro ZKB),
* Správa rizik a opatření,
* Podpora návrhu a deploymentu databází a algoritmů
* a další.

Tabulka - Přehled kategorií požadavků na EAM nástroj.

Detailní dokumentace požadavků na EAM nástroj bude na základě zobecňování zkušeností komunity architektu veřejné správy udržována ve Znalostní bázi NA VS ČR.

Reference

web OHA: odkaz

web architektury: archi.gov.cz

Digitální strategie Digital Western Australia 2016-2020: odkaz

Government of New Brunswick - Enterprise Architecture Program: odkaz

Information Technology Strategic Plan 2016-2020: odkaz

Update 2017 - Government of Canada Strategic Plan for Information Management and Information Technology 2017-2021: odkaz

Federal Enterprise Architecture (FEA), 2013: odkaz , resp. odkaz

California Information TechnologyStrategic Plan 2016 Update: odkaz

Architektonický rámec tzv. Government EA - New Zeeland (GEA-NZ): odkaz

Band, Iver, et al. 2015. Modeling Enterprise Risk Management and Security with the ArchiMate® Language. San francisco : The Open Group, 2015.

Deleu, Regine. 2014. Enterprise Architecture in Government Transformation. Aucland : New Zeeland Government, 2014.

Hrabě, Pavel. 2014. Koncepce podnikové architektury pro reformu veřejné správy ČR. Praha : VŠE v Praze, 2014.

Hrabě, Pavel. 2013. Koncepce řízení výkonnosti a zodpovědnosti pomocí KPI v české veřejné správě. Systémová integrace. 2013, Sv. 20, 1.

Hrabě, Pavel. 2019. Principy nastavení systému řízení veřejnoprávní korporace - Případová studie město Benešov. Benešov : Město Benešov, 2019.

Hrabě, Pavel. 2015. Standardizace agend v kontextu business architektury veřejné správy ČR. Praha : MV ČR, 2015.

Lankhorst, Marc and al., et. 2009. Enterprise Architecture at Work: Modelling, Communication, and Analysis. Second Edition. Second. Berlin : Springer, 2009. ISBN: 978-3-642-01309-6.

MV ČR. 2018. Informační koncepce ČR. Praha : MV ČR, 2018.

OHA MV ČR. 2016. Metodický pokyn k žádosti o stanovisko OHA k projektu. Praha : MV ČR, 2016.

The Open Group. 2017. ArchiMate 3.0.1 Specification. místo neznámé : The Open Group, 2017. C13L. ISBN: 1-937218-43-0.

The Open Group. 2018. TOGAF Version 9.2. San Francisco : The Open Group, 2018. str. 654. ISBN: 978-90-8753-679-4.

Všeobecné informace

Pojmy a zkratky budou doplněny dodatečně jak zde, tak do postupně vydávaného Slovníku pojmů eGovernmentu.

ZkratkaVysvětlení zkratky

Tabulka - Vysvětlení vybraných zkratek

Pojem Vysvětlení pojmu
Doména architektury Zájmová oblast architektury. TOGAF rozlišuje domény architektury: byznys, data, aplikace a technologie. Další rámce přidávají další domény pro oblasti motivace ke změně.
Hledisko Definuje perspektivu, ze které je možné vidět pohled. Jedná se o specifikaci konvencí pro vytvoření a použití pohledu. Pohled na model systému organizace je konkrétní artefakt (katalog, matice a zejména diagram) Hledisko říká, jak má diagram vypadat a co má prezentovat uživateli.
Metamodel Model definující jakým způsobem bude architektura popsána, ze kterých typových prvků (konceptů) a jejich vazeb bude popis architektury sestaven a podle jakých pravidel.
Metodika Definovaná a opakovatelná sada kroků pro vyřešení daného úkolu. Zaměřuje se na proces samotný, ale může obsahovat i definici požadovaného obsahu
Model Model představuje účelově zjednodušenou reprezentaci předmětu zájmu. Model je nástrojem pro porozumění předmětu zájmu. V podnikové architektuře je předmětem zájmu podnik nebo jeho část. Účelem modelu je potom prezentovat ty aspekty podniku, které jsou podstatné z pohledu zainteresovaných subjektů.
Modelování Modelování je proces, při kterém se vytváří model předmětu, vždy s ohledem na zamýšlené použití modelu.
Zainteresovaný subjekt (Stakeholder)Jednotlivec, tým nebo organizace, která má zájem na přínosu architektury.

Tabulka - Vybrané definice a pojmy

Tyto a další pojmy jsou současně obsahem následného dokumentu č. 2 k IKČR – Slovníku pojmů eGovernmentu.

Popisy, případně odkazy na přílohy, které budou existovat jako samostatné dokumenty nebo součásti Knihovny / znalostní báze Národní architektury VS ČR.

Příloha 1 – Seznam atributů prvků metamodelu

Postupně, od nejdůležitějších, budou ke každému prvku metamodelu publikovány povinné a doporučené atributy a jejich případné číselníkové hodnoty.

Příloha 2 – Klasifikace souborů, modelů a pohledů

V samostatné příloze v podobě textového dokumentu a tabulky XLS budou publikovány a aktualizovány klasifikační atributy a metadata sdílených souborů ve formátu TOGAMEFF, v nich obsažených modelů, pohledů, prvků a vazeb.


1)
z angl. Enterprise Architecture.
2)
dle usnesení vlády č. 86 z 27.1.2020 a zák. č. 365/2000 Sb.
3)
Architekturou VS se zde míní tzv. Cross-Government Enterprise Architecture (xGEA v UK, nebo GEA v Novém Zélandu, USA a mnohde jinde).
4)
z angl. The Open Group Architecture Framework, mezinárodní architektonický rámec, z něhož metodika NA VS ČR vychází.
5)
Z angl. Enterprise Architecture, v ČR nepřekládáno nebo překládáno jako podniková architektura nebo právě architektura úřadu.
6)
Angl. zkratka „As-Is“ – jak je.
7)
Angl. zkratka „To-Be“ – má být.
8)
Angl. „Roadmap“
9)
Viz definice ve Wikipedii: http://en.wikipedia.org/wiki/Enterprise_architecture_framework
10)
z angl. The Open Goup Architecture Framework
12)
Současně jde pouze o povinné osoby z hlediska účinnosti zákona č. 365/2000, IKČR a jejích následných dokumentů
13)
Artefakty jsou seznamy (katalogy), matice (tabulky) a grafické diagramy.
14)
Z angl. „Capability Architecture“,
15)
Angl. také PSA – Project Start Architecture
16)
Z angl. „Solution Architecture“
17)
Z angl. „Solution Design“
18)
Výstup projektu OP LZZ „Efektivní tvorba a implementace vládních strategií v oblasti eGovernment“, 2014, kosorcium e2020
19)
Myšleno nepřímého řízení, dohled na tyto činnosti
20)
Z angl. Enterprise Ontology
21)
Z angl. Business Capability Map
22)
Angl. „Solution Architecture“
23)
Z angl. Business Process Management (nebo jenom Modelling)
24)
Z angl. Enterprise Performance Management
25)
Z angl. Quality Management
26)
Angl. „Solution Design“
27)
Angl. „Core“
28) , 87)
Z angl. Architecture Content Framework
29)
Angl. „Compliance & Sustainability Architecture“
30)
Z angl. Corporate Social Responsibility
31)
Trvale udržitelný rozvoj
32)
Místní Agenda 21
33)
Tabulka - Definice barev prvků v doménách dle NAR, zdroj: MV ČR podle (The Open Group, 2017
34)
Z angl. Architecture Building Block
35)
Z angl. Solution Buiding Block
36)
Tj. dělit bloky na: Foundation, Common Systems, Industry, Company Specific.
37)
Angl. orig.: „Request for architecture work“.
38)
Z angl. pojmů: Business, Application, Data, Technology.
39)
Angl. orig.: „Statement of architecture work“.
40)
Vlastní architektura úřadu
41)
Architektura úřadu společně se všemi podřízenými organizacemi
42)
Architektura rozšířeného řetězce dodávky veřejné služby
43)
Angl. Stakeholders
44)
Z angl. Stakeholders
45)
V originální specifikaci tzv. Enterprise principles, nebo také jinde Corporate principles.
46)
V angličtině Goals
47)
Tabulka - Definice barev prvků podle standardu ArchiMate 3.1, zdroj: MV podle (The Open Group, 2017).
48)
Tabulka - Přehled prvků standardu ArchiMate 3.1 a jejich lokalizace, zdroj: MV podle (The Open Group, 2017).
49)
Tabulka - Přehled typů vazeb standardu ArchiMate 3.0.1, zdroj: MV podle (The Open Group, 2017).
50)
Přestože se se pod společnou správou The Open Group oba standardy stále sbližují.
51)
Analytická technika z oblasti marketingu a péče o klienta, doslova Cesta klienta (úřadem).
52)
Tabulka - Přehled definic prvků metamodelu byznys architektury, zdroj: MV podle (The Open Group, 2017).
53)
Z angl. Service Level Agreement.
54)
z angl. Capability.
55)
Tabulka - Přehled definic prvků metamodelu aplikační architektury, zdroj: MV podle (The Open Group, 2017).
56)
z angl. deployable
57)
Tabulka - Přehled definic prvků metamodelu technologické architektury, zdroj: MV podle (The Open Group, 2017).
58)
Tabulka - Přehled definic prvků metamodelu fyzické architektury, zdroj: MV podle (The Open Group, 2017).
59)
Součást byznys vrstvy a fáze vývoje architektury dle TOGAF ADM.
60)
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.
61)
Tabulka - Přehled definic prvků metamodelu architektury strategie a směřování, zdroj: MV podle (The Open Group, 2017).
62)
Z angl. Capability Based Planning.
63)
Z angl. Key Goal Indicator.
64)
Z angl. Key Performance Indicator.
65)
Z angl. Total Costs of Ownership
66)
Z angl. Process Performance Indicator.
67)
Tabulka - Přehled definic prvků metamodelu výkonnostní architektury.
68)
Z angl. Core.
69)
Tabulka - Přehled překladů prvků metamodelu bezpečnostní architektury.
70)
Tabulka - Přehled definic prvků metamodelu bezpečnostní architektury, MV podle (Band, et al., 2015).
72)
Tabulka - Definice prvků metamodelu architektury implementace a migrace, zdroj: MV podle (The Open Group, 2017).
73)
Tabulka - Definice kompozitních prvků metamodelu architektury, zdroj: MV podle (The Open Group, 2017).
74)
Z angl. Nested diagram
75)
V angl. doslova „deployable“
76)
Z angl. The Open Group ArchiMate Model Exchange File Format.
77)
Tabulka - Přehled výstupů architektury a jejich lokalizace, zdroj: (The Open Group, 2018) a MV.
78)
Tabulka - definice výstupů architektury podle TOGAF 9.2, zdroj: (The Open Group, 2018).
79)
Z angl. Viewpoint
80)
Z angl. View
81)
The Zachman Framework for Enterprise Architecture, https:%%//%%www.zachman.com/about-the-zachman-framework.
82)
GEA-NZ 3.2 – přehledy výstupů: https:%%//%%www.ict.govt.nz/assets/Architecture/GEA-NZ-Framework/GEA-NZ-Context.pdf (bohužel materiál byl přesunut, je k dispozici na OHA na vyžádání).
83)
Hodilo by se používat nějakou zkratku jako třeba tato z angl. All-of-Government.
84)
Z angl.. Architecture Content Framework
85)
Z angl. Landscape Map Viewpoint
86)
Z angl. European Interoperability Reference Architecture.
88)
Z angl. Enterprise Capability Map
89)
Zatím nemá adekvátní výraz v češtině, pracovně se říká „Semaforky“, kvůli typickým barvám zelené, žluté a červené.
90)
Z angl. Stakeholders
91)
Z angl. Drivers
92)
Z angl. Goals
93)
Z angl. Objectives
94)
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.
95)
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.
96)
Úč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.
97)
Úč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.
98)
Z angl. Project Start Architecture
99)
Z angl. „Europena Interoperability Reference Architecture“
100)
COMMON INTEGRATED MANAGEMENT AND ASSESSMENT FRAMEWORK, od Českého institutu efektivního managementu.
101)
Z angl. United Kingdom - Reference Architecture.
102)
Z angl. End-to-End, psáno také End-2-End.
103)
Z angl. Guidlines
104)
Z angl. Techniques
105)
Z angl. Architecture Maturity Assessment
106)
Z angl. Architecture Capability Framework
Pokud byste byli zalogování, mohli byste zanechat komentář.