Rozdíly

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

Odkaz na výstup diff

Následující verze
Předchozí verze
nar-dokument:struktura_modelovanych_architektur [2019/10/04 08:19] – vytvořeno Tomáš Šedivecnar_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 je vysvětleno „**Čí architektura se modeluje“**, co je to z pohledu architektury úřad (enterprise), segment a schopnost, pak dále je v této kapitole vysvětleno „**Co se pro tyto jednotky modeluje a proč“**.+Jestliže v kapitole [[nar_dokument:modelujici_urady_a_jejich_architektury|Modelující úřady a jejich architektury]] je vysvětleno „**Čí architektura se modeluje“**, co je to z pohledu architektury úřad (enterprise), segment a schopnost, pak dále je v této kapitole vysvětleno „**Co se pro tyto jednotky modeluje a proč“**.
  
 ===== 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 realizace dílčích prvků řešení+    * Design řešení a realizace dílčích prvků řešení
  
 {{ :nar-dokument:image8.png?600 | Model vrstev architektur podniku/úřadu podle rozdílné míry detailu obsahu, zdroj: (Hrabě, 2014)}} {{ :nar-dokument:image8.png?600 | Model vrstev architektur podniku/úřadu podle rozdílné míry detailu obsahu, zdroj: (Hrabě, 2014)}}
Řá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á, segmentová nebo schopnostní) je třetí vrstvou architektury úřadu, představující těžiště obsahu popisu architektury v jednotlivých tradičních (červeně orámované) i v méně obvyklých doménách, viz Obrázek 5.+**Průřezová nebo doménová architektura úřadu** (strategická, segmentová nebo schopnostní) je třetí vrstvou architektury úřadu, představující těžiště obsahu popisu architektury v jednotlivých tradičních (červeně orámované) i v méně obvyklých doménách, viz následující Obrázek.
  
 Poznání je v této vrstvě zaměřeno výhradně na existenciální aspekty všech prvků architektury úřadu a jejich vazeb (že existují, jak jsou staré, odkud pocházejí, kdo za jejich existenci odpovídá, jak dlouho budou ještě k dispozici apod.). Poznání je v této vrstvě zaměřeno výhradně na existenciální aspekty všech prvků architektury úřadu a jejich vazeb (že existují, jak jsou staré, odkud pocházejí, kdo za jejich existenci odpovídá, jak dlouho budou ještě k dispozici apod.).
Řádek 40: Řádek 40:
 {{ :nar-dokument:image9.png?600 | Pyramidální model architektur úřadu / podniku podle účelu a míry podrobnosti informací, zdroj: (Hrabě, 2014)}} {{ :nar-dokument:image9.png?600 | Pyramidální model architektur úřadu / podniku podle účelu a míry podrobnosti informací, zdroj: (Hrabě, 2014)}}
  
-Tento obrázek představuje kombinaci šedého pyramidálního modelu a barevného doménového modelu, představeného společně s podrobnějším popisem domén architektury úřadu v následující kapitole 3.2.+Tento obrázek představuje kombinaci šedého pyramidálního modelu a barevného doménového modelu, představeného společně s podrobnějším popisem domén architektury úřadu v následující části.
  
 **Architektura řešení**((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, majících něco společného, třeba jsou řešeny aplikacemi na jedné platformě. Do vrstvy architektury řešení patří i doménové architektury, které jsou svojí mírou detailu popisu dotaženy až na odpovídající úroveň podrobnosti. Často takto vzniknou postupně, složením příspěvků jednotlivých projektů řešení. Architektury řešení jsou obvykle dílčí, pokrývající část řešených problémů a změn organizace (program, projekt), které odpovídají jednotlivým dílčím potřebám a příležitostem ke změně. Architektury řešení jdou často napříč více architektonickými doménami, ale mohou být i uvnitř jediné z nich. Jsou typicky platné pro dílčí část segmentu nebo pro schopnost veřejné správy a již nemusí být a nebývají celo-úřadové. Nebo pokrývají skupinu prvků architektury, majících něco společného, třeba jsou řešeny aplikacemi na jedné platformě. Do vrstvy architektury řešení patří i doménové architektury, které jsou svojí mírou detailu popisu dotaženy až na odpovídající úroveň podrobnosti. Často takto vzniknou postupně, složením příspěvků jednotlivých projektů řešení.
  
-Domény architektur řešení mohou přesně odpovídat doménám architektury úřadu, viz Obrázek 5, kde modře orámované domény představují detailní rozpracování tradičních domén TOGAF. Domény architektur řešení v řadě případů budou odpovídat dílčím manažerským disciplínám, jako je BPM((Z angl. Business Process Management (nebo jenom Modelling)+Domény architektur řešení mohou přesně odpovídat doménám architektury úřadu, viz následující Obrázek, kde modře orámované domény představují detailní rozpracování tradičních domén TOGAF. Domény architektur řešení v řadě případů budou odpovídat dílčím manažerským disciplínám, jako je BPM((Z angl. Business Process Management (nebo jenom Modelling)
 )), 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 6.+Zaměření a obsah národních architektur v jednotlivých zemích se vzájemně liší a časem se mění. Pro Národní architekturu VS ČR je navrženo již od počátku zahrnout do rámce NAR následující architektonické domény, viz také následující Obrázek.
  
 Horizontální (hlavní, klíčové((Angl. „Core“ Horizontální (hlavní, klíčové((Angl. „Core“
Řádek 89: Řádek 89:
  
  
-Barevnost rozvržení domén NA VS ČR, viz Obrázek 6, není náhodná. Barvy tradičních vodorovných domén (vrstev) dle TOGAF/ArchiMate přebírají barevnost vrstev jazyka ArchiMate (Lankhorst, et al., 2009), barvy vertikálních domén jsou převzaty ze schématu referenčních modelů GEA-NZ 3.2 (Deleu, 2014).+Barevnost rozvržení domén NA VS ČR, viz předchozí Obrázek, není náhodná. Barvy tradičních vodorovných domén (vrstev) dle TOGAF/ArchiMate přebírají barevnost vrstev jazyka ArchiMate (Lankhorst, et al., 2009), barvy vertikálních domén jsou převzaty ze schématu referenčních modelů GEA-NZ 3.2 (Deleu, 2014).
  
-**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))) definice barev prvků v doménách dle NAR**
  
-^Doména                          ^Název barvy   ^Definice barvy (RGB)^                  +^Doména                          ^Název barvy   ^Definice barvy (RGB)^^^ 
-                               |              |Červená (R)         |Zelená (G)|Modrá (B)|+| |              |Červená (R)         |Zelená (G)|Modrá (B)|
 |Strategické směrování           |Fialová       |**204**             |204       |255      | |Strategické směrování           |Fialová       |**204**             |204       |255      |
 |Výkonnost                       |Oranžová      |**255**             |212       |175      | |Výkonnost                       |Oranžová      |**255**             |212       |175      |
Řádek 105: Řádek 105:
 |Implementační a\\ migrační      |Světle červená|**255**             |224       |224      | |Implementační a\\ migrační      |Světle červená|**255**             |224       |224      |
  
-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**, jimiž nebo jejichž specializacemi jsou vyjádřeny. Tak, jak poroste význam a rozsah konceptů zejména v bezpečnostní a standardizační doméně, lze předpokládat, že se jejich barevnost vyřeší i na úrovni světových standardů, jinak bude vyřešena v dalších verzích NAR. Ve vztahu k barvám motivační a strategické domény ArchiMate vzniká konflikt. Dočasně bude řešen tak, že prvky vertikálních (motivačních) domén si **ponechají barvy konceptů z jazyka ArchiMate**, jimiž nebo jejichž specializacemi jsou vyjádřeny. Tak, jak poroste význam a rozsah konceptů zejména v bezpečnostní a standardizační doméně, lze předpokládat, že se jejich barevnost vyřeší i na úrovni světových standardů, jinak bude vyřešena v dalších verzích NAR.
  
-Zvláštní pozici ve struktuře architektonických domén zaujímá tzv. Datová architektura. Pro TOGAF je jednou ze dvou rovnocenných složek architektury IS, ale jazyk ArchiMate ji vůbec nezná (specificky ji neformuluje). Stejně tak vize čtyřvrstvé architektury eGovernmentu s datovou architekturou nepracuje. Ve shodě se všemi těmito předpoklady metodika NAR datovou architekturu většinou považuje za implicitní součást architektury IS, ve vybraných případech ji zdůrazňuje samostatně, viz například kapitola 5.3.2. a Obrázek 6.+Zvláštní pozici ve struktuře architektonických domén zaujímá tzv. Datová architektura. Pro TOGAF je jednou ze dvou rovnocenných složek architektury IS, ale jazyk ArchiMate ji vůbec nezná (specificky ji neformuluje). Stejně tak vize čtyřvrstvé architektury eGovernmentu s datovou architekturou nepracuje. Ve shodě se všemi těmito předpoklady metodika NAR datovou architekturu většinou považuje za implicitní součást architektury IS, ve vybraných případech ji zdůrazňuje samostatně, viz například [[nar_dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu výstupu architektur]] a předcházející Obrázek.
  
-Světle červená oblast v Obrázek 6 představuje tzv. Doménu implementace a migrace, odpovídající Implementačnímu a migračnímu rozšíření ArchiMate, a umožňující vizualizovat také balíčky práce, projekty, programy a jimi dosahované změny stavů architektury (přechodné a cílové). I zde můžeme hovořit o doméně modelu organizace, zaměřené na dynamické, projektově orientované objekty řízení úřadu, resp. jeho změn.+Světle červená oblast v předcházejícím Obrázeku představuje tzv. Doménu implementace a migrace, odpovídající Implementačnímu a migračnímu rozšíření ArchiMate, a umožňující vizualizovat také balíčky práce, projekty, programy a jimi dosahované změny stavů architektury (přechodné a cílové). I zde můžeme hovořit o doméně modelu organizace, zaměřené na dynamické, projektově orientované objekty řízení úřadu, resp. jeho změn.
  
 ===== 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 7.+Všechny tři podoby a míry referencovatelnosti architektur jsou platné napříč všemi vrstvami pyramidy struktury i všemi doménami NA VS ČR, jak upozorňují obě ikony vpravo v každém řádku schématu, viz následující Obrázek.
  
 {{ :nar-dokument:image11.png?600 | Členění obsahu NA VS ČR z hlediska referencovatelnosti, zdroj: (Hrabě, 2014), aktualizace MV}} {{ :nar-dokument:image11.png?600 | Členění obsahu NA VS ČR z hlediska referencovatelnosti, zdroj: (Hrabě, 2014), aktualizace MV}}
Řá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, že v úložišti modelů každého úřadu budou uchovávány pro informaci o metodice NAR. Ten ale předpokládá, že vedle závazného metamodelu, pro celostátní výměnu modelů, bude možné si v jednotlivých úřadech metamodely rozšiřovat tzv. specializací, viz například kapitola 5.2.3.+  * **Metamodel a slovník pojmů – definiční modely (modely modelů)** přináší tato metodika a předpokládáme, že v úložišti modelů každého úřadu budou uchovávány pro informaci o metodice NAR. Ten ale předpokládá, že vedle závazného metamodelu, pro celostátní výměnu modelů, bude možné si v jednotlivých úřadech metamodely rozšiřovat tzv. specializací, viz například [[nar_dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].
   * **Zobecněné příklady** – s postupem úspěšných pilotních projektů bude přibývat modelů a diagramů tak kvalitních, že budou sloužit jako příklad. Svým charakterem jsou to individuální modely, ale mnohdy budou zobecněné, anonymizované, takže už u nich nebude patrný konkrétní modelovaný úřad. Tyto modely nejsou pro nikoho závazné, slouží pro inspiraci jako nositelé praktické zkušenosti. Takové se budou šířit jak centrálně směrem od OHA, tak komunitně mezi úřady navzájem.   * **Zobecněné příklady** – s postupem úspěšných pilotních projektů bude přibývat modelů a diagramů tak kvalitních, že budou sloužit jako příklad. Svým charakterem jsou to individuální modely, ale mnohdy budou zobecněné, anonymizované, takže už u nich nebude patrný konkrétní modelovaný úřad. Tyto modely nejsou pro nikoho závazné, slouží pro inspiraci jako nositelé praktické zkušenosti. Takové se budou šířit jak centrálně směrem od OHA, tak komunitně mezi úřady navzájem.
  
Řá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 8.+Vybrané základní kontexty pro běžný úřad graficky znázorňuje následující Obrázek.
  
 Pro OVS v roli ohlašovatele agendy v přenesené působnosti jsou důležité kontexty architektur všech jednotlivých nebo typových úřadů, na něž svou působnost přenáší. To se projeví v jeho tzv. rozšířených modelech (ROZS). Pro 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:
  
 {{ :nar-dokument:image12.png?600 | Širší kontexty modelů architektury úřadu, zdroj: (OHA MV ČR, 2016).}} {{ :nar-dokument:image12.png?600 | Širší kontexty modelů architektury úřadu, zdroj: (OHA MV ČR, 2016).}}
- 
-====== Proces tvorby architektur ====== 
- 
-Poté, co předchozí kapitoly definovaly **Co?**, tedy v jaké organizaci a jaké součásti architektury úřad modeluje, stanovuje tato kapitola **Jak?** přesně se u toho má **postupovat** v celém životním cyklu architektury. 
- 
-Z dvojice disciplín 1) management architektury a 2) governance architektury se tato kapitola zaměřuje na procesy obou, ale struktury, orgány a vybrané funkce obou jsou v samostatné kapitole. 
- 
-Pro proces tvorby architektur převzala metodika NA VS ČR cyklus z metodiky TOGAF ADM (The Open Group, 2018). Ten je rozdělen na fáze a ty dále na kroky, vysvětlené v popisu jednotlivých fází. V každé fázi je třeba vždy kontrolovat, zda výstupy a výsledky fáze odpovídají očekávání celého angažmá a metodickým požadavkům na danou fázi. V cyklu metodiky ADM se nacházejí následující fáze: 
- 
-**Předběžná fáze** (**Preliminary Phase), která popisuje přípravu a zahájení činností potřebných pro promítnutí byznys potřeb do architektury, včetně přizpůsobení architektonického rámce a definice principů a okrajových podmínek.** 
- 
-**Fáze A: Architektonická vize (Architecture Vision) popisuje úvodní fázi architektonického cyklu. Zahrnuje definici rozsahu, poznání zájmových skupin, vytvoření architektonické vize a získání souhlasů k architektonickému záměru.** 
- 
-**Fáze B: Byznys architektura (Business Architecture) popisuje vývoj architektury podnikání, poslání organizace na podporu dosažení stanovené vize.** 
- 
-**Fáze C: Architektura IS (Information Systems Architectures) popisuje postup vývoje architektury IS, zahrnující aplikační a datovou architekturu.** 
- 
-**Fáze D: Technologická architektura (Technology Architecture) popisuje vývoj architektury IT technologické infrastruktury.** 
- 
-**Fáze E: Příležitosti a řešení (Opportunities & Solutions)** provede počáteční plánování implementace a identifikaci prostředků dodávky architektonických změn, definovaných v předchozích fázích. 
- 
-**Fáze F: Plánování přechodu (Migration Planning)** představuje detailní plánování potřebných implementačních kroků. 
- 
-**Fáze G: Kontrola (řízení) implementace (Implementation Governance)** představuje architektonický dohled nad průběhem implementace. 
- 
-**Fáze H: Řízení architektonických změn (Architecture Change Management) ustavuje procedury pro řízení změn architektury**. 
- 
-**Správa požadavků (Requirements Management)** představuje vazbu procesů řízení IT požadavků a procesů řízení změn architektury. Fáze Správy (architektonických) požadavků je průběžná. Výstupy jedné fáze mohou (nebo dokonce mají) být upraveny fázemi následujícími. 
- 
-{{ :nar-dokument:image13.png?600 | Přehled fází tvorby architektury dle TOGAF ADM, zdroj: (The Open Group, 2018), překlad MV}} 
- 
- 
-ADM je postaveno na iteraci mezi jednotlivými procesy. Cílem těchto iterací je vybudovat optimální architekturu. Každá iterace je uvozena rozhodnutím o tom, co by mělo být pokryto daným architektonickým angažmá, jaká úroveň detailu je požadována a v jakém časovém výhledu by se mělo dojít k cílové architektuře (výsledku iterace). Pochopitelně je zároveň specifikováno, jakých architektonických standardů (komponent) bude využito a za jakých omezujících podmínek. 
- 
-{{ :nar-dokument:image14.png?600 | Seskupení fází cyklu ADM vývoje architektur, podle (The Open Group, 2018) návrh MV}} 
- 
- 
-===== Přizpůsobení cyklu ADM pro NA VS ČR a pro jednotlivá angažmá ===== 
- 
-Metodika TOGAF ADM předpokládá, že bude upravována na míru organizace, což platí i pro českou veřejnou správu. Úprava ADM pro NA VS ČR je popsána níže. 
- 
-Před zahájením každé dílčí architektonické práce v úřadu je třeba znovu provést níže uvedená rozhodnutí a nastavit parametry tohoto angažmá. 
- 
-==== 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/podniku architektonickým angažmá, jak z pohledu částí úřadu (enterprise) - STR/SGM/SCH, tak z hlediska kontextu architektury v korporaci a řetězci dodávky veřejných služeb - VLST/SPOL/ROZS 
-  * požadovaná míra (hloubka) modelovaného detailu (EA nebo SA, asi nikoli SD) a (L0-přehled/L1-základ/L2-detail) 
-  * časový horizont cílové architektury (např. typicky 1 rok a 5 let) 
-  * modelované domény (motivační a BADT((Z angl. pojmů: Business, Application, Data, Technology.))) a jejich koncepty 
-  * architektonické vstupy, ať již to jsou výsledky předchozích fází nebo předchozích cyklů v úřadu nebo architektonické materiály odkudkoli, třeba referenční modely z OHA MV nebo ze světa. 
- 
-Nad rámec standardu TOGAF stanovuje tato metodika NA VS ČR, aby již v předstihu před zahájením angažmá byly v Požadavku na architektonickou práci specifikovány: 
- 
-  * Základní zainteresovaní (stakeholders) vedle sponzora, který se k nim řadí automaticky, jejich potřeby a základní architektonické artefakty a výstupy, kterými mohou být naplněna jejich očekávání. 
- 
-Definitivní a závaznou specifikaci výstupů přinese vždy až schválené tzv. **Zadání pro architektonickou prá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í, zda na požadovaný záměr zadavatele odpovídá architektura uvnitř úřadu/ podniku (enterprise) nebo jeho části (segmentu, schopnosti), anebo společně s externími partnery, dodavateli a úřady bude modelován tzv. rozšířený úřad/podnik. Je tedy podstatné, zda je v daném architektonickém angažmá bude jednat o VLST((Vlastní architektura úřadu 
-)), 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/úřadu. Tedy úroveň podrobnosti „**Enterprise Architecture**“, modelující **všechny výskyty** schopností, procesů, aplikací, platforem apod. dle metamodelu NA VS ČR, které se v daném rozsahu organizace (celku, segmentu nebo dílčí schopnosti) aktuálně nacházejí nebo cílově mají nacházet. Tedy z hlediska podrobnosti diagramu je standardně očekávána tzv. úroveň **L1 – Základní.** U každého inventarizovaného nebo projektovaného objektu se ale model ptá pouze po jeho existenci a po několika s existencí zásadně spojených atributech, například zda je aplikační komponenta zakoupena nebo naprogramována, od koho, kdy vznikla a kdy bez podpory zanikne, případně zda je součástí strategické infrastruktury státu atp. 
- 
-Podle potřeby ze zadání angažmá je možno základní diagramy modelu doplnit přehledovými-L0 a detailními L2 diagramy. 
- 
-Pouze pro v architektuře úřadu identifikované **vybrané příležitosti** **pro změny** nebo pro potřeby **zpětné dokumentace existujících řešení** mohou následně v dalším architektonickém cyklu (se samostatně specifikovaným zadáním) vznikat **architektury řešení** úřadu, s úrovní podrobnosti „**Solution Architecture**“. Ty u změn určených k realizaci odpovídají na otázku: „Jak to má fungovat (uvnitř - funkce a vně - služby)?“ a představují v podobě úplných funkčních i ne-funkčních specifikací, katalogů služeb a dalších detailních architektonických artefaktů zásadní podklady pro výběr a uzavření smlouvy s interním nebo externím dodavatelem realizace změn (vč. implementace informačních systémů). 
- 
-Konkrétní **návrh konstrukce** a výrobního postupu řešení „**Solution Design“** se již v zodpovědnosti útvarů architektury úřadu nikdy netvoří. Výjimkou jsou situace, kdy povinný vzor (pattern) musí z důvodů stanovených OHA sahat až na úroveň detailního vzoru designu řešení. Pak musejí architekti úřadů být schopni prokázat, že i na této úrovni byl povinný vzor dodržen a musí se zabývat návrhem nebo kontrolou (při návrhu ze strany dodavatele) designu řešení ve spojení s tímto vzorem. 
- 
-==== 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í), stanovený na dobu **5 let** od předložení architektury ke schválení. To platí zejména pro celkovou architekturu úřadu vytvořenou pro účely aktualizace jeho Informační koncepce OVS, která je taktéž na 5 let. 
- 
-Realizace architektur se děje po krocích, odpovídajících rozvojovým programům a projektům. Každý z nich po úspěšném završení posouvá stávající stav do nejbližšího projektovaného budoucího stavu architektury. Takovým časovým řezům architektur se říká **přechodové (stavy) architektury.** Vzhledem k přetrvávajícímu ročnímu řídícímu (a rozpočtovému) cyklu ve VS ČR a k omezené míře předvídatelnosti věcí budoucích, je stanoveno, že cesta k cílovému horizontu architektury úřadu (2020, 2023, 2030 nebo 5 let) musí být povinně rozdělena přinejmenším do přechodových architektur odpovídajících **1. a 2. roku** jejich realizace. Vedle toho musí být možné prezentovat z architektonického modelu v úložišti úřadu (nebo posléze v centrálním národním úložišti) projektovanou přechodovou architekturu úřadu ke každému **milníku dokončení realizačního projektu** či programu. 
- 
-Pro všechny architektury úřadu/podniku v rámci NA VS ČR platí, že budou s týmž klouzavým (relativním) horizontem (5 let, odpovídajících **rozpočtovému výhledu**) aktualizovány **na úrovni strategické architektury úřadu** pravidelně **každý rok** tak, aby identifikované (a upřesněné) transformační projekty na následující rok mohly sloužit jako kvalifikovaný podklad pro vyjednávání o struktuře a výši **rozpočtu.** 
- 
-==== 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 kapitola 3.2. To platí bez výjimek přinejmenším pro pravidelně aktualizovanou celkovou strategickou architekturu úřadu. 
- 
-Ne vždy budou úřady disponovat dostatečným časem, schopnostmi, kapacitami či prostředky na to, aby navrhly (nebo si nechaly navrhnout) všechny dílčí architektury ve všech doménách. Proto pro segmentové a schopnostní architektury, spojované s dílčími reformními nebo IT změnami není nutné navrhovat všechny domény architektur úřadu, pokud to není potřebné pro naplnění požadavků sponzora, zadavatele architektonického angažmá. Nenavrhované domény je však vždy třeba mít alespoň okrajově na zřeteli. 
- 
-Příklad: Je-li zadáním sponzora navrhnout, které technologické platformové komponenty mohou být přesunuty do dvou cílových virtualizovaných datových center kraje a které dokonce do jednoho z NDC (eGC), pak IT technologická vrstva a komunikační vrstva musí být úplné, ale aplikační vrstva stačí jenom naznačena a datová, byznys, motivační a výkonnostní vrstva nemusí být modelována vůbec, protože se jako součást zadání angažmá předpokládá, že aplikační služby a data vůči byznys a vyšším vrstvám se změnou technologických vrstev nesmí změnit. 
- 
-==== 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áší, je potřebné, aby zadání každého angažmá bylo zpřesněno i odkazem na pro něj stanovené vstupy. 
- 
-Obdobně to platí i pro již existující architektonické artefakty. V každém zadání angažmá by mělo být stanoveno, na jaké dřívější architektonické artefakty a výstupy má navázat, zpřesnit je nebo nahradit. 
- 
-==== 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, které fáze metodiky ADM se uplatní, v jakém rozsahu a jak přizpůsobené v konkrétních situacích, kde se již po úřadu vyžaduje, aby doložil své znalosti o architektuře úřadu a dílčí architektuře odpovídající připravovanému řešení. Aktuálně jsou to tyto typy architektonických angažmá: 
- 
-  * Návrh architektonické vize úřadu 
-  * Enterprise architektura projektu (PSA) 
-  * Podklady pro žádost o stanovisko OHA k ICT projektu 
-  * Aktualizace Informační koncepce orgánu veřejné správy, jako rozpracování a konkretizace Informační koncepce ČR (schválené vládou 3. 10. 2018 na základě novely zák. č. 365/2000 S.). 
-  * Architektura řešení (SA) 
- 
-Více v následujících 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 ==== 
- 
-{{ :nar-dokument:image15.png?600 | Podpora žádosti o stanovisko OHA fázemi TOGAF ADM, zdroj MV s využitím (The Open Group, 2018)}} 
- 
-Zde bude doplněn návod nebo odkaz na samostatný dokument. 
- 
-==== 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í, rozšíření a úpravy cyklu tvorby, údržby a užití NA, podle TOGAF ADM. 
- 
-Aktuálně jsou takto potřebám NA VS ČR přizpůsobeny formulář tzv. Požadavku na architektonickou práci, část přípravné fáze a Architektonické principy, jako součást a nástroj fáze A cyklu. Ostatní části 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. 
- 
-<HTML><ol start="2" style="list-style-type: decimal;"></HTML> 
-<HTML><li></HTML><HTML><p></HTML>**Vytvořit (zavést, ustavit) architektonickou schopnost (dovednost a kapacitu):**<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> 
- 
-  * Definovat a zřídit organizační model enterprise architektury. 
-  * Definovat a zřídit procesy a zdroje potřebné pro správu a řízení enterprise architektury. 
-  * Vybrat a implementovat nástroje pro podporu architektonické schopnosti. 
-  * Definovat architektonické principy. 
- 
-=== Vstupy, kroky postupu a výstupy === 
- 
-//**Stanovení architektonických principů**// 
- 
-Zde bude doplněn návod nebo odkaz na samostatný dokument. 
- 
-//**Požadavek na architektonickou práci (PAP)**// 
- 
-Po přípravě organizace a vybudování její schopnosti vytvářet architekturu přichází první architektonický úkol, tzv. angažmá, například sestavit architektonické podklady pro vyplnění žádosti o stanovisko OHA. Zahájení takových prací musí předcházet nalezení zadavatele (sponzora) a obdržení tzv. Požadavku na architektonickou práci architektonickým týmem. Více o Požadavku na architektonickou práci a o odpovědi na něj, tzv. Zadání pro architektonickou práci, v 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, identifikování zainteresovaných (zájmových skupin((Z angl. Stakeholders 
-))) 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**// 
- 
-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/podniku jako takového. 
-  * Architektonické principy – které určují, jaký má být správný obsah navrhované cílové architektury ve všech jejích doménách (byznys – procesní, aplikační, datové, IT technologické, infrastrukturní, bezpečnostní a posléze i výkonnostní). 
-  * Metodické principy – které stanovují základní pravidla postupu tvorby a užití architektury, podrobněji rozebíraná v celé koncepci NA VS ČR 
- 
-Principy jsou určeny pro architekty úřadu (enterprise), architekty řešení úřadu, manažery informatiky a všechny další vedoucí pracovníky úřadů, pro politickou reprezentaci i širokou veřejnost. Principy mají zejména následující použití: 
- 
-  * sada principů poskytuje informační základnu managementu úřadů pro rozhodování v oblastech eGovernmentu a řízení informatiky 
-  * jako kritéria pro rozhodování a hodnocení architektur řešení a výběru produktů 
-  * jako kritéria pro posuzování shody cílové architektury úřadu s požadavky a pro posuzování shody jednotlivých projektů 
-  * jako pomůcka při posuzování obojího – stávajících systémů i variant cílové architektury 
-  * zdůvodnění principů přináší vazbu mezi cíli, požadovaným stavem veřejné správy a nezbytnými architektonickými aktivitami 
-  * důsledky principů přinášejí výčet očekávaných změn, které se musí odehrát pro naplnění principů. Tento výčet může sloužit pro kontrolu, zda předložené projekty svým architektonickým obsahem a plánovanými aktivitami dostatečně vyhovují stanoveným principům. 
- 
-Aktuální katalog principů Národní architektury VS ČR (a aktuálního Národního architektonického plánu NAP) byl zveřejněn jako součást vládou schválené Informační koncepce ČR, pod označeními P1 až P17. Tyto architektonické principy byly zařazeny také do formuláře žádosti o stanovisko OHA a výčet dopadů těchto principů, společně s podpůrnými kontrolními otázkami k nim, bude sloužit jako kontrolní seznam kritérií (Check-list) pro hodnocení shody předkládaných IT projektů s IKČR a NAP. 
- 
-Vedle toho mají úřady možnost hledat a formulovat další principy, které jsou specifické pro jimi stanovené vlastní strategické cíle. Cílem předběžné fáze procesu tvorby architektury v každém jednotlivém architektonickém angažmá je tedy nalézt všechny současné platné a relevantní architektonické principy, pokud již existují, tj. byly formulovány - v IKČR nebo v IK OVS. Pokud nejsou dostatečné nebo aktuální, budou muset být v rámci fáze vytvořeny a aktualizovány. 
- 
-Zdrojem informací pro architektonické principy v úřadu bývají vedle IKČR a IK OVS: 
- 
-  * Strategie (politika) úřadu 
-  * IT Strategie 
-  * Směrnice 
-  * Postupy 
- 
-Všechny principy jsou vzájemně provázány, musí být uplatněny jako celá sada. Občas si jednotlivé principy konkurují a vytvářejí tvůrčí napětí (například mezi širokou dostupností a důvěryhodností údajů). Výsledná rozhodnutí musí vycházet z podrobného vysvětlení požadavků a musí být vyváženým kompromisem. 
- 
-Více o architektonických principech v kapitole 7.2.2. 
- 
-//**Analýza zainteresovaných**// 
- 
-Zde bude doplněn popis nebo odkaz na samostatný dokument//.// 
- 
-//**Návrh architektonické vize**// 
- 
-Zde bude doplněn popis nebo odkaz na samostatný dokument. 
- 
-//**Zadání pro architektonickou práci**// 
- 
-Zde bude doplněn popis nebo odkaz na samostatný dokument. 
- 
-==== 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,** která popisuje, jak budou dosaženy byznys cíle úřadu, formulované prostřednictvím potřeb, strategických iniciativ (politik)((V angličtině Goals)) a stanovených cílů (proveditelných úkolů). 
-  - **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í), která popisuje, jak IS umožní realizaci byznys architektury a architektonické vize**. 
-  - **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, která zahrnuje HW, SW a komunikační infrastrukturu. 
- 
-Fáze D – technologická architektura má tyto hlavní cíle: 
- 
-  - **Vytvořit cílovou technologickou architekturu**, která umožní realizaci logických a fyzických aplikačních a datových komponent a architektonické vize. 
-  - **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**, která zejména zajistí průběžnou dodávku byznys hodnoty. 
- 
-=== 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, aby **implementační a migrační plán byl koordinovaný s ostatními přístupy řízení a zavedení změn v organizaci**. 
-  - Zabezpečit, aby **byznys hodnota, cena realizace a případné přechodové architektury** byly pochopené klíčovými zainteresovanými. 
- 
-=== Vstupy, kroky postupu a výstupy === 
- 
-==== 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 === 
- 
-//**Požadavek na architektonickou práci**// 
- 
-==== 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 ===