Struktura modelovaných architektur

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

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 řešení a 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 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.).

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í³⁾ 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 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⁴⁾, 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é následující Obrázek.

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

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 Rámec obsahu a výstupu architektur a předcházející Obrázek.

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.

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 následující Obrázek.

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

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