Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze
Předchozí verze
nar-dokument:proces_tvorby_architektur [2020/05/18 09:17] Tomáš Šedivecnar_dokument:proces_tvorby_architektur [2021/01/13 10:42] (aktuální) – ↷ Odkaz upraven z důvodu přesunutí Tomáš Šedivec
Řádek 7: Řádek 7:
 Pro proces tvorby architektur převzala metodika NA VS ČR cyklus z metodiky TOGAF ADM (The Open Group, 2018). Ten je rozdělen na fáze a ty dále na kroky, vysvětlené v popisu jednotlivých fází. V každé fázi je třeba vždy kontrolovat, zda výstupy a výsledky fáze odpovídají očekávání celého angažmá a metodickým požadavkům na danou fázi. V cyklu metodiky ADM se nacházejí následující fáze: Pro proces tvorby architektur převzala metodika NA VS ČR cyklus z metodiky TOGAF ADM (The Open Group, 2018). Ten je rozdělen na fáze a ty dále na kroky, vysvětlené v popisu jednotlivých fází. V každé fázi je třeba vždy kontrolovat, zda výstupy a výsledky fáze odpovídají očekávání celého angažmá a metodickým požadavkům na danou fázi. V cyklu metodiky ADM se nacházejí následující fáze:
  
-**Předběžná fáze** (**Preliminary Phase), která popisuje přípravu a zahájení činností potřebných pro promítnutí byznys potřeb do architektury, včetně přizpůsobení architektonického rámce a definice principů a okrajových podmínek.**+**Předběžná fáze (Preliminary Phase)**, která popisuje přípravu a zahájení činností potřebných pro promítnutí byznys potřeb do architektury, včetně přizpůsobení architektonického rámce a definice principů a okrajových podmínek.
  
-**Fáze A: Architektonická vize (Architecture Vision) popisuje úvodní fázi architektonického cyklu. Zahrnuje definici rozsahu, poznání zájmových skupin, vytvoření architektonické vize a získání souhlasů k architektonickému záměru.**+**Fáze A: Architektonická vize (Architecture Vision)** popisuje úvodní fázi architektonického cyklu. Zahrnuje definici rozsahu, poznání zájmových skupin, vytvoření architektonické vize a získání souhlasů k architektonickému záměru.
  
-**Fáze B: Byznys architektura (Business Architecture) popisuje vývoj architektury podnikání, poslání organizace na podporu dosažení stanovené vize.**+**Fáze B: Byznys architektura (Business Architecture)** popisuje vývoj architektury podnikání, poslání organizace na podporu dosažení stanovené vize.
  
-**Fáze C: Architektura IS (Information Systems Architectures) popisuje postup vývoje architektury IS, zahrnující aplikační a datovou architekturu.**+**Fáze 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 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 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.
Řádek 23: Řádek 23:
 **Fáze G: Kontrola (řízení) implementace (Implementation Governance)** představuje architektonický dohled nad průběhem implementace. **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**.+**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. **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.
Řádek 72: Řádek 72:
 ==== Rozhodnutí o hloubce obsahu ==== ==== 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/úřadu. Tedy úroveň podrobnosti „**Enterprise Architecture**“, modelující **všechny výskyty** schopností, procesů, aplikací, platforem apod. dle metamodelu NA VS ČR, které se v daném rozsahu organizace (celku, segmentu nebo dílčí schopnosti) aktuálně nacházejí nebo cílově mají nacházet. Tedy z hlediska podrobnosti diagramu je standardně očekávána tzv. úroveň **L1 – Základní.** U každého inventarizovaného nebo projektovaného objektu se ale model ptá pouze po jeho existenci a po několika s existencí zásadně spojených atributech, například zda je aplikační komponenta zakoupena nebo naprogramována, od koho, kdy vznikla a kdy bez podpory zanikne, případně zda je součástí strategické infrastruktury státu atp.+Pro modely v rámci NA VS ČR platí, nebude-li v Požadavku na architektonickou práci specificky odůvodněno jinak, že pro každé architektonické angažmá dle rozsahu v předchozím bodu se modeluje tzv. architektura podniku/úřadu. Tedy úroveň podrobnosti „**Enterprise architektury**“, modelující **všechny výskyty** schopností, procesů, aplikací, platforem apod. dle metamodelu NA VS ČR, které se v daném rozsahu organizace (celku, segmentu nebo dílčí schopnosti) aktuálně nacházejí nebo cílově mají nacházet. Tedy z hlediska podrobnosti diagramu je standardně očekávána tzv. úroveň **L1 – Základní.** U každého inventarizovaného nebo projektovaného objektu se ale model ptá pouze po jeho existenci a po několika s existencí zásadně spojených atributech, například zda je aplikační komponenta zakoupena nebo naprogramována, od koho, kdy vznikla a kdy bez podpory zanikne, případně zda je součástí strategické infrastruktury státu atp.
  
 Podle potřeby ze zadání angažmá je možno základní diagramy modelu doplnit přehledovými-L0 a detailními L2 diagramy. Podle potřeby ze zadání angažmá je možno základní diagramy modelu doplnit přehledovými-L0 a detailními L2 diagramy.
  
-Pouze pro v architektuře úřadu identifikované **vybrané příležitosti** **pro změny** nebo pro potřeby **zpětné dokumentace existujících řešení** mohou následně v dalším architektonickém cyklu (se samostatně specifikovaným zadáním) vznikat **architektury řešení** úřadu, s úrovní podrobnosti „**Solution Architecture**“. Ty u změn určených k realizaci odpovídají na otázku: „Jak to má fungovat (uvnitř - funkce a vně - služby)?“ a představují v podobě úplných funkčních i ne-funkčních specifikací, katalogů služeb a dalších detailních architektonických artefaktů zásadní podklady pro výběr a uzavření smlouvy s interním nebo externím dodavatelem realizace změn (vč. implementace informačních systémů).+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 „**Architektury řešení**“. Ty u změn určených k realizaci odpovídají na otázku: „Jak to má fungovat (uvnitř - funkce a vně - služby)?“ a představují v podobě úplných funkčních i ne-funkčních specifikací, katalogů služeb a dalších detailních architektonických artefaktů zásadní podklady pro výběr a uzavření smlouvy s interním nebo externím dodavatelem realizace změn (vč. implementace informačních systémů).
  
-Konkrétní **návrh konstrukce** a výrobního postupu řešení „**Solution Design“** se již v zodpovědnosti útvarů architektury úřadu nikdy netvoří. Výjimkou jsou situace, kdy povinný vzor (pattern) musí z důvodů stanovených OHA sahat až na úroveň detailního vzoru designu řešení. Pak musejí architekti úřadů být schopni prokázat, že i na této úrovni byl povinný vzor dodržen a musí se zabývat návrhem nebo kontrolou (při návrhu ze strany dodavatele) designu řešení ve spojení s tímto vzorem.+Konkrétní **Design řešení** 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 ==== ==== Rozhodnutí o časovém horizontu architektury ====
Řádek 94: Řádek 94:
 ==== Rozhodnutí o doménách v architektonickém angažmá ==== ==== 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á, že budou **vždy** obsahovat popis architektury (modely a artefakty) **ve všech** jejích **doménách,** viz [[nar-dokument:struktura_modelovanych_architektur|Struktura modelovaných architektur]]. To platí bez výjimek přinejmenším pro pravidelně aktualizovanou celkovou strategickou architekturu úřadu.+Pro modely architektury pro jednotlivá architektonická angažmá v úřadech se v rámci koncepce NA VS ČR předpokládá, že budou **vždy** obsahovat popis architektury (modely a artefakty) **ve všech** jejích **doménách,** viz [[nar_dokument:struktura_modelovanych_architektur|Struktura modelovaných architektur]]. To platí bez výjimek přinejmenším pro pravidelně aktualizovanou celkovou strategickou architekturu úřadu.
  
 Ne vždy budou úřady disponovat dostatečným časem, schopnostmi, kapacitami či prostředky na to, aby navrhly (nebo si nechaly navrhnout) všechny dílčí architektury ve všech doménách. Proto pro segmentové a schopnostní architektury, spojované s dílčími reformními nebo IT změnami není nutné navrhovat všechny domény architektur úřadu, pokud to není potřebné pro naplnění požadavků sponzora, zadavatele architektonického angažmá. Nenavrhované domény je však vždy třeba mít alespoň okrajově na zřeteli. Ne vždy budou úřady disponovat dostatečným časem, schopnostmi, kapacitami či prostředky na to, aby navrhly (nebo si nechaly navrhnout) všechny dílčí architektury ve všech doménách. Proto pro segmentové a schopnostní architektury, spojované s dílčími reformními nebo IT změnami není nutné navrhovat všechny domény architektur úřadu, pokud to není potřebné pro naplnění požadavků sponzora, zadavatele architektonického angažmá. Nenavrhované domény je však vždy třeba mít alespoň okrajově na zřeteli.
Řádek 179: Řádek 179:
 //**Požadavek na architektonickou práci (PAP)**// //**Požadavek na architektonickou práci (PAP)**//
  
-Po přípravě organizace a vybudování její schopnosti vytvářet architekturu přichází první architektonický úkol, tzv. angažmá, například sestavit architektonické podklady pro vyplnění žádosti o stanovisko OHA. Zahájení takových prací musí předcházet nalezení zadavatele (sponzora) a obdržení tzv. Požadavku na architektonickou práci architektonickým týmem. Více o Požadavku na architektonickou práci a o odpovědi na něj, tzv. Zadání pro architektonickou práci, v [[nar-dokument:proces_tvorby_architektur|Proces tvorby architektur]] a po ní následujících.+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 [[nar_dokument:proces_tvorby_architektur|Proces tvorby architektur]] a po ní následujících.
  
 ==== Fáze A – Architektonická vize ==== ==== Fáze A – Architektonická vize ====
Řádek 231: Řádek 231:
 Všechny principy jsou vzájemně provázány, musí být uplatněny jako celá sada. Občas si jednotlivé principy konkurují a vytvářejí tvůrčí napětí (například mezi širokou dostupností a důvěryhodností údajů). Výsledná rozhodnutí musí vycházet z podrobného vysvětlení požadavků a musí být vyváženým kompromisem. Všechny principy jsou vzájemně provázány, musí být uplatněny jako celá sada. Občas si jednotlivé principy konkurují a vytvářejí tvůrčí napětí (například mezi širokou dostupností a důvěryhodností údajů). Výsledná rozhodnutí musí vycházet z podrobného vysvětlení požadavků a musí být vyváženým kompromisem.
  
-Více o architektonických principech v [[nar-dokument:pokyny_a_techniky_pro_tvorbu_architektury|Pokyny a techniky pro tvorbu architektury]].+Více o architektonických principech v [[nar_dokument:pokyny_a_techniky_pro_tvorbu_architektury|Pokyny a techniky pro tvorbu architektury]].
  
 //**Analýza zainteresovaných**// //**Analýza zainteresovaných**//
Řádek 277: Řádek 277:
 ==== Fáze D – Technologická architektura výpočetní a komunikační infrastruktury ==== ==== Fáze D – Technologická architektura výpočetní a komunikační infrastruktury ====
  
-Zatím nepřizpůsobeno pro NAP.+Zatím nepřizpůsobeno pro NAR.
  
 === Cíle fáze === === Cíle fáze ===
Řádek 292: Řádek 292:
 ==== Fáze E – Příležitosti a řešení ==== ==== Fáze E – Příležitosti a řešení ====
  
-Zatím nepřizpůsobeno pro NAP.+Zatím nepřizpůsobeno pro NAR.
  
-  * **Cíle fáze**+=== 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. 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.
Řádek 307: Řádek 307:
 ==== Fáze F – Plánování migrace ==== ==== Fáze F – Plánování migrace ====
  
-Zatím nepřizpůsobeno pro NAP.+Zatím nepřizpůsobeno pro NAR.
  
 === Cíle fáze === === Cíle fáze ===
Řádek 338: Řádek 338:
 ==== Fáze H – Řízení architektonických změn  ==== ==== Fáze H – Řízení architektonických změn  ====
  
-Zatím nepřizpůsobeno pro NAP.+Zatím nepřizpůsobeno pro NAR.
  
 === Cíle fáze === === Cíle fáze ===
Řádek 356: Řádek 356:
 ==== Proces správy architektonických požadavků ==== ==== Proces správy architektonických požadavků ====
  
-Zatím nepřizpůsobeno pro NAP.+Zatím nepřizpůsobeno pro NAR.
  
 === Cíl správy požadavků === === Cíl správy požadavků ===