Architektura eGovernmentu ČR - nar_dokument

Modelování pro informační koncepci - ↷ Stránka přesunuta a přejmenována z 'playgroud:metodika_ik_ey' do 'nar_dokument:metodika_ik'

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-01-14T11:37:12+00:00

2025/07/03 19:41		aktuální

Architektonické úložiště a nástroj - [Struktura obsahu architektonického úložiště]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-06-02T11:05:21+00:00

2021/02/03 14:11		aktuální
Řádek 17:		Řádek 17:
	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:		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.).	+	* Metamodel architektury popisuje organizačně přizpůsobené použití rámce architektury, včetně metody pro vývoj architektury a metamodelu pro obsah architektury.
-	* 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.	+	* Schopnost architektury definuje parametry, struktury a procesy, které podporují správu úložiště architektury
-	* 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.	+	* Krajina architektury představuje architektonickou reprezentaci aktiv používaných nebo plánovaných podnikem v určitých časových okamžicích.
-	* 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ů zachycuje standardy, s nimiž musí být nové architektury v souladu, což může zahrnovat průmyslové standardy, vybrané produkty a služby od dodavatelů nebo sdílené služby již zavedené v rámci organizace
-	* 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.	+	* Knihovna referencí poskytuje pokyny, šablony, vzory a další formy referenčních materiálů, které lze využít k urychlení tvorby nových architektur podniku.
-	* 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.	+	* Úložiště správy poskytuje záznamy o činnosti správy v rámci celého podniku
		+	* Úložiště požadavků na architekturu poskytuje přehled o všech autorizovaných požadavcích na architekturu, které byly odsouhlaseny radou pro architekturu.
		+	* Úložiště řešení (Solutions Landscape) představuje architektonickou reprezentaci SBB podporujících architekturu (Architecture Landscape), které byly plánovány nebo nasazeny podnikem.

	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).		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).
Řádek 223:		Řádek 226:
	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.		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 2015((Odkazy a FAQ: [[https://www.opengroup.org/open-group-archimate-model-exchange-file-format\|https:%%//%%www.opengroup.org/open-group-archimate-model-exchange-file-format]]	+	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 2015(( [[https://www.opengroup.org/open-group-archimate-model-exchange-file-format\|Odkazy a FAQ]]
-	))((Dokumentace: [[https://www.opengroup.org/bookstore/catalog/C174\|https:%%//%%www.opengroup.org/bookstore/catalog/C174]]	+	))(([[https://publications.opengroup.org/c19c\|Dokumentace]]
	)). 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.		)). 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.

Úvod

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:31:08+00:00

2025/05/07 10:38	aktuální
Řádek 1:	Řádek 1:
	+	====== Úvod ======
	+
	+	===== Účel a popis dokumentu =====
	+
	+	Tento dokument je praktickou příručkou použití Národního architektonického rámce (NAR) https://archi.gov.cz/nar_dokument, jakožto navazujícího dokumentu Informační koncepce ČR, při vytváření architektonických modelů. Má za úkol seznámit čtenáře s tématikou obecně a zasvětit jej do postupů modelování pro potřeby práce enterprise architekta, který podporuje dlouhodobé řízení ICT úřadu, včetně vstupů pro odbor Hlavního architekta eGovernmentu (OHA) Digitální a informační agentury (DIA).
	+
	+	V dokumentu jsou popsány hlavní myšlenky, principy a zásady dobrého modelování architektury obecně, dále je pak detailně rozepsáno, co a v jaké formě je vhodné modelovat, aby byly naplněny standardy OHA a hlavně aby modely byly čtenářům srozumitelné a bylo možné je dlouhodobě udržovat a rozvíjet.
	+
	+	V první části dokumentu je popsaná samotná myšlenka modelování architektury spolu s nejobecnějšími zásadami a principy pro tvorbu dobrých modelů. Druhá část se soustředí na identifikaci prvků modelů – hlavně elementů, vazeb a pohledů na ně. Tato část reflektuje metodiku ArchiMate tak, jak je implementovaná pro potřeby OHA, a zároveň odchylky a nadstavby pro OHA zdůrazňuje, aby o nich architekt věděl a mohl je využít. Další část pak obsahuje samotný popis toho, jak modelovat v kontextu jednotlivých vrstev architektury dle NAR. Čtenář zde najde průvodce tvorbou modelu dané vrstvy. V závěrečné části dokumentu jsou pak zmíněné nástroje, které lze pro modelování použít spolu s jejich hlavními pozitivními i negativními aspekty.
	+
	+	Tento dokument je koncipován jako zastřešující, přičemž na něj navazují další dokumenty detailně popisující tvorbu architektonických modelů pro specifické případy užití (architektonická angažmá).
	+
	+	===== Proč modelujeme? =====
	+
	+	Modelujeme proto, že jako architekti poskytujeme službu našim zainteresovaným, obvykle představeným úřadu a jeho ICT oddělení, uživatelům nebo dodavatelům, aby lépe pochopili realitu našeho úřadu, jeho potřeb ICT řešení, a tak mohli činit lepší (informovaná) rozhodnutí a vzájemně si lépe rozuměli. Teprve sekundárním důvodem modelování je, že to po nás autorita OHA v některých případech vyžaduje.
	+
	+	Modelování slouží k systematickému, ideálně jednoznačně interpretovatelnému popisu určitého výseku reality. Výstupem modelování je model, tedy struktura elementů a vazeb, který popisuje danu realitu. Je na něj nahlíženo přes pohledy, které jsou přizpůsobené zájmům (hlediskům) čtenářů modelu.
	+
	+	Model reality se vytváří proto, že rozhodování a komunikace nad modelem a prostřednictvím modelu jako zjednodušeného popisu reality je snazší než totéž přímo v realitě. Účelem modelu je, že má být komunikován, nikoli ležet v úložišti. Proto jsou nejdůležitější pohledy modelu vytvořené podle hledisek zainteresovaných stran. Pravidla pro vnitřní výstavbu modelu, jeho prvky a vazby, jsou důležitá pouze pro zajištění jeho správnosti, aby mu zainteresování mohli věřit a aby se dal snáze dlouhodobě udržovat.

Metodika modelování - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:30:13+00:00

2026/08/08 16:59	aktuální
Řádek 1:	Řádek 1:
	+	====== Metodika modelování ======

	+	{{page>nar_dokument:metodika_modelovani_1}}
	+
	+	===== Best practices a principy modelování =====
	+
	+	Jak je z kapitoly výše patrné, tvorba modelu nespočívá v kreslení diagramů, nýbrž v budování systému elementů a vazeb, které mají definovaný konkrétní význam podle předepsaných pravidel. Tato pravidla umožňují čtenáři pochopení obsahu vizualizovaných částí modelu, aniž by modelář musel všechny informace vypisovat v textové podobě. Pravidla NAR a této metodiky stanovují nejen význam elementů a vazeb daného typu, ale říkají i, jak lze elementy mezi sebou propojovat, a definují jejich možné využití. Dále ukazují vazby v různých perspektivách. Tím, že model umožňuje použít jeden element či vazbu pro více pohledů, je eliminováno duplikování informací, což bývá zásadní problém pro jeho dlouhodobou udržitelnost a rozvoj.
	+
	+	Modelování dle předem dohodnutých pravidel zajišťuje, že uložené informace v modelu budou pro čtenáře pochopitelné a model bude možné dlouhodobě udržovat a rozvíjet.
	+
	+	===== Tvorba modelu obecně =====
	+
	+	{{page>nar_dokument:metodika_modelovani_2}}
	+
	+	===== Hlediska a pohledy =====
	+
	+	{{page>nar_dokument:metodika_modelovani_3}}
	+
	+	===== Členění modelu =====
	+
	+	{{page>nar_dokument:metodika_modelovani_4}}
	+
	+	===== Modelování dle NAR =====
	+
	+	{{page>nar_dokument:metodika_modelovani_5}}
	+
	+	===== Nástroje =====
	+
	+	{{page>nar_dokument:metodika_modelovani_6}}
	+
	+	===== Definice pojmů v této metodice =====
	+
	+	Níže je uvedena definice důležitých pojmů, s nimiž tento dokument pracuje. Cílem je jednoznačné chápání těchto pojmů v kontextu této metodické dokumentace.
	+
	+	//Tabulka 1: Definice pojmů//
	+
	+	^Zkratka ^Význam ^
	+	\|ArchiMate \|Framework pro modelování enterprise architektury od The Open Group \|
	+	\|BP \|Business process (obchodní process) \|
	+	\|ČR \|Česká republika \|
	+	\|DIA \|Digitální a informační agentura \|
	+	\|EA \|Enterprise architektura \|
	+	\|ESRM \|Enterprise Risk and Security Management.\\ Framework pro bezpečnostní architekturu od Bizzdesign \|
	+	\|ICT \|Informační a komunikační technologie \|
	+	\|IT \|Informační technologie \|
	+	\|NAR \|Národní architektonický rámec \|
	+	\|OHA \|odbor Hlavního architekta eGovernmentu \|
	+	\|OVS \|Orgán veřejné správy \|
	+	\|PMO \|Project Management Office (projektová kancelář) \|
	+	\|RPP \|Registr práv a povinností. Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností. Slouží jako zdroj údajů pro informační systémy základních registrů při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. \|
	+	\|KSVS \|Katalog služeb veřejné správy. \|
	+	\|TOGAF \|The Open Group Architecture Framework \|
	+	\|UML \|Unified Modeling Language \|
	+	\|VS \|Veřejná správa \|
	+
	+	Níže je uveden slovník pojmů s překlady do českého jazyka.
	+
	+	//Tabulka 2: Slovník pojmů v této metodice//
	+
	+	^Pojem ^Význam ^
	+	\|application \|aplikace / aplikační \|
	+	\|best practice \|nejlepší praxe \|
	+	\|business \|obchod / obchodní \|
	+	\|capability \|schopnosti \|
	+	\|enterprise \|podnik / podnikový. Zde hlavně úřad. \|
	+	\|layer \|vrstva \|
	+	\|motivation \|motivace / motivační \|
	+	\|note \|poznámka \|
	+	\|performance \|výkonost / výkonnostní \|
	+	\|refaktorování \|změna struktury či formy beze změny významu obsahu \|
	+	\|security \|bezpečnost / bezpečnostní \|
	+	\|stream \|tok, kanál \|
	+	\|tailoring \|přizpůsobení na míru \|
	+	\|top-down \|od celku k detailům \|
	+	\|value \|hodnota \|
	+	\|prvek modelu \|obecná součásti modelu (element, vazba) \|
	+	\|element \|základní stavební prvek modelu \|

Hlediska a pohledy

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:26:13+00:00

2025/05/07 10:38		aktuální
Řádek 1:		Řádek 1:
-	====== Modelování dle NAR ======	+	====== Hlediska a pohledy ======

-	===== Architektonické domény =====	+	===== Hlediska =====

-	Domény se podle NAR dělí na základní horizontální domény (Core), tzv. vrstvy, které představují výkon veřejné správy a provozu OVS a k tomu potřebné zdroje. Vertikální motivační domény určují důvody, proč základní domény obsahují, co obsahují, nebo proč by se měly změnit. Nakonec doména Implementace a migrace podporuje modelování té části reality OVS, kterou představují plánované a realizované změny v základních vrstvách (i změny a balíčky práce-projekty jsou součástí reality OVS).	+	Pro potřeby sladění očekávání čtenářů a tvůrců modelu a pro tvorbu výstupů z něj je potřeba správně rozhodnout, jak vizualizovat informace v modelu uložené (viz princip Přizpůsobujte výstupy pro konkrétní čtenáře). K tomu pomáhá definice Hledisek popisujících, co daný čtenář očekává, že najde v pohledech na model. Jedno hledisko může být realizované na více pohledech, ale čtenář by měl vždy být schopný najít pro sebe zajímavé informace v plném potřebném kontextu.

-	{{ :playgroud:metodika_ey:detail_architektonickych_domen.png?400 \|}}	+	V NAR a této metodice pro zjednodušení vždy jednomu hledisku zainteresovaných odpovídá jedna definice pohledu typu Diagram, která pak může mít v jednom modelu více výskytů pohledů, například v různé míře podrobnosti (L0 až L2) nebo se zaměřením na některý konkrétní koncept. Artefakty typu diagram vycházejí ze společných artefaktů typu Katalog.

-	Detailně jsou architektonické domény NAR popsané přímo ve zdrojovém materiálu:	+	Katalogy jsou pro každý modelovaný koncept vždy jednotné a unikátní, objektové. Na rozdíl od Diagramů se u Katalogů neuplatní Hlediska.

-	https://archi.gov.cz/nar_dokument:struktura_modelovanych_architektur#domeny_obsahu_architektur	+	Hlediska pro očekávané čtenáře definuje NAR: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hlediska_a_definice_pohledu_narodni_architektury_vs_cr

-	===== Metamodel =====	+	===== Druhy pohledů =====

-	Metamodel v ArchiMate slouží jako základní rámec pro modelování podnikové architektury. Definuje možné elementy a vztahy, čímž zajišťuje konzistenci a srozumitelnost napříč různými modely a organizacemi. Použití metamodelu zajišťuje kompatibilitu a snadné sdílení modelů vytvořených různými týmy nebo nástroji, což podporuje spolupráci a výměnu informací. Díky němu lze také automatizovat správu modelů a kontrolovat jejich kvalitu. Z pohledu modeláře je metamodel nejdůležitější referencí při tvorbě modelů.	+	Pohledy v notaci ArchiMate jsou klíčové pro pochopení různých aspektů podnikové architektury. Každý pohled se zaměřuje na specifickou část architektury a poskytuje různé úhly pohledu na systém. Byznys pohledy se zaměřují na byznys procesy, role, aktéry a produkty. Pomáhají pochopit, jak byznys funguje a jaké jsou jeho hlavní komponenty a vztahy mezi nimi. Aplikační pohledy se zaměřují na aplikační komponenty a jejich interakce. Ukazují, jak aplikace podporují byznys procesy a jak spolu aplikace komunikují. Technologické pohledy se zaměřují na technologickou infrastrukturu, včetně serverů, sítí a dalších technických komponent. Pomáhají pochopit, jak je technologická infrastruktura uspořádána a jak podporuje aplikační a byznys vrstvy. Motivační pohledy se zaměřují na cíle, principy a požadavky, které řídí architekturu. Pomáhají pochopit, proč je architektura navržena určitým způsobem a jaké jsou její hlavní cíle.

-	==== Povinnost využití prvků metamodelu ====	+	Pohledy zobrazují (vizualizují) vybrané části modelu tak, aby naplnily hlediska jeho čtenářů.

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

-	==== Metamodely dle komplexity ====	+	* Diagram – zobrazuje graficky vybrané elementy, jejich atributy a vazby mezi nimi. Jsou nejobvyklejším druhem pohledu.
		+	* Matice – ukazuje propojenost dvou skupin elementů. Na osách X a Y jsou výčty elementů z vybrané části modelu a na průsečících mezi nimi je indikace existence vazby daného typu a směru. Obvykle jsou použité pro vizualizaci mapování.
		+	* Katalog – je výčet elementů v podobě tabulky. U každého elementu je vypsaná vybraná množina atributů. Katalogový výpis může být uživatelsky filtrovatelný, dle zvolené formy vizualizace.

-	Pro potřeby metodiky modelování architektury v DIA definováno několik úrovní metamodelu, podle očekávané míry detailu obsažených informací v daném modelu. Ukazují také, které elementy by měly být v jádru modelu (Zjednodušený metamodel) a které se hodí pro popis sloužitějších detailnějších konstrukcí (až po Maximální metamodel).	+	Využitelné typy pohledů definuje metodika, zároveň určuje jejich roli při tvorbě modelu.

-	{{ :playgroud:metodika_ey:metamodel_diagram.png?400 \|}}	+	==== Diagramy ====

-	=== Maximální ===	+	U diagramů je nejdůležitější, aby:

-	Maximální metamodel ukazuje celkovou množinu prvků a vazeb, použitelných při vytváření modelů pro DIA. Kromě prvků definovaných ArchiMate je tento metamodel rozšířený o prvky z TOGAF a o specifické prvky pro DIA.	+	- Co nejpřesněji vyjadřovaly sdělení (příběh) svého autora, nositele myšlenky;
		+	- Co nejlépe posloužily potřebě svého čtenáře, úměrně jeho specifickým možnostem vnímání a porozumění.

-	Tento metamodel není doporučen k přímému použití ale spíše k vymezení možností v případě velmi komplexních modelů a edukovaných čtenářů.	+	Dále je třeba věnovat největší pozornost počtu a rozmístění prvků na nich. Správné rozmístění, zarovnání a celková uklizenost diagramu naprosto zásadně zlepšuje schopnost pochopení myšlenek a informací.

-	=== Základní ===	+	Pro diagram jsou zásadní následující aspekty:

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

-	=== Zjednodušený ===	+	\|Soulad s metamodelem \|Na diagramu by měly být pouze elementy, vazby a atributy předepsané metamodelem. Zásadní je nesnažit se na diagram zanést všechny informace najednou – nejspíše porušíte metodická pravidla a diagram půjde velmi obtížně naformátovat, číst i aktualizovat ^
		+	\|Barvy a legenda \|metodika předepisuje barevnost elementů a vazeb. Přesto je silně doporučeno doplnit vždy diagram o legendu, která zdůrazní barevný kód. Povinně vždy, pokud děláme složitější barevné schéma, než je zvyklost ArchiMate (žlutý business, modré aplikace, zelená infrastruktura)\|

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

-	Pro ilustraci je níže uveden Základní metamodel v podobě, v jaké je prezentován v NARu.	+	\|Čitelnost \|Diagram by měl být snadno čitelný v podobě, v jaké je zobrazen ve výstupu (obvykle dokument formátu A4, či zobrazení na displeji, zařazení do jednoho slide v PowerPointu). Platí pravidlo, že čtenář by měl být schopen význam a hlavní myšlenky diagramu pochopit do 30 sekund. K tomu pomáhají body níže. ^
		+	\|Rozměr \|Diagram by měl být čitelný celý, pokud bude zobrazen v zamýšleném výstupním formátu a pozorovaný z obvyklé vzdálenosti bez potřeby „zoomování“. \|
		+	\|Počet elementů \|Velmi záleží na druhu diagramu a zamýšleném způsobu prezentace. Doporučeno je pro diagramy jiného než přehledového účelu použít do cca 15 elementů. Přehledové diagramy, u nichž je předpoklad tisku na větší formát, mohou mít počet elementů i násobně větší a stále zachovat pochopitelnost. \|
		+	\|Uspořádání elementů \|Elementy na diagramu rozmisťujeme tak, aby byla patrná myšlenka, příběh a vztahy elementů. Vhodnou topologii (umístění) lze čerpat z referenčních modelů, pokud jsou OHA publikovány. \|
		+	\|Zvýraznění rozměrem \|Centrální prvek diagramu může být rozměrově zvětšen, aby upoutal oko, odtud začne čtenář diagram číst. \|
		+	\|Zobrazení detailů elementu \|Využijte možnosti nástroje zobrazit či naopak nezobrazit vybrané atributy elementu, podle zprávy, kterou chceme předat čtenáři a aby se detaily zbytečně neopakovaly na více diagramech. Např. u elementů navázaných na ústřední element diagramu není třeba uvádět všechny detaily, zajímá nás pouze výčet těchto elementů a jejich detailní zobrazení najdeme na diagramu jim dedikovaným. Eliminuje se tím také riziko, že se pracně odladěný diagram rozbije při přidáním nových atributů k elementu. \|
		+	\|Zobrazení vazeb \|Zvažte, zda na diagramu potřebujeme všechny vazby mezi zobrazenými elementy. Často nás zajímají vazby jen na centrální element, ale ne vazby mezi sekundárními elementy. Případně nás zajímají vazby jen vybraných typů. V takovém případě je vhodné nezajímavé vazby na diagramu schovat. Nástroje obvykle podporují možnost jak samotného vypínání viditelnosti vazeb ad-hoc a tak i plošně vypnout zobrazení dané vazby na jiných diagramech (to se hodí v případě, kdy přidáváme novou vazbu a daná kombinace elementů se objevuje i na jiných diagramech).\|
		+	\|Zarovnání elementů \|Doporučujeme věnovat velkou pozornost optimalizaci rozmístění prvků na diagramu tak, aby byly elementy zarovnané (lze např. použít mřížku v modelovacím nástroji) \|
		+	\|Zarovnání vazeb \|Vazby by měly být ideálně zalamované tak, aby se co nejméně křížily a aby neprocházely přes elementy. U přehledových diagramů lze využít zarovnání vazeb do „sběrnice“ kdy vazby vycházejí z jednoho bodu elementu, vedou přes sebe a odbočují k cílovým elementům. \|

-	{{ :playgroud:metodika_ey:zakladni_metamodel_dle_nar_pro_ilustraci.png?400 \|}}	+	{{ :playgroud:metodika_ey:ilustrace_1_-_citelny_diagram.png?400 \|}}

-	<WRAP centeralign> //Základní metamodel dle NAR pro ilustraci// </WRAP><WRAP clear/>	+	<WRAP centeralign> //Příklad čitelného diagramu// </WRAP><WRAP clear/>

-	Detailně jsou metamodely na jednotlivých úrovních popsány v NARu:	+	{{ :playgroud:metodika_ey:ilustrace_1_2_-_necitelny_diagram.png?400 \|}}

-	https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#celkovy_metamodel_na_vs_cr	+	<WRAP centeralign> //Příklad nečitelného diagramu (diagram obsahuje chaoticky rozmístěné elementy, kontrast písma a pozadí je nevhodný a nedodržuje standard, vazby jsou nepřehledné a velikost písma je pro čtenáře příliš malá)//</WRAP><WRAP clear/>

-	==== Doménové metamodely ====	+	{{ :playgroud:metodika_ey:ilustrace_1_3_-_usporadany_diagram.png?400 \|}}

-	Každá doména v této metodice má vlastní detailní metamodel, který je ale vždy součást celkového metamodelu. Cílem je ukázat výčet elementů a vazeb použitelných pro modelování v dané doméně.	+	<WRAP centeralign>//Příklad uspořádaného diagramu//</WRAP><WRAP clear/>

-	Kompletní informaci o jednotlivých metamodelech najdete v NAR: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#dilci_domenove_metamodely	+	{{ :playgroud:metodika_ey:ilustrace_1_4_-_neusporadany_diagram.png?400 \|}}

-	===== Elementy a vazby =====	+	<WRAP centeralign> //Příklad neuspořádaného diagramu (elementy nejsou zarovnány, vazby se překrývají a nejsou přehledné, velikost rámečků není jednotná a font, velikost a barva písma je zvolená bezmyšlenkovitě – není obsažena legenda)//</WRAP><WRAP clear/>

-	Metodika NAR přebírá elementy a vazby ze standardu ArchiMate, přičemž ale tvoří jejich nadstavbu. U některých z nich upřesňuje český název a/nebo význam a dále definuje vlastní elementy, byť využívající jako základy typy dle ArchiMate.	+	{{ :playgroud:metodika_ey:ilustrace_1_5_-_uklizene_a_vyfiltrovane_vazby.png?400 \|}}

-	Elementy a vazby, které mohou být využity v modelech postavených na metamodelu výše jsou specifikované v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#prehled_lokalizace_prvku_a_vazeb_standardu_archimate	+	<WRAP centeralign> //Příklad diagramu s uklizenými a vyfiltrovanými vazbami//</WRAP><WRAP clear/>

-	===== Vizuální konvence prvků modelů =====	+	{{ :playgroud:metodika_ey:ilustrace_1_6_-_diagram_se_vsemi_vazbami.png?400 \|}}

-	Tato metodika respektuje definovaný vzhled, barevnost a pravidla vizualizace dle standardu ArchiMate. Tato pravidla je třeba dodržet. Obvyklé modelovací nástroje vizuální standard ArchiMate implementují a splňují, není v nich proto třeba v této oblasti nic specifického nastavovat.	+	<WRAP centeralign> //Příklad diagramu se všemi vazbami, navíc bez zarovnání//</WRAP><WRAP clear/>

-	Detailní popis použitého vizuálního standardu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#pravidla_pouziti_jazyka_archimate_pro_modelovani_na_vs_cr	+	{{ :playgroud:metodika_ey:centricky_element2.png?400 \|}}

-	===== Přehled výstupů =====	+	<WRAP centeralign> //Příklad centrického elementu v diagramu//</WRAP><WRAP clear/>

-	{{ :playgroud:metodika_ey:prehled_vystupu_v_jednotlivych_architektnickych_domenach_dle_nar.png?400 \|}}	+	{{ :playgroud:metodika_ey:ilustrace_1_7_-_priklad_prehledoveho_diagramu.png?400 \|}}

-	<WRAP centeralign>//Přehled výstupů v jednotlivých architektnických doménách dle NAR//</WRAP><WRAP clear/>	+	<WRAP centeralign> //Příklad přehledového diagramu//</WRAP><WRAP clear/>

-	===== Tvorba modelu v jednotlivých doménách =====	+	==== Matice ====

-	Jak je popsáno v kap. Architektonické domény, pracuje tato metodika s deseti architektonickými doménami. Níže je po jednotlivých architektonických doménách v NAR popsán způsob tvorby modelu a příslušných artefaktů. Předpokládá se situace, kdy je architekt jako modelář postaven před úkol zmapovat aktuální situaci v úřadu, tedy že systematický model ještě neexistuje. Na závěr kapitoly jsou uvedena pravidla pro přehledové a průřezové artefakty (katalogy a diagramy), výrazně se vymykající jednotlivým doménám a přesahující je.	+	Matice jsou specifickým vizualizačním prvkem umožňují přehledně ukázat mapování mezi dvěma sadami elementů. Jsou užitečné pro kontrolu a ladění propojenosti, kdy jsou sady elementů ve vztahu m:n. V takovém případě se obtížně tvoří, a hlavně udržuje, podobný diagram.

-	==== Byznys architektura výkonu a provozu veřejné správy ====	+	Matice slouží pro i mapování vazeb mezi objekty napříč vrstvami architektury, což umožňuje čtenáři pochopit provázanost objektů a jejich využívání.

-	Základní modelovaný obsah byznys reality OVS slouží pro lepší pochopení požadavků byznysu na aplikační podporu. Proto potřebujeme poznat a pochopit, jaké má úřad agendy a činnosti (funkce a procesy), jestli jsou vykonávány jako služby, a dále kým, pro koho a jak, kterým obslužným kanálem, s jakými daty a dokumenty.	+	NAR tvorbu a použití matic dosud blíže neupravuje, tato metodika uvádí možné využití matic tam, kde to je efektivní.

-	=== Doporučení pro modelování prvků BA ===	+	Na co myslet při tvorbě matic:

-	Následující kapitoly vysvětlují, jak modelovat prvky reality, které se odlišují od komerčního užití jazyka ArchiMate a jsou typické pro veřejnou správu ČR.	+	\|Počet elementů na osách \|Při velkém počtu elementů může být při tisku na obvyklé formáty papíru mapa příliš jemná a nečitelná. Doporučujeme zvážit rozpad na více matic \|
		+	\|Aktualizace matice \|Při průběžné tvorbě obsahu se výčet elementů na osách matice mění. Proto je vhodné matici aktualizovat, aby ukázala vždy platný seznam elementů. Totéž se týká sledovaných vazeb.\|
		+	\|Vytvoření vazby v matici vs. v diagramech \|Pokud vytváříte vazby přímo přes matici, zkontrolujte, zda se nechtěně neobjeví na diagramech s danou kombinací elementů. \|

-	== Jak modelovat agendy a činnosti VS ==	+	//Pozn.: Některé nástroje pro správu modelů matice nepodporují (například Archi).//

-	Agendy a agendové činnosti jsou základními elementy pro modelování náplně práce úřadu. Jsou primárně definované a udržované v Registru Práv a Povinností((https:%%//%%www.szrcr.cz/cs/registr-prav-a-povinnosti	+	{{ :playgroud:metodika_ey:ilustrace_1_8_-_matice_v_nastroji_sparx_enterprise_architect.png?400 \|}}
-	)), kde je také uvedeno přiřazení k jednotlivým úřadům.	+

-	Je vhodné zmapovat agendy a činnosti nezávisle na RPP, aby byly dokumentované i neohlášené agendy, které v RPP nejsou, ale úřad je vykonává. Možným zdrojem informací může být Organizační řád úřadu a komunikace s příslušnými Ohlašovateli agend a referenty.	+	<WRAP centeralign> //Ukázka matice přímo v nástroji Sparx Enterprise Archtect//</WRAP><WRAP clear/>

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

-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_pro_tuto_oblast_v_metamodelu.png?400 \|}}	+	Katalogy jsou výčty elementů daného typu, zobrazené ve formě tabulky s možností řazení či filtrace a nastavení zobrazených atributů.

-	<WRAP centeralign>//Identifikace elementů a vazeb pro tuto oblast v metamodelu//</WRAP><WRAP clear/>	+	Katalogy jsou spolu s maticemi více interaktivní než diagramy a hodí se zejména pro práci přímo v nástroji. Obvykle se katalogem řeší potřeba výčtu elementů s konkrétním řazením a atributy, či pro gap analýzy pomocí filtrace určitých hodnot atributů.

-	== Jak modelovat služby a úkony z Katalogu služeb VS ==	+	V tištěné dokumentaci je obvykle katalog realizován pomocí šablony pro vygenerování dokumentu pro příslušnou část modelu.

-	Služby veřejné správy jsou detailnějším rozpadem agend. Popisují, jak agendy slouží klientům úřadu a jak jsou navázané na produkty, smlouvy, předpisy a jakými obslužnými kanály je poskytovaná.	+	NAR doporučuje používat pro inventarizaci a správu portfolií klíčových konceptů (procesů, rolí, aplikačních a technologických komponent a služeb apod.) katalogy v tabulkovém kalkulátoru nebo ve specializovaných nástrojích, s obsahem podle OHA publikovaných akcelerátorů. Takto připravené tabulkové zdroje je možné hromadně naimportovat do nástroje, čímž se ušetří čas. Pro hromadné úpravy je možné katalog dočasně vyexportovat, upravit vně nástroje a opět naimportovat. Vždy je ale nutné zajistit, že model je primární zdroj katalogů pro potřeby podnikové architektury.

-	Zdrojem pro výčet služeb je Katalog služeb veřejné správy((Informace o katalogu: https:%%//%%archi.gov.cz/nap:katalog_sluzeb	+	U katalogů jsou zásadní následující aspekty:
-	)), který je členěn i dle poskytovatelů služby (úřad, který danou službu poskytuje).	+

-	Je vhodné zmapovat služby nezávisle na KSVS, aby byly dokumentované i realizované služby neohlášených agend, interní služby poskytované úřady navzájem a služby pokrývané externími dodavateli (typicky služby IT podpory, správa budov, apod,).	+	\|Definice typů elementů \|Definice typů elementů v jednom katalogu – je vhodné členit katalogy dle typu elementu podle metodiky \|
		+	\|Řazení elementů \|Řazení elementů v katalogu – obvyklé je výchozí řazení abecední dle názvu, přičemž je možné při vizualizaci katalogu volit řazení dle libovolného zobrazeného atributu. \|
		+	\|Vnitřní strukturování katalogu\|Vnitřní strukturování katalogu – s ohledem na očekávané množství položek a použitý způsob vizualizace lze někdy doporučit katalog vnitřně členit, např. dle modulů. Obvyklejší je ale ponechat seznam lineární a veškerou filtraci a řazení ponechat na vizualizačním nástroji pro katalog.\|

-	Služby mají velmi různorodou granularitu a celkové množství služeb je značné, proto je vhodné některé menší služby seskupovat pod jeden element postihující celou množinu. Informaci o jednotlivých pokrytých službách pak je možné zadat do popisu.	+	//Pozn.: Některé nástroje pro správu modelů katalogy nepodporují (například Archi).//

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

-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu.png?400 \|}}	+	<WRAP centeralign> //Ukázka katalogu přímo v nástroji Sparx Enterprise Architect//</WRAP><WRAP clear/>

-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat životní události a životní situace ==
-
-	Životní události a situace mají velký význam pro konzumenty služeb – klienty úřadů. Popisují významné změny a stavy v jejich životě a často bývají spouštěči či důsledky využití služeb úřadů. Při modelování jsou využité často jako vstupní body do interakcí občana s IS úřadů – tedy obvykle při návrhu řešení IS.
-
-	Pro modelování podnikové architektury ale obvykle zásadní nejsou, neboť pro identifikaci služeb a procesů jsou použité jiné stabilní zdroje informací.
-
-	Životní události jsou modelované pomocí elementu „Životní událost“ (Business event dle ArchiMate). Obvykle jsou napojené na procesy či funkce realizující jednotlivé obchodní služby, jako jejich spouštěče či důsledky. Mohou být případně navázané na samotné Služby VS pro evidenci jejich pokrytí.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_2.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat organizační jednotky a pracovní pozice ==
-
-	Struktura organizace je vyjádřena stromovou strukturou útvarů, případně i konkrétních pracovních pozic. Při modelování podnikové architektury se tyto prvky používají pro mapování vztahu daného útvaru na služby, kanály, či jiné části, např. pro vyjádření vlastnictví, či účasti na provádění. Dále je vhodné využití pro vizualizaci komplexní organizační struktury a jejích částí, včetně umístění. Pro potřeby OHA se informace z organizační struktury využívají pro popis skladby projektového týmu.
-
-	Informace o organizační struktuře úřadu je primárně udržovaná v Organizačním řádu. Není tedy nezbytně nutné ji modelovat samu o sobě.
-
-	Organizační jednotky a pracovní pozice jsou modelované pomocí elementů „Útvar“, „Organizace“ či „Účastník interakce s VS“ (Business actor dle ArchiMate). Obvykle jsou napojené na Službu VS či Obslužný kanál VS.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_3.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat zákony, vyhlášky a vnitřní předpisy ==
-
-	Předpisy v různé podobě (zákon, vyhláška, vnitřní předpis, …) jsou často důvodem pro existenci dané služby či formují její fungování. Z toho důvodu je zajímavé je modelovat na úrovni podnikové architektury, zejména pak mapování na služby a produkty. Využití je pak právě pro gap analýzy při změnách příslušných předpisů. Primárním zdrojem je legislativa ČR, EU a sada vnitřních předpisů úřadu. Je vhodné striktně přenést název a identifikátor pro zamezení duplicit. Do popisu předpisu je pak vhodné uvést dopady do úřadu.
-
-	Předpisy jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Obvykle jsou navázané na Službu VS či Produkt VS.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_4.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat obslužné kanály ==
-
-	Obslužný kanál popisuje rozhraní, skrz které klient či pracovník úřadu přistupuje k jeho službám. Kanál je často předepsán legislativně (typicky ze zákona o právu na digitální službu). Obslužný kanál je modelovaný pomocí elementu „Obslužný kanál VS“ (Business interface dle ArchiMate). Obvykle je vázán jako mezičlánek mezi Službu VS a Účastníka interakce s VS.
-
-	== Jak modelovat procesy ==
-
-	Procesy jsou obvykle nejdetailnější úrovní popisu obchodní vrstvy v podnikové architektuře. Cílem je identifikovat: znát jejich výčet a umět slovně popsat jejich význam. Dobrým zdrojem pro identifikaci procesů bývají vnitřní směrnice, případně jakákoli jiná dokumentace procesů, např. v BPMN.
-
-	Na této úrovni lze popsat i obchodní funkce. Obchodní funkce je obecnější pojem než proces. Proces je z pohledu NAR vnímán jako specifický druh obchodní funkce, který má charakteristiku procesu: má jasného vlastníka, je řízený jako proces a chová se jako proces.
-
-	Procesy i obchodní funkce jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Hlavní vazbou je realizace příslušné Služby VS. Pokud je to vhodné, je možné navázat funkci/proces na odpovídající objekty (sloužící jako vstupy či výstupy) a role, definující sadu vlastností, které má mít Účastník interakce s VS, aby mohl části procesu vykonávat. Jak bylo zmíněno výše, procesy často spouští vybraná Životní událost a naopak, výstupem procesu může být Životní událost u klienta úřadu. Pro takto velký detail je třeba mít opodstatnění, neboť významně zvyšuje množství potřebných informací a čas na modelování a dále se může již překrývat s dalšími úrovněmi modelování, jako je modelování procesů, či funkční analýza.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_5.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	=== Hlediska a pohledy ===
-
-	Důležitými čtenáři byznys architektury jsou business architekti, datoví/informační architekti a vlastníci produktů. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:
-
-	* Hledisko portfolia (klasifikace) byznys funkcí, procesů a služeb
-	* Hledisko funkcí veřejné správy
-	* Produktové hledisko
-	* Hledisko spolupráce byznys procesů
-	* Hledisko organizační struktury
-	* Hledisko spolupráce aktérů
-
-	== Katalogy ==
-
-	Každý modelovaný typ elementu by měl mít vlastní katalog, jelikož společně s maticí představují výchozí předpoklad pro jeho správné grafické vyjádření. Nejdůležitější pro čtenáře výše bývají následující:
-
-	* Katalog agend, činností (funkcí a procesů)
-	* Katalog služeb a úkonů veřejné správy
-	* Katalog aktérů (jejich typů) a jejich rolí
-	* Katalog obslužných rozhraní veřejné správy
-	* Katalog typů subjektů a objektů (konceptuální sémantický katalog)((Katalog je základem datové domény architektury, je společný pro byznys a datovou doménu.))
-
-	Dále to mohou být například:
-
-	* Katalog organizačních jednotek, útvarů a pozic
-	* Katalog životních událostí, uplatnitelných vůči OVS
-	* Katalog formulářů a výstupů OVS
-
-	== Diagramy ==
-
-	Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.
-
-	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
-	\|Organizační struktura((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_organizacni_struktury)) \|Diagram útvarů ve stromové struktuře organizace \|Hledisko organizační struktury \|
-	\|Přehled (mapa) schopností úřadu((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_prehledu_schopnosti_uradu)) \|Přehled schopností, seskupené na Strategické, Operační, Podpůrné \|Hledisko přehledu schopností úřadu \|
-	\|Mapa agend \|Přehled agend úřadu \|Hledisko portfolia byznys funkcí a služeb \|
-	\|Mapa služeb VS \|Přehled služeb \|Hledisko portfolia byznys funkcí a služeb \|
-	\|Mapa procesů a funkcí \|Přehled procesů \|Hledisko funkcí veřejné správy \|
-	\|Spolupráce procesů((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_spoluprace_byznys_procesu)) \|Vztahy procesů mezi sebou a okolním elementům \|Hledisko spolupráce byznys procesů \|
-	\|Proces((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_spoluprace_byznys_procesu)) \|Detailní pohled na elementy v okolí jednoho procesu \|Hledisko spolupráce byznys procesů \|
-	\|Diagram informačních objektů \|Zmapování identifikovaných objektů a vizualizace vazeb mezi nimi. \|Hledisko struktury informací((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_struktury_informaci)) \|
-
-	=== Na co si dát pozor ===
-
-	\|Zajistěte si podporu organizace \|Bez pochopení na straně poskytovatelů informací není možné se dobrat věrného modelu. Je nezbytně nutné, aby o aktivitě EA bylo v organizaci povědomí a byl zřejmý účel a výhody poskytnutí informací. Často bývá tento problém zásadní pro přípravu hodnotného modelu.^
-	\|Nezabředněte do příliš velkého detailu \|Např. u modelování procesů. Pořád mít na mysli očekávanou úroveň detailu danou metamodelem a očekávaným čtenářem. Pokud je vhodné zajít do většího detailu, naznačit to popisem, nebo se odkázat na detailní model mimo tuto část. \|
-
-	=== Reference ===
-
-	Přesnou definici prvků a metamodel pro obchodní vrstvu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_byznys_architektury_ba
-
-	==== Aplikační architektura IS a datová architektura ====
-
-	Architektura aplikací a dat je stěžejní částí architektonických modelů, neboť drtivá většina agend z byznys architektury je realizovaná právě službami aplikací. V této oblasti se zaměřujeme na zmapování portfolia aplikací v úřadu a způsob, jakým spolu aplikace interagují pomocí rozhraní a s jakými daty pracují. Dále nás zajímá mapování na prvky z úrovně byznys architektury, aby byl zřejmý důvod existence jednotlivých aplikací. Doporučená redukce metamodelu NAR pro aplikační úroveň je vyobrazená na následujícím schématu.
-
-	{{ :playgroud:metodika_ey:doporucena_redukce_metamodelu_aplikacni_architektury.png?400 \|}}
-
-	<WRAP centeralign>//Doporučená redukce metamodelu aplikační architektury //</WRAP><WRAP clear/>
-
-	=== Doporučení pro modelování prvků AA ===
-
-	== Jak modelovat aplikační komponenty ==
-
-	Aplikační komponenta je nejvýraznější element aplikační architektury. Reprezentuje jednotlivé IT systémy, aplikace, nebo jejich části (pokud je to z pohledu podnikové architektury zajímavý detail) v podniku. Katalog aplikačních komponent je základním prvkem podnikové architektury, neboť dnes je většina služeb realizovaných právě pomocí IT systémů. Je proto vhodné investovat úsilí do jeho vybudování a údržby.
-
-	Základními atributy aplikačních komponent by měly být:
-
-	* Název
-	* Identifikátor
-	* Vlastník z byznysu (tzv. Věcný správce ISVS, určuje účel aplikace a její funkčnosti)
-	* Technický vlastník (tzv. Technický správce ISVS, navrhuje řešení a stará se, aby aplikace fungovala)
-	* Kategorizace
-	* Kritičnost pro fungování podniku
-
-	Doporučených atributů, užitečných pro správu aplikačního portfolia jsou desítky, viz přiložený soubor. Soubor lze použít pro inspiraci pro identifikaci atributů či vazeb, které by mohly být u aplikační komponenty evidované.
-
-	<wrap em>{{ :playgroud:metodika_ey:na_katalog_aplikaci_vzor_v2.2.xlsx \|Katalog užitečných atributů}}</wrap>
-
-	Zdrojem informací o aplikačních komponentách je typicky portfolio udržovaných aplikací a systémů evidované provozními týmy IT.
-
-	Zásadní informace u aplikační komponenty jsou vazby na okolí:
-
-	* Jaké aplikační funkce a služby realizuje
-	* Jaká aplikační rozhraní poskytuje a konzumuje
-	* S jakými Datovými objekty pracuje
-
-	Situace je ilustrována na následujícím obrázku. Podrobněji je o těchto elementech a vazbách pojednáno níže.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_6.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat aplikační služby ==
-
-	Aplikační služba realizuje Službu veřejné správy skrze využití ve Funkci/procesu VS. Je hlavním pojítkem mezi aplikační a byznysovou vrstvou architektury. Aplikační služba je tedy vlastně opodstatněním pro existenci Aplikační komponenty.
-
-	Aplikační služby lze chápat jako požadavky na funkce IT aplikace, které definuje vlastník příslušných procesů a služeb na byznys úrovni. Aplikační služba je pak realizována sadou Aplikačních funkcí, které poskytuje příslušná Aplikační komponenta.
-
-	Aplikační služby by měly vyplývat z potřeb prováděných Funkcí/procesů VS, které definuje příslušný vlastník.
-
-	{{ :playgroud:metodika_ey:fragment_metamodelu_nar_ilustrujici_kontext_aplikacni_sluzby.png?400 \|}}
-
-	<WRAP centeralign>//Fragment metamodelu NAR ilustrující kontext Aplikační služby//</WRAP><WRAP clear/>
-
-	== Jak modelovat aplikační rozhraní ==
-
-	Aplikační rozhraní je bod, kde jsou aplikační služby zpřístupněny uživatelům, či jiným aplikačním komponentám.
-
-	Význam evidence Aplikačních rozhraní je hlavně v systematizaci komunikace mezi aplikacemi a vůči uživatelům. Díky zmapování rozhraní je možné identifikovat vzory komunikace mezi aplikačními komponentami a je snadné přepoužívat existující rozhraní s vědomím dopadu změny. Velmi důležitá je evidence rozhraní k aplikačním službám, které jsou sdílené externě (mezi úřady).
-
-	Obvyklým zdrojem informací o existujících rozhraních je obchodní proces, kde jej identifikované použití rozhraní na aplikační úrovni. Dále je možné identifikovat existenci rozhraní ze solution architektury a/nebo z technické dokumentace aplikací. Dobrým zdrojem je i celofiremní integrační komponenta typu ESB (Enterprise Service Bus), či podobná, kde jsou často využívaná rozhraní koncentrována.
-
-	Pokud mezi sebou organizace komunikují aplikačním rozhraním, pak je to realizace procesu, např. využití business služby. Proto je vhodné zanést tuto informaci do modelu pomocí vazby na příslušnou obchodní Funkci či Proces (viz obrázek výše s kontextem aplikační komponenty).
-
-	Aplikační rozhraní je vždy vlastněno vybranou aplikační komponentou, které jej poskytuje a je využíváno libovolným množstvím jiných aplikačních komponent.
-
-	K aplikačnímu rozhraní je možné namapovat Datové objekty, které jsou jím přenášené.
-
-	K aplikačním rozhraním je vhodné udržovat dle potřeby následující atributy:
-
-	* Technologie (REST, XML, proprietární, …)
-	* Typ komunikace (sync, async, batch)
-	* Reference na detailní dokumentaci k rozhraní
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_7.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat datové objekty ==
-
-	Datové objekty reprezentují realizaci Objektů VS (Business Object) na aplikační úrovni, tj. Na úrovni obrazů skutečných věcí z BA v datech informačních systémů. Případně jsou to reprezentace jiných pasivních prvků evidovaných na úrovni aplikační architektury. Jejich granularita je obvykle jemnější než u Objektů VS, aby na ně bylo možno jednoznačně navázat dalšími prvky v aplikační vrstvě.
-
-	Zdrojem pro model Datových objektů jsou konceptuální a logické datové modely příslušných aplikací, ideálně získané z datového katalogu úřadu((https://data.gov.cz/p%C5%99%C3%ADlohy/popis-dat/dokumenty/Metodika-popisu-dat.pdf
-	)). Abychom předešli duplikaci informací mezi datovým katalogem a modelem podnikové architektury, je vhodné rozmyslet kde bude master pro tyto informace – zda datový katalog, nebo model EA a podle toho nastavit procesy replikace z masteru na ostatní umístění.
-
-	Modelujeme hlavně ty Datové objekty, které jsou reprezentací Objektů VS a jsou sdílené mezi aplikacemi. Je vhodné vždy rozmyslet, zda daný objekt potřebujeme v modelu mít, abychom předešli zvyšování komplexity modelu, přílišné náročnosti údržby aktuálního stavu a zaručili konzistentní granularitu napříč modelem.
-
-	Je důležité namapovat přenášené Datové objekty na Aplikační rozhraní – získáme tak podklad pro informaci o toku dat.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_8.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	=== Hlediska a pohledy ===
-
-	Důležitými čtenáři aplikační architektury jsou solution architekti, datoví/informační architekti a vlastníci aplikací a dále prakticky všechny role na úrovni Byznys a Technologické architektury (díky poloze AA mezi BA a TA). Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:
-
-	^Hledisko ^Popis ^
-	\|Aplikačního portfolia (Mapa)\|Ukazuje přehled všech používaných aplikací \|
-	\|Struktury informací \|Slouží k přehledu používaných datových objektů a jejich vazeb \|
-	\|Struktury aplikací \|Ukazuje vnitřní strukturu a vazby mezi aplikačními komponentami\|
-	\|Chování aplikací \|Zaměřuje se na detailní popis struktury jednotlivých aplikací \|
-	\|Využití aplikací \|Ilustruje, jak aplikace realizují obchodní procesy a funkce \|
-
-	== Katalogy ==
-
-	Každý modelovaný typ elementu by měl mít vlastní katalog, nejdůležitější pro čtenáře výše bývají následující:
-
-	* Katalog aplikačních komponent
-
-	Dále to mohou být například:
-
-	* Katalog aplikačních služeb
-	* Katalog rozhraní
-	* Katalog datových objektů
-
-	== Diagramy ==
-
-	Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.
-
-	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
-	\|Mapa aplikačních komponent((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hlediska_architektury_informacnich_systemu)) \|Ukazuje strukturovaný pohled na kompletní portfolio aplikací OVS \|Hledisko aplikačního portfolia (Mapa) \|
-	\|Diagram struktury aplikací((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hlediska_architektury_informacnich_systemu)) \|Zobrazuje strukturu jedné nebo více aplikací a komponent \|Hledisko struktury aplikací \|
-	\|Diagram datových objektů \|Zachycuje datový model na konceptuální či logické úrovni \|Hledisko struktury informací \|
-	\|Diagram aplikačních funkcí \|Zachycuje obvykle hnízdovým diagramem hierarchickou strukturu funkcí jedné nebo několika aplikačních komponent. \|Hledisko chování aplikací \|
-
-	== Matice ==
-
-	Matice zajímavé pro tuto vrstvu jsou uvedené níže.
-
-	^Matice ^Popis matice ^Realizované hledisko NAR ^
-	\|Mapování Datových objektů na Objekty VS \|Ukazuje jaké Datové objekty realizují jaké Objekty VS z byznys architektury \|Hledisko struktury informací \|
-	\|Mapování Aplikačních služeb na Funkce/Procesy/INterakce VS \|Ukazuje, jak jsou Procesy či Funkce byznys architektury podpořeny aplikačními službami \|Hledisko využití aplikací \|
-	\|Mapování aplikačních komponent na organizační strukturu \|Ukazuje, které organizační jednotky/územní pracoviště/ role/pozice využívají aplikační komponenty. \|Hledisko využití aplikací \|
-
-	=== Na co si dát pozor ===
-
-	\|Držte správnou granularitu aplikačních komponent \|Volba granulity aplikačních komponent (AK) je důležitá. Rozkládání aplikací má smysl tam, kde se různí vlastníci, nebo existují jiné důvody (správa, údržba, licence, apod.)\\ \\ Je proto dobré řídit se vlastnictvím – jedna AK by měla mít jednoho jasného byznysového vlastníka.\\ \\ Nezaměňujte prosím s UML komponentou, která reprezentuje sadu funkcionalit na jedné technologické platformě (to je úkol pro Technologickou komponentu).\\ \\ Dodržet definici komponenty: samostatně “deployable SW unit”, nezaměňovat s prvky vnitřní struktury takové komponenty (např. s funkčními moduly – nutno specializovat, viz NAR).\|
-	\|Zamezte duplikaci informací mezi evidenčními systémy a modelem podnikové architektury \|Prvky, které je třeba mít modelované v aplikační architektuře jsou obvykle evidované i ve specializovaných nástrojích (jak je popsáno výše) za účelem řízení správy a údržby aplikací. Je nutné zajistit, aby nedocházelo k duplikaci informací za účelem modelování EA a touto evidencí. Obvyklým řešením je určení masteru a automatizace (nebo jiné procesní zajištění) aktualizace informací na sekundárních úložištích. \|
-
-	=== Reference ===
-
-	Přesnou definici prvků a metamodel pro aplikační a datovou architekturu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_is_-_aplikacni_architektury_aa
-
-	==== Architektura IT (HW/SW) technologické infrastruktury ====
-
-	//Motto: „na čem to běží, kde to běží a jak si to spolu povídá“.//
-
-	Tato oblast je jedna ze dvou, které se v této metodice věnují infrastruktuře. Cílem obou je popsat technické podhoubí, které umožňuje fungování podnikových aplikací a jejich komunikaci.
-
-	Vrstva technologické infrastruktury má za cíl ukázat, jaké technické platformy jsou v podniku k dispozici, kde se nacházejí a jaké technologické služby jednotlivé komponenty poskytují směrem k aplikační a byznysové vrstvě. Komunikační vrstva se pak soustředí na mapu umístění důležitých technologických prvků a identifikaci komunikačních cest mezi nimi (viz kap 4.6.4). Doporučená redukce metamodelu NAR pro úroveň technologické infrastruktury je vyobrazená na následujícím schématu.
-
-	{{ :playgroud:metodika_ey:doporucena_redukce_metamodelu_technologicke_infrastruktury.png?400 \|}}
-
-	<WRAP centeralign>//Doporučená redukce metamodelu technologické infrastruktury//</WRAP><WRAP clear/>
-
-	=== Doporučení pro modelování prvků TA ===
-
-	== Jak modelovat technologické služby a funkce ==
-
-	Technologická služba (Technology service v ArchiMate) popisuje požadavek na to, co by měla technologická vrstva umět a poskytovat směrem k vyšším vrstvám, zejména aplikační. Definuje se proto, aby byl zřejmý účel technologických prvků v podniku (realizují tech. službu). Tech. služby realizují podmínky pro fungování aplikací a procesů na aplikační úrovni. Zdrojem pro přehled Tech. služeb může být implementace strategické části metodiky ITIL v podniku. Očekává se, že na definici tech. služeb poskytovaných v podniku se podílí i podnikový architekt. Příklady tech. služeb jsou Internetová konektivita, VPN, Databázová služba, Souborová služba, apod. Služby lze zapouzdřovat dle úrovní detailu.
-
-	Technologické funkce (Technology function v ArchiMate) lze využít k popisu schopností nabízených na úrovni uzlů. Typicky se jedná o funkce jednotlivých datových center, jako např. Zajištění výpočetního výkonu, Virtualizace, Vysoká dostupnost, Zálohování, Archivace, Logování, apod. Funkce lze také zapouzdřovat, pokud je to vhodné a z dlouhodobého hlediska je množství informací takto udržitelné a potřebné pro potřeby podnikového architekta.
-
-	Tech. služby jsou realizovány Tech. funkcemi.
-
-	{{ :playgroud:metodika_ey:model_technologicke_sluzby.png?200 \|}}
-
-	<WRAP centeralign>//Příklad modelu technologické služby//</WRAP><WRAP clear/>
-
-	== Jak modelovat uzly, zařízení a systémový SW ==
-
-	Uzel (Node v ArchiMate) je základním prvkem modelu technologické infrastruktury. Reprezentuje typicky server či jiný fyzický prvek počítačového typu. Zařízení (Device v ArchiMate) je pak obvykle nějaká jeho fyzická součást a Systémový software (System software v ArchiMate) pak běží na daném zařízení, např. operační systém či DB server. Node tak reprezentuje platformu, kterou má podnik k dispozici.
-
-	Zařízení může figurovat jako samostatný prvek na úrovni uzlu, typicky pro specializovaná zařízení typu firewallu, či fileserveru.
-
-	Důležitým atributem v evidenci u Systémového software je jeho verze. Doporučujeme držet ji na úrovni podnikové architektury, aby bylo možné dělat přehledy dostupných platforem z hlediska konsolidace a aktualizace.
-
-	{{ :playgroud:metodika_ey:vztah_uzel_vs._systemovy_sw_vs._zarizeni.png?400 \|}}
-
-	<WRAP centeralign>//Příklad vztahu mezi uzlem, systémovým sofwarem a zařízením//</WRAP><WRAP clear/>
-
-	== Jak modelovat komunikační infrastrukturu ==
-
-	Komunikační infrastruktura se modeluje elementem Síť (Communication Network v ArchiMate). Síť propojuje uzly. Typickými příklady komunikačních sítí jsou WiFi na úřadu, Lokální síť (LAN), Internet (WAN).
-
-	Uzly se k síti připojují pomocí vazby agregace.
-
-	{{ :playgroud:metodika_ey:propojeni_uzlu_pomoci_site_lan.png?300 \|}}
-
-	<WRAP centeralign>//Příklad propojení uzlů pomocí sítě LAN//</WRAP><WRAP clear/>
-
-	== Jak modelovat datové elementy na technologické úrovni ==
-
-	Element Artefakt (Artefact v ArchiMate) reprezentuje datový prvek na úrovni tech. architektury. Element Artefakt použijeme tehdy, když chceme ukázat realizaci Datového objektu z aplikační vrstvy (viz kap. Jak modelovat datové objekty), např. za účelem zaznamenání jeho technického uložení či využití v uzlu. Rozhodně není vhodné snažit se pomocí Artefaktů modelovat DB tabulky, Artefakt reprezentuje ucelenou struktur údajů uloženou samostatně (např. celou databázi či schéma v ní). Pro potřeby detailních informací využijte technickou dokumentaci. Modelování Artefaktů je součástí pokročilého modelování datové architektury.
-
-	{{ :playgroud:metodika_ey:realizace_datoveho_objektu.png?300 \|}}
-
-	<WRAP centeralign>//Realizace datového objektu několika artefakty v node (uzlu)//</WRAP><WRAP clear/>
-
-	=== Hlediska a pohledy ===
-
-	Čtenáři informací z oblasti technologické architektury jsou zejména Manažeři provozu (operations), Infrastrukturní inženýři a Architekti řešení (SAR). Obvykle je zajímá:
-
-	* dostupné portfolio technických platforem pro realizaci změn v aplikačním portfoliu
-	* způsob realizace technologických služeb
-	* propojenost uzlů pro komunikaci
-	* dostupnost technologických funkcí v jednotlivých umístěních
-
-	Relevantní hlediska NAR:
-
-	^Hledisko ^Popis ^
-	\|Technologického portfolia (mapa) \|Ukazuje přehled všech používaných technologických prvků \|
-	\|Technologické infrastruktury – obecné \|Ukazuje přehled infrastruktury včetně základních vazeb \|
-	\|Využití infrastruktury \|Ukazuje, jak je aplikační vrstva realizována technologickou vrstvou \|
-	\|Zjednodušené nasazení informačních systémů \|Ukazuje, jak je konkrétní aplikace realizovaná technologií \|
-
-	== Katalogy ==
-
-	Doporučujeme formou katalogů evidovat všechny základní typy elementů:
-
-	* Katalog Technologických služeb (víceúrovňový)
-	* Katalog Uzlů (včetně Systémových SW a Zařízení)
-	* Katalog Sítí
-	* Katalog Technologických služeb
-	* Katalog Technologických funkcí
-
-	== Diagramy ==
-
-	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
-	\|Mapa technologického portfolia \|Struktura infrastrukturních prvků realizující technologické služby \|Hledisko technologického portfolia (mapa) \|
-	\|Mapa využití tech. služeb pro realizaci aplikační vrstvy \|Diagram ukazuje přehled vazeb mezi aplikační a tech. vrstvou. \|Hledisko využití infrastruktury \|
-	\|Realizace aplikací pomocí SW a HW infrastruktury \|Diagram ukazuje pro jednotlivé aplikace realizaci pomocí prvků tech. architektury. \|Zjednodušené hledisko nasazení informačních systémů \|
-
-	{{ :playgroud:metodika_ey:mapa_technologickeho_portfolia.png?400 \|}}
-
-	<WRAP centeralign>//Mapa technologického portfolia//</WRAP><WRAP clear/>
-
-	{{ :playgroud:metodika_ey:mapa_vyuziti_technologicych_sluzeb.png?400 \|}}
-
-	<WRAP centeralign>//Mapa využití tech. služeb pro realizaci aplikační vrstvy pro vybranou aplikaci//</WRAP><WRAP clear/>
-
-	{{ :playgroud:metodika_ey:realizace_aplikaci_pomoci_sw_a_hw_infrastruktury.png?400 \|}}
-
-	<WRAP centeralign>//Realizace aplikací pomocí SW a HW infrastruktury//</WRAP><WRAP clear/>
-
-	//Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.//
-
-	=== Na co si dát pozor ===
-
-	\|Držte nejhrubší detail potřebný pro podnikového architekta \|Více než kde jinde je zde důležité nepřesáhnout míru detailu modelu. Katalogy konkrétních fyzických serverů a zařízení je obtížné udržovat aktuální a pro podnikového architektura to není zajímavý detail. Soustřeďte se na modelování informací zajímavých strategicky a koncepčně.\|
-
-	=== Reference ===
-
-	Přesnou definici prvků a metamodel pro architekturu IT technologické infrastruktury najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_ict_technologicke_architektury_ta
-
-	==== Architektura komunikační a fyzické infrastruktury ====
-
-	Tato vrstva má za úkol popsat geografické umístění prvků infrastruktury a komunikační cesty mezi nimi. Využívá se tedy primárně pro model datových center a komunikačních okruhů. Důležitými elementy zde jsou Budova (Facility v ArchiMate) a Síť.
-
-	Pro potřeby modelování komunikačního kanálu mezi Budovami je možné efektivně použít elementu Komunikační cesta (Path v ArchiMate), případným s vyznačením, které sítě jej realizují.
-
-	=== Doporučení pro modelování prvků KFI ===
-
-	== Jak modelovat umístění infrastruktury ==
-
-	Z hlediska podnikové architektury jsou zajímavými umístěními (lokacemi) datová centra, případně serverovny. Modelují se jako Budovy, které agregují prvky, jež jsou v nich umístěné. Součástí modelu může být, jaké daná lokace nabízí tech. funkce. Lokace jsou propojené Sítěmi.
-
-	Důležitou vlastností Budovy je označení vystihující geografickou polohu.
-
-	{{ :playgroud:metodika_ey:dve_datova_centra.png?300 \|}}
-
-	<WRAP centeralign>//Příklad modelu infrastruktury s dvěma datovými centry//</WRAP><WRAP clear/>
-
-	=== Hlediska a pohledy ===
-
-	Čtenáři informací z oblasti komunikační a fyzické infrastruktury jsou zejména Manažeři provozu (operations), Infrastrukturní inženýři a Architekti řešení (SAR). Obvykle je zajímá:
-
-	* propojenost uzlů pro komunikaci
-	* dostupnost technologických funkcí v jednotlivých umístěních
-
-	Relevantní hlediska NAR:
-
-	* Nutno definovat v NAR
-
-	== Katalogy ==
-
-	Zajímavé katalogy jsou:
-
-	* Katalog lokací (budovy, např. datová centra, serverovny, apod)
-
-	== Diagramy ==
-
-	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
-	\|Přehled lokací \|Mapa budov (datová centra, serverovny, …) s jejich propojením a napojením na vnější sítě (internet, WAN, …) \|Nutno definovat v NAR \|
-	\|Vybavení lokací \|Obsahuje vybavení, funkce, uzly a sítě v dané lokaci. \|Nutno definovat v NAR \|
-
-	//Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.//
-
-	//\\
-	//
-
-	=== Na co si dát pozor ===
-
-	Analogicky jako v kap. Na co si dát pozor viz výše (Držte nejhrubší detail potřebný pro podnikového architekta).
-
-	=== Reference ===
-
-	Přesnou definici prvků a metamodel pro architekturu komunikační a fyzické infrastruktury najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_komunikacni_a_fyzicke_infrastruktury_ki
-
-	==== Implementace a migrace ====
-
-	V této oblasti se díváme na změny architektury podniku v čase, zejména jako výhled do budoucnosti ve formě roadmapy migrace. Účelem je ukázat čtenářům postup transformace z aktuálního stavu architektury na cílový. Při tvorbě je výchozím bodem současný stav architektury, musíme jej mít tedy zmapovaný.
-
-	Migrací se myslí postup přechodu ze současné do cílové architektury přes potenciální dočasné (tranzientní) architektury.
-
-	=== Postup při realizaci roadmapy ===
-
-	Tým podnikové architektury vyjedná s ostatními zainteresovanými osobami podobu cílové architektury, která vyplývá ze strategických plánů a cílů (detailněji viz kap. Architektura strategie a směřování) a stanoví cestu (roadmapu) k cílové architektuře. Přechodové architektury slouží jako záchytné body pro dokončení transformace vybraných oblastí.
-
-	Mezi každými dvěma stavy architektury je pak stanovena sada Rozdílů, které je nutné realizovat pomocí projektů, či programů (Balíčků práce) – viz diagram níže. Tento podklad je dále využit při plánování projektového portfolia podniku a při realizace konkrétních projektů. Během realizace projektu poskytuje podnikový architekt součinnost ve formě podkladů k daným Balíčkům práce a konzultací.
-
-	Po realizaci daného Balíčku práce (typicky release) musí podnikový architekt zaktualizovat aktuální stav architektury a roadmapu.
-
-	=== Doporučení pro modelování prvků IM ===
-
-	Změny v architektuře a její průběh v čase jsou reprezentovány několika elementy:
-
-	* Stavy architektury definují současné, cílové či přechodové podoby podnikové architektury. Nesou informaci o čase, v němž by měly být realizované.
-	* Stav architektury je kromě popisu doplněn odkazy na Základní elementy struktury z jednotlivých domén, které jsou jím ovlivněné. Vazba na Stav architektury určuje i období platnosti změny daného elementu.
-	* Mezi nimi jsou definované Rozdíly, které jsou pak zpracovány pomocí Balíčků práce (které mají zhruba velikost projektu a jsou podkladem pro projektového manažera při plánování projektu).
-	* Výstup projektu pak popisuje hlavní potřebné změny, nutné k dosažení daného Stavu architektury . Výstupem může být např. nová aplikační komponenta, zrušená stará technologie, či nový obchodní proces. Nejedná se o model cílového stavu, ale jednoduchý popis potřebných změn seskupených tak, aby bylo možné je realizovat projektem.
-
-	Níže je uveden metamodel včetně kontextu do návazných oblastí architektury.
-
-	{{ :playgroud:metodika_ey:matice_mapovani_stavu_architektury.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	== Jak modelovat migraci ==
-
-	Mezi dvěma Stavy architektury (Plateu v ArchiMate) jsou definované Rozdíly (Gap v ArchiMate) a jejich realizace probíhá pomocí Balíčků práce, které definují oblast prací, které se musí provést v určitém pořadí či čase, což je hodnotný podklad pro projektového manažera.
-
-	Ke Stavu architektury je vhodné pro ukotvení v čase přiřadit základní elementy z jednotlivých domén. Toto lze dobře řešit maticemi, kde je na jedné ose seznam Stavů architektury a na druhé sada elementů daného typu z vybrané domény.
-
-	Stav architektury v dané doméně (např. aplikační) je vizualizován přehledovými mapami architektury s vyznačením, které existující prvky v ní budou zastoupené i nadále, které přibudou a které naopak budou ukončené. Pro vizualizaci této informace na diagramu je používané barevné ohraničení elementu, např typu: červená=ukončení, zelená=pokračující, modrá=nový. //Pozn. Nejedná se o vybarvení elementů dle vrstvy architektury, ale specifické bravy okrajů daných elementů na diagramu jako doplňková informace.//
-
-	Typická podoba roadmapy migrace je na obrázku níže.
-
-	{{ :playgroud:metodika_ey:ilustrace_1_15_-_diagram_s_vyznacenim_barevne_konvence.png?400 \|}}
-
-	<WRAP centeralign>//Příklad roadmapy se dvěma paralelními přechodovými architekturami//</WRAP><WRAP clear/>
-
-	== Jak modelovat projektový aspekt ==
-
-	Pro účely přípravy realizace identifikuje podnikový architekt Balíčky práce (Work package dle ArchiMate), které je potřeba realizovat, aby došlo k přechodu mezi dvěma Stavy architektury, jak je popsané výše. Balíčkem práce na této úrovni bývá Projekt. Projekty mohou být seskupené do Programu. Pokud je to vhodné, může být identifikován i detailnější rozpad Balíčků práce v rámci Projektu. Balíčky práce mohou být označené i informací o potřebném pořadí realizace či vzájemné závislosti.
-
-	Architekt vytváří podklady pro věcné zadání projektu, samotný projekt je vytvářen a řízen projektovým managerem.
-
-	Výstupem je přehled projektů, které je nutné realizovat, aby došlo k nastolení cílového Stavu architektury. U každého projektu by měly být zřejmé jeho výstupy (Outcome dle ArchiMate), cíle a časování. Očekává se, že identifikované Balíčky práce budou navázané na skutečné rozběhlé projekty, řízené z podnikového týmu PMO (Project Management Office).
-
-	{{ :playgroud:metodika_ey:diagram_balicku_prace.png?600 \|}}
-
-	<WRAP centeralign>//Diagram balíčků práce navázaných na konkrétní stavy architektury//</WRAP><WRAP clear/>
-
-	=== Hlediska a pohledy ===
-
-	Očekávanými čtenáři této oblasti architektury jsou lidé zodpovědní za strategii a směřování podniku (včetně podnikových architektů), role z oblasti řízení projektů a jejich portfolia, zejm. projektoví a programoví manažeři a solution architekti. Dále může být informace užitečná pro manažery provozu a správy, aby tušili, kdy je čekají jaké změny ve spravovaném porftoliu.
-
-	Pro ně zajímavá hlediska z NAR jsou:
-
-	* Hledisko implementace a migrace
-
-	== Katalogy ==
-
-	Elementy primárně zařazené do této oblasti mají své katalogy:
-
-	* Katalog Stavů architektury
-	* Katalog Rozdílů
-	* Katalog Balíčků práce
-	* Katalog Výstupů
-
-	== Diagramy ==
-
-	Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.
-
-	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
-	\|Pohled migrace \|Pohled na roadmapu ukazující Stavy architektur a přechody mezi nimi. Zobrazené elementy jsou:\\ \\ * Stav architektury,\\ * Rozdíl,\\ * Balíček práce (včetně závislostí a pořadí) \|Hledisko implementace a migrace \|
-	\|Pohled implementace a migrace \|Pohled ukazující vazby mezi projekty a realizovanými prvky architektury.\\ \\ Zobrazené elementy jsou zejména:\\ \\ * Stav architektury\\ * Balíček práce (včetně závislostí a pořadí)\\ * Rozdíl\\ * Měněné elementy se zvýrazněným typem změny (viz výše) \|Hledisko implementace a migrace \|
-	\|Projektový pohled \|Diagram ilustruje hlavní aspekty realizace Balíčku práce, zejm. projektu či programu.\\ \\ Jedná se o nepovinný, ale vhodný diagram ukazující všechny potřebné navázané elementy na konkrétní změnu.\\ \\ Elementy na diagramu jsou:\\ \\ * Balíček práce (projekt sám)\\ * Stav architektury\\ * Balíček práce (podřazené/nadřazené)\\ * Rozdíly realizované projektem\\ * Výstupy projektu\\ * Odpovědné role\\ * Měněné elementy se zvýrazněným typem změny (viz výše) \|Hledisko implementace a migrace \|
-
-	{{ :playgroud:metodika_ey:ilustracni_priklad_-_pohled_implementace_a_migrace.png?400 \|}}
-
-	<WRAP centeralign>//Ilustrační příklad: Pohled implementace a migrace//</WRAP><WRAP clear/>
-
-	== Matice ==
-
-	^Matice ^Popis matice ^Realizované hledisko NAR ^
-	\|Mapování Stavů architektury na měněné elementy \|Pro lepší představu o prvcích architektury ovlivněných plánovanými změnami je možné připravit matici toto ukazující. Na jedné ose je seznam Stavů architektury a na druhé sada elementů daného typu z vybrané domény. Členění matic dle domén je vhodné pro omezení množství elementů.\|Hledisko implementace a migrace \|
-
-	{{ :playgroud:metodika_ey:priklad_matice_mapovani_stavu_architektury_na_menene_elementy.png?400 \|}}
-
-	<WRAP centeralign>//Příklad matice Mapování stavů architektury na měněné elementy//</WRAP><WRAP clear/>
-
-	=== Na co si dát pozor ===
-
-	\|Nepodceňte potřebu plného sladění se stakeholdery \|Jedná se o strategickou úroveň plánování. Je nezbytné, aby příslušní manažeři věděli a panovala shoda na tom, co v roadmapě je. Neshoda může mít významné dopady na celý podnik. Zápis do formální podoby je až konečný výsledek řetězu prezentací a schůzek se zainteresovanými lidmi.\|
-	\|Nesuplujte práci projektového manažera \|Při identifikaci Balíčků práce se soustřeďte na jejich globální popis a informace, které můžete dodat pouze vy. Detailní plán a všechny další aspekty potřebné pro realizaci projektu ponechte na rolích k tomu určených, až bude projekt probíhat. \|
-
-	=== Reference ===
-
-	Přesnou definici prvků a metamodel pro architekturu implementace a migrace najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_implementace_a_migrace
-
-	==== Architektura strategie a směřování ====
-
-	V této oblasti modelujeme důvod, proč úřad (jako podnik) existuje a proč vypadá tak jak vypadá. NAR v této oblasti kombinuje motivační a strategickou vrstvu (dle ArchiMate).
-
-	Chceme vědět, v čím zájmu je, aby úřad existoval a jaké jsou motivátory k jeho existenci a hlavním aspektům jeho fungování. Z těchto prvků jsou pak odvozené cíle, které je naplňují. Na tomto základě pak definujeme principy, které ovlivňují architektonické požadavky, vedoucí na realizaci vnitřku organizace a omezení, která je nutné brát v potaz. Dále by se v této oblasti měla nacházet odpověď na důvody, proč mají proběhnout / proběhly v organizaci změny.
-
-	Strukturu elementů a vazeb použitelných v této oblasti popisuje metamodel na obrázku níže.
-
-	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_pro_tuto_oblast_v_metamodelu_9.png?400 \|}}
-
-	<WRAP centeralign>//Identifikace elementů a vazeb pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
-
-	=== Doporučení pro modelování prvků MA ===
-
-	== Jak modelovat zainteresované strany ==
-
-	Zainteresovaná strana odpovídá na otázku „V čím zájmu je, že jako úřad existuji a dělám to co dělám?“ Zainteresovanou stranou tedy bývá externí zřizovatel úřadu (vláda, ministerstvo?), a jeho nejvyšší interní představitelé (ředitel, ředitelé sekcí, …). Přehled zainteresovaných stran lze získat z organizační struktury úřadu. Důležité je nepoužívat konkrétní jména lidí, ale názvy jejich pozic či organizace. Identifikace Zainteresovaných stran je klíčová pro určení odpovědnosti za strategické směřování úřadu. Zainteresovanou stranu modelujeme pomocí elementu Stakeholder v ArchiMate.
-
-	== Jak modelovat veřejné potřeby jako hnací prvky ==
-
-	Hnací prvky (též motivátory) představují interní, či externí vlivy, které v důsledku formují vnitřní podobu úřadu („Proč úřad vypadá, jak vypadá?“). Většinou se jedná o zájmy Zainteresovaných stran.
-
-	* Veřejné potřeby jsou takovým případem hnacích prvků. Obvykle jsou dlouhodobě stabilní a určují základní aspekty fungování organizace.
-	* Analýzy či Vyhodnocení potřeby jsou výsledkem zhodnocení naplnění daného motivátoru. Identifikují potřebu změny, aby byl motivátor korektně naplněn. Definují se častěji, obvykle periodicky jako důsledek kontroly stavu organizace a jsou iniciátorem transformačních aktivit.
-
-	Hnací prvky (vč. Veřejných zájmů) modelujeme pomocí elementu Driver v ArchiMate, Vyhodnocení potřeb/Analýzu pomocí elementu Assesment. Propojíme je vazbou asociace se Zainteresovanými osobami a Vyhodnoceními potřeb.
-
-	== Jak modelovat strategické cíle a výstupy ==
-
-	Strategické cíle naplňují Hnací prvky. Jsou často používány jako základní měřítko úspěšnosti fungování organizace. Do jaké míry/hodnoty budeme daný Cíl naplňovat, určuje Výstup. Strategický cíl identifikujeme z Hnacího prvku tak, že jím definujeme, jaké změny chceme v dané oblasti dosáhnout. Název Cíle by měl obsahovat slovo určující druh/povahu změny („zvýšíme“, „snížíme“, „dosáhneme“). Výstup pak doplňuje Cíl o konkrétní hodnotu, či míru na kterou Cíl naplníme. Výstup je pak skvělým podkladem pro identifikaci KPIs či akceptačních kritérií pro strategické projekty. Strategické cíle modelujeme pomocí elementu Goal v ArchiMate, Výstupy pak pomocí elementu Outcome. Typicky jsou Cíle navázané na Hnací prvky vzniklé z Vyhodnocení potřeb (např. audit či RACI analýza, viz výše) a dále jsou na ně realizační vazbou napojené Výstupy.
-
-	== Jak modelovat architektonické principy ==
-
-	Architektonické principy definují sadu obecně platných pravidel, kterými se lze řídit při tvorbě podnikové architektury v dané oblasti. Jejich dodržováním se implicitně naplňují relevantní Strategické cíle. Při definici Strategických cílů je proto třeba brát v potaz jejich univerzálnost.
-
-	Architektonický princip by měl být definován např. následovně((https:%%//%%pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html#:~:text=The%20remainder%20of%20this%20section%20deals%20exclusively%20with,all%20IT%20resources%20and%20assets%20across%20the%20enterprise.
-	)):
-
-	^Název ^Výstižný, krátký. ^
-	\|Definice \|Jednoznačný popis zamezující víceznačnému pochopení. \|
-	\|Důvod \|Zdůraznit výhody dodržování principu. Pro snadné pochopení na netechnické úrovni. \|
-	\|Důsledky \|Popis dopadů/požadavků na části organizace implementující princip („Jak to dopadne na mě?“).\|
-
-	Pokud nejsme schopni danou část popisu principu naplnit, je pravděpodobné, že je princip nevhodně navržen. Architektonické principy je třeba členit dle oblastí či architektonických domén pro lepší přehlednost pro čtenáře z dané oblasti. Modelujeme je pomocí elementu Principle v ArchiMate. Architektonické principy jsou obvykle navázané na Strategický cíl či Výstup, jehož dosažení/udržení napomáhají.
-
-	//Pozn.: V souladu s ArchiMate je možné označit sílu vazby pomocí ++/+/-/--.//
-
-	== Jak modelovat klíčové požadavky a omezující podmínky ==
-
-	Při přípravě projektu, který bude realizovat zajištění Cíle či naplnění Výstupu je možné definovat Klíčové požadavky, jejichž splnění toto zajistí. Klíčové požadavky na úrovni podnikové architektury zdůrazňují důležité aspekty, které je potřeba vzít v potaz, např. naplnění určitých Architektonických principů.
-
-	Omezující podmínky pak systematickým způsobem vymezují „hřiště“, na kterém lze řešení stavět. Např. povolenými technickými platformami, rámcem rozpočtu či časování. Opět se mohou odkazovat na příslušné Architektonické principy či konkrétní elementy v jednotlivých doménách.
-
-	{{ :playgroud:metodika_ey:hierarchie_urovni.png?300 \|}}
-
-	<WRAP centeralign>//Příklad hierarchie úrovní//</WRAP><WRAP clear/>
-
-	=== Hlediska a pohledy ===
-
-	Očekávanými čtenáři informací v této oblasti jsou samotné Zainteresované strany – obvykle vrcholoví manažeři odpovědní za strategii v dané oblasti, dále samotní podnikoví architekti, architekti řešení a manažeři projektového portfolia. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:
-
-	* Motivační hledisko strategického směřování
-
-	Toto hledisko může být případně rozdělené podle očekávaných čtenářů na:
-
-	* Hledisko zainteresovaných stran
-	* Hledisko architektonických principů
-
-	== Katalogy ==
-
-	Doporučujeme tvořit následující katalogy elementů:
-
-	* Katalog Zainteresovaných stran
-	* Katalog Veřejných potřeb/hnacích prvků
-	* Katalog Strategických cílů
-	* Katalog Vyhodnocení potřeb/analýz
-	* Katalog Výstupů
-	* Katalog Architektonických principů
-	* Katalog Klíčových architektonických požadavků a Omezujících podmínek
-
-	== Diagramy ==
-
-	Zajímavé diagramy pro tuto doménu jsou uvedeny v tabulce níže. Pro lepší přehlednost je na obrázku barevně znázorněno pokrytí elementů metamodelu v diagramech.
-
-	{{ :playgroud:metodika_ey:umisteni_elementu_na_diagramy_v_teto_oblasti.png?400 \|}}
-
-	<WRAP centeralign>//Umístění elementů na diagramy v této oblasti//</WRAP><WRAP clear/>
-
-	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
-	\|Přehled Zainteresovaných osob a Hnacích prvků \|Ukazuje přehled Zainteresovaných osob, motivátorů, cílů. Případně lze doplnit o elementy typu Analýza a Výstup (může být rozděleno do více diagramů dle oblasti). Použité elementy:\\ \\ * Zainteresovaná osoba\\ * Hnací prvek\\ * Analýza\\ * Strategický cíl\\ * Výstup \|Hledisko zainteresovaných stran \|
-	\|Přehled Architektonických principů (Mapa) \|Ukazuje výčet definovaných Arch. principů a jejich rozdělení do oblastí. \|Hledisko architektonických principů \|
-	\|Realizace strategických elementů pomocí Klíčových požadavků a Omezujících podmínek \|Sada diagramů ukazující relevantní požadavky a omezující podmínky, spolu s jejich kontextem směrem k realizovaným Principům, Cílům a Výstupům. Je vhodné ukázat i ovlivněné prvky z ostatních arch. domén.\\ \\ Očekává se sada diagramů, dle jednotlivých implementačních iniciativ, např dle roadmapy Migrace (viz kap. Na co si dát pozor)\\ \\ Použité elementy:\\ \\ * Klíčový požadavek\\ * Omezující podmínka\\ * Strategický cíl\\ * Výstup\\ * Architektonický princip\\ * Základní prvek struktury \| \|
-
-	== Matice ==
-
-	V této oblasti nejsou definované žádné specifické matice. Pro lepší přehlednost je možné připravit matice ukazující důležité vazby, např. pokrytí Hnacích prvků pomocí Strategických cílů, či genezi Hnacích prvků od Zainteresovaných stran či z Vyhodnocení potřeb.
-
-	=== Na co si dát pozor ===
-
-	\|Zajistěte stabilní strategii \|Architektura strategie a směřování definuje základy, z nichž vychází celá architektura a fungování podniku. Měla by proto být co nejrobustnější a soustředit se na důležité prvky. Ty je však často obtížené identifikovat a nastavit měřitelně, jelikož to má dopad na Zainteresované strany. U této domény je tedy víc než u všech ostatních potřeba sladit očekávání a její řízení se všemi Zainteresovanými stranami.\|
-
-	=== Reference ===
-
-	Přesnou definici prvků a metamodel pro architektura strategie a směřování najdete v NARu: [[https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_strategie_a_smerovani_ma\|https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_strategie_a_smerovani_ma]]
-
-
-	<WRAP center round important 100%>
-	Následující oblasti architektury jsou průřezové a volitelné. Pro potřeby DIA je očekáván hlavně slovní popis situace.
-
-	Jedná o oblasti, kde není nyní metodika zcela detailní, proto u nich není popsán mechanismus modelování. Systematičtější přístup, který se pravděpodobně bude dlouhodobě rozvíjet a upřesňovat, je popsán v příslušných částech NAR.
-	</WRAP>
-
-
-
-
-	==== Architektura bezpečnosti ====
-
-	Architektura bezpečnosti je důležitá průřezová disciplína, vyžadující díky své komplexitě vlastní metodiku. Přístup úřadů k této problematice je definován příslušnými předpisy a audity. Pro potřeby architektury je důležitá evidence vztahů jednotlivých aspektů bezpečnosti k prvkům podnikové architektury a zejména zajištění jejich průběžná aktualizace. Tento problém lze řešit např. využitím frameworku ESRM(([[https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.bizzdesign.com%2Farticles%2Fhorizzon-help%2Fenterprise-risk-and-security-management&data=05%7C02%7CJaromir.Kuzelka%40cz.ey.com%7C0f43303ffbf34a6cf40a08dd468bfd1a%7C5b973f9977df4bebb27daa0c70b8482c%7C0%7C0%7C638744289267517337%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N7yRa%2BMsvRdHEhA1z31ZWPmN2hsxPaloOZYRIuIZY8g%3D&reserved=0\|https:%%//%%help.bizzdesign.com/articles/horizzon-help/enterprise-risk-and-security-management]]
-	)) od společnosti BizzDesign. Framework využívá vlastního rozšíření elementů jazyka ArchiMate v motivačním aspektu.
-
-	Základem frameworku je iterativní proces sestávající z 9 kroků, ilustrovaných na obrázku níže, které zajišťují systematické pokrytí bezpečnostních aspektů architektury.
-
-	{{ :playgroud:metodika_ey:zakladni_proces_esrm.png?400 \|}}
-
-	<WRAP centeralign>//Základní proces ESRM//</WRAP><WRAP clear/>
-
-	Červené kroky představují fázi zhodnocení rizik, zelené pak fázi realizace opatření a mechanismů pro provoz, která pokrývá i realizaci prostředků a nástrojů pro fázi zhodnocení rizik.
-
-	=== Reference ===
-
-	https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_bezpecnostni_architektury_saInformace k architektuře bezpečnosti najdete v NARu zde: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_bezpecnostni_architektury_sa
-
-	==== Architektura výkonnosti ====
-
-	Momentálně není poptávané modelování výkonnosti pro potřeby DIA. Úřady by ale měly zavádět a udržovat mechanismy umožňující měřitelnost výsledků provedených změn a jejich dlouhodobého provozování.
-
-	Jazyk ArchiMate nyní neobsahuje metriky ani jiné ukazatele výkonnosti, proto je zavádí NAR. Metodika v této oblasti však momentálně není striktně předepsaná.
-
-	=== Reference ===
-
-	Informace k architektuře výkonnosti najdete v NARu zde: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_vykonnostni_architektury_pa
-
-	==== Architektura shody s pravidly ====
-
-	Tato oblast zajišťuje korektní navázání elementů z ostatních architektonických domén (zejména Motivační) na konkrétní předpisy, standardy a kritéria udržitelnosti. Jedná se hlavně o popis toho jak jsou modelované tyto elementy a jak se na ně odkazovat ze zbylých částí modelu.
-
-	Předpokládaný způsob modelování je takový, že DIA/OHA bude vlastnit elementy reprezentující používané předpisy apod. a architekti úřadů na ně budou odkazovat pomocí vazeb z relevantních elementů – např. Hnacích prvků, Strategických cílů, Omezujících podmínek, apod., aby byl zřejmý jejich původ.
-
-	=== Reference ===
-
-	Informace k architektuře shody s pravidly najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_standardizace_shody_s_predpisy_a_udrzitelnosti

Členění modelu

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:21:15+00:00

2025/05/07 10:38		aktuální
Řádek 1:		Řádek 1:
-	====== Nástroje ======	+	====== Členění modelu ======

-	===== Modelovací nástroje =====	+	Tato metodika modelování platí pro enterprise architekturu celku, domén a segmentů OVS, v mírně omezené míře, respektive aplikovaně, pro enterprise architekturu řešení příležitostí, identifikovaných v doménových nebo segmentových architekturách.

-	Pro tvorbu modelů nejsou předepsané žádné konkrétní nástroje. Očekává se, že podnik využije svých znalostí a zkušeností k volbě nástroje dle uvážení.	+	V architektonickém popisu řešení lze pomocí této metodiky odpovídat na existencionální otázky CO? a PROČ? bude obsahovat hledané řešení, nikoli na otázky JAK MÁ FUNGOVAT? Takové modely tzv. solution architektury nejsou upraveny NAR ani touto metodikou, zejména proto, že:

-	Podrobněji jsou požadavky na nástroj popsané v NAR: [[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#potreby_a_pozadavky_pouzivani_nastroje\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#potreby_a_pozadavky_pouzivani_nastroje]]	+	- Mají jiný účel
		+	- Jazyk ArchiMate se pro ně málo hodí (spíše UML).

-	===== Výměna informací =====	+	===== Segmentace =====

-	Pro usnadnění výměn informací ve strukturované podobě stanovuje OHA formát pro výměnu modelů(([[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju]]	+	Z hlediska rozsahu modelovaných OVS a jejich korporací, či z hlediska jejich vnitřní struktury dělené na segmenty a schopnosti je tato metodika modelování univerzálně použitelná.
-	)). Jedná se o formát The Open Group ArchiMate File Exchange Format.	+

-	Je nutné, aby použitý nástroj podporoval export a import do/z tohoto formátu a interní procesy modelování umožňovaly doplnění potřebných metainformací k prvkům modelu, i samotnému exportovanému souboru.	+	Sem ale patří otázka, kolik má mít jedno OVS modelů. Před každým modelování nějakého katalogu nebo diagramu je nutno rozhodnout do jakého z nich daná informace patří. OVS by mělo být schopno rozlišit a samostatně spravovat modely:

-	====== Definice pojmů v této metodice ======	+	* VLST – Vlastní model architektury úřadu (OVS). Obsahuje prvky a pohledy specifické pro tento kontext. Úřad může obsahovat několik modelů tohoto typu pro své jednotlivé organizace.
		+	* SPOL – Společný model úřadu a všech jím kontrolovaných (a metodicky vedených) organizací (resort, krajská korporace atp.). Zde jsou umístěné pohledy kombinující prvky z několika modelů typu VLST. Mohou zde být i další prvky, spadající jen do kontextu SPOL.
		+	* 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). Zde by měly být pohledy ukazující kontext mimo rámec SPOL, typicky se sdílenými prvky jiných úřadů. DO doby, než bude k dispozici centrální správa sdílených prvků, budou zde uložené jejich kopie, které budou použité pro vazby a pohledy v modelu daného úřadu.

-	Níže je uvedena definice důležitých pojmů, s nimiž tento dokument pracuje. Cílem je jednoznačné chápání těchto pojmů v kontextu této metodické dokumentace.	+	Na obrázku níže je ilustrován princip strukturování modelů těchto typů.

-	//Tabulka 1: Definice pojmů//	+	{{ :playgroud:metodika_ey:ilustrace_1_10_-_segmentace_modelu_z_pohledu_jednoho_uradu.png?600 \|}}

-	^Zkratka ^Význam ^	+	<WRAP centeralign> //Ilustrace segmentace modelu z pohledu jednoho úřadu//</WRAP><WRAP clear/>
-	\|ArchiMate \|Framework pro modelování enterprise architektury od The Open Group \|	+
-	\|BP \|Business process (obchodní process) \|	+
-	\|ČR \|Česká republika \|	+
-	\|DIA \|Digitální a informační agentura \|	+
-	\|EA \|Enterprise architektura \|	+
-	\|ESRM \|Enterprise Risk and Security Management.\\ Framework pro bezpečnostní architekturu od Bizzdesign \|	+
-	\|ICT \|Informační a komunikační technologie \|	+
-	\|IT \|Informační technologie \|	+
-	\|NAR \|Národní architektonický rámec \|	+
-	\|OHA \|odbor Hlavního architekta eGovernmentu \|	+
-	\|OVS \|Orgán veřejné správy \|	+
-	\|PMO \|Project Management Office (projektová kancelář) \|	+
-	\|RPP \|Registr práv a povinností. Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností. Slouží jako zdroj údajů pro informační systémy základních registrů při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. \|	+
-	\|KSVS \|Katalog služeb veřejné správy. \|	+
-	\|TOGAF \|The Open Group Architecture Framework \|	+
-	\|UML \|Unified Modeling Language \|	+
-	\|VS \|Veřejná správa \|	+

-	Níže je uveden slovník pojmů s překlady do českého jazyka.	+	===== Struktura modelu =====

-	//Tabulka 2: Slovník pojmů v této metodice//	+	Jednotná struktura modelů významně pomáhá jejich pochopitelnosti a umožňuje zastupitelnost jak na straně čtenářů, tak na straně tvůrců. Dlouhodobě si DIA klade za cíl udržovat modely podnikových architektur úřadů centrálně, což vede také na potřebu jednotného strukturování modelů. Proto v této metodice popisujeme hlavní myšlenky v této oblasti.

-	^Pojem ^Význam ^	+	Model by měl být strukturován zhruba taktak, jak je vidět na obrázku níže. Struktura počítá s možností hierarchického členění modelu úřadu (prvky „Část úřadu N“). Následuje dělení dle architektonických domén, kde je očekávaná úplná nezávislost obsažených prvků (elementů, vazeb) mezi doménami. Na další úrovni jsou pak elementy sdružené do katalogů a diagramy a matice, na nichž jsou elementy a vazby zobrazené.
-	\|application \|aplikace / aplikační \|	+
-	\|best practice \|nejlepší praxe \|	+	Samotné elementy jsou držené buď ve vlastní struktuře, nebo jako součást katalogů – záleží na konkrétním nástroji. To samé platí o uložení vazeb.
-	\|business \|obchod / obchodní \|	+
-	\|capability \|schopnosti \|	+	Zatímco elementy jsou jasně přiřazené k architektonickým doménám, na pohledech mohou být elementy z více domén současně. Umístění pohledu se pak řídí převažujícím typem elementů, či tím, kam spíše logicky patří. V kapitole 4.64.6 je pak uvedeno zařazení pohledů do jednotlivých architektonických domén.
-	\|enterprise \|podnik / podnikový. Zde hlavně úřad. \|	+
-	\|layer \|vrstva \|	+	Nelze zapomenout na pohledy, které jsou striktně průřezové. Pro ně je vhodné vyčlenit uzel struktury „Přehledová hlediska“, který je sdružuje.
-	\|motivation \|motivace / motivační \|	+
-	\|note \|poznámka \|	+	{{ :playgroud:metodika_ey:ilustrace_1_11_-_princip_strukturovani_modelu_uradu.png?600 \|}}
-	\|performance \|výkonost / výkonnostní \|	+
-	\|refaktorování \|změna struktury či formy beze změny významu obsahu \|	+	<WRAP centeralign> //Princip strukturování modelu úřadu//</WRAP><WRAP clear/>
-	\|security \|bezpečnost / bezpečnostní \|	+
-	\|stream \|tok, kanál \|	+	^Prvek ^Význam ^
-	\|tailoring \|přizpůsobení na míru \|	+	\|Kořenový uzel \|Strukturní prvek, pod nímž je celý model. Nese doplňkové informace určující o jaký úřad se jedná. \|
-	\|top-down \|od celku k detailům \|	+	\|Část úřadu \|Pokud je úřad vnitřně strukturně členěn ne víceméně nezávislé části, doporučujeme to reprezentovat i v modelu. Zejména v situaci, kdy mají části různé architekty.\|
-	\|value \|hodnota \|	+	\|Architektonická doména\|Modelovaná vrstva/doména architektury (viz kap. Architektonické domény) \|
-	\|prvek modelu \|obecná součásti modelu (element, vazba) \|	+	\|Katalogy elementů \|Obsahují seznamy elementů daného typu \|
-	\|element \|základní stavební prvek modelu \|	+	\|Pohledy \|Obsahuje jednotlivé pohledy na model v příslušné arch. doméně. Typicky se jedná o diagramy a matice. \|
		+	\|Přehledová hlediska \|Uzel struktury, pod nímž jsou umístěné pohledy obsahující přehledy a průřezové pohledy, které obsahují elementy z více domén najednou. \|
		+
		+	===== Úrovně detailu =====
		+
		+	Aby byla podpořena myšlenka jednotné granularity informací přes celý model, jsou definované tři úrovně detailnosti modelovaného pohledu na realitu. Tyto úrovně jsou pojmenované L0, L1 a L2 a jsou popsané v tabulce níže.
		+
		+	^ ^Název ^Význam ^
		+	\|L0\|Přehledová\|Ukazuje principy a podstatu. Dává celkový přehled, celkový pohled na systém v dané doméně/oblasti; hlavní prvky a konzumenti. Často jsou zde agregované (seskupující) prvky.\|
		+	\|L1\|Základní \|Ukazuje všechny klíčové prvky pro ucelený pohled. Doplňuje se s přehledovou úrovní. \|
		+	\|L2\|Detailní \|Přidává detaily vybrané části z vyšší úrovně. Na této úrovni doporučujeme modelovat jen výseky, které si to zaslouží, např. díky komplexitě. \|
		+
		+	Detailní informace o konceptu úrovní detailu v NAR najdete na [[https://archi.gov.cz/nar_dokument:proces_tvorby_architektur?s%5b%5d=l1%2A#rozhodnuti_o_hloubce_obsahu\|https://archi.gov.cz/nar_dokument:proces_tvorby_architektur?s%5b%5d=l1%2A#rozhodnuti_o_hloubce_obsahu]]
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_12_-_prehledova_uroven_l0.png?400 \|}}
		+
		+	<WRAP centeralign> //Přehledová úroveň L0//</WRAP><WRAP clear/>
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_13_-_zakladni_uroven_l1.png?400 \|}}
		+
		+	<WRAP centeralign> //Základní úroveň L1 (červený rámeček ukazuje proces rozpracovaný na úrovni L2)//</WRAP><WRAP clear/>
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_14_-_detailni_uroven_l2.png?400 \|}}
		+
		+	<WRAP centeralign> //Detailní úroveň L2//</WRAP><WRAP clear/>
		+
		+	===== Modelování časové dimenze =====
		+
		+	Vždy musí být možné identifikovat časové období, k němuž se obsah modelu vztahuje. Zejména je důležité být schopný rozlišit, zda modelujeme současný (AsIs) či budoucí (ToBe) stav. Způsob realizace tohoto požadavku je vysoce závislý na způsobu řízení změn v podniku. Tato metodika doporučuje následující přístup:
		+
		+	\|Model aktuální situace je základ \|Mějte v potřebných okamžicích aktuální model stávající situace (AsIs) podnikové architektury. Lze řešit např. aktualizací modelu po releasu. \|
		+	\|Vývojové varianty modelujte odděleně od hlavního modelu \|Pokud teprve vzniká návrh cílového stavu, průběžně existuje více možných pracovních variant. Aby byla zajištěna integrita modelu, doporučujeme pracovat na modelu vzniklém kopií hlavního modelu, či ve zcela pracovním modelu. Po schválení cílového stavu jej přeneste do primárního modelu a navažte korektně na daný Stav architektury (vizte dále). \|
		+	\|Časový vývoj modelujte s pomocí vrstvy Implementace a migrace \|Pro modelování plánovaných změn použijeme část Implementace a migrace (viz kap. Implementace a migrace). Časové ukotvení nese příslušný Stav architektury. Na něj jsou navázané elementy (např. pomocí vazeb. D). Diagramy ukazují detailně situaci v tomto Stavu architektury, příslušnost ke Stavu architektury je řešena pomocí názvu či místěním diagramu. Je také využito barevné konvence pro indikaci změn v portfoliu.\|
		+	\|V případě potřeby doplňte interval platnosti k prvkům a udržujte jej aktuální \|Primárně by mělo k určení časové platnosti elementu stačit přiřazení k vybraným Stavům architektury. Pokud je to ale potřeba (např. pro zdůraznění využití až v nějakém období), doplníme element, vazbu či diagram obdobím platnosti. Je důležité nezapomenout tento údaj udržovat aktuální. \|
		+	\|Označujte model datem platnosti \|Označujeme okamžik, k němuž je model platný (Platnost k). Může to být datum, ale praktičtější může být označení obdobím, či releasem. Označení datem platnosti pomůže udržovat časové řezy modelu. \|
		+	\|Archivujte časové řezy \|Model verzujeme a starší řezy archivujeme pro účely udržování časových řezů z minulosti. \|
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_15_-_diagram_s_vyznacenim_barevne_konvence.png?600 \|}}
		+
		+	<WRAP centeralign> //Diagram s vyznačením barevné konvence pomocí ohraničení: zelená = nový, modrá = změna, červená = zrušený//</WRAP><WRAP clear/>
		+
		+	===== Metainformace =====
		+
		+	Pro jednoznačné zařazení dané části modelu pro čtenáře, ale hlavně pro potřeby automatizace zpracování obsahu modelu, vč. např. validace formální správnosti je potřeba jednotlivé prvky modelu doplnit o informace, které toto umožní.
		+
		+	Některé údaje popsané v kapitolách výše jsou elegantně zaznamenány do modelu právě pomocí metainformací.
		+
		+	Metainformace jsou v modelovacích nástrojích obvykle udržované jako specifické atributy, či tagy. Doporučujeme prozkoumat možnosti použitého modelovacího nástroje pro automatizaci a systematizaci jejich vyplňování.
		+
		+	Pro jakoukoli integrovatelnost modelů mezi sebou je nutné metainformace k prvkům modelu udržovat.
		+
		+	Základní metainformace jsou:
		+
		+	^Metainformace ^Význam ^Obvykle přiřazená k ^
		+	\|Datum platnosti \|K jakému datu je platný obsah dané části modelu \|Strukturní prvky na vyšší úrovni \|
		+	\|Autor/odpovědná osoba \|Jméno autora či osoby odpovědné za obsah dané části modelu \|Strukturní prvky, elementy, vazby, pohledy\|
		+	\|Datum poslední aktualizace \|Kdy byl daný prvek naposledy upraven \|Strukturní prvky, elementy, vazby, pohledy\|
		+	\|Vrstva architektury \|Architektonická doména (viz kap. Architektonické domény) \|Strukturní prvky \|
		+	\|Úroveň detailu \|Míra detailu modelovaného pohledu na realitu (viz. kap. Modelování časové dimenze)\|Pohledy \|
		+	\|Reference na příslušnou část metamodelu\|Určení, jakou část předpisu pro modelování daný prvek realizuje \|Elementy, vazby, pohledy \|

Modelování dle NAR

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:20:25+00:00

2025/05/15 13:13		aktuální
Řádek 1:		Řádek 1:
-	====== Nástroje ======	+	====== Modelování dle NAR ======

-	===== Modelovací nástroje =====	+	===== Architektonické domény =====

-	Pro tvorbu modelů nejsou předepsané žádné konkrétní nástroje. Očekává se, že podnik využije svých znalostí a zkušeností k volbě nástroje dle uvážení.	+	Domény se podle NAR dělí na základní horizontální domény (Core), tzv. vrstvy, které představují výkon veřejné správy a provozu OVS a k tomu potřebné zdroje. Vertikální motivační domény určují důvody, proč základní domény obsahují, co obsahují, nebo proč by se měly změnit. Nakonec doména Implementace a migrace podporuje modelování té části reality OVS, kterou představují plánované a realizované změny v základních vrstvách (i změny a balíčky práce-projekty jsou součástí reality OVS).

-	Podrobněji jsou požadavky na nástroj popsané v NAR: [[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#potreby_a_pozadavky_pouzivani_nastroje\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#potreby_a_pozadavky_pouzivani_nastroje]]	+	{{ :playgroud:metodika_ey:detail_architektonickych_domen.png?400 \|}}

-	===== Výměna informací =====	+	Detailně jsou architektonické domény NAR popsané přímo ve zdrojovém materiálu:

-	Pro usnadnění výměn informací ve strukturované podobě stanovuje OHA formát pro výměnu modelů(([[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju]]	+	https://archi.gov.cz/nar_dokument:struktura_modelovanych_architektur#domeny_obsahu_architektur
-	)). Jedná se o formát The Open Group ArchiMate File Exchange Format.	+

-	Je nutné, aby použitý nástroj podporoval export a import do/z tohoto formátu a interní procesy modelování umožňovaly doplnění potřebných metainformací k prvkům modelu, i samotnému exportovanému souboru.	+	===== Metamodel =====

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

-	Níže je uvedena definice důležitých pojmů, s nimiž tento dokument pracuje. Cílem je jednoznačné chápání těchto pojmů v kontextu této metodické dokumentace.	+	==== Povinnost využití prvků metamodelu ====

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

-	^Zkratka ^Význam ^	+	==== Metamodely dle komplexity ====
-	\|ArchiMate \|Framework pro modelování enterprise architektury od The Open Group \|	+
-	\|BP \|Business process (obchodní process) \|	+
-	\|ČR \|Česká republika \|	+
-	\|DIA \|Digitální a informační agentura \|	+
-	\|EA \|Enterprise architektura \|	+
-	\|ESRM \|Enterprise Risk and Security Management.\\ Framework pro bezpečnostní architekturu od Bizzdesign \|	+
-	\|ICT \|Informační a komunikační technologie \|	+
-	\|IT \|Informační technologie \|	+
-	\|NAR \|Národní architektonický rámec \|	+
-	\|OHA \|odbor Hlavního architekta eGovernmentu \|	+
-	\|OVS \|Orgán veřejné správy \|	+
-	\|PMO \|Project Management Office (projektová kancelář) \|	+
-	\|RPP \|Registr práv a povinností. Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností. Slouží jako zdroj údajů pro informační systémy základních registrů při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. \|	+
-	\|KSVS \|Katalog služeb veřejné správy. \|	+
-	\|TOGAF \|The Open Group Architecture Framework \|	+
-	\|UML \|Unified Modeling Language \|	+
-	\|VS \|Veřejná správa \|	+

-	Níže je uveden slovník pojmů s překlady do českého jazyka.	+	Pro potřeby metodiky modelování architektury v DIA definováno několik úrovní metamodelu, podle očekávané míry detailu obsažených informací v daném modelu. Ukazují také, které elementy by měly být v jádru modelu (Zjednodušený metamodel) a které se hodí pro popis sloužitějších detailnějších konstrukcí (až po Maximální metamodel).

-	//Tabulka 2: Slovník pojmů v této metodice//	+	{{ :playgroud:metodika_ey:metamodel_diagram.png?400 \|}}

-	^Pojem ^Význam ^	+	=== Maximální ===
-	\|application \|aplikace / aplikační \|	+
-	\|best practice \|nejlepší praxe \|	+
-	\|business \|obchod / obchodní \|	+
-	\|capability \|schopnosti \|	+
-	\|enterprise \|podnik / podnikový. Zde hlavně úřad. \|	+
-	\|layer \|vrstva \|	+
-	\|motivation \|motivace / motivační \|	+
-	\|note \|poznámka \|	+
-	\|performance \|výkonost / výkonnostní \|	+
-	\|refaktorování \|změna struktury či formy beze změny významu obsahu \|	+
-	\|security \|bezpečnost / bezpečnostní \|	+
-	\|stream \|tok, kanál \|	+
-	\|tailoring \|přizpůsobení na míru \|	+
-	\|top-down \|od celku k detailům \|	+
-	\|value \|hodnota \|	+
-	\|prvek modelu \|obecná součásti modelu (element, vazba) \|	+
-	\|element \|základní stavební prvek modelu \|	+

		+	Maximální metamodel ukazuje celkovou množinu prvků a vazeb, použitelných při vytváření modelů pro DIA. Kromě prvků definovaných ArchiMate je tento metamodel rozšířený o prvky z TOGAF a o specifické prvky pro DIA.
		+
		+	Tento metamodel není doporučen k přímému použití ale spíše k vymezení možností v případě velmi komplexních modelů a edukovaných čtenářů.
		+
		+	=== Základní ===
		+
		+	Tento metamodel je oproti Maximálnímu zjednodušen do podoby, kterou lze očekávat, že bude využívána u modelů obvyklého rozsahu, zejména u tzv. povinných angažmá. Tato metodika modelování dále pracuje se základním metamodelem.
		+
		+	=== Zjednodušený ===
		+
		+	Zjednodušený metamodel ukazuje pouze zásadní elementy. Jeho účelem je hlavně pochopit hlavní myšlenky a koncepce modelů pro DIA.
		+
		+	Pro ilustraci je níže uveden Základní metamodel v podobě, v jaké je prezentován v NARu.
		+
		+	{{ :playgroud:metodika_ey:zakladni_metamodel_dle_nar_pro_ilustraci.png?400 \|}}
		+
		+	<WRAP centeralign> //Základní metamodel dle NAR pro ilustraci// </WRAP><WRAP clear/>
		+
		+	Detailně jsou metamodely na jednotlivých úrovních popsány v NARu:
		+
		+	https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#celkovy_metamodel_na_vs_cr
		+
		+	==== Doménové metamodely ====
		+
		+	Každá doména v této metodice má vlastní detailní metamodel, který je ale vždy součást celkového metamodelu. Cílem je ukázat výčet elementů a vazeb použitelných pro modelování v dané doméně.
		+
		+	Kompletní informaci o jednotlivých metamodelech najdete v NAR: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#dilci_domenove_metamodely
		+
		+	===== Elementy a vazby =====
		+
		+	Metodika NAR přebírá elementy a vazby ze standardu ArchiMate, přičemž ale tvoří jejich nadstavbu. U některých z nich upřesňuje český název a/nebo význam a dále definuje vlastní elementy, byť využívající jako základy typy dle ArchiMate.
		+
		+	Elementy a vazby, které mohou být využity v modelech postavených na metamodelu výše jsou specifikované v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#prehled_lokalizace_prvku_a_vazeb_standardu_archimate
		+
		+	===== Vizuální konvence prvků modelů =====
		+
		+	Tato metodika respektuje definovaný vzhled, barevnost a pravidla vizualizace dle standardu ArchiMate. Tato pravidla je třeba dodržet. Obvyklé modelovací nástroje vizuální standard ArchiMate implementují a splňují, není v nich proto třeba v této oblasti nic specifického nastavovat.
		+
		+	Detailní popis použitého vizuálního standardu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#pravidla_pouziti_jazyka_archimate_pro_modelovani_na_vs_cr
		+
		+	===== Přehled výstupů =====
		+
		+	{{ :playgroud:metodika_ey:prehled_vystupu_v_jednotlivych_architektnickych_domenach_dle_nar.png?400 \|}}
		+
		+	<WRAP centeralign>//Přehled výstupů v jednotlivých architektnických doménách dle NAR//</WRAP><WRAP clear/>
		+
		+	===== Tvorba modelu v jednotlivých doménách =====
		+
		+	Jak je popsáno v kap. Architektonické domény, pracuje tato metodika s deseti architektonickými doménami. Níže je po jednotlivých architektonických doménách v NAR popsán způsob tvorby modelu a příslušných artefaktů. Předpokládá se situace, kdy je architekt jako modelář postaven před úkol zmapovat aktuální situaci v úřadu, tedy že systematický model ještě neexistuje. Na závěr kapitoly jsou uvedena pravidla pro přehledové a průřezové artefakty (katalogy a diagramy), výrazně se vymykající jednotlivým doménám a přesahující je.
		+
		+	==== Byznys architektura výkonu a provozu veřejné správy ====
		+
		+	Základní modelovaný obsah byznys reality OVS slouží pro lepší pochopení požadavků byznysu na aplikační podporu. Proto potřebujeme poznat a pochopit, jaké má úřad agendy a činnosti (funkce a procesy), jestli jsou vykonávány jako služby, a dále kým, pro koho a jak, kterým obslužným kanálem, s jakými daty a dokumenty.
		+
		+	=== Doporučení pro modelování prvků BA ===
		+
		+	Následující kapitoly vysvětlují, jak modelovat prvky reality, které se odlišují od komerčního užití jazyka ArchiMate a jsou typické pro veřejnou správu ČR.
		+
		+	== Jak modelovat agendy a činnosti VS ==
		+
		+	Agendy a agendové činnosti jsou základními elementy pro modelování náplně práce úřadu. Jsou primárně definované a udržované v Registru Práv a Povinností((https:%%//%%www.szrcr.cz/cs/registr-prav-a-povinnosti
		+	)), kde je také uvedeno přiřazení k jednotlivým úřadům.
		+
		+	Je vhodné zmapovat agendy a činnosti nezávisle na RPP, aby byly dokumentované i neohlášené agendy, které v RPP nejsou, ale úřad je vykonává. Možným zdrojem informací může být Organizační řád úřadu a komunikace s příslušnými Ohlašovateli agend a referenty.
		+
		+	Agenda i agendová činnost jsou modelovány pomocí elementů „Agenda“ a „Agendová činnost“ (Business function dle ArchiMate). Při modelování je převzat oficiální název a identifikátor agendy a činnosti z RPP. Popis by pak měl obsahovat specifika realizace dané agendy či činnosti v daném úřadě, aby nedocházelo k duplikování informací z RPP.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_pro_tuto_oblast_v_metamodelu.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat služby a úkony z Katalogu služeb VS ==
		+
		+	Služby veřejné správy jsou detailnějším rozpadem agend. Popisují, jak agendy slouží klientům úřadu a jak jsou navázané na produkty, smlouvy, předpisy a jakými obslužnými kanály je poskytovaná.
		+
		+	Zdrojem pro výčet služeb je Katalog služeb veřejné správy((Informace o katalogu: https:%%//%%archi.gov.cz/nap:katalog_sluzeb
		+	)), který je členěn i dle poskytovatelů služby (úřad, který danou službu poskytuje).
		+
		+	Je vhodné zmapovat služby nezávisle na KSVS, aby byly dokumentované i realizované služby neohlášených agend, interní služby poskytované úřady navzájem a služby pokrývané externími dodavateli (typicky služby IT podpory, správa budov, apod,).
		+
		+	Služby mají velmi různorodou granularitu a celkové množství služeb je značné, proto je vhodné některé menší služby seskupovat pod jeden element postihující celou množinu. Informaci o jednotlivých pokrytých službách pak je možné zadat do popisu.
		+
		+	Služby veřejné správy jsou modelované pomocí elementu „Služba veřejné správy“ (Business service dle ArchiMate). Při modelování je převzat oficiální název a identifikátor agendy a činnosti z KSVS. Popis by pak měl obsahovat specifika realizace dané agendy či činnosti v daném úřadě, aby nedocházelo k duplikování informací z KSVS.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat životní události a životní situace ==
		+
		+	Životní události a situace mají velký význam pro konzumenty služeb – klienty úřadů. Popisují významné změny a stavy v jejich životě a často bývají spouštěči či důsledky využití služeb úřadů. Při modelování jsou využité často jako vstupní body do interakcí občana s IS úřadů – tedy obvykle při návrhu řešení IS.
		+
		+	Pro modelování podnikové architektury ale obvykle zásadní nejsou, neboť pro identifikaci služeb a procesů jsou použité jiné stabilní zdroje informací.
		+
		+	Životní události jsou modelované pomocí elementu „Životní událost“ (Business event dle ArchiMate). Obvykle jsou napojené na procesy či funkce realizující jednotlivé obchodní služby, jako jejich spouštěče či důsledky. Mohou být případně navázané na samotné Služby VS pro evidenci jejich pokrytí.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_2.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat organizační jednotky a pracovní pozice ==
		+
		+	Struktura organizace je vyjádřena stromovou strukturou útvarů, případně i konkrétních pracovních pozic. Při modelování podnikové architektury se tyto prvky používají pro mapování vztahu daného útvaru na služby, kanály, či jiné části, např. pro vyjádření vlastnictví, či účasti na provádění. Dále je vhodné využití pro vizualizaci komplexní organizační struktury a jejích částí, včetně umístění. Pro potřeby OHA se informace z organizační struktury využívají pro popis skladby projektového týmu.
		+
		+	Informace o organizační struktuře úřadu je primárně udržovaná v Organizačním řádu. Není tedy nezbytně nutné ji modelovat samu o sobě.
		+
		+	Organizační jednotky a pracovní pozice jsou modelované pomocí elementů „Útvar“, „Organizace“ či „Účastník interakce s VS“ (Business actor dle ArchiMate). Obvykle jsou napojené na Službu VS či Obslužný kanál VS.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_3.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat zákony, vyhlášky a vnitřní předpisy ==
		+
		+	Předpisy v různé podobě (zákon, vyhláška, vnitřní předpis, …) jsou často důvodem pro existenci dané služby či formují její fungování. Z toho důvodu je zajímavé je modelovat na úrovni podnikové architektury, zejména pak mapování na služby a produkty. Využití je pak právě pro gap analýzy při změnách příslušných předpisů. Primárním zdrojem je legislativa ČR, EU a sada vnitřních předpisů úřadu. Je vhodné striktně přenést název a identifikátor pro zamezení duplicit. Do popisu předpisu je pak vhodné uvést dopady do úřadu.
		+
		+	Předpisy jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Obvykle jsou navázané na Službu VS či Produkt VS.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_4.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat obslužné kanály ==
		+
		+	Obslužný kanál popisuje rozhraní, skrz které klient či pracovník úřadu přistupuje k jeho službám. Kanál je často předepsán legislativně (typicky ze zákona o právu na digitální službu). Obslužný kanál je modelovaný pomocí elementu „Obslužný kanál VS“ (Business interface dle ArchiMate). Obvykle je vázán jako mezičlánek mezi Službu VS a Účastníka interakce s VS.
		+
		+	== Jak modelovat procesy ==
		+
		+	Procesy jsou obvykle nejdetailnější úrovní popisu obchodní vrstvy v podnikové architektuře. Cílem je identifikovat: znát jejich výčet a umět slovně popsat jejich význam. Dobrým zdrojem pro identifikaci procesů bývají vnitřní směrnice, případně jakákoli jiná dokumentace procesů, např. v BPMN.
		+
		+	Na této úrovni lze popsat i obchodní funkce. Obchodní funkce je obecnější pojem než proces. Proces je z pohledu NAR vnímán jako specifický druh obchodní funkce, který má charakteristiku procesu: má jasného vlastníka, je řízený jako proces a chová se jako proces.
		+
		+	Procesy i obchodní funkce jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Hlavní vazbou je realizace příslušné Služby VS. Pokud je to vhodné, je možné navázat funkci/proces na odpovídající objekty (sloužící jako vstupy či výstupy) a role, definující sadu vlastností, které má mít Účastník interakce s VS, aby mohl části procesu vykonávat. Jak bylo zmíněno výše, procesy často spouští vybraná Životní událost a naopak, výstupem procesu může být Životní událost u klienta úřadu. Pro takto velký detail je třeba mít opodstatnění, neboť významně zvyšuje množství potřebných informací a čas na modelování a dále se může již překrývat s dalšími úrovněmi modelování, jako je modelování procesů, či funkční analýza.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_5.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	=== Hlediska a pohledy ===
		+
		+	Důležitými čtenáři byznys architektury jsou business architekti, datoví/informační architekti a vlastníci produktů. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:
		+
		+	* Hledisko portfolia (klasifikace) byznys funkcí, procesů a služeb
		+	* Hledisko funkcí veřejné správy
		+	* Produktové hledisko
		+	* Hledisko spolupráce byznys procesů
		+	* Hledisko organizační struktury
		+	* Hledisko spolupráce aktérů
		+
		+	== Katalogy ==
		+
		+	Každý modelovaný typ elementu by měl mít vlastní katalog, jelikož společně s maticí představují výchozí předpoklad pro jeho správné grafické vyjádření. Nejdůležitější pro čtenáře výše bývají následující:
		+
		+	* Katalog agend, činností (funkcí a procesů)
		+	* Katalog služeb a úkonů veřejné správy
		+	* Katalog aktérů (jejich typů) a jejich rolí
		+	* Katalog obslužných rozhraní veřejné správy
		+	* Katalog typů subjektů a objektů (konceptuální sémantický katalog)((Katalog je základem datové domény architektury, je společný pro byznys a datovou doménu.))
		+
		+	Dále to mohou být například:
		+
		+	* Katalog organizačních jednotek, útvarů a pozic
		+	* Katalog životních událostí, uplatnitelných vůči OVS
		+	* Katalog formulářů a výstupů OVS
		+
		+	== Diagramy ==
		+
		+	Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.
		+
		+	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
		+	\|Organizační struktura((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_organizacni_struktury)) \|Diagram útvarů ve stromové struktuře organizace \|Hledisko organizační struktury \|
		+	\|Přehled (mapa) schopností úřadu((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_prehledu_schopnosti_uradu)) \|Přehled schopností, seskupené na Strategické, Operační, Podpůrné \|Hledisko přehledu schopností úřadu \|
		+	\|Mapa agend \|Přehled agend úřadu \|Hledisko portfolia byznys funkcí a služeb \|
		+	\|Mapa služeb VS \|Přehled služeb \|Hledisko portfolia byznys funkcí a služeb \|
		+	\|Mapa procesů a funkcí \|Přehled procesů \|Hledisko funkcí veřejné správy \|
		+	\|Spolupráce procesů((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_spoluprace_byznys_procesu)) \|Vztahy procesů mezi sebou a okolním elementům \|Hledisko spolupráce byznys procesů \|
		+	\|Proces((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_spoluprace_byznys_procesu)) \|Detailní pohled na elementy v okolí jednoho procesu \|Hledisko spolupráce byznys procesů \|
		+	\|Diagram informačních objektů \|Zmapování identifikovaných objektů a vizualizace vazeb mezi nimi. \|Hledisko struktury informací((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_struktury_informaci)) \|
		+
		+	=== Na co si dát pozor ===
		+
		+	\|Zajistěte si podporu organizace \|Bez pochopení na straně poskytovatelů informací není možné se dobrat věrného modelu. Je nezbytně nutné, aby o aktivitě EA bylo v organizaci povědomí a byl zřejmý účel a výhody poskytnutí informací. Často bývá tento problém zásadní pro přípravu hodnotného modelu.^
		+	\|Nezabředněte do příliš velkého detailu \|Např. u modelování procesů. Pořád mít na mysli očekávanou úroveň detailu danou metamodelem a očekávaným čtenářem. Pokud je vhodné zajít do většího detailu, naznačit to popisem, nebo se odkázat na detailní model mimo tuto část. \|
		+
		+	=== Reference ===
		+
		+	Přesnou definici prvků a metamodel pro obchodní vrstvu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_byznys_architektury_ba
		+
		+	==== Aplikační architektura IS a datová architektura ====
		+
		+	Architektura aplikací a dat je stěžejní částí architektonických modelů, neboť drtivá většina agend z byznys architektury je realizovaná právě službami aplikací. V této oblasti se zaměřujeme na zmapování portfolia aplikací v úřadu a způsob, jakým spolu aplikace interagují pomocí rozhraní a s jakými daty pracují. Dále nás zajímá mapování na prvky z úrovně byznys architektury, aby byl zřejmý důvod existence jednotlivých aplikací. Doporučená redukce metamodelu NAR pro aplikační úroveň je vyobrazená na následujícím schématu.
		+
		+	{{ :playgroud:metodika_ey:doporucena_redukce_metamodelu_aplikacni_architektury.png?400 \|}}
		+
		+	<WRAP centeralign>//Doporučená redukce metamodelu aplikační architektury //</WRAP><WRAP clear/>
		+
		+	=== Doporučení pro modelování prvků AA ===
		+
		+	== Jak modelovat aplikační komponenty ==
		+
		+	Aplikační komponenta je nejvýraznější element aplikační architektury. Reprezentuje jednotlivé IT systémy, aplikace, nebo jejich části (pokud je to z pohledu podnikové architektury zajímavý detail) v podniku. Katalog aplikačních komponent je základním prvkem podnikové architektury, neboť dnes je většina služeb realizovaných právě pomocí IT systémů. Je proto vhodné investovat úsilí do jeho vybudování a údržby.
		+
		+	Základními atributy aplikačních komponent by měly být:
		+
		+	* Název
		+	* Identifikátor
		+	* Vlastník z byznysu (tzv. Věcný správce ISVS, určuje účel aplikace a její funkčnosti)
		+	* Technický vlastník (tzv. Technický správce ISVS, navrhuje řešení a stará se, aby aplikace fungovala)
		+	* Kategorizace
		+	* Kritičnost pro fungování podniku
		+
		+	Doporučených atributů, užitečných pro správu aplikačního portfolia jsou desítky, viz přiložený soubor. Soubor lze použít pro inspiraci pro identifikaci atributů či vazeb, které by mohly být u aplikační komponenty evidované.
		+
		+	<wrap em>{{ :playgroud:metodika_ey:na_katalog_aplikaci_vzor_v2.2.xlsx \|Katalog užitečných atributů}}</wrap>
		+
		+	Zdrojem informací o aplikačních komponentách je typicky portfolio udržovaných aplikací a systémů evidované provozními týmy IT.
		+
		+	Zásadní informace u aplikační komponenty jsou vazby na okolí:
		+
		+	* Jaké aplikační funkce a služby realizuje
		+	* Jaká aplikační rozhraní poskytuje a konzumuje
		+	* S jakými Datovými objekty pracuje
		+
		+	Situace je ilustrována na následujícím obrázku. Podrobněji je o těchto elementech a vazbách pojednáno níže.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_6.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat aplikační služby ==
		+
		+	Aplikační služba realizuje Službu veřejné správy skrze využití ve Funkci/procesu VS. Je hlavním pojítkem mezi aplikační a byznysovou vrstvou architektury. Aplikační služba je tedy vlastně opodstatněním pro existenci Aplikační komponenty.
		+
		+	Aplikační služby lze chápat jako požadavky na funkce IT aplikace, které definuje vlastník příslušných procesů a služeb na byznys úrovni. Aplikační služba je pak realizována sadou Aplikačních funkcí, které poskytuje příslušná Aplikační komponenta.
		+
		+	Aplikační služby by měly vyplývat z potřeb prováděných Funkcí/procesů VS, které definuje příslušný vlastník.
		+
		+	{{ :playgroud:metodika_ey:fragment_metamodelu_nar_ilustrujici_kontext_aplikacni_sluzby.png?400 \|}}
		+
		+	<WRAP centeralign>//Fragment metamodelu NAR ilustrující kontext Aplikační služby//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat aplikační rozhraní ==
		+
		+	Aplikační rozhraní je bod, kde jsou aplikační služby zpřístupněny uživatelům, či jiným aplikačním komponentám.
		+
		+	Význam evidence Aplikačních rozhraní je hlavně v systematizaci komunikace mezi aplikacemi a vůči uživatelům. Díky zmapování rozhraní je možné identifikovat vzory komunikace mezi aplikačními komponentami a je snadné přepoužívat existující rozhraní s vědomím dopadu změny. Velmi důležitá je evidence rozhraní k aplikačním službám, které jsou sdílené externě (mezi úřady).
		+
		+	Obvyklým zdrojem informací o existujících rozhraních je obchodní proces, kde jej identifikované použití rozhraní na aplikační úrovni. Dále je možné identifikovat existenci rozhraní ze solution architektury a/nebo z technické dokumentace aplikací. Dobrým zdrojem je i celofiremní integrační komponenta typu ESB (Enterprise Service Bus), či podobná, kde jsou často využívaná rozhraní koncentrována.
		+
		+	Pokud mezi sebou organizace komunikují aplikačním rozhraním, pak je to realizace procesu, např. využití business služby. Proto je vhodné zanést tuto informaci do modelu pomocí vazby na příslušnou obchodní Funkci či Proces (viz obrázek výše s kontextem aplikační komponenty).
		+
		+	Aplikační rozhraní je vždy vlastněno vybranou aplikační komponentou, které jej poskytuje a je využíváno libovolným množstvím jiných aplikačních komponent.
		+
		+	K aplikačnímu rozhraní je možné namapovat Datové objekty, které jsou jím přenášené.
		+
		+	K aplikačním rozhraním je vhodné udržovat dle potřeby následující atributy:
		+
		+	* Technologie (REST, XML, proprietární, …)
		+	* Typ komunikace (sync, async, batch)
		+	* Reference na detailní dokumentaci k rozhraní
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_7.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat datové objekty ==
		+
		+	Datové objekty reprezentují realizaci Objektů VS (Business Object) na aplikační úrovni, tj. Na úrovni obrazů skutečných věcí z BA v datech informačních systémů. Případně jsou to reprezentace jiných pasivních prvků evidovaných na úrovni aplikační architektury. Jejich granularita je obvykle jemnější než u Objektů VS, aby na ně bylo možno jednoznačně navázat dalšími prvky v aplikační vrstvě.
		+
		+	Zdrojem pro model Datových objektů jsou konceptuální a logické datové modely příslušných aplikací, ideálně získané z datového katalogu úřadu((https://data.gov.cz/p%C5%99%C3%ADlohy/popis-dat/dokumenty/Metodika-popisu-dat.pdf
		+	)). Abychom předešli duplikaci informací mezi datovým katalogem a modelem podnikové architektury, je vhodné rozmyslet kde bude master pro tyto informace – zda datový katalog, nebo model EA a podle toho nastavit procesy replikace z masteru na ostatní umístění.
		+
		+	Modelujeme hlavně ty Datové objekty, které jsou reprezentací Objektů VS a jsou sdílené mezi aplikacemi. Je vhodné vždy rozmyslet, zda daný objekt potřebujeme v modelu mít, abychom předešli zvyšování komplexity modelu, přílišné náročnosti údržby aktuálního stavu a zaručili konzistentní granularitu napříč modelem.
		+
		+	Je důležité namapovat přenášené Datové objekty na Aplikační rozhraní – získáme tak podklad pro informaci o toku dat.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_na_okoli_pro_tuto_oblast_v_metamodelu_8.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	=== Hlediska a pohledy ===
		+
		+	Důležitými čtenáři aplikační architektury jsou solution architekti, datoví/informační architekti a vlastníci aplikací a dále prakticky všechny role na úrovni Byznys a Technologické architektury (díky poloze AA mezi BA a TA). Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:
		+
		+	^Hledisko ^Popis ^
		+	\|Aplikačního portfolia (Mapa)\|Ukazuje přehled všech používaných aplikací \|
		+	\|Struktury informací \|Slouží k přehledu používaných datových objektů a jejich vazeb \|
		+	\|Struktury aplikací \|Ukazuje vnitřní strukturu a vazby mezi aplikačními komponentami\|
		+	\|Chování aplikací \|Zaměřuje se na detailní popis struktury jednotlivých aplikací \|
		+	\|Využití aplikací \|Ilustruje, jak aplikace realizují obchodní procesy a funkce \|
		+
		+	== Katalogy ==
		+
		+	Každý modelovaný typ elementu by měl mít vlastní katalog, nejdůležitější pro čtenáře výše bývají následující:
		+
		+	* Katalog aplikačních komponent
		+
		+	Dále to mohou být například:
		+
		+	* Katalog aplikačních služeb
		+	* Katalog rozhraní
		+	* Katalog datových objektů
		+
		+	== Diagramy ==
		+
		+	Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.
		+
		+	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
		+	\|Mapa aplikačních komponent((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hlediska_architektury_informacnich_systemu)) \|Ukazuje strukturovaný pohled na kompletní portfolio aplikací OVS \|Hledisko aplikačního portfolia (Mapa) \|
		+	\|Diagram struktury aplikací((https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hlediska_architektury_informacnich_systemu)) \|Zobrazuje strukturu jedné nebo více aplikací a komponent \|Hledisko struktury aplikací \|
		+	\|Diagram datových objektů \|Zachycuje datový model na konceptuální či logické úrovni \|Hledisko struktury informací \|
		+	\|Diagram aplikačních funkcí \|Zachycuje obvykle hnízdovým diagramem hierarchickou strukturu funkcí jedné nebo několika aplikačních komponent. \|Hledisko chování aplikací \|
		+
		+	== Matice ==
		+
		+	Matice zajímavé pro tuto vrstvu jsou uvedené níže.
		+
		+	^Matice ^Popis matice ^Realizované hledisko NAR ^
		+	\|Mapování Datových objektů na Objekty VS \|Ukazuje jaké Datové objekty realizují jaké Objekty VS z byznys architektury \|Hledisko struktury informací \|
		+	\|Mapování Aplikačních služeb na Funkce/Procesy/INterakce VS \|Ukazuje, jak jsou Procesy či Funkce byznys architektury podpořeny aplikačními službami \|Hledisko využití aplikací \|
		+	\|Mapování aplikačních komponent na organizační strukturu \|Ukazuje, které organizační jednotky/územní pracoviště/ role/pozice využívají aplikační komponenty. \|Hledisko využití aplikací \|
		+
		+	=== Na co si dát pozor ===
		+
		+	\|Držte správnou granularitu aplikačních komponent \|Volba granulity aplikačních komponent (AK) je důležitá. Rozkládání aplikací má smysl tam, kde se různí vlastníci, nebo existují jiné důvody (správa, údržba, licence, apod.)\\ \\ Je proto dobré řídit se vlastnictvím – jedna AK by měla mít jednoho jasného byznysového vlastníka.\\ \\ Nezaměňujte prosím s UML komponentou, která reprezentuje sadu funkcionalit na jedné technologické platformě (to je úkol pro Technologickou komponentu).\\ \\ Dodržet definici komponenty: samostatně “deployable SW unit”, nezaměňovat s prvky vnitřní struktury takové komponenty (např. s funkčními moduly – nutno specializovat, viz NAR).\|
		+	\|Zamezte duplikaci informací mezi evidenčními systémy a modelem podnikové architektury \|Prvky, které je třeba mít modelované v aplikační architektuře jsou obvykle evidované i ve specializovaných nástrojích (jak je popsáno výše) za účelem řízení správy a údržby aplikací. Je nutné zajistit, aby nedocházelo k duplikaci informací za účelem modelování EA a touto evidencí. Obvyklým řešením je určení masteru a automatizace (nebo jiné procesní zajištění) aktualizace informací na sekundárních úložištích. \|
		+
		+	=== Reference ===
		+
		+	Přesnou definici prvků a metamodel pro aplikační a datovou architekturu najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_is_-_aplikacni_architektury_aa
		+
		+	==== Architektura IT (HW/SW) technologické infrastruktury ====
		+
		+	//Motto: „na čem to běží, kde to běží a jak si to spolu povídá“.//
		+
		+	Tato oblast je jedna ze dvou, které se v této metodice věnují infrastruktuře. Cílem obou je popsat technické podhoubí, které umožňuje fungování podnikových aplikací a jejich komunikaci.
		+
		+	Vrstva technologické infrastruktury má za cíl ukázat, jaké technické platformy jsou v podniku k dispozici, kde se nacházejí a jaké technologické služby jednotlivé komponenty poskytují směrem k aplikační a byznysové vrstvě. Komunikační vrstva se pak soustředí na mapu umístění důležitých technologických prvků a identifikaci komunikačních cest mezi nimi (viz kap 4.6.4). Doporučená redukce metamodelu NAR pro úroveň technologické infrastruktury je vyobrazená na následujícím schématu.
		+
		+	{{ :playgroud:metodika_ey:doporucena_redukce_metamodelu_technologicke_infrastruktury.png?400 \|}}
		+
		+	<WRAP centeralign>//Doporučená redukce metamodelu technologické infrastruktury//</WRAP><WRAP clear/>
		+
		+	=== Doporučení pro modelování prvků TA ===
		+
		+	== Jak modelovat technologické služby a funkce ==
		+
		+	Technologická služba (Technology service v ArchiMate) popisuje požadavek na to, co by měla technologická vrstva umět a poskytovat směrem k vyšším vrstvám, zejména aplikační. Definuje se proto, aby byl zřejmý účel technologických prvků v podniku (realizují tech. službu). Tech. služby realizují podmínky pro fungování aplikací a procesů na aplikační úrovni. Zdrojem pro přehled Tech. služeb může být implementace strategické části metodiky ITIL v podniku. Očekává se, že na definici tech. služeb poskytovaných v podniku se podílí i podnikový architekt. Příklady tech. služeb jsou Internetová konektivita, VPN, Databázová služba, Souborová služba, apod. Služby lze zapouzdřovat dle úrovní detailu.
		+
		+	Technologické funkce (Technology function v ArchiMate) lze využít k popisu schopností nabízených na úrovni uzlů. Typicky se jedná o funkce jednotlivých datových center, jako např. Zajištění výpočetního výkonu, Virtualizace, Vysoká dostupnost, Zálohování, Archivace, Logování, apod. Funkce lze také zapouzdřovat, pokud je to vhodné a z dlouhodobého hlediska je množství informací takto udržitelné a potřebné pro potřeby podnikového architekta.
		+
		+	Tech. služby jsou realizovány Tech. funkcemi.
		+
		+	{{ :playgroud:metodika_ey:model_technologicke_sluzby.png?200 \|}}
		+
		+	<WRAP centeralign>//Příklad modelu technologické služby//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat uzly, zařízení a systémový SW ==
		+
		+	Uzel (Node v ArchiMate) je základním prvkem modelu technologické infrastruktury. Reprezentuje typicky server či jiný fyzický prvek počítačového typu. Zařízení (Device v ArchiMate) je pak obvykle nějaká jeho fyzická součást a Systémový software (System software v ArchiMate) pak běží na daném zařízení, např. operační systém či DB server. Node tak reprezentuje platformu, kterou má podnik k dispozici.
		+
		+	Zařízení může figurovat jako samostatný prvek na úrovni uzlu, typicky pro specializovaná zařízení typu firewallu, či fileserveru.
		+
		+	Důležitým atributem v evidenci u Systémového software je jeho verze. Doporučujeme držet ji na úrovni podnikové architektury, aby bylo možné dělat přehledy dostupných platforem z hlediska konsolidace a aktualizace.
		+
		+	{{ :playgroud:metodika_ey:vztah_uzel_vs._systemovy_sw_vs._zarizeni.png?400 \|}}
		+
		+	<WRAP centeralign>//Příklad vztahu mezi uzlem, systémovým sofwarem a zařízením//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat komunikační infrastrukturu ==
		+
		+	Komunikační infrastruktura se modeluje elementem Síť (Communication Network v ArchiMate). Síť propojuje uzly. Typickými příklady komunikačních sítí jsou WiFi na úřadu, Lokální síť (LAN), Internet (WAN).
		+
		+	Uzly se k síti připojují pomocí vazby agregace.
		+
		+	{{ :playgroud:metodika_ey:propojeni_uzlu_pomoci_site_lan.png?300 \|}}
		+
		+	<WRAP centeralign>//Příklad propojení uzlů pomocí sítě LAN//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat datové elementy na technologické úrovni ==
		+
		+	Element Artefakt (Artefact v ArchiMate) reprezentuje datový prvek na úrovni tech. architektury. Element Artefakt použijeme tehdy, když chceme ukázat realizaci Datového objektu z aplikační vrstvy (viz kap. Jak modelovat datové objekty), např. za účelem zaznamenání jeho technického uložení či využití v uzlu. Rozhodně není vhodné snažit se pomocí Artefaktů modelovat DB tabulky, Artefakt reprezentuje ucelenou struktur údajů uloženou samostatně (např. celou databázi či schéma v ní). Pro potřeby detailních informací využijte technickou dokumentaci. Modelování Artefaktů je součástí pokročilého modelování datové architektury.
		+
		+	{{ :playgroud:metodika_ey:realizace_datoveho_objektu.png?300 \|}}
		+
		+	<WRAP centeralign>//Realizace datového objektu několika artefakty v node (uzlu)//</WRAP><WRAP clear/>
		+
		+	=== Hlediska a pohledy ===
		+
		+	Čtenáři informací z oblasti technologické architektury jsou zejména Manažeři provozu (operations), Infrastrukturní inženýři a Architekti řešení (SAR). Obvykle je zajímá:
		+
		+	* dostupné portfolio technických platforem pro realizaci změn v aplikačním portfoliu
		+	* způsob realizace technologických služeb
		+	* propojenost uzlů pro komunikaci
		+	* dostupnost technologických funkcí v jednotlivých umístěních
		+
		+	Relevantní hlediska NAR:
		+
		+	^Hledisko ^Popis ^
		+	\|Technologického portfolia (mapa) \|Ukazuje přehled všech používaných technologických prvků \|
		+	\|Technologické infrastruktury – obecné \|Ukazuje přehled infrastruktury včetně základních vazeb \|
		+	\|Využití infrastruktury \|Ukazuje, jak je aplikační vrstva realizována technologickou vrstvou \|
		+	\|Zjednodušené nasazení informačních systémů \|Ukazuje, jak je konkrétní aplikace realizovaná technologií \|
		+
		+	== Katalogy ==
		+
		+	Doporučujeme formou katalogů evidovat všechny základní typy elementů:
		+
		+	* Katalog Technologických služeb (víceúrovňový)
		+	* Katalog Uzlů (včetně Systémových SW a Zařízení)
		+	* Katalog Sítí
		+	* Katalog Technologických služeb
		+	* Katalog Technologických funkcí
		+
		+	== Diagramy ==
		+
		+	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
		+	\|Mapa technologického portfolia \|Struktura infrastrukturních prvků realizující technologické služby \|Hledisko technologického portfolia (mapa) \|
		+	\|Mapa využití tech. služeb pro realizaci aplikační vrstvy \|Diagram ukazuje přehled vazeb mezi aplikační a tech. vrstvou. \|Hledisko využití infrastruktury \|
		+	\|Realizace aplikací pomocí SW a HW infrastruktury \|Diagram ukazuje pro jednotlivé aplikace realizaci pomocí prvků tech. architektury. \|Zjednodušené hledisko nasazení informačních systémů \|
		+
		+	{{ :playgroud:metodika_ey:mapa_technologickeho_portfolia.png?400 \|}}
		+
		+	<WRAP centeralign>//Mapa technologického portfolia//</WRAP><WRAP clear/>
		+
		+	{{ :playgroud:metodika_ey:mapa_vyuziti_technologicych_sluzeb.png?400 \|}}
		+
		+	<WRAP centeralign>//Mapa využití tech. služeb pro realizaci aplikační vrstvy pro vybranou aplikaci//</WRAP><WRAP clear/>
		+
		+	{{ :playgroud:metodika_ey:realizace_aplikaci_pomoci_sw_a_hw_infrastruktury.png?400 \|}}
		+
		+	<WRAP centeralign>//Realizace aplikací pomocí SW a HW infrastruktury//</WRAP><WRAP clear/>
		+
		+	//Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.//
		+
		+	=== Na co si dát pozor ===
		+
		+	\|Držte nejhrubší detail potřebný pro podnikového architekta \|Více než kde jinde je zde důležité nepřesáhnout míru detailu modelu. Katalogy konkrétních fyzických serverů a zařízení je obtížné udržovat aktuální a pro podnikového architektura to není zajímavý detail. Soustřeďte se na modelování informací zajímavých strategicky a koncepčně.\|
		+
		+	=== Reference ===
		+
		+	Přesnou definici prvků a metamodel pro architekturu IT technologické infrastruktury najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_ict_technologicke_architektury_ta
		+
		+	==== Architektura komunikační a fyzické infrastruktury ====
		+
		+	Tato vrstva má za úkol popsat geografické umístění prvků infrastruktury a komunikační cesty mezi nimi. Využívá se tedy primárně pro model datových center a komunikačních okruhů. Důležitými elementy zde jsou Budova (Facility v ArchiMate) a Síť.
		+
		+	Pro potřeby modelování komunikačního kanálu mezi Budovami je možné efektivně použít elementu Komunikační cesta (Path v ArchiMate), případným s vyznačením, které sítě jej realizují.
		+
		+	=== Doporučení pro modelování prvků KFI ===
		+
		+	== Jak modelovat umístění infrastruktury ==
		+
		+	Z hlediska podnikové architektury jsou zajímavými umístěními (lokacemi) datová centra, případně serverovny. Modelují se jako Budovy, které agregují prvky, jež jsou v nich umístěné. Součástí modelu může být, jaké daná lokace nabízí tech. funkce. Lokace jsou propojené Sítěmi.
		+
		+	Důležitou vlastností Budovy je označení vystihující geografickou polohu.
		+
		+	{{ :playgroud:metodika_ey:dve_datova_centra.png?300 \|}}
		+
		+	<WRAP centeralign>//Příklad modelu infrastruktury s dvěma datovými centry//</WRAP><WRAP clear/>
		+
		+	=== Hlediska a pohledy ===
		+
		+	Čtenáři informací z oblasti komunikační a fyzické infrastruktury jsou zejména Manažeři provozu (operations), Infrastrukturní inženýři a Architekti řešení (SAR). Obvykle je zajímá:
		+
		+	* propojenost uzlů pro komunikaci
		+	* dostupnost technologických funkcí v jednotlivých umístěních
		+
		+	Relevantní hlediska NAR:
		+
		+	* Nutno definovat v NAR
		+
		+	== Katalogy ==
		+
		+	Zajímavé katalogy jsou:
		+
		+	* Katalog lokací (budovy, např. datová centra, serverovny, apod)
		+
		+	== Diagramy ==
		+
		+	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
		+	\|Přehled lokací \|Mapa budov (datová centra, serverovny, …) s jejich propojením a napojením na vnější sítě (internet, WAN, …) \|Nutno definovat v NAR \|
		+	\|Vybavení lokací \|Obsahuje vybavení, funkce, uzly a sítě v dané lokaci. \|Nutno definovat v NAR \|
		+
		+	//Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.//
		+
		+	//\\
		+	//
		+
		+	=== Na co si dát pozor ===
		+
		+	Analogicky jako v kap. Na co si dát pozor viz výše (Držte nejhrubší detail potřebný pro podnikového architekta).
		+
		+	=== Reference ===
		+
		+	Přesnou definici prvků a metamodel pro architekturu komunikační a fyzické infrastruktury najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_komunikacni_a_fyzicke_infrastruktury_ki
		+
		+	==== Implementace a migrace ====
		+
		+	V této oblasti se díváme na změny architektury podniku v čase, zejména jako výhled do budoucnosti ve formě roadmapy migrace. Účelem je ukázat čtenářům postup transformace z aktuálního stavu architektury na cílový. Při tvorbě je výchozím bodem současný stav architektury, musíme jej mít tedy zmapovaný.
		+
		+	Migrací se myslí postup přechodu ze současné do cílové architektury přes potenciální dočasné (tranzientní) architektury.
		+
		+	=== Postup při realizaci roadmapy ===
		+
		+	Tým podnikové architektury vyjedná s ostatními zainteresovanými osobami podobu cílové architektury, která vyplývá ze strategických plánů a cílů (detailněji viz kap. Architektura strategie a směřování) a stanoví cestu (roadmapu) k cílové architektuře. Přechodové architektury slouží jako záchytné body pro dokončení transformace vybraných oblastí.
		+
		+	Mezi každými dvěma stavy architektury je pak stanovena sada Rozdílů, které je nutné realizovat pomocí projektů, či programů (Balíčků práce) – viz diagram níže. Tento podklad je dále využit při plánování projektového portfolia podniku a při realizace konkrétních projektů. Během realizace projektu poskytuje podnikový architekt součinnost ve formě podkladů k daným Balíčkům práce a konzultací.
		+
		+	Po realizaci daného Balíčku práce (typicky release) musí podnikový architekt zaktualizovat aktuální stav architektury a roadmapu.
		+
		+	=== Doporučení pro modelování prvků IM ===
		+
		+	Změny v architektuře a její průběh v čase jsou reprezentovány několika elementy:
		+
		+	* Stavy architektury definují současné, cílové či přechodové podoby podnikové architektury. Nesou informaci o čase, v němž by měly být realizované.
		+	* Stav architektury je kromě popisu doplněn odkazy na Základní elementy struktury z jednotlivých domén, které jsou jím ovlivněné. Vazba na Stav architektury určuje i období platnosti změny daného elementu.
		+	* Mezi nimi jsou definované Rozdíly, které jsou pak zpracovány pomocí Balíčků práce (které mají zhruba velikost projektu a jsou podkladem pro projektového manažera při plánování projektu).
		+	* Výstup projektu pak popisuje hlavní potřebné změny, nutné k dosažení daného Stavu architektury . Výstupem může být např. nová aplikační komponenta, zrušená stará technologie, či nový obchodní proces. Nejedná se o model cílového stavu, ale jednoduchý popis potřebných změn seskupených tak, aby bylo možné je realizovat projektem.
		+
		+	Níže je uveden metamodel včetně kontextu do návazných oblastí architektury.
		+
		+	{{ :playgroud:metodika_ey:matice_mapovani_stavu_architektury.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat migraci ==
		+
		+	Mezi dvěma Stavy architektury (Plateu v ArchiMate) jsou definované Rozdíly (Gap v ArchiMate) a jejich realizace probíhá pomocí Balíčků práce, které definují oblast prací, které se musí provést v určitém pořadí či čase, což je hodnotný podklad pro projektového manažera.
		+
		+	Ke Stavu architektury je vhodné pro ukotvení v čase přiřadit základní elementy z jednotlivých domén. Toto lze dobře řešit maticemi, kde je na jedné ose seznam Stavů architektury a na druhé sada elementů daného typu z vybrané domény.
		+
		+	Stav architektury v dané doméně (např. aplikační) je vizualizován přehledovými mapami architektury s vyznačením, které existující prvky v ní budou zastoupené i nadále, které přibudou a které naopak budou ukončené. Pro vizualizaci této informace na diagramu je používané barevné ohraničení elementu, např typu: červená=ukončení, zelená=pokračující, modrá=nový. //Pozn. Nejedná se o vybarvení elementů dle vrstvy architektury, ale specifické bravy okrajů daných elementů na diagramu jako doplňková informace.//
		+
		+	Typická podoba roadmapy migrace je na obrázku níže.
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_15_-_diagram_s_vyznacenim_barevne_konvence.png?400 \|}}
		+
		+	<WRAP centeralign>//Příklad roadmapy se dvěma paralelními přechodovými architekturami//</WRAP><WRAP clear/>
		+
		+	== Jak modelovat projektový aspekt ==
		+
		+	Pro účely přípravy realizace identifikuje podnikový architekt Balíčky práce (Work package dle ArchiMate), které je potřeba realizovat, aby došlo k přechodu mezi dvěma Stavy architektury, jak je popsané výše. Balíčkem práce na této úrovni bývá Projekt. Projekty mohou být seskupené do Programu. Pokud je to vhodné, může být identifikován i detailnější rozpad Balíčků práce v rámci Projektu. Balíčky práce mohou být označené i informací o potřebném pořadí realizace či vzájemné závislosti.
		+
		+	Architekt vytváří podklady pro věcné zadání projektu, samotný projekt je vytvářen a řízen projektovým managerem.
		+
		+	Výstupem je přehled projektů, které je nutné realizovat, aby došlo k nastolení cílového Stavu architektury. U každého projektu by měly být zřejmé jeho výstupy (Outcome dle ArchiMate), cíle a časování. Očekává se, že identifikované Balíčky práce budou navázané na skutečné rozběhlé projekty, řízené z podnikového týmu PMO (Project Management Office).
		+
		+	{{ :playgroud:metodika_ey:diagram_balicku_prace.png?600 \|}}
		+
		+	<WRAP centeralign>//Diagram balíčků práce navázaných na konkrétní stavy architektury//</WRAP><WRAP clear/>
		+
		+	=== Hlediska a pohledy ===
		+
		+	Očekávanými čtenáři této oblasti architektury jsou lidé zodpovědní za strategii a směřování podniku (včetně podnikových architektů), role z oblasti řízení projektů a jejich portfolia, zejm. projektoví a programoví manažeři a solution architekti. Dále může být informace užitečná pro manažery provozu a správy, aby tušili, kdy je čekají jaké změny ve spravovaném porftoliu.
		+
		+	Pro ně zajímavá hlediska z NAR jsou:
		+
		+	* Hledisko implementace a migrace
		+
		+	== Katalogy ==
		+
		+	Elementy primárně zařazené do této oblasti mají své katalogy:
		+
		+	* Katalog Stavů architektury
		+	* Katalog Rozdílů
		+	* Katalog Balíčků práce
		+	* Katalog Výstupů
		+
		+	== Diagramy ==
		+
		+	Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže.
		+
		+	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
		+	\|Pohled migrace \|Pohled na roadmapu ukazující Stavy architektur a přechody mezi nimi. Zobrazené elementy jsou:\\ \\ * Stav architektury,\\ * Rozdíl,\\ * Balíček práce (včetně závislostí a pořadí) \|Hledisko implementace a migrace \|
		+	\|Pohled implementace a migrace \|Pohled ukazující vazby mezi projekty a realizovanými prvky architektury.\\ \\ Zobrazené elementy jsou zejména:\\ \\ * Stav architektury\\ * Balíček práce (včetně závislostí a pořadí)\\ * Rozdíl\\ * Měněné elementy se zvýrazněným typem změny (viz výše) \|Hledisko implementace a migrace \|
		+	\|Projektový pohled \|Diagram ilustruje hlavní aspekty realizace Balíčku práce, zejm. projektu či programu.\\ \\ Jedná se o nepovinný, ale vhodný diagram ukazující všechny potřebné navázané elementy na konkrétní změnu.\\ \\ Elementy na diagramu jsou:\\ \\ * Balíček práce (projekt sám)\\ * Stav architektury\\ * Balíček práce (podřazené/nadřazené)\\ * Rozdíly realizované projektem\\ * Výstupy projektu\\ * Odpovědné role\\ * Měněné elementy se zvýrazněným typem změny (viz výše) \|Hledisko implementace a migrace \|
		+
		+	{{ :playgroud:metodika_ey:ilustracni_priklad_-_pohled_implementace_a_migrace.png?400 \|}}
		+
		+	<WRAP centeralign>//Ilustrační příklad: Pohled implementace a migrace//</WRAP><WRAP clear/>
		+
		+	== Matice ==
		+
		+	^Matice ^Popis matice ^Realizované hledisko NAR ^
		+	\|Mapování Stavů architektury na měněné elementy \|Pro lepší představu o prvcích architektury ovlivněných plánovanými změnami je možné připravit matici toto ukazující. Na jedné ose je seznam Stavů architektury a na druhé sada elementů daného typu z vybrané domény. Členění matic dle domén je vhodné pro omezení množství elementů.\|Hledisko implementace a migrace \|
		+
		+	{{ :playgroud:metodika_ey:priklad_matice_mapovani_stavu_architektury_na_menene_elementy.png?400 \|}}
		+
		+	<WRAP centeralign>//Příklad matice Mapování stavů architektury na měněné elementy//</WRAP><WRAP clear/>
		+
		+	=== Na co si dát pozor ===
		+
		+	\|Nepodceňte potřebu plného sladění se stakeholdery \|Jedná se o strategickou úroveň plánování. Je nezbytné, aby příslušní manažeři věděli a panovala shoda na tom, co v roadmapě je. Neshoda může mít významné dopady na celý podnik. Zápis do formální podoby je až konečný výsledek řetězu prezentací a schůzek se zainteresovanými lidmi.\|
		+	\|Nesuplujte práci projektového manažera \|Při identifikaci Balíčků práce se soustřeďte na jejich globální popis a informace, které můžete dodat pouze vy. Detailní plán a všechny další aspekty potřebné pro realizaci projektu ponechte na rolích k tomu určených, až bude projekt probíhat. \|
		+
		+	=== Reference ===
		+
		+	Přesnou definici prvků a metamodel pro architekturu implementace a migrace najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_implementace_a_migrace
		+
		+	==== Architektura strategie a směřování ====
		+
		+	V této oblasti modelujeme důvod, proč úřad (jako podnik) existuje a proč vypadá tak jak vypadá. NAR v této oblasti kombinuje motivační a strategickou vrstvu (dle ArchiMate).
		+
		+	Chceme vědět, v čím zájmu je, aby úřad existoval a jaké jsou motivátory k jeho existenci a hlavním aspektům jeho fungování. Z těchto prvků jsou pak odvozené cíle, které je naplňují. Na tomto základě pak definujeme principy, které ovlivňují architektonické požadavky, vedoucí na realizaci vnitřku organizace a omezení, která je nutné brát v potaz. Dále by se v této oblasti měla nacházet odpověď na důvody, proč mají proběhnout / proběhly v organizaci změny.
		+
		+	Strukturu elementů a vazeb použitelných v této oblasti popisuje metamodel na obrázku níže.
		+
		+	{{ :playgroud:metodika_ey:identifikace_elementu_a_vazeb_pro_tuto_oblast_v_metamodelu_9.png?400 \|}}
		+
		+	<WRAP centeralign>//Identifikace elementů a vazeb pro tuto oblast v metamodelu//</WRAP><WRAP clear/>
		+
		+	=== Doporučení pro modelování prvků MA ===
		+
		+	== Jak modelovat zainteresované strany ==
		+
		+	Zainteresovaná strana odpovídá na otázku „V čím zájmu je, že jako úřad existuji a dělám to co dělám?“ Zainteresovanou stranou tedy bývá externí zřizovatel úřadu (vláda, ministerstvo?), a jeho nejvyšší interní představitelé (ředitel, ředitelé sekcí, …). Přehled zainteresovaných stran lze získat z organizační struktury úřadu. Důležité je nepoužívat konkrétní jména lidí, ale názvy jejich pozic či organizace. Identifikace Zainteresovaných stran je klíčová pro určení odpovědnosti za strategické směřování úřadu. Zainteresovanou stranu modelujeme pomocí elementu Stakeholder v ArchiMate.
		+
		+	== Jak modelovat veřejné potřeby jako hnací prvky ==
		+
		+	Hnací prvky (též motivátory) představují interní, či externí vlivy, které v důsledku formují vnitřní podobu úřadu („Proč úřad vypadá, jak vypadá?“). Většinou se jedná o zájmy Zainteresovaných stran.
		+
		+	* Veřejné potřeby jsou takovým případem hnacích prvků. Obvykle jsou dlouhodobě stabilní a určují základní aspekty fungování organizace.
		+	* Analýzy či Vyhodnocení potřeby jsou výsledkem zhodnocení naplnění daného motivátoru. Identifikují potřebu změny, aby byl motivátor korektně naplněn. Definují se častěji, obvykle periodicky jako důsledek kontroly stavu organizace a jsou iniciátorem transformačních aktivit.
		+
		+	Hnací prvky (vč. Veřejných zájmů) modelujeme pomocí elementu Driver v ArchiMate, Vyhodnocení potřeb/Analýzu pomocí elementu Assesment. Propojíme je vazbou asociace se Zainteresovanými osobami a Vyhodnoceními potřeb.
		+
		+	== Jak modelovat strategické cíle a výstupy ==
		+
		+	Strategické cíle naplňují Hnací prvky. Jsou často používány jako základní měřítko úspěšnosti fungování organizace. Do jaké míry/hodnoty budeme daný Cíl naplňovat, určuje Výstup. Strategický cíl identifikujeme z Hnacího prvku tak, že jím definujeme, jaké změny chceme v dané oblasti dosáhnout. Název Cíle by měl obsahovat slovo určující druh/povahu změny („zvýšíme“, „snížíme“, „dosáhneme“). Výstup pak doplňuje Cíl o konkrétní hodnotu, či míru na kterou Cíl naplníme. Výstup je pak skvělým podkladem pro identifikaci KPIs či akceptačních kritérií pro strategické projekty. Strategické cíle modelujeme pomocí elementu Goal v ArchiMate, Výstupy pak pomocí elementu Outcome. Typicky jsou Cíle navázané na Hnací prvky vzniklé z Vyhodnocení potřeb (např. audit či RACI analýza, viz výše) a dále jsou na ně realizační vazbou napojené Výstupy.
		+
		+	== Jak modelovat architektonické principy ==
		+
		+	Architektonické principy definují sadu obecně platných pravidel, kterými se lze řídit při tvorbě podnikové architektury v dané oblasti. Jejich dodržováním se implicitně naplňují relevantní Strategické cíle. Při definici Strategických cílů je proto třeba brát v potaz jejich univerzálnost.
		+
		+	Architektonický princip by měl být definován např. následovně((https:%%//%%pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html#:~:text=The%20remainder%20of%20this%20section%20deals%20exclusively%20with,all%20IT%20resources%20and%20assets%20across%20the%20enterprise.
		+	)):
		+
		+	^Název ^Výstižný, krátký. ^
		+	\|Definice \|Jednoznačný popis zamezující víceznačnému pochopení. \|
		+	\|Důvod \|Zdůraznit výhody dodržování principu. Pro snadné pochopení na netechnické úrovni. \|
		+	\|Důsledky \|Popis dopadů/požadavků na části organizace implementující princip („Jak to dopadne na mě?“).\|
		+
		+	Pokud nejsme schopni danou část popisu principu naplnit, je pravděpodobné, že je princip nevhodně navržen. Architektonické principy je třeba členit dle oblastí či architektonických domén pro lepší přehlednost pro čtenáře z dané oblasti. Modelujeme je pomocí elementu Principle v ArchiMate. Architektonické principy jsou obvykle navázané na Strategický cíl či Výstup, jehož dosažení/udržení napomáhají.
		+
		+	//Pozn.: V souladu s ArchiMate je možné označit sílu vazby pomocí ++/+/-/--.//
		+
		+	== Jak modelovat klíčové požadavky a omezující podmínky ==
		+
		+	Při přípravě projektu, který bude realizovat zajištění Cíle či naplnění Výstupu je možné definovat Klíčové požadavky, jejichž splnění toto zajistí. Klíčové požadavky na úrovni podnikové architektury zdůrazňují důležité aspekty, které je potřeba vzít v potaz, např. naplnění určitých Architektonických principů.
		+
		+	Omezující podmínky pak systematickým způsobem vymezují „hřiště“, na kterém lze řešení stavět. Např. povolenými technickými platformami, rámcem rozpočtu či časování. Opět se mohou odkazovat na příslušné Architektonické principy či konkrétní elementy v jednotlivých doménách.
		+
		+	{{ :playgroud:metodika_ey:hierarchie_urovni.png?300 \|}}
		+
		+	<WRAP centeralign>//Příklad hierarchie úrovní//</WRAP><WRAP clear/>
		+
		+	=== Hlediska a pohledy ===
		+
		+	Očekávanými čtenáři informací v této oblasti jsou samotné Zainteresované strany – obvykle vrcholoví manažeři odpovědní za strategii v dané oblasti, dále samotní podnikoví architekti, architekti řešení a manažeři projektového portfolia. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR:
		+
		+	* Motivační hledisko strategického směřování
		+
		+	Toto hledisko může být případně rozdělené podle očekávaných čtenářů na:
		+
		+	* Hledisko zainteresovaných stran
		+	* Hledisko architektonických principů
		+
		+	== Katalogy ==
		+
		+	Doporučujeme tvořit následující katalogy elementů:
		+
		+	* Katalog Zainteresovaných stran
		+	* Katalog Veřejných potřeb/hnacích prvků
		+	* Katalog Strategických cílů
		+	* Katalog Vyhodnocení potřeb/analýz
		+	* Katalog Výstupů
		+	* Katalog Architektonických principů
		+	* Katalog Klíčových architektonických požadavků a Omezujících podmínek
		+
		+	== Diagramy ==
		+
		+	Zajímavé diagramy pro tuto doménu jsou uvedeny v tabulce níže. Pro lepší přehlednost je na obrázku barevně znázorněno pokrytí elementů metamodelu v diagramech.
		+
		+	{{ :playgroud:metodika_ey:umisteni_elementu_na_diagramy_v_teto_oblasti.png?400 \|}}
		+
		+	<WRAP centeralign>//Umístění elementů na diagramy v této oblasti//</WRAP><WRAP clear/>
		+
		+	^Diagram ^Popis diagramu ^Realizované hledisko NAR ^
		+	\|Přehled Zainteresovaných osob a Hnacích prvků \|Ukazuje přehled Zainteresovaných osob, motivátorů, cílů. Případně lze doplnit o elementy typu Analýza a Výstup (může být rozděleno do více diagramů dle oblasti). Použité elementy:\\ \\ * Zainteresovaná osoba\\ * Hnací prvek\\ * Analýza\\ * Strategický cíl\\ * Výstup \|Hledisko zainteresovaných stran \|
		+	\|Přehled Architektonických principů (Mapa) \|Ukazuje výčet definovaných Arch. principů a jejich rozdělení do oblastí. \|Hledisko architektonických principů \|
		+	\|Realizace strategických elementů pomocí Klíčových požadavků a Omezujících podmínek \|Sada diagramů ukazující relevantní požadavky a omezující podmínky, spolu s jejich kontextem směrem k realizovaným Principům, Cílům a Výstupům. Je vhodné ukázat i ovlivněné prvky z ostatních arch. domén.\\ \\ Očekává se sada diagramů, dle jednotlivých implementačních iniciativ, např dle roadmapy Migrace (viz kap. Na co si dát pozor)\\ \\ Použité elementy:\\ \\ * Klíčový požadavek\\ * Omezující podmínka\\ * Strategický cíl\\ * Výstup\\ * Architektonický princip\\ * Základní prvek struktury \| \|
		+
		+	== Matice ==
		+
		+	V této oblasti nejsou definované žádné specifické matice. Pro lepší přehlednost je možné připravit matice ukazující důležité vazby, např. pokrytí Hnacích prvků pomocí Strategických cílů, či genezi Hnacích prvků od Zainteresovaných stran či z Vyhodnocení potřeb.
		+
		+	=== Na co si dát pozor ===
		+
		+	\|Zajistěte stabilní strategii \|Architektura strategie a směřování definuje základy, z nichž vychází celá architektura a fungování podniku. Měla by proto být co nejrobustnější a soustředit se na důležité prvky. Ty je však často obtížené identifikovat a nastavit měřitelně, jelikož to má dopad na Zainteresované strany. U této domény je tedy víc než u všech ostatních potřeba sladit očekávání a její řízení se všemi Zainteresovanými stranami.\|
		+
		+	=== Reference ===
		+
		+	Přesnou definici prvků a metamodel pro architektura strategie a směřování najdete v NARu: [[https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_strategie_a_smerovani_ma\|https:%%//%%archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_strategie_a_smerovani_ma]]
		+
		+
		+	<WRAP center round important 100%>
		+	Následující oblasti architektury jsou průřezové a volitelné. Pro potřeby DIA je očekáván hlavně slovní popis situace.
		+
		+	Jedná o oblasti, kde není nyní metodika zcela detailní, proto u nich není popsán mechanismus modelování. Systematičtější přístup, který se pravděpodobně bude dlouhodobě rozvíjet a upřesňovat, je popsán v příslušných částech NAR.
		+	</WRAP>
		+
		+
		+
		+
		+	==== Architektura bezpečnosti ====
		+
		+	Architektura bezpečnosti je důležitá průřezová disciplína, vyžadující díky své komplexitě vlastní metodiku. Přístup úřadů k této problematice je definován příslušnými předpisy a audity. Pro potřeby architektury je důležitá evidence vztahů jednotlivých aspektů bezpečnosti k prvkům podnikové architektury a zejména zajištění jejich průběžná aktualizace. Tento problém lze řešit např. využitím frameworku ESRM(([[https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.bizzdesign.com%2Farticles%2Fhorizzon-help%2Fenterprise-risk-and-security-management&data=05%7C02%7CJaromir.Kuzelka%40cz.ey.com%7C0f43303ffbf34a6cf40a08dd468bfd1a%7C5b973f9977df4bebb27daa0c70b8482c%7C0%7C0%7C638744289267517337%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N7yRa%2BMsvRdHEhA1z31ZWPmN2hsxPaloOZYRIuIZY8g%3D&reserved=0\|https:%%//%%help.bizzdesign.com/articles/horizzon-help/enterprise-risk-and-security-management]]
		+	)) od společnosti BizzDesign. Framework využívá vlastního rozšíření elementů jazyka ArchiMate v motivačním aspektu.
		+
		+	Základem frameworku je iterativní proces sestávající z 9 kroků, ilustrovaných na obrázku níže, které zajišťují systematické pokrytí bezpečnostních aspektů architektury.
		+
		+	{{ :playgroud:metodika_ey:zakladni_proces_esrm.png?400 \|}}
		+
		+	<WRAP centeralign>//Základní proces ESRM//</WRAP><WRAP clear/>
		+
		+	Červené kroky představují fázi zhodnocení rizik, zelené pak fázi realizace opatření a mechanismů pro provoz, která pokrývá i realizaci prostředků a nástrojů pro fázi zhodnocení rizik.
		+
		+	=== Reference ===
		+
		+	https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_bezpecnostni_architektury_saInformace k architektuře bezpečnosti najdete v NARu zde: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_bezpecnostni_architektury_sa
		+
		+	==== Architektura výkonnosti ====
		+
		+	Momentálně není poptávané modelování výkonnosti pro potřeby DIA. Úřady by ale měly zavádět a udržovat mechanismy umožňující měřitelnost výsledků provedených změn a jejich dlouhodobého provozování.
		+
		+	Jazyk ArchiMate nyní neobsahuje metriky ani jiné ukazatele výkonnosti, proto je zavádí NAR. Metodika v této oblasti však momentálně není striktně předepsaná.
		+
		+	=== Reference ===
		+
		+	Informace k architektuře výkonnosti najdete v NARu zde: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_vykonnostni_architektury_pa
		+
		+	==== Architektura shody s pravidly ====
		+
		+	Tato oblast zajišťuje korektní navázání elementů z ostatních architektonických domén (zejména Motivační) na konkrétní předpisy, standardy a kritéria udržitelnosti. Jedná se hlavně o popis toho jak jsou modelované tyto elementy a jak se na ně odkazovat ze zbylých částí modelu.
		+
		+	Předpokládaný způsob modelování je takový, že DIA/OHA bude vlastnit elementy reprezentující používané předpisy apod. a architekti úřadů na ně budou odkazovat pomocí vazeb z relevantních elementů – např. Hnacích prvků, Strategických cílů, Omezujících podmínek, apod., aby byl zřejmý jejich původ.
		+
		+	=== Reference ===
		+
		+	Informace k architektuře shody s pravidly najdete v NARu: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#metamodel_architektury_standardizace_shody_s_predpisy_a_udrzitelnosti

Nástroje - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:19:47+00:00

2026/08/08 16:59	aktuální
Řádek 1:	Řádek 1:
	+	====== Nástroje ======
	+
	+	===== Modelovací nástroje =====
	+
	+	Pro tvorbu modelů nejsou předepsané žádné konkrétní nástroje. Očekává se, že podnik využije svých znalostí a zkušeností k volbě nástroje dle uvážení.
	+
	+	Podrobněji jsou požadavky na nástroj popsané v NAR: [[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#potreby_a_pozadavky_pouzivani_nastroje\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#potreby_a_pozadavky_pouzivani_nastroje]]
	+
	+	===== Výměna informací =====
	+
	+	Pro usnadnění výměn informací ve strukturované podobě stanovuje OHA formát pro výměnu modelů(([[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju]]
	+	)). Jedná se o formát The Open Group ArchiMate File Exchange Format.
	+
	+	Je nutné, aby použitý nástroj podporoval export a import do/z tohoto formátu a interní procesy modelování umožňovaly doplnění potřebných metainformací k prvkům modelu, i samotnému exportovanému souboru.
	+
	+
	+

Tvorba modelu obecně

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:15:11+00:00

2025/05/07 10:38	aktuální
Řádek 1:	Řádek 1:
	+	====== Tvorba modelu obecně ======
	+
	+	Obecně platné principy pro dobrý model jsou popsané níže.
	+
	+	^Princip ^Popis ^
	+	\|Buďte poctiví \|Nazývejte každou věc z reality při jejím zachycování do modelu pravým jménem, vyhýbejte se opisům “úřednického newspeaku”. \|
	+	\|Buďte věrní \|Usilujte o to, aby kterýkoli diagram, v jakékoli míře podrobnosti byl vždy co nejvěrnějším obrazem Vašeho porozumění realitě. To znamená v praxi mimo jiné používání prvků modelovacího jazyka pro to, pro co jsou určeny. Tedy aplikační komponenty pro aplikace a ne pro procesy, nenahrazovat business služby aplikacemi, dát si pozor na rozdíl mezi rolemi a aktéry atd. \|
	+	\|Buďte výstižní \|Modelujte a popisujte realitu tak, aby bylo dodrženo pravidlo „Dokonalosti je dosaženo, když není co odebrat, ne když není co přidat“. Model by měl být tak jednoduchý, jak je možné, v kontextu očekávaných čtenářů a metodiky. Snažte se, aby model na dané úrovni detailu neobsahoval v jiné podobě stejné informace vícekrát. Informace se mohou opakovat při modelování stejné oblasti na nižší/vyšší úrovni detailu – jedná se o popis stejné části reality –, ale musí být poplatné dané úrovni detailu – viz další princip. \|
	+	\|Dávejte popis ke každému prvku \|Ke každému prvku (strukturní prvky, element, vazba, pohled) vedle jeho názvu navíc doplňte vyčerpávající slovní popis (do příslušného pole – např. Note, Documentation apod.). Pomůže to čtenáři pochopit vaše myšlenky a dále zamezí možnosti nesprávného pochopení. Zejména u diagramů je vhodné čtenáři poskytnout popis jako průvodce zobrazenými elementy a vazbami, aby byly zřejmé prezentované myšlenky. Popisy také zvyšují hustotu informací ve výstupu z modelu a čtenáři pomáhají lépe pochopit kontext. \|
	+	\|Čleňte model dle úrovní detailu \|Model by měl být členěn stejným způsobem přes celý rozsah modelované reality. Je vhodné definovat jasně úrovně detailu a ty dodržet. Např. L0, L1, L2, jak je popsané níže v této metodice (kap. 3.6.4). Nejvyšší úroveň by měla ukazovat celý rozsah modelované reality, detailnější úrovně se mohou zaměřit jen na zajímavé části. Lze využít hierarchického strukturování modelu v katalozích elementů a digramů zaměřených na danou úroveň detailu. To implicitně zlepšuje čtivost dokumentace z modelu, neboť jde přirozenou cestou od celku k detailům („top-down“). \|
	+	\|Buďte konzistentní a dodržujte standardy napříč modelem \|Dodržujte stejný způsob popisu přes všechny části dané oblasti a úrovně detailu modelu. Významně to usnadní sdílení informací v modelu s ostatními, zastupitelnost modelářů a také to umožní formální kontrolu kvality modelu. Mezi důležitá rozhodnutí patří i jazyk, v němž bude model tvořen. Jakmile je potenciálně možné, že bude model tvořit a číst i cizojazyčný uživatel, zvažte tvorbu modelu v angličtině. V modelech pro státní správu dle NAR je čeština vždy primárním jazykem. \|
	+	\|Používejte správné prvky \|Dobře rozmyslete, jaký typu elementu použijete pro uložení dané informace. Např. aplikační komponenty ať reprezentují aplikace a ne procesy, nenahrazujte business služby aplikacemi, rozlišujte mezi rolemi a aktéry atd. Buďte co nejlépe seznámení s modelovacím standardem (vč. metamodelu).\\ \\ Cílem je předejít duplikaci informací a mít informace uložené na očekávaných místech. \|
	+	\|Zaveďte a dodržujte jmenné konvence a identifikátory prvků modelu \|Standardizaci, jednoznačnosti a pochopitelnosti pomáhá jednotný způsob označování prvků modelu a používání ustálených označení pro jednotlivé prvky. Jmenná konvence umožňuje zavést do názvu prvku doplňkové informace, které pak není třeba hledat v atributech prvku. Systém identifikátorů pak zajistí, že se lze na konkrétní prvek odkázat, aniž by bylo třeba vypisovat jeho celý název, či dokonce kontext. \|
	+	\|Modelování není programování \|I když je samozřejmě vhodné maximálně využít možností nabízené metodikou či standardem, je nutné co nejvíce přiblížit výstup čtenáři. Sebelepší metodika nepokrývá všechny potřebné situace a informace, které v je v modelu nutné uvést. Proto v případě, že by forma informace v modelu byla na úkor pochopitelnosti, je možné volit náhradní (byť nekonfliktní) způsoby zanesení informace do modelu. Vždy je např. možné popsat potřebné detaily textově do popisu na daném místě. Na diagramy je možné doplnit doplňující poznámky přímo, pod elementy je možné přidat další vysvětlující diagramy, matice apod. Buďte v tomto kreativní a mějte na mysli pohodlí pro čtenáře, neboť bez čtenáře je model zbytečný. \|
	+	\|Počítejte s budoucím rozšířením modelu \|Model strukturujte více robustně, než je aktuálně potřeba, abyste umožnili jeho snadné průběžné rozšiřování bez nutnosti refaktorování (změny struktury či formy). Je vhodné rozdělit modelovaný systém na moduly, které jsou stejným způsobem použity ve všech vrstvách/doménách modelu (nebo jsou alespoň konzistentní v rámci jedné vrstvy/domény). Tyto moduly pak slouží k logickému členění obsahu modelu a umožňují tvořit systematicky a jednoznačné identifikátory prvků. \|
	+	\|Přizpůsobujte výstupy pro konkrétní čtenáře \|Při modelování je nutné myslet na čtenáře. Jednotlivé výstupy z modelu by měly být přizpůsobené čtenáři daného hlediska tak, aby dostal informaci, kterou potřebuje, ve formě, kterou snadno pochopí, ideálně v podobě uceleného příběhu. Je vhodné strukturovat model už s ohledem na způsob vytváření výstupů pro čtenáře (export modelu, generovaná dokumentace, ručně udržovaná dokumentace se vstupy z modelu apod.). Většinou je pro dosažení optimálního výsledku potřeba přizpůsobit strukturu modelu podle očekávané formy výstupu pro čtenáře. \|
	+	\|Ambici pro verzování modelu nastavte na začátku \|Definujte si potřeby pro udržování časových řezů modelu. Přístupů a potřeb verzování je mnoho, od jedné verze po schopnost okamžitého pohledu do minulosti i budoucnosti. Pro dlouhodobou udržitelnost přehledu o verzích a platnosti obsahu modelu je zásadní si tuto ambici na začátku nastavit a podle toho pak nastavit proces tvorby a údržby modelu a výstupů. \|
	+	\|Automatizujte tvorbu výstupů \|Je vhodné mít schopnost časté tvorby dohodnutých výstupů s co nejmenší námahou. Ideální je zcela automatizovaný způsob tvorby generování výstupů. To umožňuje iterativně ladit výstup v dané verzi do nejlepší kvality, eliminuje lidské chyby a také umožňuje snadno identifikovat rozdíly mezi verzemi. Při tvorbě šablon dbejte na to, aby výstup obsahoval co nejméně prázdného místa. Výstup tak bude působit mnohem kompaktněji a nebude mít tolik stránek, což je zásadní pro jeho čtivost. \|
	+	\|Zajistěte si podporu od organizace \|Podpora se získá zejména tím, že výstupy architektů jsou vytvářeny tak, aby byly užitečné konkrétním lidem pro řešení jejich konkrétních problémů. Modelování na úrovni podnikové architektury vyžaduje získávání co nejpřesnějších informací prakticky od všech týmů v organizaci. Aby bylo možné tyto informace získat a ideálně znát i jejich očekávaný vývoj, je potřeba, aby stakeholdeři (majitelé těchto informací) věděli, že mají poskytnout součinnost a že to je pro ně přidaná hodnota. V budoucnu budou moci čerpat z modelu přesné a provázané informace v celofiremním kontextu. Podpora od organizace spočívá zejména v adopci týmu Enterprise architektury (EA) a jeho procesů do organizace, zejména na nejvyšších úrovních jejího řízení. Tým EA by měl být aktivní a snažit se být viditelný v příslušných diskusích. Dále je pro adopci výstupů EA dobré, když jsou přizpůsobené čtenářům (viz výše).\|
	+
	+	Výše popsané principy lze uplatnit na jednotlivé prvky modelu. Základními prvky modelu jsou elementy, vazby, atributy a pohledy. Dále je detailněji popsáno, které principy jsou na nich uplatněné a jakou jsou uplatněny formou.
	+
	+	===== Elementy =====
	+
	+	Element modelu reprezentuje jednu konkrétní část reality z pohledu její struktury či chování a popisuje její vlastnosti. Je to základní stavební prvek modelu.
	+
	+	Při modelování elementů doporučujeme mít na paměti následující:
	+
	+	^Zvolit správný typ elementu \|Respektovat kontext z hlediska metodiky (arch. doména, úroveň detailu) ^
	+	\|Název \|Výstižný a co nejkratší \|
	+	\|Jednoznačný identifikátor\|Zapadající do pravidel pro daný kontext (stereotyp, arch. doména, modul) \|
	+	\|Dostatečný popis \|Popis významně pomůže pochopení významu elementu, a to nejen pro čtenáře, ale i pro modeláře. Popis např. umožní rozhodnout, zda je třeba zakládat nový element, či rozšířit působnost existujícího. \|
	+	\|Relevantní pohledy \|Rozmyslete do jakých pohledů element patří přidat. Obvykle to definuje metodika a nástroj jej může do nich zahrnout automaticky na základě jeho umístění či stereotypu. Je ale vhodné se zamyslet, zda např. pro element nezaložit diagram ukazující kontext jeho použití pro lepší pochopení čtenářem. \|
	+	\|Zanořování elementů \|V případě této metodiky je doporučeno vytvářet lineární seznamy položek pro snadnou katalogizaci. Pro vizuální zapouzdřování je vhodné používat diagramy (včetně elementů typu Boundary), případně korektní vazby a elementy držet uložené lineárně. Cílem je zajistit předvídatelný způsob evidence elementů ve struktuře modelu a podpořit jednotný způsob stavění výstupní dokumentace.\|
	+
	+	===== Vazby =====
	+
	+	Propojuje elementy a říká jakým způsobem spolu dané elementy souvisejí. Pro vazbu jsou zásadní následující aspekty:
	+
	+	^Typ \|Musí být v souladu s metamodelem příslušné arch. domény a úrovní detailu) ^
	+	\|Název \|Zvážit, zda je třeba a neváhat jej doplnit, pokud to pomůže při čtení modelu na příslušných pohledech. U názvu je možné čtenáři indikovat směr čtení významu vazby mezi dvěma elementy. \|
	+	\|Popis vazby \|Není na první pohled zásadní, ale může významně pomoci při určování opodstatněnosti nové vazby mezi stejnými elementy. U vhodně strukturovaných dokumentů popis vazby pomůže významně k pochopení myšlenek a informací v modelu.\|
	+	\|Směrovost vazby \|Obvykle definovaná metodikou. Pozor na správný směr. \|
	+	\|Vlastnosti koncových bodů vazby \|V případě datového modelování je velmi přínosné doplnit k danému koncovému bodu vazby. \|
	+
	+	===== Atributy a doplňkové informace =====
	+
	+	Elementy, vazby i strukturní prvky v modelu mohou nést doplňkové informace, které je často vhodné držet ve strukturované podobě. Tyto údaje jsou označené jako atributy. Základními atributy jsou název a popis, k nim se ale přidávají další. Atributy lze roztřídit do skupin dle využití (profilů).
	+
	+	==== Základní atributy a jmenná konvence ====
	+
	+	Nejdůležitějšími a nejčastěji použitými atributy elementů i vazeb jsou název, popis a jednoznačný identifikátor.
	+
	+	=== Název ===
	+
	+	Název prvku by měl být lidsky čitelný, a proto je důležité zvolit vhodný jazyk. Dále by měl být co nejkratší a výstižný. Tato metodika v souladu s ArchiMate definuje pro jednotlivé typy elementů formu jakou by měl název mít:
	+
	+	* Behaviorální elementy musí být nazývány průběhovým časem (musí být patrná činnost/chování) (na příklad "Poskytování katalogu služeb", "Editování údajů". "Prodej zboží").
	+	* Pasivní elementy jsou nazývány podstatným jménem ("Dokument", "Faktura").
	+	* Aktivní elementy jsou pojmenovány podstatným jménem ("Jan Novák", Oddělení fakturace, Zákon 111/2009 Sb.).
	+
	+	=== Technický identifikátor ===
	+
	+	Technický identifikátor slouží pro jednoznačné označení prvku modelu. Obvykle není využíván mimo technický kontext modelovacího nástroje.
	+
	+	=== Globální identifikátor ===
	+
	+	Pro účely jednoznačné identifikace prvku v rámci modelování celé státní správy je očekávané zavedení //globálního identifikátoru//. Globální identifikátor nenahrazuje technický identifikátor, jedná se o další údaj.
	+
	+	Tento identifikátor by byl prvku přiřazován nejspíše po importu modelu úřadu do plánovaného centrálního úložiště.
	+
	+	Atribut bude nutné u daného prvku udržovat i lokálně po opětovném přenosu z centrálního úložiště do místního modelu. Takto budou označené zejména všechny sdílené prvky modelů.
	+
	+	==== Klasifikační atributy ====
	+
	+	Důležitým obecným profilem je Klasifikace. Klasifikační atributy slouží k jednoznačnému zařazení prvku modelu v kontextu požadované struktury, určení a umístění v centrálním úložišti modelů DIA. Jsou obvykle realizované pomocí Tagů (záleží ale na nástroji).
	+
	+	Klasifikační atributy jsou součástí metainformací o modelu (viz kap. Úrovně detailu).
	+
	+	<WRAP center round info 30%>
	+	Klasifikační atributy přes všechny prvky modelů jsou uvedené v externím dokumentu.
	+	</WRAP>
	+

Rychlá navigace

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-02-10T08:30:34+00:00

2026/08/08 16:59	aktuální
Řádek 1:	Řádek 1:
	+	====== Metodika modelování ======

	+	{{page>nar_dokument:metodika_modelovani_1}}
	+
	+	===== Best practices a principy modelování =====
	+
	+	Jak je z kapitoly výše patrné, tvorba modelu nespočívá v kreslení diagramů, nýbrž v budování systému elementů a vazeb, které mají definovaný konkrétní význam podle předepsaných pravidel. Tato pravidla umožňují čtenáři pochopení obsahu vizualizovaných částí modelu, aniž by modelář musel všechny informace vypisovat v textové podobě. Pravidla NAR a této metodiky stanovují nejen význam elementů a vazeb daného typu, ale říkají i, jak lze elementy mezi sebou propojovat, a definují jejich možné využití. Dále ukazují vazby v různých perspektivách. Tím, že model umožňuje použít jeden element či vazbu pro více pohledů, je eliminováno duplikování informací, což bývá zásadní problém pro jeho dlouhodobou udržitelnost a rozvoj.
	+
	+	Modelování dle předem dohodnutých pravidel zajišťuje, že uložené informace v modelu budou pro čtenáře pochopitelné a model bude možné dlouhodobě udržovat a rozvíjet.
	+
	+	===== Tvorba modelu obecně =====
	+
	+	{{page>nar_dokument:metodika_modelovani_2}}
	+
	+	===== Hlediska a pohledy =====
	+
	+	{{page>nar_dokument:metodika_modelovani_3}}
	+
	+	===== Členění modelu =====
	+
	+	{{page>nar_dokument:metodika_modelovani_4}}
	+
	+	===== Modelování dle NAR =====
	+
	+	{{page>nar_dokument:metodika_modelovani_5}}
	+
	+	===== Nástroje =====
	+
	+	{{page>nar_dokument:metodika_modelovani_6}}
	+
	+	===== Definice pojmů v této metodice =====
	+
	+	Níže je uvedena definice důležitých pojmů, s nimiž tento dokument pracuje. Cílem je jednoznačné chápání těchto pojmů v kontextu této metodické dokumentace.
	+
	+	//Tabulka 1: Definice pojmů//
	+
	+	^Zkratka ^Význam ^
	+	\|ArchiMate \|Framework pro modelování enterprise architektury od The Open Group \|
	+	\|BP \|Business process (obchodní process) \|
	+	\|ČR \|Česká republika \|
	+	\|DIA \|Digitální a informační agentura \|
	+	\|EA \|Enterprise architektura \|
	+	\|ESRM \|Enterprise Risk and Security Management.\\ Framework pro bezpečnostní architekturu od Bizzdesign \|
	+	\|ICT \|Informační a komunikační technologie \|
	+	\|IT \|Informační technologie \|
	+	\|NAR \|Národní architektonický rámec \|
	+	\|OHA \|odbor Hlavního architekta eGovernmentu \|
	+	\|OVS \|Orgán veřejné správy \|
	+	\|PMO \|Project Management Office (projektová kancelář) \|
	+	\|RPP \|Registr práv a povinností. Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností. Slouží jako zdroj údajů pro informační systémy základních registrů při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. \|
	+	\|KSVS \|Katalog služeb veřejné správy. \|
	+	\|TOGAF \|The Open Group Architecture Framework \|
	+	\|UML \|Unified Modeling Language \|
	+	\|VS \|Veřejná správa \|
	+
	+	Níže je uveden slovník pojmů s překlady do českého jazyka.
	+
	+	//Tabulka 2: Slovník pojmů v této metodice//
	+
	+	^Pojem ^Význam ^
	+	\|application \|aplikace / aplikační \|
	+	\|best practice \|nejlepší praxe \|
	+	\|business \|obchod / obchodní \|
	+	\|capability \|schopnosti \|
	+	\|enterprise \|podnik / podnikový. Zde hlavně úřad. \|
	+	\|layer \|vrstva \|
	+	\|motivation \|motivace / motivační \|
	+	\|note \|poznámka \|
	+	\|performance \|výkonost / výkonnostní \|
	+	\|refaktorování \|změna struktury či formy beze změny významu obsahu \|
	+	\|security \|bezpečnost / bezpečnostní \|
	+	\|stream \|tok, kanál \|
	+	\|tailoring \|přizpůsobení na míru \|
	+	\|top-down \|od celku k detailům \|
	+	\|value \|hodnota \|
	+	\|prvek modelu \|obecná součásti modelu (element, vazba) \|
	+	\|element \|základní stavební prvek modelu \|

2025/05/07 10:38		aktuální
Řádek 1:		Řádek 1:
-	====== Nástroje ======	+	====== Členění modelu ======

-	===== Modelovací nástroje =====	+	Tato metodika modelování platí pro enterprise architekturu celku, domén a segmentů OVS, v mírně omezené míře, respektive aplikovaně, pro enterprise architekturu řešení příležitostí, identifikovaných v doménových nebo segmentových architekturách.

-	Pro tvorbu modelů nejsou předepsané žádné konkrétní nástroje. Očekává se, že podnik využije svých znalostí a zkušeností k volbě nástroje dle uvážení.	+	V architektonickém popisu řešení lze pomocí této metodiky odpovídat na existencionální otázky CO? a PROČ? bude obsahovat hledané řešení, nikoli na otázky JAK MÁ FUNGOVAT? Takové modely tzv. solution architektury nejsou upraveny NAR ani touto metodikou, zejména proto, že:

-	Podrobněji jsou požadavky na nástroj popsané v NAR: [[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#potreby_a_pozadavky_pouzivani_nastroje\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#potreby_a_pozadavky_pouzivani_nastroje]]	+	- Mají jiný účel
		+	- Jazyk ArchiMate se pro ně málo hodí (spíše UML).

-	===== Výměna informací =====	+	===== Segmentace =====

-	Pro usnadnění výměn informací ve strukturované podobě stanovuje OHA formát pro výměnu modelů(([[https://archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s%5b%5d=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju\|https:%%//%%archi.gov.cz/nar_dokument:architektonicke_uloziste_a_nastroj?s[]=export%2A#principy_synchronizace_centralnich_a_lokalnich_architektonickych_nastroju]]	+	Z hlediska rozsahu modelovaných OVS a jejich korporací, či z hlediska jejich vnitřní struktury dělené na segmenty a schopnosti je tato metodika modelování univerzálně použitelná.
-	)). Jedná se o formát The Open Group ArchiMate File Exchange Format.	+

-	Je nutné, aby použitý nástroj podporoval export a import do/z tohoto formátu a interní procesy modelování umožňovaly doplnění potřebných metainformací k prvkům modelu, i samotnému exportovanému souboru.	+	Sem ale patří otázka, kolik má mít jedno OVS modelů. Před každým modelování nějakého katalogu nebo diagramu je nutno rozhodnout do jakého z nich daná informace patří. OVS by mělo být schopno rozlišit a samostatně spravovat modely:

-	====== Definice pojmů v této metodice ======	+	* VLST – Vlastní model architektury úřadu (OVS). Obsahuje prvky a pohledy specifické pro tento kontext. Úřad může obsahovat několik modelů tohoto typu pro své jednotlivé organizace.
		+	* SPOL – Společný model úřadu a všech jím kontrolovaných (a metodicky vedených) organizací (resort, krajská korporace atp.). Zde jsou umístěné pohledy kombinující prvky z několika modelů typu VLST. Mohou zde být i další prvky, spadající jen do kontextu SPOL.
		+	* 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). Zde by měly být pohledy ukazující kontext mimo rámec SPOL, typicky se sdílenými prvky jiných úřadů. DO doby, než bude k dispozici centrální správa sdílených prvků, budou zde uložené jejich kopie, které budou použité pro vazby a pohledy v modelu daného úřadu.

-	Níže je uvedena definice důležitých pojmů, s nimiž tento dokument pracuje. Cílem je jednoznačné chápání těchto pojmů v kontextu této metodické dokumentace.	+	Na obrázku níže je ilustrován princip strukturování modelů těchto typů.

-	//Tabulka 1: Definice pojmů//	+	{{ :playgroud:metodika_ey:ilustrace_1_10_-_segmentace_modelu_z_pohledu_jednoho_uradu.png?600 \|}}

-	^Zkratka ^Význam ^	+	<WRAP centeralign> //Ilustrace segmentace modelu z pohledu jednoho úřadu//</WRAP><WRAP clear/>
-	\|ArchiMate \|Framework pro modelování enterprise architektury od The Open Group \|	+
-	\|BP \|Business process (obchodní process) \|	+
-	\|ČR \|Česká republika \|	+
-	\|DIA \|Digitální a informační agentura \|	+
-	\|EA \|Enterprise architektura \|	+
-	\|ESRM \|Enterprise Risk and Security Management.\\ Framework pro bezpečnostní architekturu od Bizzdesign \|	+
-	\|ICT \|Informační a komunikační technologie \|	+
-	\|IT \|Informační technologie \|	+
-	\|NAR \|Národní architektonický rámec \|	+
-	\|OHA \|odbor Hlavního architekta eGovernmentu \|	+
-	\|OVS \|Orgán veřejné správy \|	+
-	\|PMO \|Project Management Office (projektová kancelář) \|	+
-	\|RPP \|Registr práv a povinností. Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností. Slouží jako zdroj údajů pro informační systémy základních registrů při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. \|	+
-	\|KSVS \|Katalog služeb veřejné správy. \|	+
-	\|TOGAF \|The Open Group Architecture Framework \|	+
-	\|UML \|Unified Modeling Language \|	+
-	\|VS \|Veřejná správa \|	+

-	Níže je uveden slovník pojmů s překlady do českého jazyka.	+	===== Struktura modelu =====

-	//Tabulka 2: Slovník pojmů v této metodice//	+	Jednotná struktura modelů významně pomáhá jejich pochopitelnosti a umožňuje zastupitelnost jak na straně čtenářů, tak na straně tvůrců. Dlouhodobě si DIA klade za cíl udržovat modely podnikových architektur úřadů centrálně, což vede také na potřebu jednotného strukturování modelů. Proto v této metodice popisujeme hlavní myšlenky v této oblasti.

-	^Pojem ^Význam ^	+	Model by měl být strukturován zhruba taktak, jak je vidět na obrázku níže. Struktura počítá s možností hierarchického členění modelu úřadu (prvky „Část úřadu N“). Následuje dělení dle architektonických domén, kde je očekávaná úplná nezávislost obsažených prvků (elementů, vazeb) mezi doménami. Na další úrovni jsou pak elementy sdružené do katalogů a diagramy a matice, na nichž jsou elementy a vazby zobrazené.
-	\|application \|aplikace / aplikační \|	+
-	\|best practice \|nejlepší praxe \|	+	Samotné elementy jsou držené buď ve vlastní struktuře, nebo jako součást katalogů – záleží na konkrétním nástroji. To samé platí o uložení vazeb.
-	\|business \|obchod / obchodní \|	+
-	\|capability \|schopnosti \|	+	Zatímco elementy jsou jasně přiřazené k architektonickým doménám, na pohledech mohou být elementy z více domén současně. Umístění pohledu se pak řídí převažujícím typem elementů, či tím, kam spíše logicky patří. V kapitole 4.64.6 je pak uvedeno zařazení pohledů do jednotlivých architektonických domén.
-	\|enterprise \|podnik / podnikový. Zde hlavně úřad. \|	+
-	\|layer \|vrstva \|	+	Nelze zapomenout na pohledy, které jsou striktně průřezové. Pro ně je vhodné vyčlenit uzel struktury „Přehledová hlediska“, který je sdružuje.
-	\|motivation \|motivace / motivační \|	+
-	\|note \|poznámka \|	+	{{ :playgroud:metodika_ey:ilustrace_1_11_-_princip_strukturovani_modelu_uradu.png?600 \|}}
-	\|performance \|výkonost / výkonnostní \|	+
-	\|refaktorování \|změna struktury či formy beze změny významu obsahu \|	+	<WRAP centeralign> //Princip strukturování modelu úřadu//</WRAP><WRAP clear/>
-	\|security \|bezpečnost / bezpečnostní \|	+
-	\|stream \|tok, kanál \|	+	^Prvek ^Význam ^
-	\|tailoring \|přizpůsobení na míru \|	+	\|Kořenový uzel \|Strukturní prvek, pod nímž je celý model. Nese doplňkové informace určující o jaký úřad se jedná. \|
-	\|top-down \|od celku k detailům \|	+	\|Část úřadu \|Pokud je úřad vnitřně strukturně členěn ne víceméně nezávislé části, doporučujeme to reprezentovat i v modelu. Zejména v situaci, kdy mají části různé architekty.\|
-	\|value \|hodnota \|	+	\|Architektonická doména\|Modelovaná vrstva/doména architektury (viz kap. Architektonické domény) \|
-	\|prvek modelu \|obecná součásti modelu (element, vazba) \|	+	\|Katalogy elementů \|Obsahují seznamy elementů daného typu \|
-	\|element \|základní stavební prvek modelu \|	+	\|Pohledy \|Obsahuje jednotlivé pohledy na model v příslušné arch. doméně. Typicky se jedná o diagramy a matice. \|
		+	\|Přehledová hlediska \|Uzel struktury, pod nímž jsou umístěné pohledy obsahující přehledy a průřezové pohledy, které obsahují elementy z více domén najednou. \|
		+
		+	===== Úrovně detailu =====
		+
		+	Aby byla podpořena myšlenka jednotné granularity informací přes celý model, jsou definované tři úrovně detailnosti modelovaného pohledu na realitu. Tyto úrovně jsou pojmenované L0, L1 a L2 a jsou popsané v tabulce níže.
		+
		+	^ ^Název ^Význam ^
		+	\|L0\|Přehledová\|Ukazuje principy a podstatu. Dává celkový přehled, celkový pohled na systém v dané doméně/oblasti; hlavní prvky a konzumenti. Často jsou zde agregované (seskupující) prvky.\|
		+	\|L1\|Základní \|Ukazuje všechny klíčové prvky pro ucelený pohled. Doplňuje se s přehledovou úrovní. \|
		+	\|L2\|Detailní \|Přidává detaily vybrané části z vyšší úrovně. Na této úrovni doporučujeme modelovat jen výseky, které si to zaslouží, např. díky komplexitě. \|
		+
		+	Detailní informace o konceptu úrovní detailu v NAR najdete na [[https://archi.gov.cz/nar_dokument:proces_tvorby_architektur?s%5b%5d=l1%2A#rozhodnuti_o_hloubce_obsahu\|https://archi.gov.cz/nar_dokument:proces_tvorby_architektur?s%5b%5d=l1%2A#rozhodnuti_o_hloubce_obsahu]]
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_12_-_prehledova_uroven_l0.png?400 \|}}
		+
		+	<WRAP centeralign> //Přehledová úroveň L0//</WRAP><WRAP clear/>
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_13_-_zakladni_uroven_l1.png?400 \|}}
		+
		+	<WRAP centeralign> //Základní úroveň L1 (červený rámeček ukazuje proces rozpracovaný na úrovni L2)//</WRAP><WRAP clear/>
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_14_-_detailni_uroven_l2.png?400 \|}}
		+
		+	<WRAP centeralign> //Detailní úroveň L2//</WRAP><WRAP clear/>
		+
		+	===== Modelování časové dimenze =====
		+
		+	Vždy musí být možné identifikovat časové období, k němuž se obsah modelu vztahuje. Zejména je důležité být schopný rozlišit, zda modelujeme současný (AsIs) či budoucí (ToBe) stav. Způsob realizace tohoto požadavku je vysoce závislý na způsobu řízení změn v podniku. Tato metodika doporučuje následující přístup:
		+
		+	\|Model aktuální situace je základ \|Mějte v potřebných okamžicích aktuální model stávající situace (AsIs) podnikové architektury. Lze řešit např. aktualizací modelu po releasu. \|
		+	\|Vývojové varianty modelujte odděleně od hlavního modelu \|Pokud teprve vzniká návrh cílového stavu, průběžně existuje více možných pracovních variant. Aby byla zajištěna integrita modelu, doporučujeme pracovat na modelu vzniklém kopií hlavního modelu, či ve zcela pracovním modelu. Po schválení cílového stavu jej přeneste do primárního modelu a navažte korektně na daný Stav architektury (vizte dále). \|
		+	\|Časový vývoj modelujte s pomocí vrstvy Implementace a migrace \|Pro modelování plánovaných změn použijeme část Implementace a migrace (viz kap. Implementace a migrace). Časové ukotvení nese příslušný Stav architektury. Na něj jsou navázané elementy (např. pomocí vazeb. D). Diagramy ukazují detailně situaci v tomto Stavu architektury, příslušnost ke Stavu architektury je řešena pomocí názvu či místěním diagramu. Je také využito barevné konvence pro indikaci změn v portfoliu.\|
		+	\|V případě potřeby doplňte interval platnosti k prvkům a udržujte jej aktuální \|Primárně by mělo k určení časové platnosti elementu stačit přiřazení k vybraným Stavům architektury. Pokud je to ale potřeba (např. pro zdůraznění využití až v nějakém období), doplníme element, vazbu či diagram obdobím platnosti. Je důležité nezapomenout tento údaj udržovat aktuální. \|
		+	\|Označujte model datem platnosti \|Označujeme okamžik, k němuž je model platný (Platnost k). Může to být datum, ale praktičtější může být označení obdobím, či releasem. Označení datem platnosti pomůže udržovat časové řezy modelu. \|
		+	\|Archivujte časové řezy \|Model verzujeme a starší řezy archivujeme pro účely udržování časových řezů z minulosti. \|
		+
		+	{{ :playgroud:metodika_ey:ilustrace_1_15_-_diagram_s_vyznacenim_barevne_konvence.png?600 \|}}
		+
		+	<WRAP centeralign> //Diagram s vyznačením barevné konvence pomocí ohraničení: zelená = nový, modrá = změna, červená = zrušený//</WRAP><WRAP clear/>
		+
		+	===== Metainformace =====
		+
		+	Pro jednoznačné zařazení dané části modelu pro čtenáře, ale hlavně pro potřeby automatizace zpracování obsahu modelu, vč. např. validace formální správnosti je potřeba jednotlivé prvky modelu doplnit o informace, které toto umožní.
		+
		+	Některé údaje popsané v kapitolách výše jsou elegantně zaznamenány do modelu právě pomocí metainformací.
		+
		+	Metainformace jsou v modelovacích nástrojích obvykle udržované jako specifické atributy, či tagy. Doporučujeme prozkoumat možnosti použitého modelovacího nástroje pro automatizaci a systematizaci jejich vyplňování.
		+
		+	Pro jakoukoli integrovatelnost modelů mezi sebou je nutné metainformace k prvkům modelu udržovat.
		+
		+	Základní metainformace jsou:
		+
		+	^Metainformace ^Význam ^Obvykle přiřazená k ^
		+	\|Datum platnosti \|K jakému datu je platný obsah dané části modelu \|Strukturní prvky na vyšší úrovni \|
		+	\|Autor/odpovědná osoba \|Jméno autora či osoby odpovědné za obsah dané části modelu \|Strukturní prvky, elementy, vazby, pohledy\|
		+	\|Datum poslední aktualizace \|Kdy byl daný prvek naposledy upraven \|Strukturní prvky, elementy, vazby, pohledy\|
		+	\|Vrstva architektury \|Architektonická doména (viz kap. Architektonické domény) \|Strukturní prvky \|
		+	\|Úroveň detailu \|Míra detailu modelovaného pohledu na realitu (viz. kap. Modelování časové dimenze)\|Pohledy \|
		+	\|Reference na příslušnou část metamodelu\|Určení, jakou část předpisu pro modelování daný prvek realizuje \|Elementy, vazby, pohledy \|

2021/03/11 08:56		aktuální
Řádek 10:		Řádek 10:
	*[[:slovnik_egov\|Slovník pojmů eGovernmentu]]		*[[:slovnik_egov\|Slovník pojmů eGovernmentu]]
	*[[:nar_dokument\|Národní architektonický rámec]]		*[[:nar_dokument\|Národní architektonický rámec]]
-	* [[nar_dokument:uvod\|Úvod]]	+	* [[:nar_dokument:uvod\|Úvod]]
-	* [[nar_dokument:modelujici_urady_a_jejich_architektury\|Modelující úřady a jejich architektury]]	+	* [[:nar_dokument:modelujici_urady_a_jejich_architektury\|Modelující úřady a jejich architektury]]
-	* [[nar_dokument:struktura_modelovanych_architektur\|Struktura modelovaných architektur]]	+	* [[:nar_dokument:struktura_modelovanych_architektur\|Struktura modelovaných architektur]]
-	* [[nar_dokument:proces_tvorby_architektur\|Proces tvorby architektur]]	+	* [[:nar_dokument:proces_tvorby_architektur\|Proces tvorby architektur]]
-	* [[nar_dokument:ramec_obsahu_a_vystupu_architektur\|Rámec obsahu a výstupů architektur]]	+	* [[:nar_dokument:ramec_obsahu_a_vystupu_architektur\|Rámec obsahu a výstupů architektur]]
-	* [[nar_dokument:referencni_modely_a_klasifikacni_ramce\|Referenční modely a klasifikační rámce]]	+	* [[:nar_dokument:referencni_modely_a_klasifikacni_ramce\|Referenční modely a klasifikační rámce]]
-	* [[nar_dokument:pokyny_a_techniky_pro_tvorbu_architektury\|Pokyny a techniky pro tvorbu architektur]]	+	* [[:nar_dokument:pokyny_a_techniky_pro_tvorbu_architektury\|Pokyny a techniky pro tvorbu architektur]]
-	* [[nar_dokument:architektonicke_dovednosti_utvary_a_organy\|Architektonické dovednosti, útvary a orgány]]	+	* [[:nar_dokument:architektonicke_dovednosti_utvary_a_organy\|Architektonické dovednosti, útvary a orgány]]
-	* [[nar_dokument:architektonicke_uloziste_a_nastroj\|Architektonické úložiště a nástroj]]	+	* [[:nar_dokument:architektonicke_uloziste_a_nastroj\|Architektonické úložiště a nástroj]]
	*[[:nap_dokument\|Národní architektonický plán]]		*[[:nap_dokument\|Národní architektonický plán]]
	*[[:znalostni_baze\|Rozšiřující znalostní báze]]		*[[:znalostni_baze\|Rozšiřující znalostní báze]]
Řádek 25:		Řádek 25:

	[[:uvod_schvalovani\|3.Schvalování projektů a záměrů ICT]]		[[:uvod_schvalovani\|3.Schvalování projektů a záměrů ICT]]
		+
		+	[[:reporty\|4. Seznam reportů]]