Referenční modely a klasifikační rámce

Není možné srovnávat a vyhodnocovat části architektur mezi sebou, pokud bychom si nebyli jistí, jestli ukazují vždy to samé, tu samou část úřadu, ten samý typ komponenty, tu samou kategorii procesů apod.

Bez toho není možné se snažit o sjednocování, konsolidaci, redukci, náhradu atp. Klasifikace prvků architektury je nezbytným předpokladem všech architektonických rozhodování. Proto tato kapitola přináší koncepci Národních klasifikačních systémů a na jejich bázi vytvořených referenčních modelů, platných vedle architektur ústředních správních úřadů v převážné míře i pro architektury kraje nebo ORP a jejich organizací.

V současné poradenské praxi, zaměřené na zlepšování řízení úřadů státní správy a samosprávy v ČR, se setkáváme s dvojím významem a rozsahem pojmu „referenční model“:

• Referenční model integrovaného systému řízení úřadu (RM ISŘ)- se zaměřuje na představení a udržování znalostí a praxí ze všech vzájemně souvisejících metod manažerského řízení úřadu.
• Referenční model architektury úřadu (RM A) - dále již také jenom jako RM, je vzorem, akcelerátorem a klasifikačním systémem dle nejlepších praxí pro architekturu úřadu.

Tento architektonický rámec se dále zabývá již jenom referenčními modely architektury úřadu, které jsou však v praxi cenným východiskem pro vybudování referenčních modelů Integrovaných systémů řízení.

Referenční model architektury úřadu by měl pokrývat všechny tzv. domény úřadu a jim odpovídající vrstvy a vertikály architektury.

Klasifikační systémy a referenční modely nemohou vzniknout tzv. „od stolu“, nýbrž zobecněním praxí nabytých zkušeností. A protože v české veřejné správě ještě žádná sdílená architektonická zkušenost neexistuje, na rozdíl od zahraničí, vznikají první verze klasifikačních systémů a referenčních modelů NA VS ČR jako kombinace zahraničních vzorů, místních ukončených či ještě probíhajících akademických výzkumů, zejména na VŠE, a pilotních projektů EA v orgánech veřejné moci ČR.

Jedním z inspiračních zdrojů pro budoucí referenční modely jsou také některé z dřívějších výstupů dodavatelského konsorcia e2020 (2014).

Z mezinárodních zdrojů jsou nejdůležitější taxonomie Nového Zélandu, které dále rozpracovaly aktuální taxonomie veřejné správy USA. K nim se řadí ještě prvky z referenční architektury VS Velké Británie.

Díky blízkosti Slovenské republiky a podobné stavu rozpracování obou národních architektur VS budou taxonomie a referenční model ČR vznikat ve spolupráci a se zohledněním slovenských zkušeností.

Do třetice díky příslušnosti ČR do EU a potřebě stát se součástí evropské architektury pro interoperabilitu bude EIRA¹⁾ představovat významnou inspiraci pro ty části Národní architektury, které jsou právě řešením problematiky interoperability. Ostatní lokální referenční modely EIRA nepokrývá.

Více informací, vlastního obsahu a odkazů k mezinárodním referenčním modelům a taxonomiím se nachází ve Znalostní bázi NA VS ČR.

Projekt e2020 přinesl mnoho set diagramů, vytvořených 1:1 k modelům, což není metodicky zcela správně. Mělo by se jednat o rozdílné pohledy (řezy) na konsolidované modely – co modelující jednotka to jeden model.

Modely jsou ale aktuálně jediným dostupným uceleným souborem architektonických artefaktů, vyjadřujících první představu významné skupiny architektů dodavatelského konsorcia e2020 o cílové podobě architektury českého eGovernmentu na konci roku 2019. A současně tak jsou jedinou dostupnou centrálně pojatou českou architektonickou zkušeností v oblasti enterprise architektury veřejné správy.

Za referenční v architektonickém slova smyslu, tzn., že mohou být předlohou při modelování lokální architektury úřadu, je z výstupů projektu e2020 možno považovat tyto skupiny modelů:

• Modely ústředních správních úřadů (ÚSÚ) – 8 modelů, vždy dva za každou vrstvu architektury (byznys, aplikační, IT technologickou a infrastrukturní), z toho 4 pouze indikativní (úroveň 0) a 4 přesnější (úroveň 1). Kombinace obou úrovní podrobnosti do jisté míry představuje tehdejší návrh taxonomie architektury ÚSÚ.
• Modely krajských samospráv, resp. pouze krajských úřadů (KRJ) – ve stejné struktuře jako ÚSÚ.
• Modely statutárních měst a obcí s rozšířenou působností (STM a ORP) - ve stejné struktuře jako ÚSÚ, ale dvakrát v podstatě totéž, jen s drobnými odchylkami.

Tyto modely obsahují řadu drobných nekonzistencí mezi sebou vzájemně a neopírají se o žádný společný klasifikační systém komponent. Právě tyto skupiny tzv. referenčních modelů již byly publikovány na webu OHA a budou nadále součástí Znalostní báze NS VS ČR. Zpětné zhodnocení modelů proti praxi a proběhlému vývoji eGovernmentu za uplynulé období povede k případnému zohlednění zkušeností a k jejich promítnutí do dalších aktualizací níže uvedených referenčních modelů NAR a do jejich úprav pro jednotlivé úrovně hierarchie veřejné správy ČR.

Národní architektonický rámec usiluje o vytvoření a aktualizaci RM pro všechny vertikální i horizontální domény architektury. V nejbližším období ale budou dostupné pouze referenční modely pro klíčové objekty základních architektonických vrstev (BADT), z nichž referenční modely BA a AA již jsou představeny níže. Následovat by měly RM technologických vrstev, RM datové architektury a RM architektury strategického směřování.

Tato část je zaměřena na RM byznys architektury, tj. architektury výkonu veřejné správy a provozu úřadu, který je dále označován zkráceně jako RM-BA. Jediný tuzemský zdroj informací pro vytvoření hledaného RM je soubor prezentací a modelů vytvořených jako pracovní verze v OHA. K jeho vytvoření přispěly i dílčí zkušenosti z pilotních projektů tvorby architektury úřadu Ministerstva průmyslu a obchodu (2015), Moravskoslezského kraje (2017) a Města Benešova (2018 - 2019).

Model vzniká postupně tak, aby se následně, po verifikaci v projektech stal součástí Národního architektonického plánu a základní procesní dekompozicí pro projekt PMA3 (Procesní modelování agend).

RM-BA VS ČR byl vytvářen ve spolupráci s dalšími organizacemi, na základě diskusí s VŠE (prof. V. Řepa, M. Zimmermannová), neziskovou organizací CIEM (model CIMAF²⁾, R. Fišer) a s Národní sítí zdravých měst (P. Švec, J. Boušková).

Z toho dále vyplývá, že není-li dostatek místních zdrojů, je nutné kvalitní výchozí referenční model sestavit s využitím zahraničních inspirací. Pro tento RM byly využity modely procesních a funkčních dekompozic (referenční klasifikace) samospráv z Nizozemí a USA a referenční model státní správy z Nového Zélandu, které se jeví jako nejvíce relevantní.

• Dělí architekturu po vrstvách a doménách ve shodě s NAR (kombinace standardů TOGAF, ArchiMate a architektonického rámce Nového Zélandu).
• Ve vrstvě BA se zaměřuje na klasifikaci činností (chování), bez ohledu na to, zda jsou řízeny pouze jako funkce (z pracovních náplní), jako procesy (řízené sekvence funkcí) nebo jako služby (řízené výstupy procesů).
• RM představuje referenční (vzorovou) klasifikaci resp. taxonomii výše uvedených prvků. Současně poskytuje vizuální referenci (topologii diagramů – co je dole/nahoře, vlevo/vpravo).
• RM uznává, že je možné vytvořit více referenčních klasifikačních systémů, tento se zaměřuje na klasifikaci činností v dimenzi od poskytování individuálních funkcí (služeb) pro konkrétní jmenovité klienty na jedné straně až po základní provozní aktivity na druhé straně.
• Každý z referenčních modelů využívá stejnou terminologii názvů pro klasifikační úrovně:
  • 1. úroveň – byznys (aplikační, technická) oblast
  • 2. úroveň – byznys (aplikační, technická) kategorie
  • 3. úroveň – byznys (aplikační, technická) skupina

Principiální diagram nejvyšší úrovně referenčního modelu byznys architektury VS ČR, viz následující obrázek:

Příkladem dalšího detailního rozpadu klasifikace mohou být provozní procesy. Ty mají tu vlastnost, že až na drobné odchylky (jiný účtový rozvrh, zákon o VZ, zákon o úředních, apod.) se tyto funkce, procesy a interní služby nijak neliší od týchž v libovolné komerční nebo neziskové organizaci. Proto je účelné i od těchto organizací přebírat nejlepší praxe.

V téže procesní oblasti je představena i další úroveň klasifikace - byznys skupiny (funkcí, procesů, služeb), z důvodu zobrazení již rozdělené do dvou diagramů:

Referenční model BA může být postupně s podporou pilotních projektů dopracován ještě do větší podrobnosti a nabídnout referenční klasifikaci i pro procesy (funkce či služby) jednotlivých byznys skupin, jak je zde na příkladu z projektu Studie Benešov představeno pro skupinu Správy majetku obce.

V modelu a grafickém vyjádření identifikovaných úrovní 3 až 5 dekompozice byly zvoleny tyto objekty:

• úroveň 3 – Skupina procesů (funkcí) – objekt ArchiMate Skupina
• úroveň 4 – Proces nebo funkce (v tomto případě funkce) – objekt ArchiMate Funkce
• úroveň 5 – Podproces, činnost (v tomto případě dílčí funkce) – objekt Funkce.

Klasifikační objekt Skupina je v následujících dvou schématech, na rozdíl od všech výše uvedených diagramů vyjádřen tradiční grafickou notací jako „kartotéční lístek“. Tím se chce zdůraznit rozdíl mezi poslední úrovní (abstraktní) klasifikace a první úrovní výkonných funkcí.

Na následujícím obrázku je představen souhrnný referenční model byznys architektury veřejné správy ve variantě pro město (obec). Jenom s malým úsilím pilotních úřadů je možné RB-BA přizpůsobit také realitě kraje, ústředního správního úřadu nebo rozpočtové kapitoly.

Zatím jediný dostupný lokalizovaný referenční model pro aplikační architekturu NA VS ČR je k dispozici pro klasifikaci a vizualizaci mapy aplikačního portfolia, členěného podle účelu aplikací. Jedná se o referenční model vypracovaný na VŠE, který nemá, s výjimkou výše uvedeného britského modelu UK-RA³⁾, ve světě srovnatelnou obdobu.

Všechny ostatní modely člení aplikace spíše podle způsobu získání (nákup, vývoj) nebo podle druhu technického řešení než podle účelu, například model CORA. Oba pohledy na aplikační portfolio je možno kombinovat, záleží na obsahu aktuálně kladených otázek, o nichž je třeba nad architektonickými modely rozhodovat.

Na hledaný referenční model aplikační architektury byly kladeny následující požadavky:

• Musí seskupovat aplikace podle byznys účelu a uživatelského způsobu použití, aby u aplikačních komponent v téže klasifikaci podpořil rozhodování o jejich konsolidaci či záměně nebo zřízení tam, kde pro byznys účel chybí.
• Musí dávat smysl v kterékoli úrovni detailu (hierarchie) klasifikace aplikací, tento zjevný smysl musí být srozumitelný byznys uživatelům referenčního modelu a z něho odvozených individuálních modelů.
• Musí být po úpravách použitelný ve všech segmentech a na všech úrovních hierarchie veřejné správy.

Referenční model byl vytvořen jako soubor zásad, příkladné obrázky, klasifikační hierarchie a šablona jazyka ArchiMate. Aktuální verze modelu, viz níže, je vytvořena jako generický model pro veřejnou správu, spíše zaměřený na segmenty úřadů s rozsáhlým kmenem klientů a s procesy hromadné obsluhy klientů. NAR a NAP předpokládá vytvoření klonů modelu i pro další segmenty veřejné správy, například zaměřené na projektově orientovanou správu liniové infrastruktury a další.

První úroveň dekompozice dle RM-AA přináší dělení aplikačního portfolia podle dvou základních dimenzí, vertikální a horizontální. Vertikální dimenze modelu dělí aplikační architekturu podle míry blízkosti aplikací uživateli, jeho potřebám a managementu organizace na tzv. vrstvy, které odpovídají členění od technické integrace až po uživatelskou interakci. Model je tvořen šesti vrstvami:

Horizontální dimenze představuje členění aplikací podle jejich role v podpoře hodnotového řetězce organizace. Zjednodušeně říká, že zcela vlevo jsou aplikace podporující výkon činností, evidenci a komunikaci informací spojených s externími subjekty, zcela vpravo jsou aplikace podporující evidenci interních zdrojů a činnosti s nimi, uprostřed jsou aplikace, které oba tyto světy spojují, například účetnictví a logistika v ERP v transakční (IV.) vrstvě, resp. reporting a podpora rozhodování v analytické (III.) vrstvě.

Horizontální členění se uplatní zejména u aplikací s výrazným byznys obsahem, tj. u transakční a informační vrstvy, kde je zdůrazněno, jak ukazuje následující obrázek.

V modelu jsou aplikační oblasti a kategorie orámovány pojmy, odpovídajícími hlavním konceptům (Byznys Objektům), které jsou předmětem evidence v podnikových informačních systémech a současně jsou součástí prostředí podniku, s nímž systémy interagují. V generickém modelu to jsou tři klíčové kategorie externích zájmových skupin: vlastníci, zákazníci a dodavatelé, a dále tři základní podnikové zdroje: znalosti, zaměstnanci a majetek (technologie). V modelu pro veřejnou správu jsou dodavatelé převedeni zleva doprava, protože organizace veřejné správy nepovažují (dosud) dodavatele za partnery při tvorbě hodnoty a dodávce veřejné služby, ale považují je spíše za externí zdroj.

Jádrem modelu jsou prostřední dvě klíčové vrstvy transakcí a znalostí, které přímo podporují provádění funkcí, procesů a služeb úřadu. Jsou dále členěny podle horizontální dimenze do hlavních oblastí aktivit od vykonávání externích činností (výkon služeb veřejné správy) po správu zdrojů úřadu. Cílem těchto dvou vrstev je pokrývat ucelené (E2E⁴⁾) scénáře tvorby hodnoty, tedy pokrývat všech pět klíčových oblastí dekompozice RM byznys architektury, viz následující Obrázek, jenom jinak uspořádané.

Transakční operace vytvářejí množství dat, které slouží pro podporu rozhodování (uprostřed), dále doplňují spolu s dokumenty znalosti úřadu (vpravo) nebo představují informace pro vlastníky, politiky a veřejnost (vlevo). Spolu tvoří vrstvu znalostí a podpory rozhodování.

Pod transakční vrstvou se nachází vrstva všeobecných, průřezových IT a bezpečnostních služeb, které většinou nejsou spojeny s jedinou výlučnou byznys a aplikační funkcí, nýbrž slouží mnoha z nich (identity a oprávnění, monitoring, kancelářský balík, archivace, mapové aplikace apod.).

Nejspodnější vrstvu tvoří aplikační SW jednotlivých platforem, integrační, mobilní, komunikační a dalších, sloužících pro provoz a propojování aplikací.

Naopak nad vrstvami pro transakční zpracování a práci s informacemi se nachází vrstva pro orchestraci služeb z jednotlivých informačních sil do jednotlivých uživatelských rozhraní, také zvaná kompozitní vrstva nebo platforma.

Nejvyšší vrstvu, nejbližší uživatelům, tvoří všechny představitelné formy uživatelských rozhraní, od tradičního těžkého klienta, přes prohlížeč, mobilní aplikace až po tzv. Internet věcí nebo inteligentní oblečení. Tedy cokoli, co je uživateli schopno zpřístupnit aplikační služby nižších vrstev.

Dělení aplikací do oblastí, kategorií a skupiny má velký význam pro stanovení pravidel řízení jednotlivých aplikací. Více informací o architektonických pravidlech pro jednotlivé oblasti a kategorie aplikační architektury se nacházejí v dokumentu NAP.

Při úvahách o uplatnění referenčních modelů, například v této části u RM-AA platí, že celkový model aplikační architektury tvoří opakující se vzory, tzv. „fraktály“, pouze menší nebo větší, podle toho, kde v organizační hierarchii se referenční model uplatní.

Některé organizace veřejné správy mají korporátní charakter (typicky ministerstva, kraje nebo obce) a poskytují některé své funkce a aplikace i dalším organizacím z korporace. Každá ze samostatných jednotek této hierarchie by pro své vlastní řízení IT měla aplikovat a dle vlastní situace upravit referenční model aplikační architektury, představený výše.

Potom každá z výše v hierarchii postavených jednotek bude mít modely dva. Jeden elementární (individuální, IND), pokrývající IT podporu jejích vlastních procesů a druhý souhrnný (společný, SPOL), zahrnující v sobě na příslušných místech modelu vedle vlastních aplikací i aplikace, vyskytující se v podřízených nebo řízených jednotkách. Symbolicky to ukazuje následující diagram, viz následující obrázek, v němž jsou představeny souhrnné modely na různých úrovních architektury veřejné správy. V levé zelené části transakční oblasti je naznačeno, že každý vyšší (společný) model obsahuje i všechny aplikace evidované v nižším modelu.

Modely vyšší úrovně potom mohou sloužit například k rozhodování o konsolidaci (sjednocování) aplikační architektury a využití sdílených služeb, buď povinně u jednotek, kam dosáhne rozhodovací pravomoc vyšší jednotky, nebo dobrovolně, pokud vyšší jednotka nabídne té nižší aplikační pokrytí domény za výhodnějších podmínek, které by konsolidace a centralizace měla umožnit.

Z pohledu každé z organizací není rozhodující pro uvedení do aplikační mapy, zda aplikaci vlastní. Důležité je, že aplikační potřebu z určité oblasti má pokrytou řešením určitých kvalit, ať je jí vlastněné (modeluje jako aplikační komponentu), sdílí jej horizontálně s partnerskou organizací nebo jej přebírá od nadřízené jednotky (modeluje jako aplikační službu).

Není dosud definován na úrovni NA VS ČR.

Není dosud definován na úrovni NA VS ČR.

Není dosud definován na úrovni NA VS ČR.

Není dosud definován na úrovni NA VS ČR.