Jestliže v kapitole 2 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č“.

Vycházíme z faktu, že úřady a podniky ve veřejné správě architekturu, tj. strukturu prvků, jejich vazeb a chování, mají, jde jen o to ji poznat, popsat, porozumět jí a komunikovat ji. To se v různých částech úřadu, pro různé účely děje do různé podrobnosti a různou formou.

Pokud v této metodice pracujeme zejména s popisem architektury pro účel řízení návrhu a implementace změn v úřadu, pak jednotlivé úrovně popisu architektury tvoří pyramidu podle jejich míry poznání následujícím způsobem, viz také Obrázek 4:

• Vrstvy (enterprise) architektury úřadu
  • Architektonická vize
  • Celostní modely architektur úřadu/podniku – mapa schopností, ontologie a slovník pojmů
  • Segmentové, schopnostní a doménové modely architektur úřadu/podniku
• Vrstva architektur řešení v úřadu
  • Doménové a projektové průřezové architektury řešení
• Vrstva návrhu konkrétních řešení
  • Design a konstrukce realizace dílčích prvků řešení

Architektonická vize je vrstvou agregovaných informací, sloužících k předání základních poselství o poznání organizace, jejího stávajícího a zejména častěji cílového stavu. Vrstva nemusí souviset přímo s jednotlivými poznanými dílčími prvky organizace. Modely vize představují vizualizaci vybraných odpovědí na strategické otázky Kam? a Proč? se organizace vydává.

Druhá a třetí vrstva spolu s vizí představují podnikovou architekturu, architekturu úřadu (EA). V těchto vrstvách je zachycena inventarizace, vizualizace a porozumění tomu, co všechno se v organizaci nachází a v jakých vazbách. Modely těchto vrstev představují odpovědi na otázky Co? a Jaké prvky? organizaci tvoří. Při popisu budoucího stavu tyto vrstvy představují informaci o tom Co? a Proč? strukturu systému organizace do budoucna tvořit má.

Celostní architektura úřadu je nositelem celostního pohledu na úřad / podnik. Představuje výčet všech typů objektů (konceptů), které se v organizaci vyskytují, ať již jsou dále v strategických, segmentových a schopnostních architekturách modelovány či nikoli. Tento přehled typů objektů je základem pro slovník pojmů, spojovaných s architekturou, tedy se strukturou a chováním organizace.

Současně je tato struktura organizace vyjádřena jejím úplným meta-modelem, nebo jinak zvaným ontologickým modelem. Tato vrstva enterprise ontologie¹⁾ a pojmového slovníku by také mohla být označena jako meta-architektura úřadu. Z tohoto ontologického modelu organizace jsou postupně vybírány objekty (například proces, služba aplikace, organizační jednotka atp.), které jsou předmětem inventarizace současného stavu a plánování stavu budoucího.

Součástí celostní vrstvy je i rozdělení organizace na menší jednotky, jejichž výstupy společně tvoří chování, život organizace. Hovoříme o tzv. mapě schopností²⁾, poskytující úplný přehled o organizaci v jednom diagramu. Seskupení schopností v mapě současně ukazuje logiku a význam tzv. segmentů činnosti organizace, např. segmentů typů veřejných služeb. Zde každá jednotlivá schopnost představuje nejmenší jednotku organizace, jejíž vnitřní architektura nás na této úrovni plánování nezajímá, ale kterou můžeme v nižších, podrobnějších vrstvách dále zkoumat a poznávat.

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.

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

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.

Architektura řešení³⁾ již není považována za součást tzv. (enterprise) architektury úřadu, ale do velké míry na ni navazuje. Architektura řešení představuje vrstvu architektury vysvětlující, jak prvky tvořící organizaci fungují, jaká je jejich vnitřní výstavba, jak společně reagují na konkrétní potřebu (řeší ji). Její modely tedy představují vizualizaci odpovědí zejména na otázku: Jak funguje?, respektive: Jak to má fungovat?. Architektury řešení musí vyhovovat architektonickým principům architektur úřadu / podniku z vyšších vrstev pyramidálního modelu.

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⁴⁾, EPM⁵⁾ nebo QM⁶⁾ a budou využívat odpovídající nástroje a notace.

Design řešení⁷⁾ představuje vrstvu architektury přinášející detailní poznání o tom, jak lze dílčí prvek architektury vytvořit, vyrobit, jak uvést do provozu jednotlivý konkrétní prvek architektury úřadu. Může jít o návrh změny pracovního postupu (proces), zadání programování SW komponenty, vzorec pro výpočet ukazatele výkonnosti apod. Modely designu řešení představují vizualizaci odpovědí na otázku Jak je to udělané?, respektive Jak to má být udělané?. Tyto konstrukční dokumenty sice již nepředstavují artefakty architektury, ale tvoří spolu s nimi jednotnou soustavu znalostí o úřadu/podniku a i ony by měly být vytvářeny v souladu s poznatky a povinnými náležitostmi vyšších vrstev architektur úřadu.

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.

Horizontální (hlavní, klíčové⁸⁾) domény architektur vyjadřují všechny základní prvky existence organizace, tj. její fungování a její zdroje (zde stále zaměřené převážně na IT zdroje). Tedy koncepty poskytující odpověď na otázku Co tvoří naši organizaci?:

• Byznys architektura – tedy architektura všech součástí výkonu veřejné správy a podpůrných provozních funkcí, zejména zaměřená na procesy, služby, organizaci, role a zodpovědnosti.
• Architektura informačních systémů, členěná na:
  • Informační (datovou) a
  • Aplikační architekturu
• Technologická architektura, pro potřeby VS ČR dělená dle čtyřvrstvé vize architektury na:
  • architekturu IT technologií, také zvanou platformovou a
  • architekturu komunikační infrastruktury

Vertikální domény motivační architektury, doplňují a protínají horizontální architektury a poskytují odpovědi na otázku Proč je naše organizace taková, jaká je?, respektive Proč by měla být jiná než je?:

• Architektura strategie a směrování, původně také zvaná jenom motivační architektura
• Architektura výkonnosti, měřící dosahování strategie i provozní efektivity
• Architektura rizik a bezpečnosti – postihující specifické bezpečnostní aspekty napříč doménami
• Architektura shody s pravidly, standardizace a dlouhodobé udržitelnosti

V tomto rozdělení je navrženo mimo jiné to, že do samostatné domény architektury strategie a směrování jsou z byznys architektury dle TOGAF přesunuty koncepty motivace. Z oblastí, které například TOGAF považuje za součást obsahu metamodelu obsahu (ACF⁹⁾), ale nemodeluje je jako architekturu, byly ve shodě s ArchiMate do domény architektury „Shody s pravidly¹⁰⁾“ převzaty některé negativně motivující (limitující) koncepty jako jsou omezení a předpoklady. V případě architektury pro VS ČR se zejména jedná o zákony formulující obsah tzv. agend. Následně jsou v téže doméně umístěny formulované (prohlášené) závazné standardy architektury. Třetí součástí jsou, u organizací, které se zabývají udržitelností (CSR¹¹⁾, TUR¹²⁾, MA21¹³⁾) pravidla kritéria udržitelnosti.

Tento návrh struktury domén architektonického rámce je pro NA VS ČR výhodný zejména proto, že jako kombinace dvou ve veřejných správách nejvíce užívaných standardů TOGAF a FEAF (v nejnovější modifikaci pro GEA-NZ 3.2) usnadňuje prvotní zavedení podnikové architektury do praxe veřejné správy ČR a podpoří její první cíl, kterým je efektivní správa ICT VS. Následně je toto rozvržení domén otevřené do budoucna pro rozvoj dle potřeb užití NA VS ČR stále větší měrou pro vlastní reformu VS.

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

Tabulka definice barev prvků v doménách dle NAR

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.

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.

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.

Prací centrálních i místní architektů veřejné správy bude vznikat celá řada modelů různého významu při řízení úřadů. Některé modely slouží jako definiční nebo podpůrné při tvorbě architektur úřadů, jiné jsou výsledkem vlastní práce úřadů a představují jejich unikátní soubor poznání. Aktuálně rozlišujeme tyto kategorie modelů:

• Metamodel

• Referenční modely
• Společné (sdílené) modely, včetně modelů povinných vzorů
• Zobecněné (anonymizované) příklady
• Individuální modely

Některé výstupy architektury, například standardy protokolů komunikace IS nebo standardy porovnávání výkonnosti procesů VS, budou závazné napříč celou veřejnou správou, jiné budou závazné například jenom pro výkon státní správy, ale už nikoli pro územní samosprávy. Některé části obsahu architektury nebudou závazné nikde a budou mít pouze popisný a doporučující charakter. Takové koncepci se v zahraničí říká „federativní architektura“ a povinnosti dané zákony jsou v ní dobře patrné.

Z hlediska obecnosti, jednoty a účelu jednotlivých modelů bude obsah architektury členěn na:

• Referenční modely (RM) - vyjadřující zobecnění nejlepších praxí aplikovaných na realitu české VS a klasifikační hierarchie jednotlivých domén na úrovni celého národního rámce. Na této úrovni se nevyskytují žádné konkrétní obsahy architektur (ani As-Is, ani To-Be). Tato vrstva je povinně referenční na meta-úrovni, tj. přináší povinné klasifikace a povinné formy vyjádření modelů. Zkráceně jde referenční klasifikaci a formu modelování.
• Společný (sdílený) obsah - modely zahrnující ty součásti architektonických modelů, které organizace na různých úrovních veřejné správy musí nebo mohou sdílet, nebo je musí implementovat identicky. Tato vrstva je povinně i dobrovolně referenční pro obsahy To-Be architektur a je prostředkem zajištění konzistence celkové To-Be architektury veřejné správy. Zkráceně jde o referenční obsah architektury.
• 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ýš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.
• 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.

Vyjádření změn architektur v průběhu času a sledování vývoje architektur od plánovaného stavu k jeho dosažení je obtížnou architektonickou úlohou, pojatou v TOGAF dvěma různými myšlenkovými koncepcemi a nepodporovanou přímo žádnou součástí specifikace ArchiMate.

TOGAF v metamodelu rozlišuje mezi tzv. Logickými a Fyzickými komponentami u aplikační a technologické architektury, ne tak již u byznys architektury nebo datové architektury. Logické komponenty jsou obecné, předpokládané, existující jenom nehmotně jako součást koncepce. Fyzické komponenty jsou konkrétními instancemi logických, mají svá jména, dodavatele, verze, měřitelné atributy apod.

Vedle toho doporučuje TOGAF dělit architektonické poznání do tzv. stavebních bloků, určených pro opakované využití v návrzích i v realitě. Zatímco architektonické stavební bloky (ABB¹⁴⁾) předepisují, jaký typ komponenty (nebo funkce, služby apod.) má být použit pro typový účel, pak stavební blok řešení (SBB¹⁵⁾) ukazuje, jak již je to konkrétně uděláno a co je možno znovu použít.

Za architektonický stavební blok (ABB) je možno označit primárně tzv. logickou komponentu, a za stavební blok (SBB) řešení tzv. fyzickou komponentu. Komplikovanější je to u konceptů (objektů), u nichž metamodel TOGAF fyzické/logické nerozlišuje.

V praxe české veřejné správy ukázala potřebu používat společně v modelech a diagramech architektury úřadu architektonické stavební bloky i stavební bloky řešení, a to i přesto, že to notace ArchiMate nepodporuje, pouze od verze 3.0 doporučuje své koncepty tomuto přístupu přizpůsobit tzv. specializací do stereotypů. Záměrem je dostat obojí do týchž diagramů, aby mohly být mezi sebou porovnávány jejich plánované a skutečně dosažené atributy.

Návrh metodiky NAR se tak v této části obrací k doporučením „Enterprise Continua“ dle TOGAF, zpočátku pro jeho vertikální členění na ABB a z nich plynoucí SBB, bez ambice klasifikovat zleva doprava podle míry obecnosti¹⁶⁾.

Doporučuje se pohlížet na ABB a SBB trojím pohledem a realizovat je v modelu třemi způsoby:

(1) pomocí stereotypů core objektů ArchiMate, zejména u konceptu aplikace, které jsou předmětem takovéto klasifikace,

(2) pomocí sady atributů těchto objektů, které jsou odlišné u ABB (obecnější) a u SBB (konkrétnější), přičemž jeden a týž objekt (instance konceptu) může nakonec nést obě takové sady (profily),

(3) prostřednictvím katalogu, seznamu, do něhož lze vyfiltrovat prvky, označené příznakem jako ABB nebo SBB a ukázat přehledně jejich atributy – tedy výpis z Enterprise Continua.

ABB velmi výrazně odpovídají v TOGAF uváděným „logickým aplikačním komponentám“, kdežto SBB se velmi shodují s „fyzickými aplikačními komponentami“. Podle TOGAF by v jednom modelu mohly být oboje, v ArchiMate to bez „zdvojení“, tj. specializace objektů metamodelu není možné.

Podle NAR v jednom modelu (nikoli jen v diagramu) ArchiMate musí být každá v realitě úřadu existující „věc“, například aplikační komponenta, uvedena jenom jednou, tj. není přípustné zachytit „box“ jak pro ABB, tak pro SBB v jednom modelu. Proto ABB rozdělíme na dvě kategorie: kandidátské ABB a generické ABB.

• Kandidátský ABB je předchůdcem, dočasným zástupcem cílového SBB v individuálním modelu v době, kdy ještě není znám dodavatel a jeho řešení. Představuje logickou komponentu, dokud není k dispozici fyzická. Proto může být součástí modelu individuální (ostré) architektury úřadu. V průběhu implementace se mu budou měnit statusy a nakonec se tento prvek ArchiMate stane SBB, ale ponese se si i předchozí profil ABB (bude možnost srovnání).
• Generický ABB je vzorem pro více implementací (SBB) a/nebo má být vizualizován i po jejich implementaci. Takový prvek modelu v ArchiMate může být modelován samostatným Boxem, ale výhradně v modelu referenční architektury, tj. v samostatném modelu (package). V žádné inventurní sestavě aplikačních komponent úřadu z EAM repozitory tak nebudou „vyjíždět“ oba, ABB i SBB. Nebude (nesmí) tak vznikat mylný dojem jiného počtu a struktury aplikací, než je skutečný.

V případě potřeby je možno vytvořit diagram, čerpající objekty z obou modelů současně, tj. z individuálního i referenčního, a tak i graficky vyjádřit potřebné srovnání.

Vedle použití pojmu stavebního bloku z TOGAF pro obecné řízení architektury se v NAP tento pojem používá v užším a přesnějším vymezení jako Stavební blok eGovernmentu:

Stavebním blokem eGovernmentu nazýváme takový funkční celek (nebo případně jeho část), který:

a) poskytuje centrální sdílené funkce (jako služby) všem (více, mnoha) aktérům (účastníkům) eGovernmentu, nebo mnoha ostatním funkčním celkům, nebo

b) představuje mnohokrát opakovatelný vzor jednotných lokálních funkčních celků

c) vždy je spravován s centrální zodpovědností (governance).

Každý z výše uvedených výseků či přehledů architektury úřadu je možno vyjádřit pohledy, tj. tabulkami (Katalogy a Matice) nebo graficky (Diagramy) na libovolné úrovni podrobnosti.

Pro zachování zpětné kompatibility k prvotní koncepci modelování projektu konsorcia e2020 z roku 2014 a předejití pojmovým konfliktům při použití referenčních modelů tohoto projektu je v této kapitole uvedeno modifikované vysvětlení původních tzv. úrovní „Agregačních úrovní“ L0, L1 a L2“, upravené s respektem k definicím TOGAF, záměrně v přehozeném pořadí:

• L1 – Základní úroveň pohledu na architekturu úřadu - běžná úroveň pohledu na příslušnou strategickou, segmentovou nebo schopnostní architekturu modelovaného úřadu. Podstatou pohledu úrovně L1 je, že naplňuje základní účel architektury úřadu, tedy vizualizuje všechny inventurou nalezené nebo do budoucna projektované výskyty určitých konceptů (prvků) modelu a vazby mezi nimi. Obvykle se však v této své celistvosti zaměřuje pouze na několik vybraných konceptů (prvků metamodelu) architektury úřadu. Například na aplikační komponenty, jejich služby a rozhraní.
• L0 – Přehledová úroveň pohledu na architekturu úřadu - nejvyšší úroveň pohledu na modelovaný úřad jako celek. Tato úroveň pohledu na model organizace představuje vyjádření principu nebo přehledu modelu. Jejím typickým rysem je, že pro zdůraznění strategického principu vyzdvihuje pouze podstatné výskyty určitých konceptů modelu a ty méně podstatné vynechává. Případně místo vizualizace konkrétních výskytů (instancí) vizualizuje princip (přehled) pomocí nadřazených klasifikačních kategorií referenčních modelů a pomocí skupin objektů.
• L2 - Detailní úroveň pohledu na model architektury úřadu - Úroveň L2 rozvíjí do ještě většího (plného) detailu přidáním dalších konceptů metamodelu a jejich atributů strategický, segmentový pohled ale zejména schopnostní pohled na jednotný celostní model architektury úřadu. Například v aplikační architektuře přidává spolupráci aplikací a více úrovní vnitřních funkcí aplikací.

Aktuální metodika nepředepisuje povinnou míru podrobnosti diagramů, výše uvedené úrovně jsou do praktického ověření pilotními projekty pouze doporučeny. Praxe pilotních úřadů ukazuje, že používání různých úrovní podrobnosti pro jinak totéž hledisko (definici pohledu) je i nadále účelné.

Všechny i dílčí modely úřadu musí být vytvářeny a všechna architektonická rozhodnutí činěna s vědomím informací o architektuře prostředí, jehož je úřad součástí, tzv. v jejich kontextu.

Velmi často budou v úřadu modelovány dílčí segmentové a schopnostní architektury nebo čtyřvrstvé architektury funkčních celků ISVS (tzv. full-stack). Úrovně, obálky či slupky jejich kontextů lze definovat na následujících úrovních:

• Kontext celkové architektury vlastního úřadu nebo organizace VS
• Kontext architektury veřejnoprávní korporace (resortu, kraje, ORP), pokud je úřad jejich součástí, zejména korporátních sdílených služeb (i potenciálních)
• Kontext architektury prvků centrálních sdílených služeb eGovernmentu ČR
• Kontext architektury prvků centrálních sdílených služeb eGovernmentu EU
• 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.

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 každý OVS, který je správcem nějaké samoobslužné digitální služby, je důležitý kontext architektur typových klientů této služby.

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

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

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

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

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.

<ol start="2" style="list-style-type: decimal;">

<li>

<p>

</p>

</li>

</ol>

• 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 kapitole 4.1.1 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 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.

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

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 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:

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

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

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

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.