Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
Následující verze | Předchozí verze | ||
nar-dokument:struktura_modelovanych_architektur [2019/10/04 08:19] – vytvořeno Tomáš Šedivec | nar_dokument:struktura_modelovanych_architektur [2021/01/13 10:42] (aktuální) – ↷ Odkaz upraven z důvodu přesunutí Tomáš Šedivec | ||
---|---|---|---|
Řádek 1: | Řádek 1: | ||
====== Struktura modelovaných architektur ====== | ====== Struktura modelovaných architektur ====== | ||
- | Jestliže v kapitole | + | Jestliže v kapitole |
===== Modely architektury podle účelu a podrobnosti ===== | ===== Modely architektury podle účelu a podrobnosti ===== | ||
Řádek 16: | Řádek 16: | ||
* Doménové a projektové průřezové architektury řešení | * Doménové a projektové průřezové architektury řešení | ||
* Vrstva návrhu konkrétních řešení | * Vrstva návrhu konkrétních řešení | ||
- | * Design a konstrukce | + | * Design |
{{ : | {{ : | ||
Řádek 34: | Řádek 34: | ||
V celostní vrstvě se nalezené objekty zachycují společně, modely se nedělí na segmenty ani na domény. | V celostní vrstvě se nalezené objekty zachycují společně, modely se nedělí na segmenty ani na domény. | ||
- | **Průřezová nebo doménová architektura úřadu** (strategická, | + | **Průřezová nebo doménová architektura úřadu** (strategická, |
Poznání je v této vrstvě zaměřeno výhradně na existenciální aspekty všech prvků architektury úřadu a jejich vazeb (že existují, jak jsou staré, odkud pocházejí, | Poznání je v této vrstvě zaměřeno výhradně na existenciální aspekty všech prvků architektury úřadu a jejich vazeb (že existují, jak jsou staré, odkud pocházejí, | ||
Řádek 40: | Řádek 40: | ||
{{ : | {{ : | ||
- | Tento obrázek představuje kombinaci šedého pyramidálního modelu a barevného doménového modelu, představeného společně s podrobnějším popisem domén architektury úřadu v následující | + | Tento obrázek představuje kombinaci šedého pyramidálního modelu a barevného doménového modelu, představeného společně s podrobnějším popisem domén architektury úřadu v následující |
**Architektura řešení**((Angl. „Solution Architecture“ | **Architektura řešení**((Angl. „Solution Architecture“ | ||
Řádek 47: | Řádek 47: | ||
Architektury řešení jsou obvykle dílčí, pokrývající část řešených problémů a změn organizace (program, projekt), které odpovídají jednotlivým dílčím potřebám a příležitostem ke změně. Architektury řešení jdou často napříč více architektonickými doménami, ale mohou být i uvnitř jediné z nich. Jsou typicky platné pro dílčí část segmentu nebo pro schopnost veřejné správy a již nemusí být a nebývají celo-úřadové. Nebo pokrývají skupinu prvků architektury, | Architektury řešení jsou obvykle dílčí, pokrývající část řešených problémů a změn organizace (program, projekt), které odpovídají jednotlivým dílčím potřebám a příležitostem ke změně. Architektury řešení jdou často napříč více architektonickými doménami, ale mohou být i uvnitř jediné z nich. Jsou typicky platné pro dílčí část segmentu nebo pro schopnost veřejné správy a již nemusí být a nebývají celo-úřadové. Nebo pokrývají skupinu prvků architektury, | ||
- | Domény architektur řešení mohou přesně odpovídat doménám architektury úřadu, viz Obrázek | + | Domény architektur řešení mohou přesně odpovídat doménám architektury úřadu, viz následující |
)), EPM((Z angl. Enterprise Performance Management | )), EPM((Z angl. Enterprise Performance Management | ||
)) nebo QM((Z angl. Quality Management | )) nebo QM((Z angl. Quality Management | ||
Řádek 57: | Řádek 57: | ||
===== Domény obsahu architektur ===== | ===== Domény obsahu architektur ===== | ||
- | Zaměření a obsah národních architektur v jednotlivých zemích se vzájemně liší a časem se mění. Pro Národní architekturu VS ČR je navrženo již od počátku zahrnout do rámce NAR následující architektonické domény, viz také Obrázek | + | Zaměření a obsah národních architektur v jednotlivých zemích se vzájemně liší a časem se mění. Pro Národní architekturu VS ČR je navrženo již od počátku zahrnout do rámce NAR následující architektonické domény, viz také následující |
Horizontální (hlavní, klíčové((Angl. „Core“ | Horizontální (hlavní, klíčové((Angl. „Core“ | ||
Řádek 89: | Řádek 89: | ||
- | Barevnost rozvržení domén NA VS ČR, viz Obrázek | + | Barevnost rozvržení domén NA VS ČR, viz předchozí |
- | **Tabulka definice barev prvků v doménách dle NAR** | + | **Tabulka((Tabulka - Definice barev prvků v doménách dle NAR, zdroj: MV ČR podle (The Open Group, 2017))) |
- | ^Doména | + | ^Doména |
- | | | |Červená (R) | + | | | |Červená (R) |
|Strategické směrování | |Strategické směrování | ||
|Výkonnost | |Výkonnost | ||
Řádek 105: | Řádek 105: | ||
|Implementační a\\ migrační | |Implementační a\\ migrační | ||
- | Tabulka - Definice barev prvků v doménách dle NAR, zdroj: MV ČR podle (The Open Group, 2017) | + | |
Ve vztahu k barvám motivační a strategické domény ArchiMate vzniká konflikt. Dočasně bude řešen tak, že prvky vertikálních (motivačních) domén si **ponechají barvy konceptů z jazyka ArchiMate**, | Ve vztahu k barvám motivační a strategické domény ArchiMate vzniká konflikt. Dočasně bude řešen tak, že prvky vertikálních (motivačních) domén si **ponechají barvy konceptů z jazyka ArchiMate**, | ||
- | Zvláštní pozici ve struktuře architektonických domén zaujímá tzv. Datová architektura. Pro TOGAF je jednou ze dvou rovnocenných složek architektury IS, ale jazyk ArchiMate ji vůbec nezná (specificky ji neformuluje). Stejně tak vize čtyřvrstvé architektury eGovernmentu s datovou architekturou nepracuje. Ve shodě se všemi těmito předpoklady metodika NAR datovou architekturu většinou považuje za implicitní součást architektury IS, ve vybraných případech ji zdůrazňuje samostatně, | + | Zvláštní pozici ve struktuře architektonických domén zaujímá tzv. Datová architektura. Pro TOGAF je jednou ze dvou rovnocenných složek architektury IS, ale jazyk ArchiMate ji vůbec nezná (specificky ji neformuluje). Stejně tak vize čtyřvrstvé architektury eGovernmentu s datovou architekturou nepracuje. Ve shodě se všemi těmito předpoklady metodika NAR datovou architekturu většinou považuje za implicitní součást architektury IS, ve vybraných případech ji zdůrazňuje samostatně, |
- | Světle červená oblast | + | Světle červená oblast |
===== Architektury podle míry obecnosti a závaznosti ===== | ===== Architektury podle míry obecnosti a závaznosti ===== | ||
Řádek 132: | Řádek 132: | ||
* **Individuální modely** (IM) – nejdůležitější modely v úložišti úřadu, tj. vlastní modely vyjadřující koncepce rozvoje jednotlivých organizací VS, vytvořené s metodickou podporou NAR, podle povinných referenčních informací z hlediska formy i obsahu a v souladu s Národním architektonickým plánem (NAP) a jeho harmonogramem. | * **Individuální modely** (IM) – nejdůležitější modely v úložišti úřadu, tj. vlastní modely vyjadřující koncepce rozvoje jednotlivých organizací VS, vytvořené s metodickou podporou NAR, podle povinných referenčních informací z hlediska formy i obsahu a v souladu s Národním architektonickým plánem (NAP) a jeho harmonogramem. | ||
- | Všechny tři podoby a míry referencovatelnosti architektur jsou platné napříč všemi vrstvami pyramidy struktury i všemi doménami NA VS ČR, jak upozorňují obě ikony vpravo v každém řádku schématu, viz Obrázek | + | Všechny tři podoby a míry referencovatelnosti architektur jsou platné napříč všemi vrstvami pyramidy struktury i všemi doménami NA VS ČR, jak upozorňují obě ikony vpravo v každém řádku schématu, viz následující |
{{ : | {{ : | ||
Řádek 138: | Řádek 138: | ||
Výše uvedenou strukturu modelů doplňují ještě tzv. modely modelování - **metamodely** a pro akceleraci zavedení EA velmi žádané **praktické příklady: | Výše uvedenou strukturu modelů doplňují ještě tzv. modely modelování - **metamodely** a pro akceleraci zavedení EA velmi žádané **praktické příklady: | ||
- | * **Metamodel a slovník pojmů – definiční modely (modely modelů)** přináší tato metodika a předpokládáme, | + | * **Metamodel a slovník pojmů – definiční modely (modely modelů)** přináší tato metodika a předpokládáme, |
* **Zobecněné příklady** – s postupem úspěšných pilotních projektů bude přibývat modelů a diagramů tak kvalitních, | * **Zobecněné příklady** – s postupem úspěšných pilotních projektů bude přibývat modelů a diagramů tak kvalitních, | ||
Řádek 209: | Řádek 209: | ||
* Kontext architektury na straně typových klientů a partnerů při dodávce veřejné služby. | * Kontext architektury na straně typových klientů a partnerů při dodávce veřejné služby. | ||
- | Vybrané základní kontexty pro běžný úřad graficky znázorňuje Obrázek | + | Vybrané základní kontexty pro běžný úřad graficky znázorňuje |
Pro OVS v roli ohlašovatele agendy v přenesené působnosti jsou důležité kontexty architektur všech jednotlivých nebo typových úřadů, na něž svou působnost přenáší. To se projeví v jeho tzv. rozšířených modelech (ROZS). | Pro OVS v roli ohlašovatele agendy v přenesené působnosti jsou důležité kontexty architektur všech jednotlivých nebo typových úřadů, na něž svou působnost přenáší. To se projeví v jeho tzv. rozšířených modelech (ROZS). | ||
Řádek 216: | Řádek 216: | ||
{{ : | {{ : | ||
- | |||
- | ====== Proces tvorby architektur ====== | ||
- | |||
- | Poté, co předchozí kapitoly definovaly **Co?**, tedy v jaké organizaci a jaké součásti architektury úřad modeluje, stanovuje tato kapitola **Jak?** přesně se u toho má **postupovat** v celém životním cyklu architektury. | ||
- | |||
- | Z dvojice disciplín 1) management architektury a 2) governance architektury se tato kapitola zaměřuje na procesy obou, ale struktury, orgány a vybrané funkce obou jsou v samostatné kapitole. | ||
- | |||
- | Pro proces tvorby architektur převzala metodika NA VS ČR cyklus z metodiky TOGAF ADM (The Open Group, 2018). Ten je rozdělen na fáze a ty dále na kroky, vysvětlené v popisu jednotlivých fází. V každé fázi je třeba vždy kontrolovat, | ||
- | |||
- | **Předběžná fáze** (**Preliminary Phase), která popisuje přípravu a zahájení činností potřebných pro promítnutí byznys potřeb do architektury, | ||
- | |||
- | **Fáze A: Architektonická vize (Architecture Vision) popisuje úvodní fázi architektonického cyklu. Zahrnuje definici rozsahu, poznání zájmových skupin, vytvoření architektonické vize a získání souhlasů k architektonickému záměru.** | ||
- | |||
- | **Fáze B: Byznys architektura (Business Architecture) popisuje vývoj architektury podnikání, | ||
- | |||
- | **Fáze C: Architektura IS (Information Systems Architectures) popisuje postup vývoje architektury IS, zahrnující aplikační a datovou architekturu.** | ||
- | |||
- | **Fáze D: Technologická architektura (Technology Architecture) popisuje vývoj architektury IT technologické infrastruktury.** | ||
- | |||
- | **Fáze E: Příležitosti a řešení (Opportunities & Solutions)** provede počáteční plánování implementace a identifikaci prostředků dodávky architektonických změn, definovaných v předchozích fázích. | ||
- | |||
- | **Fáze F: Plánování přechodu (Migration Planning)** představuje detailní plánování potřebných implementačních kroků. | ||
- | |||
- | **Fáze G: Kontrola (řízení) implementace (Implementation Governance)** představuje architektonický dohled nad průběhem implementace. | ||
- | |||
- | **Fáze H: Řízení architektonických změn (Architecture Change Management) ustavuje procedury pro řízení změn architektury**. | ||
- | |||
- | **Správa požadavků (Requirements Management)** představuje vazbu procesů řízení IT požadavků a procesů řízení změn architektury. Fáze Správy (architektonických) požadavků je průběžná. Výstupy jedné fáze mohou (nebo dokonce mají) být upraveny fázemi následujícími. | ||
- | |||
- | {{ : | ||
- | |||
- | |||
- | ADM je postaveno na iteraci mezi jednotlivými procesy. Cílem těchto iterací je vybudovat optimální architekturu. Každá iterace je uvozena rozhodnutím o tom, co by mělo být pokryto daným architektonickým angažmá, jaká úroveň detailu je požadována a v jakém časovém výhledu by se mělo dojít k cílové architektuře (výsledku iterace). Pochopitelně je zároveň specifikováno, | ||
- | |||
- | {{ : | ||
- | |||
- | |||
- | ===== Přizpůsobení cyklu ADM pro NA VS ČR a pro jednotlivá angažmá ===== | ||
- | |||
- | Metodika TOGAF ADM předpokládá, | ||
- | |||
- | Před zahájením každé dílčí architektonické práce v úřadu je třeba znovu provést níže uvedená rozhodnutí a nastavit parametry tohoto angažmá. | ||
- | |||
- | ==== Nastavení rozsahu architektonického angažmá ==== | ||
- | |||
- | Metodika ADM je iterativní proces, s iteracemi mezi fázemi i uvnitř každé fáze. Pro každou iteraci v ADM, pro každé jednotlivé nové architektonické zadání (angažmá) v úřadu/ podniku musí být předem, v **Požadavku na architektonickou práci**((Angl. orig.: „Request for architecture work“. | ||
- | )), viz vzor ve Znalostní databázi, stanoveno (The Open Group, 2018): | ||
- | |||
- | * šířka pokrytí úřadu/ | ||
- | * požadovaná míra (hloubka) modelovaného detailu (EA nebo SA, asi nikoli SD) a (L0-přehled/ | ||
- | * časový horizont cílové architektury (např. typicky 1 rok a 5 let) | ||
- | * modelované domény (motivační a BADT((Z angl. pojmů: Business, Application, | ||
- | * architektonické vstupy, ať již to jsou výsledky předchozích fází nebo předchozích cyklů v úřadu nebo architektonické materiály odkudkoli, třeba referenční modely z OHA MV nebo ze světa. | ||
- | |||
- | Nad rámec standardu TOGAF stanovuje tato metodika NA VS ČR, aby již v předstihu před zahájením angažmá byly v Požadavku na architektonickou práci specifikovány: | ||
- | |||
- | * Základní zainteresovaní (stakeholders) vedle sponzora, který se k nim řadí automaticky, | ||
- | |||
- | Definitivní a závaznou specifikaci výstupů přinese vždy až schválené tzv. **Zadání pro architektonickou práci**((Angl. orig.: „Statement of architecture work“. | ||
- | )), které je odpovědí týmu architektury úřadu na Požadavek na architektonickou práci a skutečným zadáním následujícího projektu tvorby architektury. | ||
- | |||
- | ==== Rozhodnutí o šířce rozsahu ==== | ||
- | |||
- | Primárně se jedná o rozhodnutí, | ||
- | )), SPOL((Architektura úřadu společně se všemi podřízenými organizacemi | ||
- | )) nebo ROZS((Architektura rozšířeného řetězce dodávky veřejné služby | ||
- | )). | ||
- | |||
- | Při každém architektonickém zadání pro individuální modely uvnitř úřadu (enterprise) je třeba rozhodnout, zda se bude jednat o celostní, strategickou architekturu nebo segmentovou či dokonce pouze schopnostní architekturu. | ||
- | |||
- | Vždy je ale důležité respektovat zásadu, že i jakkoli dílčí architektura se modeluje s vědomím plného architektonického kontextu úřadu. S prvními dílčími angažmá je nutné vytvořit i základní přehledové diagramy (mapy) jednotlivých vrstev architektury celého úřadu, jinak není možné plnohodnotné architektonické rozhodování. | ||
- | |||
- | ==== Rozhodnutí o hloubce obsahu ==== | ||
- | |||
- | Pro modely v rámci NA VS ČR platí, nebude-li v Požadavku na architektonickou práci specificky odůvodněno jinak, že pro každé architektonické angažmá dle rozsahu v předchozím bodu se modeluje tzv. architektura podniku/ | ||
- | |||
- | Podle potřeby ze zadání angažmá je možno základní diagramy modelu doplnit přehledovými-L0 a detailními L2 diagramy. | ||
- | |||
- | Pouze pro v architektuře úřadu identifikované **vybrané příležitosti** **pro změny** nebo pro potřeby **zpětné dokumentace existujících řešení** mohou následně v dalším architektonickém cyklu (se samostatně specifikovaným zadáním) vznikat **architektury řešení** úřadu, s úrovní podrobnosti „**Solution Architecture**“. Ty u změn určených k realizaci odpovídají na otázku: „Jak to má fungovat (uvnitř - funkce a vně - služby)? | ||
- | |||
- | Konkrétní **návrh konstrukce** a výrobního postupu řešení „**Solution Design“** se již v zodpovědnosti útvarů architektury úřadu nikdy netvoří. Výjimkou jsou situace, kdy povinný vzor (pattern) musí z důvodů stanovených OHA sahat až na úroveň detailního vzoru designu řešení. Pak musejí architekti úřadů být schopni prokázat, že i na této úrovni byl povinný vzor dodržen a musí se zabývat návrhem nebo kontrolou (při návrhu ze strany dodavatele) designu řešení ve spojení s tímto vzorem. | ||
- | |||
- | ==== Rozhodnutí o časovém horizontu architektury ==== | ||
- | |||
- | Při každém architektonickém angažmá je třeba rozhodnout, v jakém časovém horizontu (za jak dlouho) se má nacházet cílová navrhovaná architektura. Délku požadovaného horizontu na jedné straně prodlužuje požadavek dlouhodobé stability návrhu, na druhé straně ji zkracuje přirozená neschopnost predikovat cokoli na dobu delší cca tří let (zejména pak v IT oblasti). | ||
- | |||
- | Skutečná délka časového horizontu architektonického angažmá vyplývá z potřeby zvládnout splnit požadavky zadavatele (manažerského sponzora změny). Přirozeně se ve VS horizont odvozuje od politicko-hospodářských milníků, ty představují tzv. **horizont pevný** (absolutní)**.** Pro aktuální NA VS ČR je v souladu s evropskými i národními strategickými dokumenty takovým absolutním pevným horizontem **rok 2020,** následně rok **2023** (5 let IK ČR) a rok **2030.** | ||
- | |||
- | Vedle toho je třeba, aby architektura úřadu vždy přinášela dostatečný informační předstih a podklad pro rozhodování. Proto tato metodika stanovuje, že jako další milník cílové architektury se musí používat **horizont klouzavý** (relativní), | ||
- | |||
- | Realizace architektur se děje po krocích, odpovídajících rozvojovým programům a projektům. Každý z nich po úspěšném završení posouvá stávající stav do nejbližšího projektovaného budoucího stavu architektury. Takovým časovým řezům architektur se říká **přechodové (stavy) architektury.** Vzhledem k přetrvávajícímu ročnímu řídícímu (a rozpočtovému) cyklu ve VS ČR a k omezené míře předvídatelnosti věcí budoucích, je stanoveno, že cesta k cílovému horizontu architektury úřadu (2020, 2023, 2030 nebo 5 let) musí být povinně rozdělena přinejmenším do přechodových architektur odpovídajících **1. a 2. roku** jejich realizace. Vedle toho musí být možné prezentovat z architektonického modelu v úložišti úřadu (nebo posléze v centrálním národním úložišti) projektovanou přechodovou architekturu úřadu ke každému **milníku dokončení realizačního projektu** či programu. | ||
- | |||
- | Pro všechny architektury úřadu/ | ||
- | |||
- | ==== Rozhodnutí o doménách v architektonickém angažmá ==== | ||
- | |||
- | Pro modely architektury pro jednotlivá architektonická angažmá v úřadech se v rámci koncepce NA VS ČR předpokládá, | ||
- | |||
- | Ne vždy budou úřady disponovat dostatečným časem, schopnostmi, | ||
- | |||
- | Příklad: Je-li zadáním sponzora navrhnout, které technologické platformové komponenty mohou být přesunuty do dvou cílových virtualizovaných datových center kraje a které dokonce do jednoho z NDC (eGC), pak IT technologická vrstva a komunikační vrstva musí být úplné, ale aplikační vrstva stačí jenom naznačena a datová, byznys, motivační a výkonnostní vrstva nemusí být modelována vůbec, protože se jako součást zadání angažmá předpokládá, | ||
- | |||
- | ==== Rozhodnutí o použitých vstupech ==== | ||
- | |||
- | Tato metodika ve svých aktualizacích stanovuje postupně narůstající sadu povinných a doporučených akcelerátorů (vzorů, taxonomií a referenčních modelů, návodů, příkladů). Ty podle míry závaznosti musí nebo mohou být použity ve všech odpovídajících angažmá. | ||
- | |||
- | Pokud je možnost volby nebo pro dané angažmá odpovídající akcelerátory koncepce ještě nepřináší, | ||
- | |||
- | Obdobně to platí i pro již existující architektonické artefakty. V každém zadání angažmá by mělo být stanoveno, na jaké dřívější architektonické artefakty a výstupy má navázat, zpřesnit je nebo nahradit. | ||
- | |||
- | ==== Rozhodnutí o volbě hledisek podle zainteresovaných ==== | ||
- | |||
- | Již před zahájením architektonického angažmá musí být v Požadavku na architektonickou práci identifikovány klíčové zájmové skupiny((Angl. Stakeholders | ||
- | )), jejich požadavky a potřeby a architektonické artefakty (pohledy na model), jimiž je možné tyto potřeby naplnit, pokud to nevyplývá ze závazných podkladů pro některá angažmá, jako je například Žádost o stanovisko OHA nebo tvorba Informační koncepce OVS. | ||
- | |||
- | Zejména jde o to, že manažeři úřadu budou muset v souvislosti s architektonickým angažmá (na základě jeho výsledků) činit investiční rozhodnutí o realizaci změn a výstupy architektonické práce musí tato jejich rozhodování podpořit a usnadnit. | ||
- | |||
- | ===== Praktické příklady architektonických angažmá ===== | ||
- | |||
- | V této kapitole je vysvětleno, | ||
- | |||
- | * Návrh architektonické vize úřadu | ||
- | * Enterprise architektura projektu (PSA) | ||
- | * Podklady pro žádost o stanovisko OHA k ICT projektu | ||
- | * Aktualizace Informační koncepce orgánu veřejné správy, jako rozpracování a konkretizace Informační koncepce ČR (schválené vládou 3. 10. 2018 na základě novely zák. č. 365/2000 S.). | ||
- | * Architektura řešení (SA) | ||
- | |||
- | Více v následujících podkapitolách. | ||
- | |||
- | ==== Návrh architektonické vize úřadu ==== | ||
- | |||
- | Zde bude doplněn návod nebo odkaz na samostatný dokument. | ||
- | |||
- | ==== Enterprise architektura projektu (PSA) ==== | ||
- | |||
- | ==== Architektura pro žádost o stanovisko OHA k ICT projektu ==== | ||
- | |||
- | {{ : | ||
- | |||
- | Zde bude doplněn návod nebo odkaz na samostatný dokument. | ||
- | |||
- | ==== Architektura pro Informační koncepci OVS ==== | ||
- | |||
- | Zde bude doplněn návod nebo odkaz na samostatný dokument. | ||
- | |||
- | ===== Přizpůsobený obsah cyklu ADM pro NA VS ČR ===== | ||
- | |||
- | V této kapitole budou do níže uvedené struktury postupně doplňována a zde vysvětlována přizpůsobení, | ||
- | |||
- | Aktuálně jsou takto potřebám NA VS ČR přizpůsobeny formulář tzv. Požadavku na architektonickou práci, část přípravné fáze a Architektonické principy, jako součást a nástroj fáze A cyklu. Ostatní části této kapitoly zatím nesou prázdnou strukturu dle originálního TOGAF ADM. | ||
- | |||
- | ==== Předběžná fáze ==== | ||
- | |||
- | === Cíle === | ||
- | |||
- | Cílem této fáze je vykonat všechny přípravné aktivity potřebné pro zahájení jakékoli architektonické práce v úřadu. Proto se tato fáze obvykle provádí pouze jednou, na počátku budování architektonické schopnosti úřadu, případě při zásadních změnách podmínek pro architektonickou práci. | ||
- | |||
- | Přípravná fáze má tyto hlavní cíle: | ||
- | |||
- | - **Určit požadovanou architektonickou schopnost (dovednost) úřadu**: | ||
- | |||
- | * Ověřit organizační kontext pro budování enterprise architektury úřadu. | ||
- | * Identifikovat a určit rozsah organizací úřadu, zapojených do tvorby architektury. | ||
- | * Identifikovat už zavedené manažerské a řídící rámce, metody a procesy, které se prolínají s architektonickou schopností. | ||
- | * Stanovit cílovou architektonickou zralost. | ||
- | |||
- | < | ||
- | < | ||
- | |||
- | * Definovat a zřídit organizační model enterprise architektury. | ||
- | * Definovat a zřídit procesy a zdroje potřebné pro správu a řízení enterprise architektury. | ||
- | * Vybrat a implementovat nástroje pro podporu architektonické schopnosti. | ||
- | * Definovat architektonické principy. | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | // | ||
- | |||
- | Zde bude doplněn návod nebo odkaz na samostatný dokument. | ||
- | |||
- | // | ||
- | |||
- | Po přípravě organizace a vybudování její schopnosti vytvářet architekturu přichází první architektonický úkol, tzv. angažmá, například sestavit architektonické podklady pro vyplnění žádosti o stanovisko OHA. Zahájení takových prací musí předcházet nalezení zadavatele (sponzora) a obdržení tzv. Požadavku na architektonickou práci architektonickým týmem. Více o Požadavku na architektonickou práci a o odpovědi na něj, tzv. Zadání pro architektonickou práci, v kapitole 4.1.1 a po ní následujících. | ||
- | |||
- | ==== Fáze A – Architektonická vize ==== | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Fáze architektonické vize zahrnuje definování rozsahu architektury, | ||
- | ))) a vytvoření a schválení architektonické vize pro následující architektonický cyklus. Fáze A: Architektonická vize má tyto hlavní cíle: | ||
- | |||
- | - **Vytvořit vysokoúrovňovou vizi** schopností a hodnot, které budou dodány jako výsledek následně navrhované enterprise architektury úřadu. | ||
- | - **Získat schválené Zadání architektonické práce (ZAP)**, které definuje rozsah a přístup, který bude použit pro realizaci projektu architektury k rozpracování a naplnění architektonické vize. | ||
- | |||
- | Fáze začíná přijetím Požadavku na architektonickou práci (PAP) architektonickou kanceláří úřadu od sponzorující (požadující) organizace, oddělení. | ||
- | |||
- | Pro architektonickou práci AK úřadu budou využity veškeré dostupné referenční materiály, primárně poskytnuté OHA jako součást NAR a NAP, následně další zkušenosti a nejlepší praxe. | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | // | ||
- | |||
- | Architektonické principy jsou z cílů rozvoje eGovernmentu odvozená po široké diskusi odsouhlasená pravidla, která slouží primárně k tomu, aby byla plně dodržena při návrzích cílové architektury veřejné správy (a jejích informačních systémů), které tak největší měrou naplní reformní cíle strategie veřejné správy. | ||
- | |||
- | Rozsah uplatnění principů je stejný jako rozsah povinnosti modelovat architekturu úřadu, tj. s postupnými dalšími etapami zavádění Národní architektury VS ČR se rozšiřuje. | ||
- | |||
- | Pro účely NA VS ČR rozlišujeme tři kategorie principů, lišící se způsobem vlivu na návrh architektury: | ||
- | |||
- | * Celkové((V originální specifikaci tzv. Enterprise principles, nebo také jinde Corporate principles.)) principy – tedy principy, které ovlivňují reformní a investiční rozhodování a chování úřadu/ | ||
- | * Architektonické principy – které určují, jaký má být správný obsah navrhované cílové architektury ve všech jejích doménách (byznys – procesní, aplikační, | ||
- | * Metodické principy – které stanovují základní pravidla postupu tvorby a užití architektury, | ||
- | |||
- | Principy jsou určeny pro architekty úřadu (enterprise), | ||
- | |||
- | * sada principů poskytuje informační základnu managementu úřadů pro rozhodování v oblastech eGovernmentu a řízení informatiky | ||
- | * jako kritéria pro rozhodování a hodnocení architektur řešení a výběru produktů | ||
- | * jako kritéria pro posuzování shody cílové architektury úřadu s požadavky a pro posuzování shody jednotlivých projektů | ||
- | * jako pomůcka při posuzování obojího – stávajících systémů i variant cílové architektury | ||
- | * zdůvodnění principů přináší vazbu mezi cíli, požadovaným stavem veřejné správy a nezbytnými architektonickými aktivitami | ||
- | * důsledky principů přinášejí výčet očekávaných změn, které se musí odehrát pro naplnění principů. Tento výčet může sloužit pro kontrolu, zda předložené projekty svým architektonickým obsahem a plánovanými aktivitami dostatečně vyhovují stanoveným principům. | ||
- | |||
- | Aktuální katalog principů Národní architektury VS ČR (a aktuálního Národního architektonického plánu NAP) byl zveřejněn jako součást vládou schválené Informační koncepce ČR, pod označeními P1 až P17. Tyto architektonické principy byly zařazeny také do formuláře žádosti o stanovisko OHA a výčet dopadů těchto principů, společně s podpůrnými kontrolními otázkami k nim, bude sloužit jako kontrolní seznam kritérií (Check-list) pro hodnocení shody předkládaných IT projektů s IKČR a NAP. | ||
- | |||
- | Vedle toho mají úřady možnost hledat a formulovat další principy, které jsou specifické pro jimi stanovené vlastní strategické cíle. Cílem předběžné fáze procesu tvorby architektury v každém jednotlivém architektonickém angažmá je tedy nalézt všechny současné platné a relevantní architektonické principy, pokud již existují, tj. byly formulovány - v IKČR nebo v IK OVS. Pokud nejsou dostatečné nebo aktuální, budou muset být v rámci fáze vytvořeny a aktualizovány. | ||
- | |||
- | Zdrojem informací pro architektonické principy v úřadu bývají vedle IKČR a IK OVS: | ||
- | |||
- | * Strategie (politika) úřadu | ||
- | * IT Strategie | ||
- | * Směrnice | ||
- | * Postupy | ||
- | |||
- | Všechny principy jsou vzájemně provázány, | ||
- | |||
- | Více o architektonických principech v kapitole 7.2.2. | ||
- | |||
- | // | ||
- | |||
- | Zde bude doplněn popis nebo odkaz na samostatný dokument// | ||
- | |||
- | //**Návrh architektonické vize**// | ||
- | |||
- | Zde bude doplněn popis nebo odkaz na samostatný dokument. | ||
- | |||
- | // | ||
- | |||
- | Zde bude doplněn popis nebo odkaz na samostatný dokument. | ||
- | |||
- | ==== Fáze B – Byznys architektura výkonu a provozu veřejné správy ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAR. | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Cílem této fáze je vývoj byznys architektury služeb veřejné správy, jako rozpracování změn plynoucích ze schválené architektonické vize úřadu. | ||
- | |||
- | Fáze B – byznys architektura má tyto hlavní cíle: | ||
- | |||
- | - **Vytvořit cílovou byznys architekturu, | ||
- | - **Definovat kandidáty na balíčky práce (projekty) pro architektonickou roadmapu,** identifikované na základě rozdílů mezi výchozí (současnou) a cílovou byznys architekturou. | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | ==== Fáze C – Architektura IS (aplikační a datová) ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAR. | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Cílem této fáze je vývoj architektury informačních systémů v úřadu veřejné správy, zahrnující vývoje jejich datové a aplikační architektury. | ||
- | |||
- | Fáze C – architektura IS má tyto hlavní cíle: | ||
- | |||
- | - **Vytvořit cílovou architekturu informačních systémů (dat a aplikací), | ||
- | - **Definovat kandidáty balíčky práce (projekty) pro architektonickou roadmapu,** identifikované na základě rozdílů mezi výchozí (současnou) a cílovou architekturou IS (datovou a aplikační). | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | ==== Fáze D – Technologická architektura výpočetní a komunikační infrastruktury ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAP. | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Cílem této fáze je vývoj technologické architektury, | ||
- | |||
- | Fáze D – technologická architektura má tyto hlavní cíle: | ||
- | |||
- | - **Vytvořit cílovou technologickou architekturu**, | ||
- | - **Definovat kandidáty balíčky práce (projekty) pro architektonickou roadmapu,** identifikované na základě rozdílů mezi výchozí (současnou) a cílovou technologickou architekturou. | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | ==== Fáze E – Příležitosti a řešení ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAP. | ||
- | |||
- | * **Cíle fáze** | ||
- | |||
- | Cílem této fáze je identifikovat projekty, programy nebo portfolia, která efektivně dodají cílovou architekturu definovanou v předcházejících fázích. | ||
- | |||
- | Fáze E - Příležitosti a řešení má tyto hlavní cíle: | ||
- | |||
- | - **Generovat počáteční (iniciální) úplnou verzi architektonické roadmapy, založené na rozdílových analýzách a kandidátských komponentách pro architektonickou roadmapu, definovaných ve fázích B, C a D.** | ||
- | - Určit zda je potřebný postupný přístup po krocích a pokud ano, pak definovat tzv. **přechodné architektury**, | ||
- | |||
- | === Vstupy, kroky postupu a výstupy | ||
- | |||
- | ==== Fáze F – Plánování migrace ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAP. | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Cílem této fáze je definovat migrační plány, jak se dostat ze současné do cílové architektury. | ||
- | |||
- | Fáze F – plánování migrace má tyto hlavní cíle: | ||
- | |||
- | - Finalizovat **architektonickou roadmapu** a **implementační a migrační plán.** | ||
- | - Zabezpečit, | ||
- | - Zabezpečit, | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | ==== Fáze G – Dohled na zavedení plánované architektury ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAP. | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Cílem této fáze je architektonický dohled nad implementací architektury. | ||
- | |||
- | Fáze G – Dohled na zavedení má tyto hlavní cíle: | ||
- | |||
- | - **Zabezpečit soulad** výstupů implementačních projektů **s cílovou architekturou** (architektonický dohled). | ||
- | - Vykonat příslušné **governance** **architektury** pro řešení a jakékoli implementací řízené architektonické požadavky na změny. | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | ==== Fáze H – Řízení architektonických změn ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAP. | ||
- | |||
- | === Cíle fáze === | ||
- | |||
- | Cílem této fáze je zavedení procedur pro řízení změn nové architektury. | ||
- | |||
- | Fáze H – Řízení změn má tyto hlavní cíle: | ||
- | |||
- | - **Zajistit, aby architektonický cyklus byl udržovaný.** | ||
- | - **Zajistit, aby rámec dohledu architektury byl naplňován.** | ||
- | - **Zajistit, aby EA schopnost rostla v souladu s aktuálními požadavky.** | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === | ||
- | |||
- | // | ||
- | |||
- | ==== Proces správy architektonických požadavků ==== | ||
- | |||
- | Zatím nepřizpůsobeno pro NAP. | ||
- | |||
- | === Cíl správy požadavků === | ||
- | |||
- | Cílem této fáze je zavedení procesu řízení architektonických požadavků v průběhu vývoje architektury. Fáze: správa požadavků má tyto hlavní cíle: | ||
- | |||
- | - Zajistit, aby **proces správy požadavků byl podporovaný** a uplatňovaný pro všechny relevantní fáze metodiky vývoje architektury. | ||
- | - **Řídit architektonické požadavky** identifikované v průběhu architektonického cyklu anebo fáze. | ||
- | - **Zajistit, aby relevantní architektonické požadavky byly dostupné** pro každou fázi metodiky vývoje architektury. | ||
- | |||
- | === Vstupy, kroky postupu a výstupy === |