Toto je starší verze dokumentu!
Modelování pro informační koncepci
Příloha 1: Modelování dle NAR
Účel a popis dokumentu
Tento dokument slouží jako rozšíření Metodiky modelování podnikové architektury pro účely přípravy podkladů ke tvorbě informační koncepce úřadu. Očekávané využití dokumentu je získání představy o potřebných informacích a jejich strukturování v modelu podnikové architektury tak, aby usnadnily přípravu IK dle šablony publikované DIA.
Dokument se odkazuje na a vychází z následujících dokumentů/zdrojů. Předpokládáme, že je čtenář s těmito podklady obeznámen.
- NAR
- Metodika modelování podnikové architektury
- Šablona Informační koncepce
Struktura informační koncepce
Informační koncepce jako dokument má předepsanou komplexní strukturu. Jádrem jsou následující hlavní oblasti:
Podniková architektura
Podporuje pohled na úřad jako celek s cílem identifikovat a popsat silné a slabé stránky a příležitosti ke zlepšení a určit, do jakého stavu se úřad dostane po jejich realizaci.
Oblast řízení ICT
Tato část je pojatá jako podmnožina podnikové architektury s cílem jasně vyhodnotit a navrhnout způsob fungování ICT na úřadě. Má tedy analogickou strukturu.
Jak je vidět, jednotlivé části a jejich pořadí reprezentují logickou posloupnost přípravy strategie úřadu. Při přípravě IK akcentujeme potřebu zamyšlení se nad těmito základními tématy a pomáháme je systematicky utřídit a rozvést. Části IK lze tedy připravovat v pořadí uvedeném výše.
Doporučený postup naplnění dokumentu IK je ilustrován na následujícím obrázku. Architekt nejprve vyslechne potřeby klíčových zainteresovaných stran (vedení úřadu), pro účely rozpracování v IK. V další fázi pak poznává svůj úřad na úrovni obecnosti a abstrakce (poslání, schopnosti, procesní dekompozice), aby mu porozuměl a u jednotlivých schopností nebo procesů, případně v OVM u agend se mohl ptát, do jaké míry jsou již digitálně transformované a uspokojivě podpořeny IT technologiemi. Tato část je v IK rozpracována v největším detailu. Ten je dodržen i v návrhu cílového stavu. Nakonec architekt popíše obsah IK v podobě manažerského shrnutí.
V dalších částech tohoto dokumentu popíšeme, jak optimálně připravit podklady pro naplnění IK za pomoci modelu podnikové architektury dle NAR.
Paralelní příprava IK a modelu podnikové architektury
Jak je popsáno výše, příprava IK bude probíhat nejen ve formě využití informací z modelu, ale model bude tvořen a upravován v průběhu přípravy IK tak, aby byl aktuální a obsahoval všechny zajímavé informace, k jejichž vyjádření vede šablona IK. Na konci přípravy IK by měl díky tomuto přístupu vzniknout aktuální a obsahově bohatší model podnikové architektury úřadu.
Příprava dokumentu IK za pomoci modelu
V této části popisujeme doporučení pro využití informací z modelu podnikové architektury, jako jsou pohledy a katalogy. Při přípravě IK pomohou vizualizovat a nalézt požadované údaje a také mohou sloužit jako inspirace. Odkazujeme se na dokumentaci Metodika modelování podnikové architektury úřadů1), včetně názvů konkrétních pohledů.
V návaznosti na přehled výše je zde detailněji popsané, jak připravit obsah základních částí, z nichž je IK postavená a které se použijí jako základ pro závěrečné shrnutí. Jednotlivé oblasti architektury jsou detailně popsány v metodice NAR.
V každé části níže najdete odkaz na příslušnou kapitolu v šabloně IK, u které jsou tipy a doporučení na informace v modelu, jež by mohly být užitečné pro její naplnění. Očekává se, že zásadním obsahem dokumentu IK bude vlastní text doplněný o model, který bude sloužit jako zdroj diagramů, katalogů a základních informací o relevantních položkách.
U kapitol Informační koncepce, které nejsou v tomto dokumentu explicitně uvedené, se očekává doplnění informací, které v modelu nejspíše nebudou. To ale neznamená, že nebude nikdy užitečné je modelovat – rozhodnutí je na autorovi samotném.
Podniková architektura úřadu
Stávající stav
Stávající stav ukazuje architekturu úřadu tak, jak funguje dnes. Tento pohled by neměl idealizovat situaci, ale pokud se některé běžící projekty již blíží k úspěšnému konci, lze je považovat za dokončené a promítnout jejich výsledky sem – do mapy současného stavu. Stávající stav by měl autor IK držet v modelu podnikové architektury jako aktuální a obsah by měl reflektovat skutečnou situaci.
Byznys architektura
Popis byznys architektury má být zaměřen na přehled organizace, agend a procesů úřadu. Pro účely informační koncepce budou z modelu využity především přehledové mapy výše zmíněných oblastí a katalogy s potřebnými informacemi. V následující tabulce uvádíme využitelné pohledy na byznys architekturu v jednotlivých sekcích informační koncepce.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Přehled byznys architektury | * Mapa schopností úřadu * Přehled služeb VS * Mapa byznys dekompozice, tj. mapy funkcí, procesů nebo služeb = Mapa procesů a funkcí | * Vizte část metodiky „Jak modelovat procesy“2) * Mapa byznys dekompozice obsahuje hierarchii skupin činností s prvky, které jsou modelované podle toho, co bylo v úřadu skutečně identifikováno (byznys funkce, proces, služby). * Jednotlivé části mapy je doporučeno dělit do sekcí dle šablony IK * Pro lepší přehlednost je vhodné vytvořit diagramy i pro jednotlivé sekce IK |
| Hlavní a podpůrné procesy | * Katalog agend, činností * Katalog funkcí, procesů a služeb * Matice Mapování Aplikačních služeb na Funkce/Procesy/Interakce VS | * Informaci o aplikacích a IS, které realizují daný proces je možné najít v matici Mapování aplikačních služeb na procesy * Důležitým údajem je rozlišení agend na ohlašované a neohlašované – je doporučeno zavést tento údaj do modelu (např. formou identifikátoru z RPP, či tagu, který toto indikuje) * Stav digitalizace je specifický údaj pro potřeby IK – tuto informaci je možné vyjádřit např. barevnou konvencí na příslušných diagramech s využitím škály dle šablony IK |
| Přehled digitalizace z pohledu organizační struktury | * Diagram Organizační struktury * Katalog organizačních jednotek, útvarů a pozic | * Viz Jak modelovat organizační jednotky a pracovní pozice * Vztah útvarů a používaných IS lze vysledovat z vykonávaných agend (Útvar → Služba/Funkce/Proces → Aplikace) * Stav digitalizace – vizte řádek výše |
| Přehled údajů ve správě úřadu | Katalog datových objektů (objektů VS) úřadu | * Vybudujte si Slovník pojmů (Business glossary), v budoucnu navázaný na celostátně centralizovaný slovník3). * Slovník by měl být strukturovaný s ohledem na zákonné požadavky na strukturování dat v informačních systémech4) |
Níže uvádíme několik příkladů jak členit pohledy na byznys architekturu.
Příklad 1 – Mapa služeb VS
Pohled je členěn do částí navazujících na sebe. Začíná určením rolí/aktérů - odběratelů služeb a dalších účastníků. Ti přistupují ke službám přes obslužné kanály, což je další vrstvou. Dále pak následují vrstva služeb a vrstva funkcí, které je realizují.
Příklad 2 – Služby veřejné správy úřadu
Příklad 3 - Mapa procesů a funkcí
Mapa procesů může být rozdělená do bloků znázorněných na obrázku. Jedná se o referenční rozložení doporučené DIA. Nejdůležitější služby jsou vlevo nahoře, podpůrné a provozní procesy pak níže a řízení, které vstupuje do každé oblasti je vpravo. Jednotlivé bloky by měly být ohraničené pomocí elementu “Seskupení” (Grouping), jak je naznačeno na obrázku. Vyvarujte se pokud možno použití „obsahových“ elementů za účelem vizuálního seskupení (například seskupení dílčích procesů pod rámcový proces).
Mapa procesů a funkcí
Tato mapa dekompozice byznys činností organizace je hierarchická a je tvořena prvky Seskupení, Byznys funkce, Proces nebo Služba podle toho, jakou formu řízení (governance) identifikovaná činnost skutečně má a jaké z nich se úřad rozhodl modelovat. K rozčlenění diagramu do oblastí použijeme element Seskupení. Pokud je podstata funkce či procesu skutečně hierarchická, lze využít i zapouzdření do sebe. Musí mít ale sama o sobě význam funkce či procesu. Vyvarujme se použití elementů jiných než Seskupení čistě k seskupování.
Příklad mapy procesů a funkcí5)
Příklad 4 – Členění procesů a funkcí dle domén
Hlavní procesy (zde byznys funkce) mohou být vertikálně členěny podle společných segmentů buď činností nebo klientských, jak je ukázán o na tomto příkladu6)
Příklad 5 – Diagram Organizační struktury
Organizační struktura má tvar stromu se špičkou reprezentující vedení úřadu a dále níže jednotlivé úrovně útvarů. Útvary (reprezentované aktéry) jsou volitelně rozdělené dle lokalit.
Diagram Organizační struktury
Při popisu organizační struktury využíváme typu vazby asociace tam, kde se jedná o vztah jiný, než pro podřízený útvar v rámci hierarchie – např. útvar ředitele nemá v sobě všechny další útvary, ale má za ně odpovědnost. Vazba kompoziční (zanořující) je využitá tam, kde je přímá podřízenost.
Příklad diagramu Organizační struktury7)
Příklad 6 – Diagram organizační struktury se zanořováním
Hierarchii lze vyjádřit zapouzdřením. V tomto případě dává smysl seskupovat útvary v rámci jednoho zastřešujícího nadřízeného elementu.
Příklad organizační struktury úřadu
Příklad 7 – Využití seskupování podle vybraného aspektu
Příklad ukazuje využití seskupování podle aspektu, který mají příslušné útvary společný, jenž ale není součást hierarchie v organizační struktuře (nemá vedoucího, náměstka).
Příklad 8 – Mapa schopností úřadu
Příklad níže dobře znázorňuje působnost úřadu, provozní a speciální schopnosti úřadu, Vhodným seskupováním lze celý diagram zpřehlednit a učinit pochopitelným. Schopnostní mapa je vhodným diagramem pro potřeby IK.
Příklad dobře zpracované mapy schopností úřadu8).
Příklad 9 – Diagram Objektů VS
Diagram Objektů VS ukazuje přehledně vazby mezi jednotlivými objekty v hierarchickém uspořádání a vztahy mezi nimi. Tím je vytvořen konceptuální datový model doplněný vazbami definující hierarchii, kompozici a vztahy mezi nimi. Jedná se o „hierarchickou pavučinu“.
Příklad níže ukazuje možné typy vazeb pro účely přípravy IK: vazba asociace indikuje obecný vztah, ideálně s popisem významu, vazba kompozice či agregace vyjadřuje hierarchii a specializace pro znázornění konkrétních objektů, které připívají k objektům obecněji definovaným.
Příklad diagramu (Byznys) objektů VS
Aplikační architektura
Pro účely informační koncepce se popis aplikační architektury zaměřuje na přehledové diagramy mapy aplikací a informačních systémů a diagramy vazeb mezi aplikační a byznysovou vrstvou. Zde je vhodné co nejvíce využít odkazů na centrální evidenci sdílených služeb či číselníků, pokud jsou k dispozici.
V následující tabulce uvádíme využitelné pohledy na aplikační architekturu v jednotlivých sekcích informační koncepce.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Přehled a klasifikace všech informačních systémů úřadu | * Mapa aplikačních komponent | * Diagram je vhodné dělit do oblastí dle zvoleného klíče (např. dle referenčního modelu NAP9)) * Pro lepší přehlednost je vhodné vytvářet dílčí diagramy i pro jednotlivé oblasti (pokud je klasifikovaných komponent více než 20-30 a celková mapa by se stala nečitelnou na první pohled). |
| Přehled ISVS a provozních ISVS ve správě úřadu, Ostatní provozní informační systémy úřadu, Nástroje podporující spolupráci | * Katalog IS a jejich aplikačních komponent | * Jako atributy u aplikací zpravidla uvádíme: identifikátory, zkratky nebo věcného správce. * Logický celek Informační systém (IS) doporučujeme modelovat jako podtyp aplikační komponenty. * IS se obvykle komplexní se samostatně spravovanými částmi a modelují se proto jako složené z více aplikačních komponent. * Stav architektury je specifický údaj pro IK, lze opět vyjádřit i barevně na diagramech. * Katalog IS koresponduje s Kartami ISVS, které jsou vedeny v souladu s metodickým pokynem. |
| Využití klíčových sdílených služeb eGovernmentu a externích IS | * Katalog aplikačních komponent * Katalog aplikačních služeb | * Na diagramu uveďte využité sdílené služby. * Při modelování používejte vazby na sdílené aplikační služby či komponenty |
| Publikace služeb | * Katalog aplikačních komponent * Katalog aplikačních služeb | * K publikaci sdílených služeb či komponent je vhodné se odkazovat na jejich evidenci v katalogu. |
| Využití cloud řešení | * Katalog aplikačních komponent * Katalog aplikačních služeb | * Typ nasazení aplikace (např. on-prem / cloud / eGovernment cloud) lze evidovat jako atribut u elementu v modelu a pak jej lze snadno filtrovat pro účely přípravy IK. |
| Integrační model aplikační architektury | * Diagram Struktury aplikací | Specificky koncipovaný diagram / diagramy, ukazující vazbu mezi aplikačními komponenty a vazby na sdílené aplikační komponenty. Diagram Struktury aplikací se v IK používá jako tzv. diagram integrační architektury (Integrace aplikací), který napříč celým aplikačním portfoliem úřadu ukazuje klíčové (principiální) integrační vazby mezi IS a jejich komponentami. |
Příklad 10 – Členění přehledu aplikačních komponent
Mapa aplikačních komponent úřadu je rozložená od shora dolů na vrstvy reprezentující: uživatelské rozhraní, komponenty sloužící k propojení (integrační vrstva), komponenty realizující obchodní logiku pro provádění agend, dále pak obsahuje podpůrné aplikace a nejníže uvádí technické aplikační komponenty.
Mapa možného rozčlenění IS a aplikačních komponent
Diagram v této podobě podporuje rozhodování o konsolidaci a dekompozici aplikací. Ukazuje, ve kterých oblastech portfolia (Mapy) se nachází mnoho roztříštěných aplikací, kde se nacházejí velké monolitické aplikace nebo kde se naopak zatím nenacházejí žádné aplikace, a tudíž odpovídající oblast byznys architektury nemá IT podporu.
Příklad 11 – Členění přehledu aplikačních komponent dle oblasti využití
Mapa níže je členěná dle oblasti využítí aplikací v úřadu. Toto členění je vhodné, pokud jsou oblasti převážně disjunktní, tedy je velmi málo takových aplikací, které se používají napříč oblastmi.
Příklad mapy aplikačních komponent10)
Příklad 12 – Diagram struktury aplikací
Tento diagram se používá primárně za účelem vizualizace komunikace aplikací mezi sebou a okolím. Nejbližší externí sousedi jsou také zobrazeni. V případě velmi komplexních IT systémů je možné ho využít pro indikaci jejich vnitřní struktury. Není to ale pro potřeby IK obvykle nutné. Diagram pak obsahuje modelovanou aplikaci jako zapouzdřující element, který obsahuje elementy reprezentující uživatelské či technické rozhraní a další.
Pokud se jedná o integraci skrz dedikovanou integrační vrstvu, nemusí se do mapy explicitně kreslit – cílem je vidět které aplikace spolu komunikují.
Diagram struktury aplikací
Na diagramu níže je vidět integrace aplikací mezi sebou, komplexní IS je členěn za účelem pochopení jeho vnitřní struktury. Je zde navíc využita indikace hlavních aplikačních funkcí, které daná aplikační komponenta realizuje.
Příklad diagramu struktury aplikací11).
Datová architektura
Zde je IK poměrně specifická v požadavcích na předané informace. V modelu je vhodné připravit katalog datových/informačních objektů a přehledy o zacházení s nimi skrz vrstvy byznysové a aplikační, příp. i technologické. Stěžejní je model objektů VS, který se uplatní v rámci byznysové vrstvy IK OVS.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Jednotlivé architektury práce s daty | * Diagram byznys objektů (objektů VS) | Jako konceptuální datový model. Pokud je vhodné, doplňte popis požadovaných informací diagramy ilustrujícími danou skutečnost. |
| Architektura sdílení dat v propojeném datovém fondu | * Diagram struktury aplikací | Ilustruje, jak aplikační a platformové nástroje slouží OVM k přístupu do PPDF |
| Architektura zpřístupnění dat | * Diagram struktury aplikací | Ukazuje, jaké nástroje slouží OVM pro přípravu a publikaci dat jako OpenData nebo data s řízeným přístupem |
| Architektura kmenových dat a číselníků | * Diagram struktury aplikací | Ukazuje v návaznosti na konceptuální model, jak je v OVM řešena centralizace a ochrana kmenových dat s vazbou na základní registry a jmenný rejstřík eSSS a jak centrální správa interních číselníků a vazba na externí číselníky |
| Architektura analytického zpracování dat | * Diagram struktury aplikací | Ukazuje architekturu zpracování dat pro podporu rozhodování v OVM. |
Technologická architektura
I v technologické oblasti je v IK očekávaný přehled situace, tedy z modelu architektury úřadu lze využít přehledové pohledy. Zajímavý je pohled na technologické portfolio a používané technologické platformy. Doporučujeme věnovat pozornost i další vrstvě – komunikaci – aby nedocházelo k překryvům informací častěji, než je potřeba.
Architektura infrastruktury datových center
Na tuto oblast nahlíží informační koncepce ze dvou úhlů pohledu: topologie datových center a pohledu přes platformy.
Topologie reprezentuje přehled datových center, jejich propojení a síťovou infrastrukturu v nich. Cílem topologického pohledu je udělat si představu, jak jsou rozložené IT prostředky fyzicky a jak je koncipované zajištění dostupnosti a odolnosti technologických služeb infrastruktury.
Cílem pohledu na platformy je ukázat klasifikaci IT výpočetních a úložných technologií, optimálně dle referenčního modelu. Diagramy by měly ukazovat přehled technologických prvků, které tvoří služby na technologické úrovni a na nichž stojí provozované aplikace. Na úrovni L1 lze zdůraznit použité technické platformy v jednotlivých uzlech, zařízeních a sítích.
Pro potřeby modelování a vizualizací lze pracovat s následující referenční hierarchií technologických prvků a jejich využitím v různých typech nasazení infrastruktury:
Systematizace hierarchie prvků technologické architektury a jejich využití v různých typech nasazení
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Topologie DC | * Diagram topologie datových center | * Umístění klíčových uzlů IT technologií do jednotlivých lokalit |
| Technologické platformy | * Technologické platformy | * Model různých instancí jednotlivých druhů zařízení a provozního SW tak, aby bylo umožněno rozhodování o jejich konsolidaci |
| Cloud | * Technologické platformy | * Při větším využití externí infrastruktury lze přidat samostatný přehledový diagram * Využité prvky cloudové infrastruktury označujte např. barevně pro indikaci typu – IaaS, PaaS, SaaS (navázání na informaci na aplikační úrovni) |
Příklad 13 – Diagram topologie datových center
Diagram topologie datových center vizualizuje, jaká datová centra či serverovny úřad spravuje či využívá a soustředí se na popis jejich infrastruktury z logického a fyzického pohledu.
Prvky jsou seskupeny dle lokací, které reprezentují datová centra či serverovny. Uvnitř každé lokace je přehled uzlů a zařízení (jakékoliv úzce zaměřené zařízení – např. firewall). Uzly a zařízení jsou pak napojené na sítě. Dále jsou vypsány funkce a vybavení, které dané DC nabízí pro provozování infrastruktury, typicky fyzické zabezpečení, klimatizaci, redundanci a zálohu pro zajištění dostupnosti apod. Diagram by měl naznačit způsob propojení DC s ostatními – např. i pomocí na internetu nezávislých sítí.
Struktura diagramu topologe datových center
Příklad 14 – Diagram platforem
Diagram platforem vizualizuje, jaké kombinace technologií jsou podporované a jak jsou sestavené ze stavebních prvků.
Struktura diagramu technologických platforem
Diagram ukazuje možné znázornění platforem, které jsou k dispozici pro běh aplikací. Diagram je strukturován vertikálně v duchu hierarchie popsané výše. Pozn.: Na tomto diagramu chybí vrstva sítí.
Příklad diagramu technologických platforem
Příklad 15 – Diagram technologického portfolia
Portfolio by mělo indikovat, jaké technologie jsou použité, aby bylo možné jejich analýzou dojít k závěru, zda pokrývají potřeby úřadu v technologické oblasti, případně zda nejsou zbytečné duplicity. Níže je uveden obrázek portfolia technologií zaměřený na indikaci dostupných prostředí a dostupných technologických platforem (převážně virtuálních) a úložišť.
Příklad mapy technologického portfolia – L012)
Příklad referenčních rámců pro možné členění prvků technologické architektury:
Klasifikační rámec technologické architektury (L0)
Klasifikační rámec technologické architketury L2
Architektura komunikační infrastruktury
V této části je popsané, jakým způsobem je úřad propojen s dalšími úřady, sdílenými službami eGovernmentu (příp. zahraničními službami) a se svými klienty.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Technologická architektura komunikační infrastruktury úřadu | * Vybavení lokací * Diagram komunikační infrastruktury | * Cílem je ukázat umístění prvků infrastruktury a komunikační cestu mezi nimi a do okolí * Dále je důležité ukázat topologii sítí, prvky zabezpečení, zálohování a monitoringu komunikace |
Příklad 16 – Diagram komunikační infrastruktury
Diagram komunikační infrastruktury13)
Příklad 17 – Diagram přehledu a vybavení lokací
Diagram přehledně ukazuje jednotlivé lokace, ve kterých jsou umístěná datová centra a hlavní technické a komunikační vybavení. V ideálním případě by měly být akcentovány technologické služby a funkce nabízené danou lokací. Diagram uvádí naznačené funkce virtualizace, cluster managementu a zálohování (backup). Pozn.: V tomto konkrétním příkladu chybí elementy síťové komunikace, které by měly na takovémto přehledovém diagramu být.
Příklad přehledu a vybavení lokací14)
Jiné příklady:
Klasifikační rámec Infrastrukturní architketury L0
Klasifikační rámec infrastrukturní architektury L2. Diagram ukazuje možné aspekty pro členění (klasifikaci) technologického portfolia. Může posloužit jako inspirace
Přehled projektů
Obsah této části lze čerpat z architektury implementace a migrace, která je vhodná pro modelování roadmapy rozvoje architektury podniku a může obsahovat zajímavé informace o plánovaných projektech.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Přehled projektů | * Pohled migrace | Pokud je aplikovaná metodika Architektury implementace a migrace15), je možné jako pomůcku použít přehled Balíčků práce (programy/projekty) |
Motivace ke změně
Tato část se věnuje úřadu z pohledu jeho poslání, identifikovaných nedostatků a potřeby změn vůči stávajícímu stavu. Model v podobě jednoho nebo více diagramů je pro IK OVS dobrovolně volitelný.
Tuto část lze pojmout jako analýzu, jejíž výsledek je zapsán do dokumentu IK. Zároveň je možné toho využít k tvorbě či aktualizaci modelu architektury strategie a směřování16) úřadu, kde budou důležité prvky zapsané.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Poslání a kompetence úřadu | * Přehled Zainteresovaných osob a Hnacích prvků * Katalogy Zainteresovaných stran, Veřejných potřeb/hnacích prvků, Strategických cílů, Vyhodnocení potřeb/analýz | * Z pohledu identifikace důvodů pro změny jsou důležité elementy Veřejná potřeba a Vyhodnocení potřeby. * Klíčové je navázání těchto motivátorů na dotčené elementy z vrstvy strategie a byznysu (zejména Agendy a Činnosti, příp. Schopnosti úřadu) * Pro lepší pochopitelnost je vhodné vložit i diagramy s přehledem strategických a motivačních elementů samostatně |
| Strategické cíle úřadu | * Přehled Zainteresovaných osob a Hnacích prvků * Katalog Strategických cílů úřadu | * Vizualizujeme zde navázání motivátorů změn výše na identifikované Strategické cíle úřadu * Namodelováním těchto vazeb lépe definujeme dopad změn do cílů |
| Externí byznys požadavky | * Katalog Veřejných potřeb/hnacích prvků | * Externí mají zdroj mimo úřad, jedná se o legislativu či požadavky jiných úřadů * Externí požadavky mohou být systematicky evidované jako Hnací prvky (drivery) * Důležité je popsat dopad na úřad |
| Interní byznys požadavky | * Katalog Vyhodnocení potřeb/analýz | * Interní požadavky vznikají obvykle jako výstup vnitřních auditů, analýz či vyhodnocení výkonnosti procesů v rámci úřadu * Interní požadavky je možné evidovat jako Vyhodnocení potřeby/analýzy (assesment) |
| Vliv moderních trendů na změny | * Katalog Veřejných potřeb/hnacích prvků | * Trendy mají zdroj mimo úřad, mohou být systematicky evidované jako Hnací prvky (drivery) * Důležité je popsat dopad na úřad |
| Dopady byznys požadavků a strategických cílů úřadu na ICT | * Matice pokrytí Hnacích prvků pomocí Strategických cílů | * Pro jasnou představu o dopadech lze využít informací v modelu a připravit matici ukazující vazby mezi požadavky (Hnací prvky, Vyhodnocení potřeb) a Strategickými cíli. Z nich lze pak dobře identifikovat dopady do oblasti ICT |
| Cíle ICT strategie | * Katalog Veřejných potřeb/hnacích prvků * Katalog Vyhodnocení potřeb/analýz | * Může to být podmnožina Veřejných potřeb/hnacích prvků a Vyhodnocení potřeb/analýz z oblasti ICT |
| Hodnocení ekonomické výhodnosti provozu, způsobu provozu a přínosů IS | * Katalog Vyhodnocení potřeb/analýz | * Informace o provedených hodnoceních a jejich výsledcích lze využít na vybudování modelu Vyhodnocení potřeb/analýz, které pak jsou vstupem pro interní požadavky na zlepšení |
| Shoda s cíli Informační koncepce ČR | * Katalog Veřejných potřeb/hnacích prvků | * Cíle IK ČR lze případně použít jako zdroj pro identifikované Veřejné potřeby/hnací prvky z oblasti IK ČR a projekty, které je realizují, lze modelovat jako Balíčky práce |
| Dopady principů Informační koncepce ČR do digitalizace úřadu | * Realizace strategických elementů pomocí Klíčových požadavků a Omezujících podmínek * Katalog Architektonických principů * Katalog Klíčových architektonických požadavků a Omezujících podmínek | * Lze využít informace o modelovaných Architektonických principech IK ČR a jejich vazby na Klíčové architektonické požadavky, příp. Balíčky práce, které je realizují |
| Model motivační architektury úřadu | * Přehled Zainteresovaných osob a Hnacích prvků * Přehled Architektonických principů | * Přehledové diagramy ukazující celou šíři motivační architektury – úroveň L0. |
| Shrnutí a interpretace potřebných změn architektury | * Katalog Veřejných potřeb/hnacích prvků * Katalog Vyhodnocení potřeb/analýz * Katalog Balíčků práce | * Výčet motivátorů ke změnám, doplněný o projektově orientované informace a prioritu. * Pokud je k dispozici přehled Balíčků práce relevantních pro cílový stav architektury, lze jej také použít jako zdroj. |
Příklad 18 – Přehled Zainteresovaných osob a Hnacích prvků
Diagram ukazuje na nejvyšší úrovni přehled zainteresovaných osob, jejichž zájmy jsou reprezentované hnacími prvky a výstupy analýz. Z nich pak vycházejí cíle, které je naplňují.
Přehled Zainteresovaných osob a Hnacích prvků
Na diagramu níže je hezky vidět hierarchie Zainteresovaná osoba → Hnací prvek → Strategický cíl. Všimněte si elementů reprezentující zákonné předpisy v podobě Požadavků. Pro modelování předpisů samotných je vhodné použít element Předpis (Contrack v ArchiMate), ale je možné je modelovat i pomocí Požadavků.
Příklad přehledu Zainteresovaných osob a Hnacích prvků (model motivační vrstvy úřadu)17)
Příklad 19 – Přehled Zainteresovaných osob a Hnacích prvků
Tento příklad je rozšířený o požadavky a principy ve spodní části.
Příklad přehledu Zainteresovaných osob a Hnacích prvků18))
Cílový stav
Cílový stav architektury úřadu by měl adresovat motivace ke změně popsané výše a vymezit se vůči současnému stavu. Pro účely tvorby dokumentu IK je vhodné zvolit přístup, kdy k jednotlivým diagramům či jiným pohledům použitým v popisu stávajícího stavu (kap. 3.1) vzniknou jejich analogy poplatné stavu cílovému s vyznačením změn. Tato myšlenka je podpořená v obecné metodice modelování v části s popisem architektury implementace a migrace19), kde je vysvětlen tento koncept (k cílovému stavu architektury by měly být vztažené diagramy ilustrující změnu oproti současnému stavu). Doporučujeme tento přístup posílit tím, že část modelu obsahující implementaci a migraci bude vznikat již s ohledem na využití v IK, včetně identifikovaných stavů architektury, gapů a balíčků práce. Jeden ze stavů architektury by měl reprezentovat cílový stav dle IK a na něj by měly být vztažené příslušné diagramy.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Architektonická vize úřadu | * Zjednodušené pohledy na všechny vrstvy architektury | * Vizi úřadu je vhodné doplnit o diagramy ilustrující hlavní myšlenky čtenáři * Diagramy mohou být na každé z úrovní architektury, podle oblasti a povahy ilustrovaných myšlenek. * Forma by měla být maximálně přizpůsobena pro hladké předání myšlenky čtenáři. * Systematické navázání na motivační vrstvu architektury (Stavy architektura v roadmapě) lze optimálně řešit pomocí navázání jednotlivých „core“ elementů na dané stavy architektur. Vyžaduje to však systematický přístup při modelování a ideálně pokročilý modelovací nástroj, který toto dokáže dobře vizualizovat. |
| Návrh cílové byznys architektury | * Mapa služeb VS * Mapa procesů a funkcí | * Využijte stejné pohledy, jako v popisu stávajícího stavu v IK a aktualizujte je tak, aby obsahovaly i elementy relevantní pro cílový stav. * Nové elementy přidejte do modelu a zajistěte, aby se vyskytly pouze na diagramech cílového stavu. * Vyznačte vizuálně (barevnou konvencí dle metodiky20)) typ změny pro každý element: Beze změny, Nové, Změněné, Zrušené (lze řešit i jejich odstraněním, ale doporučujeme v tom případě jasně napsat do popisu diagramu, že se ruší) |
| Návrh cílové aplikační a datové architektury | * Mapa aplikačních komponent * Diagram objektů VS | * Stejně jako u byznysové architektury, využijte i zde diagramy z popisu stávajícího stavu, udělejte jejich verzi platnou pro cílový stav a vyznačte změny. |
| Využití klíčových sdílených služeb eGovernmentu a externích IS | * Katalog aplikačních komponent * Katalog aplikačních služeb | * Ukažte cílovou množinu využívaných sdílených služeb ve stejné formě jako je v popisu stávajícího stavu. * Popište změny ve využití konkrétních sdílených služeb. |
| Publikace služeb | * Katalog aplikačních komponent * Katalog aplikačních služeb | * Nezapomeňte elementy reprezentující poskytovanou sdílenou službu doplnit příznakem sdílené služby pro automatizaci. |
| Návrh cílové IT technologické architektury | * Diagram topologie datových center * Technologické platformy | * Stejně jako u byznysové architektury, využijte diagramy z popisu stávajícího stavu, udělejte jejich verzi platnou pro cílový stav a vyznačte změny. |
| Návrh cílové komunikační technologické architektury | * Vybavení lokací * Diagram komunikační infrastruktury | * Stejně jako u byznysové architektury, využijte diagramy z popisu stávajícího stavu, udělejte jejich verzi platnou pro cílový stav a vyznačte změny. |
Obrázek níže ukazuje barevnou notaci použitou pro indikaci změn proti současnému stavu na diagramech cílového stavu pro daný stav architektury.
Možná barevná notace pro indikaci změn na diagramech (zde pomocí barvy okrajů, lze ale také přebarvit celou plochu objektu)
Ke každému stavu architektury by měla být přiložena sada přehledových diagramů, které demonstrují, jaké změny nastanou vůči předchozímu stavu v byznysové, aplikační a technologické architektuře.
Příklad 20 – Cílový stav aplikační architektury
Následující diagram ukazuje příklad vybraného cílového stavu architektury na aplikační úrovni (týká se práce s daty v úřadu). Všimněte si použití barevné konvence, která je pro čtenáře navíc popsaná v legendě k diagramu.
Cílový stav aplikační architektury
Plán realizace změn
Tato část se obsahově významně kryje s modelem Architektury implementace a migrace. Toho lze využít k jeho vytvoření či aktualizaci a získat z modelu informace pro dokument IK. V modelu by měly existovat Stavy architektury reprezentující stávající a cílový stav popsaný v IK. Informace na ně navázané pak tvoří většinou potřebné údaje pro tuto část IK. Z modelů cílové architektury lze využít Balíčky práce, které poslouží jako zdroj pro identifikaci realizačních projektů.
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Návrh strategie implementace | * Pohled migrace | * Je vhodné dát diagramu podobu vhodnou pro prezentaci jako roadmapa. Časové měřítko je možné doplnit pomocí poznámek. * V případě prezentace pomocí Gantova diagramu však doporučujeme využít vizualizaci v nástroji, který je k tomuto účelu přímo určen. |
| Přehled všech běžících i plánovaných projektů/programů | * Projektový pohled | * Balíčky práce reprezentují projekty či programy. To lze použít jako základ pro přehled projektů. * Informace o stavu rozhodně není doporučeno držet v modelu! K tomu slouží specializované nástroje a není to v gesci podnikového architekta. |
| Předpoklady úspěšné realizace plánovaných projektů/programů | * Předpoklady mohou být modelované, obvykle ale bude dostačující slovní vyjádření přesně vystihující kontext daného projektu. Vytvořené balíčky práce by měly obsahovat předpoklady pro zahájení práce na každém z nich. | |
| Způsob financování projektů/programů a provozu ICT | Pozn.: Tyto informace by neměly být součástí modelu podnikové architektury. |
Koncepce řízení služeb ICT
Tato část může být pojatá jako podmnožina modelu úřadu, který popisuje oblast ICT. Je tedy možné využít stejné postupy, informace a pohledy, jako jsou popsané v kapitolách výše s tím, že při modelování je vhodné chápat ICT jako oblast a dělat pro ni samostatné pohledy či sekce v modelu.
Stávající stav
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Popis stávajícího stavu řízení informatiky | * Mapa služeb VS * Mapa procesů a funkcí | * Pro účely IK postačí uvést diagram služeb ICT a rozsahu spravovaných komponent a aktuální plnění SLA |
| Zhodnocení stavu a metod řízení životního cyklu IS | * Mapa procesů a funkcí | * Zhodnocení stavu řízení změn a životního cyklu IS je možné se odkázat na mapu procesů, pokud jsou tyto procesy namodelovány. V každém případě by mělo být monitorováno řešení byznys požadavků. |
| Strategie, plánování a organizace řízení informatiky | * Organizační struktura * Mapa služeb VS * Mapa procesů a funkcí | * Připravované byznysové změny se projeví v modelování architektur. Tyto změny budou promítnuty do nové informační koncepce spolu se zdůvodněním požadavků ICT na zajištění služeb úřadu v požadované kvalitě. |
| Přehled běžících a schválených projektů pro řízení ICT | * Projektový pohled | * Balíčky práce reprezentují projekty či programy. To lze použít jako základ pro přehled projektů. * Informace o stavu rozhodně není doporučeno držet v modelu! K tomu slouží specializované nástroje a není to v gesci podnikového architekta. |
| Shrnutí potřeb ze stávajícího stavu | * Katalog Vyhodnocení potřeb/analýz | * Model lze případně doplnit o elementy typu Vyhodnocení potřeb, které budou reflektovat informace zde obsažené |
Příklad 21 – Diagram přehledu procesů v oblasti řízení ICT
Na diagramu je vidět kategorizovaný přehled procesů použitých v řízení ICT úřadu, postavený na základě metodiky COBIT. Pozn.: Použití elementů procesů jako seskupovacích prvků není doporučeno, doporučujeme na diagramu využít element Grouping z ArchiMate.
Diagram přehledu procesů v oblasti řízení ICT.
Motivace ke změně
| Sekce v IK | Využitelné pohledy z modelu | Poznámka |
|---|---|---|
| Popis důvodů pro změny řízení informatiky | * Katalogy Zainteresovaných stran, Veřejných potřeb/hnacích prvků, Strategických cílů, Vyhodnocení potřeb/analýz | * Lze využít informací v modelu z oblasti architektury strategie a směřování21), a to jak pro inspiraci pro použití v IK, tak i opačně pro aktualizaci modelu. |
| Shoda se zásadami řízení ICT z IKČR | * Přehled Architektonických principů * Matice mapování principů na cíle a požadavky | * V modelu lze identifikovat motivační elementy typu Strategický cíl či Klíčový arch. požadavek, které realizují daný uvedený princip a váží se na něj. |
| Shrnutí a interpretace identifikovaných změn řízení ICT | * Projektový pohled | * Balíčky práce reprezentují záměry (budoucí projekty). To lze použít jako základ pro přehled. |
Cílový stav
Zde by měl být postup totožný s částí popisující cílový stav architektury úřadu (kap. 3.1.3), jen s omezením na oblast řízení ICT a témata:
- řízení životního cyklu IS,
- strategie, plánování a řízení informatiky,
- způsob spolupráce s ostatními útvary úřadu,
- způsob spolupráce s centrálními autoritami v oblasti ICT a eGovernmentu.
Plán realizace změn
Zde by měl být postup totožný s částí popisující plán realizace změn celé architektury úřadu (kap. 3.1.4), jen s omezením na oblast řízení ICT a témata výše.
Přehled příkladů v dokumentu
Příklad 1 – Mapa služeb VS
Příklad 2 – Služby veřejné správy úřadu
Příklad 3 - Mapa procesů a funkcí
Příklad 4 – Členění procesů a funkcí dle domén
Příklad 5 – Diagram Organizační struktury
Příklad 6 – Diagram organizační struktury se zanořováním
Příklad 7 – Využití seskupování podle vybraného aspektu
Příklad 8 – Mapa schopností úřadu
Příklad 9 – Diagram Objektů VS
Příklad 10 – Členění přehledu aplikačních komponent
Příklad 11 – Členění přehledu aplikačních komponent dle oblasti využití
Příklad 12 – Diagram struktury aplikací
Příklad 13 – Diagram topologie datových center
Příklad 14 – Diagram platforem
Příklad 15 – Diagram technologického portfolia
Příklad 16 – Diagram komunikační infrastruktury
Příklad 17 – Diagram přehledu a vybavení lokací
Příklad 18 – Přehled Zainteresovaných osob a Hnacích prvků
Příklad 19 – Přehled Zainteresovaných osob a Hnacích prvků
Příklad 20 – Cílový stav aplikační architektury
Příklad 21 – Diagram přehledu procesů v oblasti řízení ICT
Seznam použitých zkratek
| Zkratka | Význam |
|---|---|
| AA | Aplikační architektura |
| AKI | Architektura komunikační infrastruktury |
| BA | Byznys architektura |
| COBIT | Control Objectives for Information and Related Technologies (framework pro řízení IT) |
| DA | Datová architektura |
| DC | Datové centrum |
| DIA | Digitální informační agentura |
| IaaS | Infrastructure as a Service (infrastruktura jako služba) |
| IK | Informační koncepce |
| IS | Informační systém |
| ISVS | Informační systémy veřejné správy |
| IT | Informační technologie |
| NAR | Národní architektonický rámec |
| OVM | Orgán veřejné moci |
| OVS | Orgán veřejné zprávy |
| PaaS | Platform as a Service (platforma jako služba) |
| RPP | Registr práv a povinností |
| SaaS | Software as a Service (software jako služba) |
| SLA | Service Level Agreement (dohoda o úrovni poskytovaných služeb) |
| SW | Software |
| TA | Technologická architektura |
| VS | Veřejná správa |
Diskuze