Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu

Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu Odbor Hlavního architekta egovernmentu MV Praha, Únor 2016 verze 4.01

Obsah Úvodní informace a pokyny... 4 1. Základní podmínky projektu... 5 1.1. Úvodní informace zpracovatele žádosti... 5 1.2. Charakteristika projektu... 5 1.3. Souhlasy zpracovatele... 6 2. Architektonické informace o projektu... 7 2.1. Naplnění Strategických cílů rozvoje ICT služeb... 8 2.2. Dodržení architektonických principů NA VS ČR... 9 2.3. Enterprise architektura projektu dle pravidel NA VS ČR... 11 2.3.1. Motivační architektura strategie a směrování... 13 2.3.2. Efektivita projektu výkonnostní architektura... 14 2.3.3. Byznys architektura - poskytování veřejných služeb... 15 2.3.4. Architektura informační systémů... 17 2.3.5. Technologická architektura vrstva IT technologie (HW a SW)... 18 2.3.6. Technologická architektura vrstva komunikační infrastruktury... 18 2.3.7. Bezpečnostní architektura... 19 2.3.8. Shoda s pravidly, standardizace a dlouhodobá udržitelnost... 20 2.3.9. Přehled služeb čtyřvrstvé architektury... 21 2.4. Architektura (pozice) navrhovaného řešení v kontextu strategické architektury úřadu a navazujících subjektů veřejné správy... 22 2.4.1. Pozice řešení v byznys architektuře úřadu... 23 2.4.2. Pozice řešení v architektuře informačních systémů úřadu... 23 2.4.3. Pozice řešení v IT technologické architektuře úřadu... 24 2.4.4. Pozice řešení v komunikační infrastruktuře úřadu... 25 2.5. Architektura (pozice) navrhovaného řešení v kontextu egovernmentu - způsob využití sdílených prvků architektury úřadu a egovernmentu... 26 2.5.1. Využití sdílených prvků egovernmentu v byznys architektuře úřadu... 27 2.5.2. Využití sdílených prvků egovernmentu v architektuře IS úřadu... 27 2.5.3. Využití sdílených prvků egovernmentu v IT technologické architektuře úřadu... 28 2.5.4. Využití sdílených prvků egovernmentu v komunikační infrastruktuře úřadu... 28 2.6. Architektura řešení projektu... 29 2.7. Plán dlouhodobého rozvoje architektury projektu (Roadmapa)... 30 2.7.1. Etapy a milníky plánu zavedení architektury projektu... 31 2.7.2. Ostatní klíčové milníky úřadu související s projektem... 31 2.7.3. Ostatní klíčové milníky egovernmentu související s projektem... 31 3. Další údaje o projektu... 32 3.1. Potřebnost a výstupy projektu... 32 3.2. Připravenost projektu k realizaci... 32 3.2.1. Technická připravenost projektu... 32 2

3.2.2. Finanční připravenost projektu... 32 3.2.3. Personální připravenost projektu... 32 3.2.4. Metodická připravenost projektu... 33 3.3. Podmínky a průběh realizace projektu... 33 3.4. Ekonomické parametry projektu... 33 3.4.1. Hodnota výdajů a ekonomická náročnost projektu.... 33 3.4.2. Personální náročnost projektu... 35 3.5. Analýza rizik a negativních důsledků... 36 3.5.1. Identifikace rizik neúspěchu projektu... 36 3.5.2. Identifikace negativních důsledků projektu... 36 3.6. Plán údržby, dlouhodobá udržitelnost výstupů projektu... 36 3.6.1. Plánovaná životnost jednotlivých výstupů projektu... 36 3.6.2. Plánovaná péče o výstupy projektu v jednotlivých letech životnosti... 36 3.6.3. Připravenost na řízené ukončení životnosti výstupu projektu a případný přechod na další řešení. 36 4. Přehled Požadovaných výjimek... 37 4.1. Výjimky z naplnění cílů Strategie rozvoje ICT služeb... 37 4.2. Výjimky z dodržení architektonických principů... 37 4.3. Výjimky z požadavku na využití sdílených prvků architektury úřadu... 37 4.4. Výjimky z požadavku na využití sdílených prvků egovernmentu ČR... 37 4.5. Výjimky z dodržení architektonických vzorů... 37 5. Upozornění a doporučení... 38 6. Přílohy... 38 6.1. Příloha 1: Vzor žádosti o udělení výjimky... 38 Historie verzí Verze Datum Poznámky k verzi 3.7 30.12.2015 Verze schválená OHA. 3.8 4.1.2016 Změny v konzistenci dokumentů formuláře a pokynu. 3.9 6.1.2016 Úpravy pravopisu 4.0 15.1.2016 Úpravy popisu tabulky byznys architektury, tabulky shody s předpisy a popisu zainteresovaných osob, zapracované zpřesnění postupu odhadu hodnoty projektu a TCO 4.01 4.2.2016 Úprava podpisových doložek 3

Ú V O D N Í I N F O R M A C E A P O K Y N Y Vzor žádosti, který dostáváte do ruky, vznikl na základě úkolu uloženého ministru vnitra usnesením vlády České republiky ze dne 2. 11. 2015 č. 889 k dalšímu rozvoji informačních a komunikačních technologií služeb veřejné správy, vč. přílohy č. 2 - Základní zásady postupu pro při čerpání finančních prostředků na výdaje související s informačními a komunikačními technologiemi s hodnotou více než 6 mil. Kč ročně. Vzor žádosti se sestává ze dvou samostatných dokumentů a) Formulář žádosti o stanovisko Hlavního architekta egovernmentu b) Metodický pokyn k vyplnění formuláře žádosti o stanovisko Hlavního architekta egovernmentu (tento dokument). Žádost je podána MVČR, Odboru Hlavního architekta egovernmentu (OHA) do datové schránky ID: 6bnaawp. Přílohou Žádosti je vyplněný formulář. Proces posuzování projektů je následující. OHA zkontroluje kompletnost žádosti, v případě nedostatků si vyžádá doplnění, a rozhodne o délce lhůty: Základní projekty lhůta na schválení do 30 kalendářních dnů nebo Složité projekty lhůta na schválení do 60 kalendářních dnů Lhůta na vyřízení začíná běžet převzetím kompletní žádosti. V průběhu posouzení si OHA může vyžádat doplnění nebo vysvětlení ze strany Žadatele, po tuto dobu je běh lhůty pozastaven. OHA vydá stanovisko, které zašle zpět prostřednictvím ISDS na adresu původního Žadatele. Pro urychlení vyřízení je možné, v odůvodněných případech, konzultovat projekt ještě před podáním žádosti samotné. Způsob vyplnění Formuláře žádosti. Formulář žádosti obsahuje dva typy položek k vyplnění: tabulku, do které vkládejte požadované informace do příslušných buněk, prostor pro vložení diagramu, označený <zde vložte diagram(y)>. Vzor žádosti (Formulář i Metodický pokyn) jsou univerzálně použitelné a robustní tak, aby pokryly celé spektrum možných projektů, na které se vztahuje schvalovací povinnost. Vzor žádosti je nutno aplikovat pro každý projekt individuálně a metodické postupy použít přiměřeně ke složitosti a zaměření projektu. V případě, že není, ta která část Formuláře, pro váš projekt nebo kontext projektu relevantní, uveďte není relevantní, aby bylo zřejmé, že jste položku záměrně nevyplnili z důvodu, že nemá smysl. V případě, že váš projekt není v souladu s: a) strategickými cíli rozvoje služeb VS a ICT služeb 1 b) architektonickými principy Národní architektury VS, viz kap 2.2 Vzoru žádosti c) architektonickými vzory sdílených služeb egovernmentu 2, ale přesto existuje objektivní důvod realizovat jej žádaným způsobem, uveďte do předmětné části formuláře, že žádáte o výjimku, a pro každou takovou vyplňte žádost o udělení výjimky, kterou naleznete v příloze č. 1 Formuláře žádosti. 1 Viz. Strategie rozvoje ICT služeb veřejné správy a její opatření na zefektivnění ICT služeb, přijatá usnesením vlády ze dne 2.11.2015 č. 889 2 http://www.mvcr.cz/soubor/architektonicke-vzory-sdilenych-sluzeb-egovernmentu-pdf.aspx 4

1. Z Á K L A D N Í P O D M Í N K Y P R O J E K T U Podkapitoly této úvodní kapitoly mají charakter hlavičky či krycího listu celé žádosti o stanovisko OHA. Nachází se v nich vše podstatné o projektu na jediný pohled. 1.1. Úvodní informace zpracovatele žádosti Zde uveďte základní identifikační údaje Vaší organizace, která podle usnesení vlády vystupuje současně jako žadatel i jako zpracovatel. Obchodní jméno, sídlo, IČO a kód organizace zpracovatele. Jméno, příjmení a kontakty na statutárního zástupce. Jméno, příjmení a kontakty na kontaktní osobu pro projekt. Jméno, příjmení a kontakty na architekta/architekty projektu. Datum vypracování. Kód organizace je jednoznačné písmenné označení organizace veřejné správy, dostupné například v rámci údajů seznamu datových stránek na portálu veřejné správy zde: https://seznam.gov.cz/ovm/osslist.do a jeho údaj se nachází po rozkliknuti organizace na záložce doplňkové údaje. Statutárním zástupcem se pro účely žádosti o výjimku myslí osoba, oprávněná podpisovým řádem úřadu schválit a podat takovou žádost. 1.2. Charakteristika projektu Zde uveďte výpis souhrnných údajů Vašeho projektu ze žádosti: Název projektu. Hlavní cíl projektu. Zainteresovaní - Kdo má hlavní zájem 3 na úspěchu projektu. Místo realizace projektu. Termíny plánovaného zahájení a dokončení realizace projektu. Shrnutí synergických nebo komplementárních vazeb projektu. Shrnutí shody se základními principy Národní architektury egovernmentu. Určení věcného správce, technického správce a provozovatele. 4 Externí výdaje na ICT spojené s projektem 5 - roční průměr a počet let pro roční průměr Externí výdaje na ICT spojené s projektem za 5 let Celkové náklady vlastnictví (TCO) za 5 let 6 Personální náročnost. Jako zainteresované zde do souhrnu uveďte ty vybrané osoby, nejčastěji v úřadu zpracovatele, které mají zájem a současně vliv na úspěch projektu, tj. zejména tzv. sponzora a případně několik dalších. Plný seznam klíčových zainteresovaných uveďte v kapitole 2.3.1. Definice: Při uplatnění všech, v metodice TCO uvedených principů, na odstavec d) citovaných Základních zásad platí, že projekt (záměr) se stává relevantním pro povinnost podat žádost o stanovisko OHA tehdy, pokud souhrn všech nově zamýšlených, s vlastnictvím nebo užíváním nového řešení, nebo jeho nové části, spojených externích výdajů na přípravu, pořízení, úpravu, zavedení a 5 leté (případně kratší) období užívání, udržování a rozvíjení ICT služby k žádosti předmětného řešení přesáhne hodnotu 30 mil. Kč bez DPH (případně úměrně době užívání hodnotu alikvotně nižší), resp. roční průměr takových souhrnných výdajů, vztažený k rozhodné době užívání služby (5, případně méně let) přesáhne hodnotu 6 mil. Kč bez DPH ročně. 3 Z angl. Stakeholders, zainteresovaní na projektu 4 Jednotlivé role jsou definovány ve Strategii rozvoje ICT služeb VS a její opatření na zefektivění služeb kapitola 5.1 str. 15 5 Podle Čl. 2, odst. d) Přílohy 2 usnesení vlády ze dne 2. listopadu 2015 č. 889: Základní zásady postupu při čerpání finančních prostředků na výdaje související s informačními a komunikačními technologiemi s hodnotou vyšší než 6 mil. Kč ročně. 6 Podle Čl. 2, odst. e) tamtéž 5

Relevantní pro žádost (ani pro výpočet její hodnoty) tedy nejsou takové budoucí výdaje, které již plynou z dříve uzavřených závazků (smluv) zpracovatele žádosti, například opakovaná platba licence na údržbu, protože nepředstavují žádný nový záměr. Pro vyplnění odhadu průměrných plánovaných výdajů projektu uveďte údaj, odpovídající podílu souhrnu všech externích výdajů za období přípravy a za deklarovaný počet let užívání ICT služby a tohoto počtu let. Jako odhad celkové hodnoty projektu za 5 let (nebo výjimečně kratší dobu životnosti projektu) uveďte souhrnný údaj externích výdajů použitý pro nalezení ročního průměru. Pro stanovení souhrnu plánovaných výdajů použijte libovolnou účelovou, druhovou (účetní 7 ) či jinou strukturu výdajů, která Vám pomůže snadno a správně nalézt odhad výdajů, odpovídající plně výše uvedené definici. Takto můžete postupovat zejména tehdy, máte-li pocit, že váš záměr hranici relevance pro žádost o stanovisko OHA nepřekročí a vy tedy pravděpodobně nebudete plánovat kompletní TCO v dalších pasážích žádosti. Tento odhadovaný souhrn výdajů bude při zpracování žádosti následně, jakožto externí náklady, rozdělen při plánování TCO do jednotlivých nákladových kategorií podle životního cyklu řešení v tabule TCO, viz kap 3.4 Formuláře žádosti, sloupec 3 kapitola 3.4.1. Pokud je z velikosti řešení zjevné, že budete podávat žádost, doporučujeme obrácený postup. Začněte připravovat žádost, její architekturu, její roadmapu a kompletní plán TCO, interních a externích nákladů. Pak vezměte součet externích výdajů ve sloupci 3 z tabulky v kapitole 3.4.1 a tuto hodnotu uplatněte jako rozhodnou hodnotu výdajů pro relevanci žádosti v přehledové tabulce v kapitole 1.2 Formuláře žádosti, jak v celkové výši, tak ji použijte pro výpočet průměru za rozhodnou dobu. Jako celkové náklady vlastnictví za 5 let (nebo případně skutečnou kratší, výše uvedenou rozhodnou dobu, odpovídající životnosti řešení) v této souhrnné tabulce uveďte hodnotu součtového řádku ve sloupci 4 tabulky TCO v kapitole 3.4.1. Rozhodnou dobou 5 let (nebo v odůvodněných případech méně) se myslí doba skutečného (produktivního) užívání ICT služby, ať již byla služba pořízena jakkoli. U řešení, jehož potřeba (podporovaná veřejná služba) pomine dříve než za 5 let nebo jehož životnost skončí dříve, a to bez náhrady navazujícím řešením, tj. u nějž přestane být ICT služba využívána dříve než za 5 let, se jako doba TCO, a jako rozhodná doba pro výši výdajů pro žádost o stanovisko OHA, uvažuje tato skutečná kratší doba užívání (provozu). Tato kratší doba slouží v tom případě také pro výpočet odpovídajících průměrných ročních výdajů Všechny finanční hodnoty výše jsou myšleny bez DPH. 1.3. Souhlasy zpracovatele Zde uveďte souhlasy osob zodpovědných za projekt v uvedených rolích, s obsahem a podáním žádosti o stanovisko OHA: Souhlas sponzora (doporučený) Souhlas ředitele informatiky Souhlas statutárního zástupce úřadu Sponzorem se stejně jako v předchozí kapitole myslí klíčový stakeholder, ten/ta, kdo má největší zájem na úspěchu projektu, aktivně v jeho prospěch vystupuje a ve své manažerské pozici může zásadními rozhodnutími a podporou úspěch projektu ovlivnit. Tyto podpisové doložky můžete vyplnit různými způsoby: 1) Vyplnit jména a datumy a soubor následně podepsat elektronicky 2) Vytisknout pouze danou stránku, vyplnit a podepsat ručně a následně vložit zpět do dokumentu jako přílohu 7 Například podle tabulky rozpočtové skladby ICT projektu dle NKÚ, kterou některé úřady pro takový účel používají. 6

2. A R C H I T E K T O N I C K É I N F O R M A C E O P R O J E K T U V této kapitole jsou uvedeny informace o všem, co ovlivňuje motivaci a obsah předkládaného projektu, zejména pak všechny aspekty struktury a chování části úřadu, zahrnuté do projektu. Dále pak kontext architektury úřadu ve vztahu ke sdíleným službám egovernmentu. Ostatní atributy definice projektu se nacházejí v kapitole 0-7

Další údaje o projektu. Struktura architektonické části dokumentu vychází ze struktury domén obsahu Národní architektury VS ČR, viz také Metodika modelování NA VS ČR 8. Tato struktura se skládá ze čtyř základních bloků informací. Vertikální domény představují všechny formy (složky) motivace organizace ke konání veřejné služby a k její změně. Jsou to: Strategie a směrování Kam chceme jít? - jaké politiky si úřad naplánoval a proč Výkonnost a jakost Jak dobří chceme být v tom, co děláme? jaká máme měřítka výkonnosti a jakosti Rizika a bezpečnost Čeho se chceme vyvarovat a jak se proti tomu bráníme? Shoda s pravidly, standardizace a udržitelnost Jaká pravidla jsme si pro svou cestu stanovili (či nám byla dána)? Další oblastí informací o struktuře a fungování úřadu je vlastní výkon všeho, co dělá. Tedy: Kdo jsme a co děláme? To je obsaženo ve žluté vrstvě tzv. byznys architektury, zde zvané opisem Architektura výkonu a provozu veřejné správy. Třetí nezbytnou součástí úřadu jsou jeho zdroje, aktiva (majetek, lidé a znalosti), potřebná pro tyto činnosti. Zde, při použití architektury pro podporu řízení IT projektů se jedná pouze o tzv. informační a technologická aktiva, modelovaná v tyrkysových a zelených horizontálních vrstvách architektury. Poslední oblastí architektonických informací je tzv. Roadmapa, tedy plán cesty k cílové architektuře úřadu přes jednotlivé klíčové milníky a jejich přechodné architektury. Tato struktura obsahu architektury se uplatní jak při popisu obsahu projektu, tak v širších kontextech celého úřadu, jeho resortu či krajské korporace a celého českého egovernmentu a vybraných prvků z EU. Souhrn těchto všech tvoří tzv. Národní architekturu veřejné správy ČR. Pro zjednodušení struktury žádosti jsou některé vyšší architektury vynechány. Pokud je to důležité, připište informace o resortu a korporaci k architektuře úřadu a informace o EU k architektuře egovernmentu. Pro účely této Žádosti o stanovisko, jsou pro zjednodušení u popisu širšího kontextu projektu také vynechány motivační, vertikální domény architektury, viz následující schéma. Zde jsou do jednotlivých oblastí obsahu vepsána odpovídající čísla kapitol Žádosti: 8 Metodika je společně s ostatními materiály k Žádosti dostupná na webových stránkách http://www.mvcr.cz/clanek/hlavni-architektegovernmentu.aspx 8

Pod bloky tzv. Enterprise architektury (architektury úřadu a širšího kontextu), které odpovídají na existenciální otázku: Co je, respektive co bude?, se nachází blok tzv. architektur řešení, které odpovídají na otázku: Jak to funguje, respektive má fungovat? Architektura řešení je však v této Žádosti, na rozdíl od například Zadávací dokumentace podle Zákona o veřejných zakázkách, vyžadována pouze v minimální míře, slouží pro prokázání, zda a jakým způsobem se v architektuře budoucího řešení uplatní povinné Architektonické vzory sdílených služeb egovernmentu, které mírou svého detailu odpovídají právě architektuře řešení. 2.1. Naplnění Strategických cílů rozvoje ICT služeb Všechny předkládané ICT projekty po 1. 1. 2016 již musí odpovídat duchu i znění platné ICT strategie státu, kterou je aktuálně Strategie rozvoje ICT služeb veřejné správy a její opatření na zefektivnění veřejných služeb, schválená vládou ČR dne 2. 11. 2015, usnesením č. 889. 9 Uveďte, zda a čím předkládaný projekt naplňuje jednotlivé cíle Strategie rozvoje ICT služeb. Pokud je Váš projekt pro naplnění cílů Strategie nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že jde o IT komoditu typu tonery, která z podstaty není reformní. Nemůžete-li prokázat soulad projektu s cíli Strategie, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. 9 https://apps.odok.cz/zvlady/usneseni/-/usn/2015/889 9

2.2. Dodržení architektonických principů NA VS ČR Architektonické principy jsou z cílů rozvoje egovernmentu odvozená 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. Uveďte do tabulky, zda a čím předkládaný projekt naplňuje jednotlivé architektonické principy: Název principu Znění principu 10 Dostupnost Služby veřejné správy musí být všem dostupné především v elektronické podobě, v jakémkoliv čase, v jakékoliv lokalitě a musí být poskytovány nediskriminačním a bezbariérovým způsobem. Použitelnost Služby veřejné správy musí být navrhovány s ohledem na potřeby klienta tak, aby mohl vždy vyřídit svoji životní situaci v úplnosti elektronickou službou. Důvěryhodnost Elektronické služby veřejné správy musí být koncipovány takovým způsobem, aby klienti měli plnou důvěru k jejich využívání. Transparentnost Pořízení, rozvoj i provoz služeb veřejné správy musí být vždy zajištěn transparentním způsobem. Bezpečnost Elektronické služby musí zajistit adekvátní zabezpečení datového obsahu i přístupu k datům a službám samotným. Spolupráce a Elektronické služby veřejné správy jsou navrhovány a budovány primárně na principu sdílení spolupráce a sdílení informací a zdrojů mezi úřady veřejné správy. Udržitelnost Pořízení nových služeb veřejné správy musí být vždy opodstatněné a služby musí být navrhovány jako dlouhodobě využitelné. Technologická neutralita Služby veřejné správy musí být koncipovány jako technologicky a platformově nezávislé a nesmí být závislé na omezené skupině dodavatelů. Při tom se řiďte zde uvedenými důsledky principů, tj. právě tím, jak se mají architektonické principy promítat do projektů. Prověřte, zda a jak jsou u předloženého projektu splněna níže uvedená tvrzení: Název principu Dostupnost Použitelnost Důvěryhodnost Důsledky 11 principu pro projekty Všechny nové nebo zásadně měněné veřejné služby musí být navrhovány jako vnitřně plně elektronické. Každá služba musí být realizovatelná rovnocenně přes povinná elektronická rozhraní egovernmentu, samoobslužná (on-line i off-line) a asistovaná. Uživatelům musí být umožněno učinit podání vůči veřejné správě v plně elektronické podobě (a bez místní příslušnosti), bez nutnosti následného dokládání papírových dokumentů a kdykoli (kromě okamžiků nezbytné údržby systémů). Služby musí být koncipovány tak, aby všechny postupy při jejich využití byly srozumitelné, jednotné, služby byly snadno a rychle použitelné, využívaly inteligentní a interaktivní formuláře s automatickým doplněním známých informací a podporou on-line finančních transakcí a vedly k automatickému zpracování informací od klienta. Pro zajištění opakované použitelnosti je nutné, aby uživatelům na straně veřejnosti i veřejné správy byla dostupná plná historie vzájemné komunikace, úplný přehled v minulosti řešených souvisejících životních situací a archiv všech relevantních dokladů a dokumentů. Služby a jejich IT podpora musí být koncipovány tak, aby mohly být v případě spolupráce úřadů na řešení životní situace klienta řazeny (orchestrovány) do společného komplexního automatizovaného řešení této situace. Procesní i informační design nových služeb musí zajistit, aby vzájemně vyměňované informace (mezi klientem a úřadem i mezi úřady navzájem) byly spolehlivé, přesné, relevantní a aktuální. Odesílatel musí mít jistotu, že elektronicky odesílané informace budou doručeny, nebo že je lze z pohledu právních důsledků za doručené považovat. Obdobně to platí pro platnost a závaznost elektronicky obdržených dokumentů od VS. 10 Z angl. Statement (volně) 11 Z angl. Implications (dle TOGAF, volně přeloženo) 10

Název principu Transparentnost Bezpečnost Spolupráce sdílení Udržitelnost Technologická neutralita a Důsledky 11 principu pro projekty Elektronické služby veřejné správy musí využívat jednotný důvěryhodný identitní prostor pro klienty veřejné správy (i pro úředníky), jakmile bude k dispozici, a podporovat využívání elektronické identity. Při tvorbě koncepčních materiálů v oblasti rozvoje služeb veřejné správy musí být vždy jejich součástí i principy zajištění zpětné vazby od veřejnosti a mechanismy jejího promítnutí do výsledné koncepce. Nové služby musí být vždy koncipovány s ohledem na požadavek na publikování veřejných dat v adekvátním formátu. Veřejnosti musí být zajištěn přístup k výstupům prováděných auditů výkonu služeb veřejné správy a jiných forem hodnocení jejich výkonu. Prostředky poskytování elektronických veřejných služeb musí být adekvátně chráněny před poškozením a zneužitím. U elektronických veřejných služeb musí být zajištěna adekvátní ochrana osobních údajů a utajovaných skutečností. Služby musí být vždy koncipovány jako auditovatelné a pro tento účel musí vytvářet adekvátní auditní stopu. Nové služby (nebo jejich součásti) musí být navrhovány jako univerzální, sdílené, opakovatelně použitelné, bez omezujících vazeb na specifické agendy. Návrhy služeb veřejné správy a jejich IT podpory musí přednostně využívat existující stavební kameny, již vybudované ve shodě s principy sdílené architektury veřejné správy ČR. Na návrzích služeb veřejné správy se musí podílet ve vzájemné spolupráci odborné týmy napříč veřejnou správou. Řešení podporující výkon veřejné služby nesmí fixovat pouze stávající podobu podporovaných procesů a pravidel a musí být koncipována jako modulární, škálovatelná a parametrizovatelná. Sdílení nebo nákup nové standardní služby musí být vždy upřednostněno před vývojem vlastní služby. Dílčí vývoj na míru je přípustný pouze pro prokazatelnou lokální zvláštnost, přinášející VS výhodu. Nová nebo zásadně pozměněná IT řešení mají být vytvářena vždy výhradně na podporu inovovaných služeb egovernmentu. Není záměrem investovat do nových řešení na podporu nezměněných, zastaralých procesů a služeb. Řešení podporující výkon veřejné služby musí být navržena pro efektivní údržbu a rozvoj, tj. musí být standardizovaná, rozšiřitelná, integrovatelná, upgradovatelná a podporovatelná i vlastními silami úřadu. Služby veřejné správy musí být dostupné na všech běžně používaných platformách, stejně jako tomu je dnes u všech ostatních informačních řešení v soukromém sektoru. Řešení egovernmentu musí být vybudována na kvalitní, otevřené architektuře tak, aby bylo možné vyměňovat jednotlivé prvky řešení bez nutnosti měnit jejich okolí. Technologická neutralita musí být zajištěna jak při nezávislém využívání služeb mezi vrstvami architektur, tak při záměnách prvků uvnitř vrstvy. Oporou pro hledání odpovědi k vyplnění jsou Vám otázky ve formuláři, do nichž byly důsledky principů pro přiblížení přeformulovány. Uveďte tedy do tabulky, do řádku s názvem principu, zda předkládaný projekt naplňuje jednotlivé architektonické principy. Pod to, k jednotlivým otázkám, stručně uveďte, jakým způsobem předkládané řešení principy naplní. Pokud je Váš projekt pro uplatnění pravidla nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že jde o IT komoditu typu tonery, která z podstaty není reformní. Nemůžete-li prokázat soulad projektu s principy, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. 11

2.3. Enterprise architektura projektu dle pravidel NA VS ČR Popište a graficky znázorněte schopnostní architekturu úřadu 12 v oblastech spojených s předkládaným projektem, také zvanou úvodní EA projektu 13. Dělení architektur úřadu vysvětluje podrobněji Metodika modelování NA VS ČR a ukazuje jej následující schéma: Architektura schopností - představuje dílčí architekturu úřadu, sloužící pro podrobnější porozumění určité oblasti úřadu a jeho skupině externích, interních nebo průřezových schopností. Například schopnosti přidělovat a spravovat identitu občanů, schopnosti provozovat nemovitosti úřadu nebo schopnosti spravovat dokumenty, spojené s kteroukoli jinou hlavní schopností. Architektura schopností je nejčastěji vytvářena ve spojení s nějakou předpokládanou, ve vyšších architekturách identifikovanou změnou, kterou je potřeba na úrovni podnikové architektury rozpracovat do příležitostí a plánu změn dříve, než budou zahájeny práce na hledání detailní architektury možných řešení. Právě takovou architekturu byste nyní měli předkládat pro Žádost o Stanovisko OHA. Místo vlastní architektury projektu v tomto dokumentu, v kontextu architektury celého úřadu a celého egovernmentu ČR, ukazuje vybarvená část následujícího schématu. 12 Z angl. Government Enterprise Architecture Capability Architecture 13 Z angl. PSA Project Start Architecture 12

Již popsané prvky architektury pak v následných digramech mají barvu světle šedou, dosud nepopsané bílou. Vlastní architektonické informace uveďte v následujících podkapitolách. Každá doména architektury je ve shodě s Metodikou modelování NA VS ČR popsána pomocí katalogů základních objektů dané domény, grafických diagramů a vysvětlujícího textového bloku. U prvků architektury řešení informačního systému (aplikační, technologická a komunikační architektura) uveďte ve vysvětlujících textech na konci každé podkapitoly, mezi jakými variantami schopnostní architektury pro projekt bylo rozhodováno a proč byla vybrána právě předkládaná varianta. 13

2.3.1. Motivační architektura strategie a směrování Tato část architektury projektu objasňuje, pro jakou změnu je projekt navržen, co změnu vyvolalo, kdo stojí o její realizaci a jak se pozná, že se to podařilo. Tedy: Kterým směrem změn se úřad vydává? Katalog zainteresovaných stran (stakeholders): Uveďte jména, funkce, potřeby a zájmy (z pohledu přínosů projektu) tzv. zájmových skupin, zejména zainteresovaných jednotlivců 14. Zvláště pak zdůrazněte tzv. výkonného sponzora, tj. osobnost z vedení úřadu, která je klíčovým zadavatelem, podporovatelem projektu, má zásadní zájem na jeho úspěchu a nejvíce se zasazuje za jeho realizaci. Dále uveďte ostatní klíčové manažerské i politické osobnosti, osobně nebo funkčně zainteresované na projektu, jejich zájmy, potřeby a cíle spojené s realizací projektu. Zde neuvádějte cílové skupiny uživatelů či jejich role, pro ně určena kapitola 2.3.3. Katalog motivátorů a potřeb: Uveďte motivátor 15, tj. externí vliv či veřejnou potřebu/potřeby, na něž úřad reaguje politickou či strategickou iniciativou. Zde motivátor ve významu externího (úřadem přímo neovlivnitelného vlivu) může mít podobu například, nárůstu nezaměstnanosti, válečného stavu v sousední zemi, pokles zásob podzemní vody apod. Katalog strategických cílů: Dále uveďte s projektem spojené strategické cíle 16 této (výše uvedené) politiky / iniciativy. Takové cíle nejde realizovat přímo, nýbrž prostřednictvím splnění dílčích úkolů, viz následující tabulka Katalog proveditelných úkolů: Zde uveďte s projektem splněné proveditelné cíle / úkoly 17, takové, jejichž splněním lze realizovat strategické cíle politiky / iniciativy. Katalog metrik: Uveďte (byznys a politické) metriky, pomocí nichž se pozná, že celá politika byla úspěšná, stanovené cíle a úkoly splněné. Zvláště označte kritéria, která budou sloužit jako měřítko úspěchu implementace předkládaného projektu. Modely motivační architektury (NEPOVINNÉ): Zde vložte diagramy vzájemných vztahů výše uvedených objektů motivace ke změně architektury, zahrnuté do projektu. Tedy strategické iniciativy (politiky) ve vztahu k motivátorům, na něž reagují, strategické cíle a proveditelné úkoly jednotlivých iniciativ, případně vazby cílů a architektonických principů egovernmentu a úřadu. Vysvětlení motivační architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 14 Z angl. Stakeholders (dle TOGAF) 15 Z angl. Driver (dle TOGAF) 16 Z angl. Goal (dle TOGAF) 17 Z angl. Objectives (dle TOGAF) 14

2.3.2. Efektivita projektu výkonnostní architektura Tato část architektury projektu objasňuje, s jakými přínosy je projekt spojen, jaké ukazatele efektivity a kvality jsou pro projekt relevantní, pokud nějaké a jak je možné je měřit. Tedy: Jak dobří chceme díky projektu být? Rozdělení ukazatelů výkonnosti vychází z osvědčeného tzv. Logického modelu řízení výkonnosti a zodpovědnosti, viz následující schéma. Z něho je jasně patrné, že strategické cíle (politiky) je možno naplňovat pouze konkrétními činnostmi (službami veřejné správy), které i díky podpoře ICT řešeními mohou být (měly by být) efektivnější než před projektem. Schéma ukazuje vzájemný vztah ukazatelů efektivity (3E), které jsou detailně vysvětleny pod čarou. Katalog ukazatelů výkonnosti a kvality: Uveďte ukazatele zlepšení výkonnosti předmětné, projektem implementované nebo měněné ukazatele zlepšení výkonnosti předmětné veřejné služby a jejich očekávané hodnoty (míra zlepšení) 3E. Zvýšení hospodárnosti 18 čerpání zdrojů pro veřejnou službu Zvýšení účinnosti 19 práce zdrojů při tvorbě výstupů Zvýšení účelnosti 20 výstupů služby pro dosažení výsledků Dále uveďte vliv projektu na zvyšování úrovně a kvality předmětné služby, tj. hodnoty služby vnímané jejími spotřebiteli, klienty veřejné správy. Katalog výsledků, dopadů a multiplikačních efektů politiky (strategické iniciativy), podpořené předloženým projektem: Uveďte přehled výsledků a dopadů projektu a očekávané významné multiplikační efekty projektu (např. nepřímo vytvořená pracovní místa nebo poptávka), jejich kvantifikovaný odhad. Pro orientaci mezi typy ukazatelů využijte následující logický model řízení výkonnosti veřejné správy. Vysvětlení výkonnostní architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 18 Hospodárnost (Economy) vztahuje se k nákladům na zdroje pro spotřebovávané vstupy. Metriky hospodárnost se používají k posouzení, zda za pořízení nezbytných zdrojů je placena odpovídající cena. 19 Účinnost (Efficiency) účinnost představuje vztah mezi vstupy a výstupy, je poměrem dosažených výstupů ke spotřebovaným vstupům. Účinnost je výrazem dimenze dělat věci správně a ukazuje na výkonnost ve smyslu způsobu, jakým je činnost uskutečňována. 20 Účelnost (Effectiveness) je výrazem míry jakou produkované výstupy vedou k očekávaným výsledkům. Metriky účelnosti se zaměřují na sílu vztahu mezi provedenou intervencí a dosaženým výsledkem. Účelnost je výrazem dimenze dělat správné věci a ukazuje na výkonnost ve smyslu volby činnosti, která je uskutečňována. 15

2.3.3. Byznys architektura - poskytování veřejných služeb Tato část architektury projektu objasňuje, kdo (aktéři), v jaké roli a kudy (komunikační kanály) se zapojuje do činností úřadu, zahrnutých do projektu. Externí nebo interní činnosti úřadu mohou být popsány jako tzv. funkce, tj. konání, které má někdo v popisu práce, ale které neřídíme ani jako službu s SLA 21, ani je neřídíme jako proces. Známé procesy a služby je možno jako doplněk identifikovaných funkcí uvést. Tedy: Kdo jsme, kolik nás je a co děláme v rámci projektu? Katalog organizačních jednotek, aktérů a rolí: Uveďte, které OVM a které jejich organizační jednotky a jakékoli další subjekty budou zapojeny do poskytování veřejné služby podporované projektem. Uveďte typické a významné aktéry, jejich role jako uživatelů řešení, poskytovatelů a klientů veřejné služby. Uveďte u organizací, rolí nebo typů aktérů jaký v těchto kategoriích odhadujete počet uživatelů informačních systémů, které jsou předmětem posuzovaného projektu. Je to důležitá informace o jeho velikosti i o požadavcích na jeho architekturu. Celkový součet přes všechny kategorie je přirozeně větší, než celkový počet uživatelů, protože uživatelé mohou být rozepsáni současně do více kategorií. Jeden uživatel se započte současně do organizace, do role i do typického aktéra. Počty uživatelů celého IS uveďte alespoň jednou, v té kategorii, kde se Vám to podaří nejlépe odhadnout. Dokážete-li to, vyplňte co nejlépe ve všech kategoriích. Katalog funkcí, procesů veřejné správy: Uveďte, jaké činnosti výkonu veřejné správy předložený projekt zavádí nebo mění. Tyto činnosti popište jako interní funkce, které budou řešením podporovány, a k tomu jako procesy (sekvence funkcí), pokud v úřadu budou cílově tyto funkce jako procesy řízeny. Katalog služeb veřejné správy: Uveďte, jaké služby 22 veřejné správy předložený projekt zavádí nebo mění. Služby popište jako externí výkon směrem ke klientovi (občanovi, organizaci) s tím, že uvedete, kdo službu poskytuje (typicky která role), kdo jí využívá a přijímá její hodnotu (která role) a přes jaké rozhraní (komunikační, obslužný kanál). Je to velmi důležité, neboť většina principů a požadavků architektury egovernmentu je spojena právě se službymi VS, zejména s elektronickými službami VS. Katalog komunikačních (obslužných) rozhraní, kanálů: Uveďte všechna komunikační rozhraní, kterými budou klienti službu veřejné správy využívat. Přitom se vyjádřete k míře využití povinných elektronických rozhraní, on-line i off-line, samoobslužných i asistovaných. Uveďte odhadovaný počet klientů (ostatních úředníků) obsluhovaných jednotlivými kanály ročně. Přitom berte v úvahu vývoj této veřejné služby v průběhu celých 5 let a očekávaný nárůst preference elektronických kanálů. Při velkých změnách využití kanálů na začátku a konci 5 letého období uveďte nejvyšší odhady a vysvětlete v popisu průběh změn. Pokud je Váš projekt pro využití povinných komunikačních rozhraní nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že předložený projekt z podstaty neužívá žádné komunikační rozhraní pro klienty veřejné správy. Nemůžete-li prokázat soulad projektu s požadovanými povinnými komunikačními rozhraními, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. Model byznys architektury (výkonu veřejné správy) pohled funkcí a/nebo procesní pohled: Zde vložte diagram 21 Z angl. Service Level Agreement, ujednání o parametrech úrovně poskytované služby. 22 Služba je nehmotná aktivita (funkce) přinášející přidanou hodnotu, vykonaná poskytovatelem pro příjemce na základě jeho požadavku a v souladu se vzájemnou dohodou (smlouvou) o parametrech služby, HRABĚ, Pavel. Úloha služeb v rámci podnikové architektury (Enterprise Architecture), článek v časopise Systémová integrace, číslo 1/2010. 16

Model byznys architektury (výkonu veřejné správy) pohled organizační struktury: Zde vložte diagram Vysvětlení byznys architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující 17

2.3.4. Architektura informační systémů Podle Metodiky modelování NA VS ČR se doména (vrstva) architektury informačních systémů dělí na dvě dílčí, na aplikační architekturu a datovou architekturu. 2.3.4.1. Architektura informační systémů část: Aplikační architektura Tato část architektury projektu objasňuje, které aplikační komponenty IS budou projektem zavedeny, změněny nebo zrušeny, jaké jsou jejich vzájemná a externí rozhraní a na podporu kterých byznys funkcí slouží. Tedy: Jaké IT aplikace podpoří změny našich veřejných služeb? Katalog aplikačních komponent a klíčových aplikačních funkcí: Uveďte všechny zaváděné nebo měněné aplikační komponenty podporující služby veřejné správy, zahrnuté do projektu, jejich základní aplikační funkce. Katalog aplikačních rozhraní: Uveďte aplikační rozhraní aplikačních komponent zahrnutých do projektu na ostatní s nimi integrované komponenty (interní a externí z pohledu úřadu) Modely aplikační architektury pohled struktury aplikací: Zde vložte diagram dle Metodiky, který ukazuje přehled aplikačních komponent, zahrnutých do projektu. Modely aplikační architektury pohled využití aplikací: Zde vložte diagram dle Metodiky, který ukazuje vazby komponentami zahrnutými do projektu (případně funkcemi a službami komponent) a odpovídajícími byznys funkcemi. Modely aplikační architektury pohled komunikace aplikací: Zde vložte diagram dle Metodiky, který ukazuje vazby rozhraní mezi komponentami projektu navzájem a mezi nimi a světem vně projektu. Vysvětlení aplikační architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 2.3.4.2. Architektura informačních systémů část: Datová architektura Tato část architektury projektu objasňuje, které základní objekty a subjekty reálného světa, ve světle jejich zahrnutí do právního prostředí české VS, budou předmětem evidence budovaného či měněného procesu veřejné služby a odpovídajícího informačního systému. Tedy: Co si budeme o svém konání evidovat a jak velká to bude evidence? Datovou architekturu je doporučeno postihnout tzv. na konceptuální úrovni, tj. pomocí byznys objektů. Komu je to bližší, může klíčové objekty představit na logické úrovni, tj. pomocí datových entit, jimiž budou informace o nich zachycovány. Katalog základních datových entit projektu: Uveďte, které důležité objekty a subjekty reality a práva jsou předmětem evidence navrhovaného informačního systému. Použijte <Objekt> a <Datový objekt>, k nim v tabulce připojte vysvětlující komentář. Uveďte, jak velké budou počty evidovaných objektů (občanů, případů, rozhodnutí platební výměrů apod.) celkem na konci 5 letého období. Model konceptuální datové architektury projektu: Zde vložte diagram podle Metodiky, tj. tzv. Pohled informační struktury. Nebo použijte jakoukoli Vám blízkou podobu konceptuálního, případně logického ERD 23 modelu základních objektů evidence v projektu. Vysvětlení datové architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 23 Z angl. Entity-Relationship Diagram. 18

2.3.5. Technologická architektura vrstva IT technologie (HW a SW) Tato část architektury projektu objasňuje první polovinu celkové technologické architektury projektu, v dělení podle čtyřvrstvé vize architektury egovenrmentu. Zaměřuje se na HW a systémový SW výpočetních technologií a na jejich technologické (tzv. platformové) funkce a služby. Tedy: Jaké IT technologie potřebujeme pro běh aplikací našeho projektu? Katalog technologických komponent a klíčových platformových funkcí: Uveďte technologické komponenty, případně funkce a platformové (IT) služby datového centra využívané pro příslušné aplikační komponenty, zahrnuté do projektu. Modely technologické architektury pohled struktury technologické architektury Zde vložte diagram dle Metodiky modelování Modely technologické architektury pohled využití technologické architektury Zde vložte diagram dle Metodiky modelování Vysvětlení IT technologické architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 2.3.6. Technologická architektura vrstva komunikační infrastruktury Tato část architektury projektu objasňuje druhou polovinu celkové technologické architektury projektu, v dělení podle čtyřvrstvé vize architektury egovernmentu. Zaměřuje se na infrastrukturu datových center a na komunikační infrastrukturu, jejich infrastrukturní funkce, případně služby. Tedy: Jakou infrastrukturu datových center a komunikace potřebujeme pro provoz IT technologie našeho projektu? Katalog infrastrukturních komponent, funkcí a služeb: Uveďte technologické komponenty a funkce, případně služby, komunikační infrastruktury využívané pro příslušné platformové a aplikační komponenty. Modely technologické architektury pohled struktury komunikační infrastruktury: Zde vložte diagram dle Metodiky modelování Modely technologické architektury pohled využití komunikační infrastruktury: Zde vložte diagram dle Metodiky modelování Vysvětlení architektury komunikační infrastruktury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 19

2.3.7. Bezpečnostní architektura Tato část architektury projektu objasňuje pasivní bezpečnostní pohled, tj. které prvky kterékoli z vrstev architektury projektu jsou hodny z hlediska své potřeby zabezpečení mimořádného zřetele a jakými prostředky a opatřeními bude toto zabezpečení realizováno. Tedy: Co v mém projektu potřebuje chránit a co s tím pomůže? Současně objasňuje z obráceného, aktivního pohledu, které prvky zvýšeného zabezpečení projekt do úřadu přináší a co a před čím jimi bude nově nebo lépe chráněno. Tedy: Která rizika a hrozby úřadu pomůže projekt zmírnit a čím? Katalog pasivní bezpečnostní architektury projektu: Uveďte, které navrhované objekty architektury úřadu, zahrnuté do rozsahu projektu, jsou cílem nějaké hrozby nebo jejich implementace vyžaduje konkrétní bezpečnostní opatření. Uveďte jaké. Katalog aktivní bezpečnostní architektury projektu: Uveďte, které hrozby a rizika úřadu pomáhá navrhovaný projekt zmírnit, jakým objektem architektury a jakým implementovaným způsobem, opatřením. Diagram bezpečnostní architektury Volitelně vložte objasňující diagram /diagramy pasivní i aktivní bezpečnostní architektury v libovolné notaci (verze ArchiMate 2.1 objekty bezpečnostní architektury dosud neobsahuje). Vysvětlení bezpečnostní architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. V souvislosti s projekty egovernmentu hraje podstatnou roli otázka prokazování identity, její ověřování a přidělování oprávnění pro práci v informačních systémech podporujících službu veřejné správy. Proto je do části bezpečnostní architektury uvedena sekce, požadující vysvětlení, jak budou tyto funkce řešeny. Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích Zde postupně vysvětlete: Jakými prostředky způsoby mohou subjekty /uživatelé prokázat svoji identitu (eop, uživatel ISDS apod.). Obecně platí, že dobrý projekt by měl umožňovat použití všech aktuálně dostupných a v blízké době připravovaných prostředků prokázání identity, fyzické a (zejména) elektronické. Jakým způsobem bude řešení ověřovat identitu subjektů/uživatelů v jejich rolích Jakým způsobem budou uživatelům v jejich rolích přidělována oprávnění pro IS 20

2.3.8. Shoda s pravidly, standardizace a dlouhodobá udržitelnost Tato část architektury projektu objasňuje, co projekt při realizaci plánovaných změn definuje a omezuje, ať ji to jsou: a) právní předpisy a normy b) platné mezinárodní, národní nebo místní standardy c) dobrovolná pravidla pro dlouhodobou udržitelnost Tedy: Čím jsme při realizaci projektu definování a omezeni? Katalog předpisů a norem: Uveďte, které existující nebo teprve připravované právní a interní normy formalizují, regulují naplnění strategie projektem představovanými změnami. Uveďte jenom předpisy, které přímo formují architekturu řešení, spojeného s projektem, ať již ovlivňují architekturu jako celek nebo formují jenom některý dílčí prvek architektury (třeba dílčí proces nebo službu). Pak uveďte, který je to prvek a jaký na něj má předpis vliv. Uveďte, které další předpisy libovolné právní váhy mají přímý vliv na kterýkoli výše navrhovaný prvek řešení. Katalog v projektu uplatněných standardů: Uveďte, které mezinárodní, národní nebo místní standardy úřadu a dříve za standard architektury úřadu prohlášené stavební bloky architektury se v návrhu uplatnily. Cílem je jednak v architektuře uplatnit maximum standardů, a současně znovupoužít maximum v architektuře úřadu identifikovaných již existujících stavebních bloků řešení (SBB 24 ) nebo předem standardizovaných architektonických stavebních bloků (ABB 25 ). Katalog v návrhu znovupoužitých stavebních bloků řešení a úřadem standardizovaných architektonických stavebních bloků Uveďte, které existující stavební bloky řešení (SBB) nebo předem standardizované architektonické stavební bloky (ABB) se v navrhovaném řešení uplatní. Popřípadě můžete uvést, pokud t tak plánujete, které části vašeho řešení se mají stát opakovaně využitelnými stavebními bloky SBB/ABB pro navazující projekty úřadu, resortu či egovernmentu. Katalog zásad a opatření dlouhodobé udržitelnosti úřadu (nepovinný): Pokud v úřadu zavádíte či již uplatňujete zásady dlouhodobé udržitelnosti 26 úřadu, například dle metodiky CSR 27, uveďte (nepovinně), které zásady a která opatření jsou předkládaným projektem implementována a která mají na projekt významný vliv, a to v těchto oblastech: Ekonomická udržitelnost Sociální udržitelnost Environmentální udržitelnost Vysvětlení legislativy, standardizace a udržitelnosti architektury projektu: Zde vysvětlete všechny potřebné souvislosti a pro projekt důležité informace, spojené s výše uvedenými architektonickými objekty, anebo je doplňující. 24 Z angl. Solution Building Blocks 25 Z angl. Architecture Building Blocks 26 Z angl. Sustainability 27 Z angl. Corporate Social Responsibility 21

2.3.9. Přehled služeb čtyřvrstvé architektury Tato část architektury projektu objasňuje, jak komponenty funkce nižší vrstvy architektury poskytují služby komponentám a funkcím vrstvy vyšší. Tedy: Jaká je vnitřní i vnější struktura služeb úřadu, zahrnutých do projektu? V případě menšího rozsahu architektury navrhovaného projektu uveďte namísto dílčích diagramů Využití prvků vrstvy vyšší vrstvou, nebo ještě jednou vedle nich navíc, všechny tyto vazby mezi vrstvami společně, pohromadě v diagramu dle hlediska Přehled služeb čtyřvrstvé architektury s následující definicí (metamodelem): Pokud v úřadu vztahy mezi vrstvami dosud neřídíte pomocí služeb 28, můžete vazby mezi vrstvami namodelovat napřímo (třeba aplikační komponenta -> byznys funkce) a služby (dočasně) přeskočit. S tím, že byste si ale měli dát za cíl, řízení pomocí služeb zavést. 28 Definice Služba je nehmotná aktivita (funkce) přinášející přidanou hodnotu, vykonaná poskytovatelem pro příjemce na základě jeho požadavku a v souladu se vzájemnou dohodou (smlouvou) o parametrech služby. (Hrabě, Úloha služeb v rámci podnikové architektury (Enterprise Architecture), 2010) 22

2.4. Architektura (pozice) navrhovaného řešení v kontextu strategické architektury úřadu a navazujících subjektů veřejné správy V následujících podkapitolách formuláře představte a vysvětlete pozici (kontext) navrhovaného projektu ve strategické (celkové) architektuře úřadu, resp. případně resortu nebo vyššího správního celku, jak jej ukazuje barevná část schématu dokumentu níže: Prokažte na každé z vrstev čtyřvrstvé vize architektury egovernmentu modelu vlastního úřadu 29, že navrhované řešení využívá všechny dostupné i potenciální sdílené komponenty a služby a že do architektury úřadu nevkládá duplicitu nebo multiplicitu. V případě, že projektem podporovanou veřejnou službu nelze efektivně poskytnout bez spolupráce s partnerskými úřady nebo pobočkovou sítí například na krajských úřadech nebo ORP, musí být v této kapitole žádosti představen model architektury celého rozšířeného řetězce dodávky veřejné služby 30. V budoucnu se analýza a prohlášení ve všech vrstvách bude týkat postupně i shody nebo podobnosti nejen v úřadu, ale i v resortu, korporaci, celém státu a případně EU 31. 29 typ modelu VLST, dle Metodiky modelování NA VS ČR 30 typ modelu ROZS 31 typ modelu SPOL 23

2.4.1. Pozice řešení v byznys architektuře úřadu V celkové klasifikované mapě hierarchie dovedností (nebo funkcí nebo procesů nebo služeb) úřadu představte, která část dovedností úřadu bude součástí rozsahu projektu a předmětem podpory implementovanými aplikačními komponentami. Tedy: Jak souvisí činnosti zahrnuté do projektu s jinými jinde v úřadu, resortu? Diagram byznys architektury hledisko funkcí veřejné správy (Mapa) zde vložte diagram Vysvětlení architektury projektu v kontextu byznys architektury úřadu: Zde vysvětlete například, jak souvisí implementovaná služba s ostatními službami úřadu. Nebo například jak nová služba využívá všechny sdílené komunikační kanály úřadu (přepážky, CzechPOINT, portál úřadu nebo PVS, apod.). Uveďte do kontextu všechny do projektu zahrnuté funkce (procesy či služby). Vysvětlete, jak případně tato služba souvisí s ostatními vykonávanými službami pracovišť rozšířeného řetězce. Prohlášení o jedinečnosti zaváděné byznys architektury: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou, pouze parametricky odlišnou, dovednost VS (funkci, proces nebo službu), jaká již v úřadu nebo rozšířeném řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 2.4.2. Pozice řešení v architektuře informačních systémů úřadu 2.4.2.1. Pozice řešení v aplikační části architektury IS úřadu V celkové klasifikované mapě hierarchie aplikačních komponent (nebo funkcí nebo služeb) úřadu představte, která skupina aplikací bude součástí rozsahu projektu. Tedy: Jak souvisí aplikace zahrnuté do projektu se všemi ostatními aplikacemi úřadu, resortu? Diagram aplikační architektury IS hledisko portfolia aplikačních komponent a funkcí (Mapa) zde vložte diagram Vysvětlení architektury projektu v kontextu aplikační architektury úřadu: Zde vysvětlete například, jak souvisí navrhované komponenty s ostatními obdobnými komponentami úřadu (například zda a proč potřebuje nová agenda samostatnou spisovou službu nebo naopak, jak nová agendová aplikační komponenta využije stávající komponenty spisové služby a platebního nástroje úřadu). Současně v případě rozšířeného řetězce vysvětlete, jak bude integrována centrální aplikační komponenta s existujícími nebo připravovanými lokálními aplikačními komponentami a funkcemi řešení na pracovištích rozšířeného řetězce dodávky této veřejné služby. Prohlášení o jedinečnosti zaváděné aplikační architektury IS: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou aplikační komponentu (funkci nebo službu), jaká již v úřadu nebo řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 24

2.4.2.2. Pozice řešení v datové části architektury IS úřadu V celkovém konceptuálním datovém modelu klíčových objektů evidence úřadu (nebo datových objektů) úřadu představte, které prvky datového modelu úřadu budou součástí rozsahu projektu a předmětem podpory veřejných služeb implementovanými aplikačními komponentami. Tedy: Jak souvisí datové objekty evidované projektem s hlavními datovými objekty, evidovanými kdekoli jinde v úřadu, resortu? Diagram datové architektury IS hledisko struktury informací nebo hledisko konceptuální ERD zde vložte diagram Vysvětlení architektury projektu v kontextu datové architektury úřadu: Zde vysvětlete například, jak souvisí navrhované evidované datové objekty s ostatními obdobnými datovými objekty úřadu nebo pracovišť řetězce (například zda a proč potřebuje nová agenda znovu evidovat základní údaje a rodinné vztahy fyzické osoby) nebo naopak poukažte na to, jak nová agenda využije po úpravě stávajících aplikačních komponent, evidujících tytéž objekty. Současně v případě rozšířeného řetězce vysvětlete, jak budou datové objekty centrální části řešení, dostupné a užívané z lokálních pracovišť uvedeny do souladu či integrovány s týmiž lokálně udržovanými datovými objekty. Prohlášení o jedinečnosti zaváděné datové architektury IS: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádný stejný nebo podobný, pouze parametricky v některých atributech odlišný, datový objekt k témuž reálnému byznys objektu (třeba osoba), jaký již v úřadu nebo řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 2.4.3. Pozice řešení v IT technologické architektuře úřadu V celkové klasifikované mapě hierarchie technologických komponent (nebo funkcí nebo služeb) úřadu představte, která skupina technologických IT prvků bude součástí rozsahu projektu. Tedy: Jak souvisí IT technologické prvky (HW a systémový SW) se všemi ostatními takovými prvky v úřadu, resortu? Diagram technologické architektury hledisko portfolia IT technologických komponent a funkcí (Mapa) popisuje IT technologie z hlediska jejich typů bez ohledu na společné umístění, představuje logickou technologickou architekturu. zde vložte diagram Diagram technologické architektury tzv. infrastrukturní hledisko IT technologií (popisuje IT technologie podle logiky instalace zařízení společně a v lokalitách, představuje fyzickou technologickou architekturu) zde vložte diagram Vysvětlení architektury projektu v kontextu IT technologické architektury úřadu: Zde vysvětlete například, jak souvisí navrhované technologické komponenty s ostatními obdobnými komponentami úřadu (například zda a proč potřebuje nová agendová aplikace samostatné HW řešení nebo naopak jak nová agendová aplikační komponenta využije stávající virtualizované prostředí datového centra úřadu). Současně v případě rozšířeného řetězce vysvětlete, jak bude integrována centrální komponenta s existujícími nebo připravovanými technologickými komponentami a funkcemi řešení na pracovištích rozšířeného řetězce dodávky této veřejné služby. Prohlášení o jedinečnosti zaváděné IT technologické architektury IS: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou technologickou komponentu (funkci nebo službu), jaká již v úřadu nebo řetězci existuje. 25

Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 2.4.4. Pozice řešení v komunikační infrastruktuře úřadu V celkové klasifikované mapě hierarchie technologických komponent (nebo funkcí nebo služeb) komunikační infrastruktury úřadu představte, která skupina technologických IT prvků bude součástí rozsahu projektu. Tedy: Jak souvisí infrastruktura projektu s celkovou infrastrukturou úřadu, resortu? Diagram technologické architektury hledisko portfolia infrastrukturních komunikačních komponent a funkcí (Mapa) popisuje komunikační infrastrukturu z hlediska jejích typů bez ohledu na společné umístění, představuje logickou infrastrukturní architekturu. zde vložte diagram Diagram technologické architektury tzv. infrastrukturní hledisko komunikační infrastruktury (popisuje komunikační technologie podle logiky instalace zařízení společně a v lokalitách, představuje fyzickou technologickou architekturu). zde vložte diagram Vysvětlení architektury projektu v kontextu architektury komunikační infrastruktury úřadu: Zde vysvětlete například, jak souvisí navrhované komunikační komponenty s ostatními obdobnými komponentami úřadu. Současně v případě rozšířeného řetězce vysvětlete, jak bude integrována centrální komponenta s existujícími nebo připravovanými technologickými komponentami a funkcemi řešení na pracovištích rozšířeného řetězce dodávky této veřejné služby. Prohlášení o jedinečnosti zaváděné architektury komunikační infrastruktury: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou komunikační infrastrukturní komponentu (funkci nebo službu), jaká již v úřadu nebo řetězci existuje. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 26

2.5. Architektura (pozice) navrhovaného řešení v kontextu egovernmentu - způsob využití sdílených prvků architektury úřadu a egovernmentu Představte a vysvětlete pozici (kontext) navrhovaného projektu ve strategické (celkové) architektuře egovernmentu České republiky. Prokažte na každé z vrstev čtyřvrstvé vize architektury egovernmentu modelu vlastního úřadu (typ VLST), že navrhované řešení využívá všechny dostupné i potenciální (pro jeho kontext vhodné) sdílené komponenty a služby egovernmentu a že do architektury úřadu nevkládá duplicitu nebo multiplicitu vůči těmto centrálním sdíleným prvkům egovernmentu. V případě, že projektem podporovanou veřejnou službu nelze efektivně poskytnou bez spolupráce s partnerskými úřady nebo pobočkovou sítí, například na krajských úřadech nebo ORP, musí být v této kapitole žádosti míra využití sdílených prvků egovernmentu posouzena z pohledu celého rozšířeného řetězce dodávky veřejné služby (model typu ROZS), tedy jak tyto partnerské organizace využijí sdílené prvky egovernmentu. V budoucnu se analýza a prohlášení ve všech vrstvách bude týkat postupně i míry využití sdílených služeb Governmentu na úrovni EU. 27

2.5.1. Využití sdílených prvků egovernmentu v byznys architektuře úřadu Představte a vysvětlete, které byznys služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované funkce (procesy a služby) z byznys architektury projektu, kapitola 2.3.3, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v byznys architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou, pouze parametricky odlišnou, dovednost VS (funkci, proces nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 2.5.2. Využití sdílených prvků egovernmentu v architektuře IS úřadu 2.5.2.1. Využití sdílených prvků egovernmentu v aplikační části architektury IS úřadu Představte a vysvětlete, které aplikační služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované aplikační komponenty (funkce a služby) z aplikační architektury projektu, kapitola 0, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v aplikační architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou aplikační komponentu (funkci nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 2.5.2.2. Využití sdílených prvků egovernmentu v datové části architektury IS úřadu Představte a vysvětlete, které byznys a datové objekty veřejné správy bude navrhovaný projekt využívat z nabídky sdíleného datového fondu egovernmentu ČR. Přesvědčte se, že všechny navrhované datové objekty z datové architektury projektu, kapitola 2.3.5, plně využívají nabídku sdíleného datového fondu egovernmentu, dodržují pravidla sdílení dat a nezavádějí lokální duplicitní evidenci. Prohlášení o plném využití sdílených služeb egovernmentu v datové architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádný stejný nebo podobný, pouze parametricky v některých atributech odlišný, datový objekt k témuž reálnému byznys objektu (třeba osoba), jaký již je k dispozici jako součást sdíleného datového fondu egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 28

2.5.3. Využití sdílených prvků egovernmentu v IT technologické architektuře úřadu Představte a vysvětlete, které IT technologické služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované IT technologické komponenty (funkce a služby) z technologické architektury projektu, kapitola 2.3.5, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v IT technologické architektuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou technologickou komponentu (funkci nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 2.5.4. Využití sdílených prvků egovernmentu v komunikační infrastruktuře úřadu Představte a vysvětlete, které komunikační, infrastrukturní služby veřejné správy bude navrhovaný projekt využívat z nabídky sdílených služeb egovernmentu ČR. Přesvědčte se, že všechny navrhované infrastrukturní komunikační komponenty (funkce a služby) z komunikační architektury projektu, kapitola 2.3.6, plně využívají nabídku sdílených služeb egovernmentu a nezavádějí lokální duplicitu. Prohlášení o plném využití sdílených služeb egovernmentu v komunikační infrastruktuře projektu: Zde uveďte prohlášení, že navrhovaný projekt nezavádí žádnou stejnou nebo podobnou komunikační infrastrukturní komponentu (funkci nebo službu), jaká již je k dispozici jako sdílená služba egovernmentu. Pokud nemůžete prohlásit, že projekt nezavádí žádnou duplicitu, uveďte, o jakou duplicitu se jedná, vysvětlete její důvod a uveďte, že žádáte o výjimku: <žádáme výjimku>. 29

2.6. Architektura řešení projektu Prokažte vysvětlením a odpovídajícím diagramem architektury, jak jsou v architektuře předkládaného řešení dodrženy aktuální Architektonické vzory sdílených služeb egovernmentu, publikované dokumentem 32 OHA MV ČR. Viz barevná část pod dosud popsanými enterprise architekturami projektu, úřadu a egovernmentu. Uveďte, zda a jak předkládaný projekt dodržuje jednotlivé vzory architektury sdílených služeb egovernmentu. Pokud je Váš projekt pro dodržení vzoru nerelevantní, pak uveďte <nerelevantní> a přidejte zdůvodnění, proč se tak domníváte - například, že jde o projekt rozpočetnictví úřadu nebo znalostní báze utajovaných skutečností, kde se aktuální vzory neuplatní. Nemůžete-li prokázat soulad projektu se vzory, uveďte do tabulky, že žádáte o výjimku: <žádáme výjimku>, a ve formuláři dle dané přílohy 6.1 zformulujte text a parametry této výjimky. Diagram aplikační architektury hledisko spolupráce aplikací Architektonické diagramy by měly v korespondenci s Vaším textem v jednom nebo několika diagramech ukazovat, jak přesně se publikované vzory uplatní ve spojení s projektem nově zaváděnými nebo měněnými aplikačními komponentami. 32 http://www.mvcr.cz/soubor/architektonicke-vzory-sdilenych-sluzeb-egovernmentu-pdf.aspx 30

2.7. Plán dlouhodobého rozvoje architektury projektu (Roadmapa) Pokud na cestě rozvoje od současného stavu k cílovému stavu za 5 let je identifikováno jeden a více postupných přechodových stavů architektury, pak musí být přehledně představeny a vysvětleny v této kapitole. V rámci celého formuláře se etapou myslí jedna část celku, která má svoji architekturu. Etapa je tedy typicky samotný projekt. Každá etapa má své fáze. V rámci projektu jakožto etapy jsou to typicky fáze příprava, realizace, ukončení. Tyto fáze jsou předmětem projektového managementu a v rámci architektury dlouhodobého rozvoje nehrají žádnou roli (v hrubém pojetí jsou potřeba ve 3. Kapitole) Přechod mezi etapami, stav na konci etapy, je přechodová architektura. Etapa 1 Samotný Projekt Etapa 2 Rozvoj v dalším projektu Etapa 3 Přechod na jiné řešení Fáze 1 Příprava Přechodová architektura Přechodová architektura Fáze 1 Fáze 2 Realizace Fáze 1 Fáze 2 Fáze 2 Fáze 3 Fáze 3 Ukončení Fáze 4 31