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.

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.

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

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

Metodika ADM je iterativní proces, s iteracemi mezi fázemi i uvnitř každé fáze. Pro každou iteraci v ADM, pro každé jednotlivé nové architektonické zadání (angažmá) v úřadu/ podniku musí být předem, v Požadavku na architektonickou práci¹⁾, 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²⁾) 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³⁾, které je odpovědí týmu architektury úřadu na Požadavek na architektonickou práci a skutečným zadáním následujícího projektu tvorby architektury.

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

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

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

Pro modely v rámci NA VS ČR platí, nebude-li v Požadavku na architektonickou práci specificky odůvodněno jinak, že pro každé architektonické angažmá dle rozsahu v předchozím bodu se modeluje tzv. architektura podniku/úřadu. Tedy úroveň podrobnosti „Enterprise 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.

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í 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stanovení architektonických principů

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

Požadavek na architektonickou práci (PAP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Analýza zainteresovaných

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

Návrh architektonické vize

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

Zadání pro architektonickou práci

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

Zatím nepřizpůsobeno pro NAR.

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

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

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

Zatím nepřizpůsobeno pro NAR.

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

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

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

Zatím nepřizpůsobeno pro NAR.

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

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

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

Zatím nepřizpůsobeno pro NAR.

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

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

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

Zatím nepřizpůsobeno pro NAR.

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

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

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

Zatím nepřizpůsobeno pro NAP.

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

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

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

Zatím nepřizpůsobeno pro NAR.

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

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

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

Požadavek na architektonickou práci

Zatím nepřizpůsobeno pro NAR.

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

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