Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
Obě strany předchozí revize Předchozí verze Následující verze | Předchozí verze Následující verzeObě strany příští revize | ||
nap:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2019/08/06 00:43] – /* Pravidla pro otevřená data VDF (VDF-OD) */ dchocholaty | nap-dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu [2020/12/02 15:36] – [Pravidla pro aplikace agendového zázemí (BO)] Tomáš Šedivec | ||
---|---|---|---|
Řádek 1: | Řádek 1: | ||
+ | ~~Title: Architektura úřadu v kontextu veřejné správy a jejích vrstvách architektury~~ | ||
- | ======= Pravidla tvorby a údržby vlastní čtyřvrstvé architektury jednotlivých | + | ====== |
+ | Tato kapitola popisuje architekturu úřadu a veřejné správy ČR po jednotlivých vrstvách architektury a zapracování požadavků do informační koncepce a architektury úřadu. Jde o jiný přístup k popisu požadavků na využívání systémů a služeb eGovernmentu než v části [[nap-dokument: | ||
- | V této kapitole NAP předepisuje pravidla pro návrh a výstavbu vlastních, lokálních architektur úřadů, a to primárně po architektonických vrstvách. | + | Skladba |
- | Současně v úvodu v návaznosti na výše uvedené architektonické principy eGovernmentu a principy rozvoje informatiky jsou uvedeny vybrané klíčové architektonické požadavky, které musí být uplatněny při návrhu koncepcí dlouhodobého rozvoje ISVS úřadů. | + | {{ :soubor:nap.png |}} |
- | ====== Architektonické požadavky ====== | ||
+ | ===== Pravidla architektury strategie a směřování úřadu ===== | ||
- | Architektonické požadavky navazují na tzv. konkrétní dopady((Z angl. „implications“, | ||
- | Architektonické požadavky budou průběžně zveřejňovány Ministerstvem vnitra v rámci jeho koordinační role (PV pro Architekturu RVIS, diskuse, spolupráce, | ||
+ | <WRAP center round tip 60%> | ||
+ | Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. | ||
+ | </ | ||
- | ====== Pravidla pro architektury strategie, výkonnosti, | ||
+ | Pro architekturu strategie a směřování je podstatný především soulad se strategickými dokumenty, jejich principy a cíli. Mezi tyto dokumenty patří: | ||
+ | - Strategie Digitální Česko a z ní zejména Informační koncepce ČR | ||
+ | - Informační koncepce úřadu | ||
+ | - Národní architektonický plán | ||
+ | - Strategický rámec rozvoje veřejné správy 2014+ | ||
+ | - Koncepce klientsky orientované veřejné správy 2021+ | ||
+ | - Strategie rozvoje infrastruktury pro prostorové informace v České republice do roku 2020 (GeoInfoStrategie) | ||
+ | V modelu vlastní celkové architektury úřadu by praktickému používání při řízení úřadu měly sloužit zejména diagramy strategických cílů, architektonických principů, architektonických požadavků a omezujících podmínek, vytýčených směrů rozvoje a očekávaných výstupů. Tyto by měly sladěným způsobem kombinovat objekty převzaté z nadřazených strategií, viz výše a z vlastních strategií a koncepcí úřadu. | ||
- | ====== Pravidla byznys architektury výkonu veřejných služeb úřadu ====== | ||
- | Z hlediska řízení informatizace představuje byznys architektura zadání pro efektivní IT podporu výkonu veřejné správy. Proto je aktuální model cílového stavu byznys architektury úřadu povinným předpokladem a nedílnou součástí informační koncepce každého úřadu, orgánu veřejné správy. | ||
+ | ===== Pravidla výkonnostní architektury úřadu ===== | ||
- | ===== Rozdělení procesů a funkcí veřejné správy ===== | ||
- | Pro rozhodování o variantách | + | <WRAP center round tip 60%> |
+ | Zapracování pravidel této vrstvy | ||
+ | </ | ||
- | Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model procesní, respektive funkční dekompozice úřadu a její diagram, tzv. Mapu byznys portfolia/ | ||
- | Tento model musí z podstaty komplexního řízení informatizace úřadu obsahovat identifikované | + | **Pro tuto doménu architektury nejsou |
- | * rozhodnutí o konsolidaci IT podpory byznys funkcí úřadu | ||
- | * rozhodnutí o možnostech sdílené IT podpory byznys funkcí úřadu | ||
- | * optimalizaci funkcí úřadu s podporou ICT - doplnění a rozvoj nedostatečné ICT podpory funkcí úřadu | ||
- | Přitom je nutné pohlížet na identifikované funkce | + | ===== Pravidla byznys architektury výkonu veřejných služeb úřadu |
- | - hledisko míry podpory externích služeb pro klienty veřejné správy | ||
- | - hledisko míry (a potenciálu) podobnosti, jednotnosti | + | <WRAP center round tip 60%> |
+ | Popis centrálně poskytovaných systémů | ||
- | - hledisko míry (a potenciálu) vymístění funkcí | + | Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap-dokument: |
- | - hledisko výkonu funkcí | + | Zapracování pravidel této vrstvy architektury popíše |
+ | </ | ||
- | Ad a) Hledisko klasifikace dle podpory služeb pro klienty. Pro usnadnění modelování byznys vrstvy architektury úřadu vydává a aktualizuje OHA MV akcelerátor, | ||
- | {{soubor: | + | Z hlediska řízení informatizace představuje byznys architektura zadání pro efektivní IT podporu výkonu veřejné správy. Proto je aktuální model cílového stavu byznys architektury úřadu povinným předpokladem a nedílnou součástí informační koncepce každého úřadu, orgánu veřejné správy. |
+ | ==== Rozdělení procesů a funkcí veřejné správy ==== | ||
- | - Základní dělení funkcí, procesů a služeb úřadu | + | Pro rozhodování o variantách podpory potřeb výkonu veřejné správy |
+ | Vedoucí útvaru informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model procesní, respektive funkční dekompozice úřadu a její diagram, tzv. Mapu byznys portfolia/ | ||
- | * Hlavní procesy, funkce | + | Tento model musí z podstaty komplexního řízení informatizace |
- | * Podpůrné procesy, funkce | + | |
- | * Funkce a procesy správy zdrojů - úřad vykonává pro zajištění | + | |
- | * Řídící a rozvojové funkce - vykonává | + | |
- | * Provozní funkce - vykonává | + | |
- | Referenční model byznys | + | * rozhodnutí o konsolidaci IT podpory |
+ | * rozhodnutí o možnostech sdílené IT podpory byznys funkcí úřadu, | ||
+ | * optimalizaci funkcí | ||
- | * Obslužné funkce | + | Přitom je nutné pohlížet na identifikované |
- | * Odborné funkce - představující specializaci na výkon a rozhodování v agendě či provozní funkci, angl. Middle-Office (dále také MO). Dále mohou být děleny na: | + | |
- | | + | |
- | | + | - Hledisko míry (a potenciálu) podobnosti, jednotnosti a centralizace procesů. |
+ | | ||
+ | - Hledisko výkonu funkcí úřadu vlastním nebo cizím jménem a na vlastní nebo cizí účet. | ||
- | * Funkce společného zázemí agend - představující funkce vykonávané typicky (ale ne výhradně) mimo interakci s klientem, z angl. Back-Office (dále také BO), společně a jednotně pro více (až pro všechny) agend úřadu. | + | Podle všech výše uvedených úhlů pohledu se liší potřeby funkcí |
- | * Funkce správy spisů | + | |
- | * Funkce integrace | + | |
- | {{soubor: | + | Detailní referenční modely byznys architektury, |
+ | === Hledisko míry podpory externích služeb pro klienty veřejné správy === | ||
- | - Další | + | Pro usnadnění modelování byznys vrstvy architektury úřadu navrhuje Národní architektonický plán následující Referenční model byznys architektury úřadu. Ten dělí funkce úřadu do vrstev podle jejich „vzdálenosti“ od poskytování |
+ | * Hlavní procesy, funkce úřadu - úřad vykonává v interakci s externím klientem nebo pro výkon služby veřejné správy externímu klientovi | ||
+ | * Podpůrné procesy, funkce úřadu - úřad vykonává jako předpoklad, | ||
+ | * Funkce a procesy správy sdílených zdrojů - úřad vykonává pro zajištění všech ostatních předpokladů a zdrojů dle své role a pozice ve veřejné správě, bez přímé souvislosti s podporou služeb svým individuálním externím klientům. | ||
+ | * Řídící a rozvojové funkce - vykonává úřad, aby byl schopen plánovat, realizovat, monitorovat a vyhodnocovat kvalitu a výkonnost svých funkcí a jejich další rozvoj. | ||
+ | * Provozní funkce - vykonává úřad jako správu základních zdrojů pro zajištění své udržitelné existence (provozu), bez ohledu na to, jaké jsou jeho hlavní, podpůrné a sdílené zdrojové funkce. | ||
- | Ad b) Hledisko jednotnosti a centralizace. | + | {{ : |
- | Takto identifikované a klasifikované funkce | + | Referenční model byznys architektury |
- | Ad c) Hledisko vymístění (outsourcingu) a využití sdílených | + | * Obslužné funkce - představující interakci s klienty ve všech a v kterémkoli obslužném a komunikačním kanálu, angl. Front-Office (dále také FO), cílově co nejvíce společně a jednotně, napříč agendami. |
+ | * Odborné funkce - představující specializaci na výkon a rozhodování v agendě či provozní funkci, angl. Middle-Office (dále také MO). Dále mohou být děleny na: | ||
+ | * Generické odborné funkce veřejné správy (vidimace, konverze apod.) | ||
+ | * Agendově specifické funkce veřejné správy | ||
+ | * Funkce společného zázemí agend - představující funkce vykonávané typicky (ale ne výhradně) mimo interakci s klientem, z angl. Back-Office (dále také BO), společně a jednotně pro více (až pro všechny) agend úřadu. | ||
+ | * Funkce správy spisů a případů - sloužící ke správě dokumentů a informací propojujících jednotlivé fáze (a funkční oblasti) vyřizování případů | ||
+ | * Funkce integrace a spolupráce mezi úřady při výkonu | ||
- | Identifikované funkce v modelu byznys architektury úřadu je nutné posuzovat z hlediska dostupnosti již sdílených byznys služeb nebo potenciálu na vymístění (outsourcing) k poskytovateli takové sdílené služby - uvnitř úřadu nebo samosprávné jednotky z vlastního rozhodnutí, | ||
- | Přitom rozlišujeme následující možnosti (úrovně) sdílení na: | + | {{ : |
- | {{soubor: | ||
- | * Celostátně | + | === Hledisko míry (a potenciálu) vymístění funkcí a využití sdílených |
- | * služby externí | + | Identifikované funkce v modelu byznys architektury úřadu je nutné posuzovat z hlediska dostupnosti již sdílených byznys |
- | * služby interní na podporu úřadů a úředníků - služby zdrojových, řídících a provozních procesů | + | |
+ | Přitom rozlišujeme následující možnosti (úrovně) sdílení na: | ||
+ | |||
+ | * Celostátně (celoplošně) sdílené služby. Ty se na této i na všech další úrovních dělí ještě na: | ||
+ | * služby externí na podporu klientů veřejné správy (a případně OVM) - služby hlavních a podpůrných procesy | ||
+ | * služby interní na podporu úřadů a úředníků - služby sdílených zdrojových, | ||
* Sdílené služby veřejnoprávních korporací (správců rozpočtových kapitol, krajských a místních (ORP) územních korporací) | * Sdílené služby veřejnoprávních korporací (správců rozpočtových kapitol, krajských a místních (ORP) územních korporací) | ||
- | * Sdílené služby uvnitř úřadu - typicky služby pro obslužné funkce (FO), pro funkce zázemí agend (BO) a pro funkce správy spisů a případů | + | * Sdílené služby uvnitř úřadu - typicky služby pro obslužné funkce (FO), pro funkce zázemí agend (BO) a pro funkce správy |
* Individuální (dílčí, specifické, | * Individuální (dílčí, specifické, | ||
- | Ad d) Hledisko výkonu funkcí vlastním jménem a na vlastní účet. | + | === Hledisko výkonu funkcí |
- | Jako protipól funkcí předaných k vykonání jinému úřadu, organizaci, vyskytují se v orgánech veřejné správy funkce vykonávaném pro někoho jiného, tj. cizím jménem, na cizí účet, případně obojí. U všech identifikovaných funkcí úřadu je nutné - vždy posuzovat i tento aspekt, tj. u činností (procesů, funkcí, služeb) čím jménem a na čí účet jsou vykonávány. | + | Jako protipól funkcí předaných k vykonání jinému úřadu, organizaci, vyskytují se v orgánech veřejné správy funkce vykonávaném pro někoho jiného, tj. cizím jménem, na cizí účet, případně obojí. U všech identifikovaných funkcí úřadu je nutné - vždy posuzovat i tento aspekt, tj. u činností (procesů, funkcí, služeb) čím jménem a na čí účet jsou vykonávány. |
- | + | ||
- | Podle všech výše uvedených úhlů pohledu se liší potřeby funkcí úřadu na jejich aplikační podporu, proto je nutno mezi nimi rozlišovat a následně podle tohoto navrhovat řešení této aplikační podpory a volit způsob její realizace. Je důležité tyto vlastnosti | + | |
- | + | ||
- | Detailní referenční modely byznys architektury, | + | |
+ | * Výkon služeb veřejné správy v přenesené působnosti | ||
+ | * Výkon korporátních nebo státních středisek sdílených služeb | ||
- | ===== Ohlášení agend úřadu v RPP ===== | ||
+ | ==== Ohlášení agend úřadu v RPP ==== | ||
- | Zákon 111/2009 Sb. o základních registrech zavedl jednoznačnou hierarchii agend a agendových informačních systémů spolu s vyznačením jak údajů, které jsou v rámci agendy vedeny, tak údajů, které je agenda oprávněna při své činnosti využívat ze základních registrů a dalších agend. V rámci tohoto textu jsou uvedeny důsledky plynoucí pro návrh architektury informačních systémů na všech vrstvách modelu. | + | [[https:// |
Agendu definuje ústřední správní úřad zodpovědný za výkon agendy **v právní terminologii**. Při popisu údajů se tedy nevyužívá technologická terminologie, | Agendu definuje ústřední správní úřad zodpovědný za výkon agendy **v právní terminologii**. Při popisu údajů se tedy nevyužívá technologická terminologie, | ||
Řádek 136: | Řádek 153: | ||
998-1-1-1 **Jméno** vlastníka silničního vozidla. | 998-1-1-1 **Jméno** vlastníka silničního vozidla. | ||
- | Smyslem této notace, oznámení agend v Registru práv a povinností a následné technologické specifikace je **jednoznačné oddělení právních a informačních zodpovědností.** Při návrhu publikace prostřednictvím | + | Smyslem této notace, oznámení agend v [[nap:rpp|Registru práv a povinností]] a následné technologické specifikace je **jednoznačné oddělení právních a informačních zodpovědností.** Při návrhu publikace prostřednictvím |
Správce Agendového informačního systému tedy musí spolupracovat se správcem agendy na ohlášení agendy tak, aby bylo možné provést jednoznačnou dekompozici údaje v kontextu na jedno informační položky. Definice těchto informačních položek je následovně součástí definice datového rozhraní. | Správce Agendového informačního systému tedy musí spolupracovat se správcem agendy na ohlášení agendy tak, aby bylo možné provést jednoznačnou dekompozici údaje v kontextu na jedno informační položky. Definice těchto informačních položek je následovně součástí definice datového rozhraní. | ||
Řádek 142: | Řádek 159: | ||
**Zvolený princip zamezuje záměnám údajů podle jejich názvů (jméno vlastníka vozidla je určitě něco jiného než jméno vlastníka nemovitosti, | **Zvolený princip zamezuje záměnám údajů podle jejich názvů (jméno vlastníka vozidla je určitě něco jiného než jméno vlastníka nemovitosti, | ||
- | Správce agendy při ohlášení také určuje, jaké údaje ze základních registrů či jiných agend má oprávnění při své činnosti využívat a správce agendového informačního systému pak při návrhu datového rozhraní čerpá z definice datových položek jednotlivých ISVS, které údaje/data publikují do propojeného datového fondu veřejné správy | + | Správce agendy při ohlášení také určuje, jaké údaje ze základních registrů či jiných agend má oprávnění při své činnosti využívat a správce agendového informačního systému pak při návrhu datového rozhraní čerpá z definice datových položek jednotlivých ISVS, které údaje/data publikují do [[nap: |
**Pokud je agenda vykonávána prostřednictvím více Agendových informačních systémů, pak správce agendy musí určit toho správce agendového informačního systému, který bude závazně určovat rozpad údaje na datové položky, a ostatní správci agendových informačních systémů musí tento rozpad respektovat.** | **Pokud je agenda vykonávána prostřednictvím více Agendových informačních systémů, pak správce agendy musí určit toho správce agendového informačního systému, který bude závazně určovat rozpad údaje na datové položky, a ostatní správci agendových informačních systémů musí tento rozpad respektovat.** | ||
- | + | ==== Rozdělení obslužných a komunikačních kanálů veřejné správy ==== | |
- | ===== Rozdělení obslužných a komunikačních kanálů veřejné správy ===== | + | |
Obslužné a komunikační kanály úřadu veřejné správy vůči jeho externím klientům je pro účely jejich efektivního řízení a jejich IT podpory možné dělit z několika úhlů pohledu, a to podle: | Obslužné a komunikační kanály úřadu veřejné správy vůči jeho externím klientům je pro účely jejich efektivního řízení a jejich IT podpory možné dělit z několika úhlů pohledu, a to podle: | ||
- | * Sdílení a subjektivity provozovatele obslužného kanálu na vlastní, centrální, | + | * Sdílení a subjektivity provozovatele obslužného kanálu na vlastní, centrální, |
- | * Podle míry zapojení klienta na samoobslužné nebo asistované (osobní, vně listinné či hlasové, ale vnitřně plně elektronické) | + | * Podle míry zapojení klienta na |
- | * Podle vazby na místo a agendu na univerzální - bez místní a věcné příslušnosti, | + | * samoobslužné nebo |
- | * Podle komunikačního média a prostředku podání/ | + | * asistované (osobní, vně listinné či hlasové, ale vnitřně plně elektronické) |
+ | * Podle vazby na místo a agendu na | ||
+ | * univerzální - bez místní a věcné příslušnosti, | ||
+ | * územní - s místní, ale bez věcné příslušnosti a | ||
+ | * agendové - s věcnou příslušností (jedné nebo více agend téhož ústředního správního úřadu), ale bez místní příslušnosti | ||
+ | * Podle komunikačního média a prostředku podání/ | ||
- | {{soubor:media: | + | Cílem je, co nejvíce potřeb klientů obsloužit v prvním stupni obsluhy, tj. v [[nap:univerzalni_kontaktni_misto|univerzálních kontaktních místech]] (také jako " |
- | Cílem je, co nejvíce potřeb klientů obsloužit v prvním stupni obsluhy, v univerzálních kontaktních místech (UKM) - klientských centrech, jako je samoobslužný Portál klienta (občana, podnikatele, | + | Výchozím předpokladem při návrhu řešení by měla být maximální snaha, aby v rámci |
- | Zásadou je, že v kterémkoli UKM nalezne klient | + | V případě asistovaných kontaktních míst (univerzálních i v územních či agendových OVS) však zprostředkuje |
- | V případě asistovaných kontaktních míst (univerzálních i v OVS) však zprostředkuje informace o všech informacích ze vztahu klienta a veřejné správy úředník, výhradně na základě explicitního zmocnění klientem. To je jediný případ, kdy smí úředník najednou vidět více než jednu agendu současně, přitom ale smí vidět pouze stavové informace z notifikací, | + | Všechny úkony v obslužných kanálech musí být adekvátně |
- | + | ||
- | Všechny úkony v obslužných kanálech musí být adekvátně zaznamenány ve spisové službě úřadu. | + | |
Úřad veřejné správy je povinen v legislativě (může-li ji ovlivnit), v procesech úřadu a v jejich aplikační podpoře (v rozsahu dle platné legislativy) zajistit plnou rovnoprávnost všech obslužných kanálů a umožnit klientovi volbu mezi kanály. | Úřad veřejné správy je povinen v legislativě (může-li ji ovlivnit), v procesech úřadu a v jejich aplikační podpoře (v rozsahu dle platné legislativy) zajistit plnou rovnoprávnost všech obslužných kanálů a umožnit klientovi volbu mezi kanály. | ||
Řádek 171: | Řádek 189: | ||
Preference kanálu, efektivnějšího z pohledu úřadu, tedy typicky elektronického samoobslužného kanálu, je možná pouze zvýšením jeho atraktivity pro klienta, nikoli regulatorním opatřením (nařízením, | Preference kanálu, efektivnějšího z pohledu úřadu, tedy typicky elektronického samoobslužného kanálu, je možná pouze zvýšením jeho atraktivity pro klienta, nikoli regulatorním opatřením (nařízením, | ||
- | Pro informatickou podporu v úřadu dále vyplývá, že na konci horizontu pravidel této IKČR, aktuálně v roce 2022, platí pro všechny agendy úřadu, že: | + | Pro informatickou podporu v úřadu dále vyplývá, že na konci horizontu pravidel této IKČR, aktuálně v roce 2023, platí pro všechny agendy úřadu, že: |
- | * Všechna řešení (zákonná i informatická) musí být navržena tak, aby vnitřně byla plně elektronická a vně podporovala všechny obslužné kanály (konverze dokumentů). | + | * Všechna řešení (zákonná, byznys |
* Všechny kontaktní kanály, včetně specializovaných, | * Všechny kontaktní kanály, včetně specializovaných, | ||
- | Budou navrženy takové úpravy právního prostředí a IT řešení, aby v dlouhodobém horizontu podporovaly rovnost a provázanost obslužných kanálů (Multichannel) - tj. řízení je možné v kterémkoli kanálu začít, v jiném sledovat jeho průběh a v jiném řízení dokončit. | + | Budou navrženy takové úpravy právního prostředí, byznys procesů a funkcí |
- | ===== Portály občana a úředníka ===== | ||
- | Portál je mimo jiné i technickým nástrojem pro on-line transakční služby klientům veřejné správy, pro informování o výkonu veřejné správy a pro interaktivní komunikaci ze strany klienta. Proto mají být součástí portálu také popsané životní situace (pokud možno interaktivní na základě parametrů), | ||
- | Portály tedy nemohou být samostatné a nepropojené aplikace, ale naopak musí se jednat o prostředek, | + | ==== Vliv byznys architektury |
- | Oba typy samoobslužných kanálů přístupu k externím | + | Z charakteru činností úřadu, viz dekompozice výše, vyplývá, jaké jsou možnosti pro sdílení |
- | V případě Portálu občana v PVS stojí občan jako samoobslužný uživatel „vně“ veřejné správy | + | Tam, kde úřad ze zákona zůstává zodpovědný za určitou činnost (agendu, podpůrnou funkci) nemůže využít sdílených |
- | V případě portálů samospráv se předpokládají dva trendy: a) jednak budou lokální portály samospráv obsahovat obrácený směr navigace do Portálu občana, kde bude moci klient vyřídit vše ostatní ze státní správy, co případně nenašel v místním portálu | + | Příkladem je ERP nebo spisová služba. Zde jak procesy, tak jejich aplikační podporu musí mít každý úřad vlastní, zůstává |
- | Naproti tomu v případě | + | V takovém |
- | Všechny sdílené portálové komponenty, které mají být užívány v lokálních portálech úředníka, | ||
- | ===== Služby pro životní situace - úplné elektronické podání (ÚEP) | + | ===== Pravidla aplikační architektury IS VS úřadu |
- | Zejména byznys a aplikační architektura úřadu musí být v nových a významně měněných agendách | + | <WRAP center round tip 60%> |
+ | Popis centrálně poskytovaných systémů | ||
+ | Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap-dokument: | ||
- | ===== Vliv byznys | + | Zapracování pravidel této vrstvy |
+ | </ | ||
- | Z charakteru | + | Z hlediska řízení informatizace představuje aplikační architektura těžiště řízení efektivní IT podpory výkonu veřejné správy. Rozvoj každého informačního systému |
- | Tam, kde úřad ze zákona zůstává zodpovědný za určitou činnost (agendu, podpůrnou funkci) nemůže využít sdílených | + | Informační systémy veřejné správy slouží pro podporu výkonu agendy či agend veřejné správy. Musí tedy sloužit pro úředníka jako prostředek, který ho provádí jeho úřední činností a který mu pomáhá při jeho úřední práci, shromažďuje a doplňuje potřebné údaje, hlídá naplnění určitých povinností |
- | Příkladem je ERP (rozpočetnictví) nebo spisová služba. Zde jak procesy, tak jejich aplikační podporu musí mít každý úřad vlastní, zůstává věcným správcem těchto řešení. Pokud je tedy úřad věcným správcem nějakého řešení, zachovává si za něj zodpovědnost a pravomoc o něm okamžitě rozhodovat - musí to být řešení v pravomoci tohoto úřadu. | ||
- | V takovém případě, pro taková řešení jako je ERP nebo eSSL může OVS využít sdílené služby pouze na IT technologické a platformové úrovni, SW řešení mu musí poskytnuto maximálně tzv. multitenantní formou (více samostatných nájemníků) na společné technické infrastruktuře. | + | ==== Principy klasifikace aplikací dle referenčního modelu ==== |
- | ====== Pravidla aplikační architektury IS VS úřadu ====== | + | Informační systémy veřejné správy (ISVS), tak jak je definují jejich agendové nebo jiné zákony, se tedy obvykle skládají z jedné nebo více aplikačních komponent. Aplikační komponenty ISVS a ostatních informačních systémů úřadu, lze pro účely jejich správy dělit například |
- | + | ||
- | + | ||
- | Z hlediska řízení informatizace představuje aplikační architektura těžiště řízení efektivní IT podpory výkonu veřejné správy. Rozvoj všech informačních systémů úřadu se děje prostřednictvím rozvoje jeho komponent a v kontextu všech ostatních aplikačních komponent úřadu a aplikačních služeb eGovernmentu. Proto je aktuální model cílového stavu aplikační architektury úřadu základem informační koncepce každého úřadu, orgánu veřejné správy. | + | |
- | + | ||
- | Informační systémy veřejné správy slouží pro podporu výkonu agendy či agend veřejné správy. Musí tedy sloužit pro úředníka jako prostředek, | + | |
- | + | ||
- | + | ||
- | ===== Principy klasifikace aplikací dle referenčního modelu ===== | + | |
- | + | ||
- | + | ||
- | Informační systémy veřejné správy (ISVS), tak jak je definují jejich agendové nebo jiné zákony, se tedy obvykle skládají z jedné nebo více aplikačních komponent. Aplikační komponenty ISVS a ostatních informačních systémů úřadu, lze pro účely jejich správy dělit například podle míry sdílení aplikačních služeb a podle klientů těchto služeb, nebo podle vztahu IS k řetězci obsluhy klientů veřejné správy. | + | |
Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model dekompozice aplikačních komponent a aplikačních funkcí úřadu a její diagram, tzv. Mapu aplikačního portfolia/ | Vedoucí informatiky úřadu a techničtí správci ISVS jsou povinni ve spolupráci s jejich věcnými správci vytvořit a udržovat aktuální model dekompozice aplikačních komponent a aplikačních funkcí úřadu a její diagram, tzv. Mapu aplikačního portfolia/ | ||
Řádek 232: | Řádek 238: | ||
Podporu pro rozhodování při řízení životního cyklu aplikačních komponent informačních systémů VS a současně vyjádření nejlepší praxe jejich inventarizace a třídění poskytuje tzv. Referenční model aplikační architektury, | Podporu pro rozhodování při řízení životního cyklu aplikačních komponent informačních systémů VS a současně vyjádření nejlepší praxe jejich inventarizace a třídění poskytuje tzv. Referenční model aplikační architektury, | ||
- | {{soubor:media:image16.png?487x213}} | + | {{ :soubor:rozdeleni_aplikacnich_komponent.png |Rozdělení aplikačních komponent úřadu do vrstev}} |
+ | Dělení vychází z účelu aplikačních komponent shora počínaje úlohou uživatelského rozhraní a navigace až po platformy, zcela nezávislé na druzích uživatelů a poskytovaných služeb úřadu. V aplikační mapě se toto dělení uplatní jako vrstvy vertikální dimenze. | ||
- | - Rozdělení | + | {{ : |
+ | Dále dělení aplikací vychází z byznys logiky podporovaných byznys funkcí, kde na jedné straně jsou to funkce (služby) pro vnější klienty, partnery a veřejnost, na druhé straně jsou funkce detailně podporující jednotlivé klíčové zdroje úřadu (znalosti, zaměstnance, | ||
- | Dělení vychází z účelu aplikačních komponent shora počínaje úlohou uživatelského rozhraní | + | Pokud zákon pro nějakou agendu definuje i způsob IT podpory evidence údajů, |
- | {{soubor: | + | Z toho vyplývá aktuálně proveditelný požadavek na optimalizaci procesů a aplikačního portfolia úřadu tak, že pro průřezové procesy agend (podobné, příbuzné či jednotné byznys funkce a procesy) využije jednotných nebo dokonce centrálních sdílených komponent aplikačního portfolia úřadu (např. pro obsluhu klientů na přepážkách, |
+ | Pokud se takto sdílí v úřadu několik komponent napříč agendami, používají tyto pro externí označování klienta nikoli AIFO, ale nejlépe nějaké společné veřejné klientské číslo občana a organizace v rámci systému kmenových dat úřadu. AIFO, jako neveřejný identifikátor, | ||
- | - Rozdělení transakčních | + | === Průřezové, |
+ | Rozsah a obsah aplikací pro obslužné, odborné a funkce zázemí agend se liší podle segmentů veřejné správy. Odlišnosti ostatních kategorií jsou minimální, | ||
- | Dále dělení | + | Obsah aplikací |
- | + | ||
- | Rozsah a obsah aplikací pro obslužné, odborné a funkce zázemí agend se liší podle segmentů veřejné správy. Odlišnosti ostatních kategorií jsou minimální, | + | |
Povinností ředitele informatiky úřadu (technického správce) je zohlednit vzájemnou podobnost aplikací podle jejich kategorie při rozhodování o konsolidaci aplikací nebo o návrhu aplikační podpory v kategoriích, | Povinností ředitele informatiky úřadu (technického správce) je zohlednit vzájemnou podobnost aplikací podle jejich kategorie při rozhodování o konsolidaci aplikací nebo o návrhu aplikační podpory v kategoriích, | ||
- | Referenční model aplikační architektury s plným detailem třídění a s odlišným obsahem klíčových transakčních komponent pro jednotlivé odlišující se segmenty veřejné správy (např. zdravotnictví, | + | Referenční model aplikační architektury s plným detailem třídění a s odlišným obsahem klíčových transakčních komponent pro jednotlivé odlišující se segmenty veřejné správy (např. zdravotnictví, |
- | Pokud zákon pro nějakou agendu definuje i způsob IT podpory evidence údajů, | + | {{ : |
- | Na druhou stranu dosud není možné, nestanovuje-li to explicitně zákon, sdílet v ISVS aplikační komponenty vlastněné jiným úřadem (ani příslušnou korporací, tj. rezortem, krajem nebo ORP). | ||
- | Z toho vyplývá aktuálně proveditelný požadavek optimalizace procesů a aplikačního portfolia úřadu tak, že pro průřezové procesy agend (podobné, příbuzné či jednotné byznys funkce a procesy) využije jednotných nebo dokonce centrálních sdílených komponent aplikačního portfolia úřadu (např. pro obsluhu klientů na přepážkách, | ||
- | Pokud se takto sdílí v úřadu několik komponent napříč agendami, používají tyto pro externí označování klienta nikoli AIFO, ale nejlépe nějaké společné klientské číslo občana v rámci systému úřadu. AIFO bude využíváno pouze při externí výměně údajů o klientovi v agendě prostřednictvím Back-End integrace přes ISZR a eGSB. | ||
- | ===== Pravidla pro uživatelská rozhraní a přístup k informačním systémům ===== | ||
- | Uživatelská rozhraní | + | ==== Pravidla pro uživatelská rozhraní |
- | * Úřad musí mít všechny svoje formuláře primárně v autentizované zóně portálu a umožnit předvyplnění údajů z PPDF s využitím zaručené identity klienta | ||
- | * Agendové a místní portály se budou rozšiřovat z informačních na transakční (ÚEP) | ||
- | * Transakční obsah portálu (formuláře) musí být integrován (federalizován) s PVS - Portál občana (cílově s předáním identity) | ||
- | * Identifikace uživatelů v portálu musí využívat národní identifikační schéma (NIA) | ||
- | V případě | + | Uživatelská rozhraní ISVS i provozních systémů musí být především ergonomicky optimální pro nejlepší podporu odpovídajících |
- | IS poskytující služby uživatelům, | + | * Úřad musí mít všechny svoje formuláře primárně v autentizované zóně [[nap: |
+ | * Agendové a místní portály se budou rozšiřovat z informačních na transakční | ||
+ | * Transakční obsah portálu (formuláře nebo uživatelská rozhraní portálových aplikací) | ||
+ | * Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace. Tato identifikace je nyní zajištěna pouze prostřednictvím [[nap: | ||
Kromě výjimečně zdůvodnitelných případů, například modelovacích nebo GIS nástrojů, nebo při nedostupnosti dostatečně propustného internetového připojení, | Kromě výjimečně zdůvodnitelných případů, například modelovacích nebo GIS nástrojů, nebo při nedostupnosti dostatečně propustného internetového připojení, | ||
- | IKČR předpokládá postupné sjednocování | + | NAP předpokládá postupné sjednocování vzhledu a chování portálových aplikací ústředních správních úřadů pro dosažení jednotného uživatelského zážitku klienta. To platí zejména poté, co budou elementární služby úřadů dostupné „proklikem“ z portálu občana. |
- | + | ||
- | U místních portálů obcí IKČR naopak předpokládá i nadále lokální specifický „look & feel“, který podporuje sounáležitost občana s obcí, jako klíčovou podporovanou hodnotu, vedle ergonomie a efektivity obsluhy, která tím nesmí být dotčena. | + | |
- | + | ||
- | Cílově IKČR předpokládá, | + | |
- | ===== Pravidla pro obslužné agendové aplikace (FO) ===== | + | Cílem je pro menší ústřední úřady a územní samosprávy umožnit místo budování lokálních portálů využívat SaaS služeb Portálu občana v PVS, a to v prvním kroku pro svěřené služby státní správy v přenesené působnosti, |
+ | ==== Pravidla pro obslužné agendové aplikace (FO) ==== | ||
- | Cílově musí být obslužné aplikační funkce jednotné a centralizované v úřadu, resortu (nebo korporaci) a státu tak, aby klientům veřejné správy umožňovaly dobrý „zážitek“ a efektivní obsluhu, a to úměrně výše uvedenému členění obslužných kanálů veřejné správy a požadavků na jejich podporu. | + | Cílově musí být obslužné aplikační funkce jednotné a centralizované v úřadu, resortu (nebo korporaci) a státu tak, aby klientům veřejné správy umožňovaly dobrý |
To znamená, že aplikace obslužných kanálů stejného typu, například externí portál, musí být hierarchicky federativně integrované nebo zcela centrální. Aplikace různého typu, například uživatelské rozhraní pro fyzickou přepážku a pro portál musí být vzájemně integrovány tak, že užívají společnou aplikační logiku komunikace s klienty, která není vestavěna ani do portálu, ani do přepážkového SW, ale právě do společného aplikačního SW obslužných kanálů, také označovaného CRM, což ve veřejné správě znamená Citizen Relationship Management. | To znamená, že aplikace obslužných kanálů stejného typu, například externí portál, musí být hierarchicky federativně integrované nebo zcela centrální. Aplikace různého typu, například uživatelské rozhraní pro fyzickou přepážku a pro portál musí být vzájemně integrovány tak, že užívají společnou aplikační logiku komunikace s klienty, která není vestavěna ani do portálu, ani do přepážkového SW, ale právě do společného aplikačního SW obslužných kanálů, také označovaného CRM, což ve veřejné správě znamená Citizen Relationship Management. | ||
Řádek 295: | Řádek 294: | ||
CRM společně s komunikačními technologiemi (web, mail, telefon, chat, SMS, DS, a další) zajistí jednotnou vícekanálovou obsluhu (multichannel, | CRM společně s komunikačními technologiemi (web, mail, telefon, chat, SMS, DS, a další) zajistí jednotnou vícekanálovou obsluhu (multichannel, | ||
- | Podstatnou část agendové byznys logiky | + | Podstatnou část agendové byznys logiky |
- | ===== Pravidla pro odborné (specifické) agendové aplikace (MO) ===== | + | ==== Pravidla pro odborné (specifické) agendové aplikace (MO) ==== |
- | Ve všech případech, | + | Ve všech případech, |
Tento systém musí být dostupný prostřednictvím síťové infrastruktury státu ve všech obslužných místech veřejné správy, agendových i univerzálních. Musí být uzpůsoben k integraci na lokální i na celostátní aplikační komponenty pro obsluhu klientů (FO), pro lokální společné funkce zázemí agend (platby, vedení spisu apod.) (BO), zejména pak musí být integrovatelný na lokální spisovou službu, lokální saldokontní účetnictví klientů a lokální EkIS úřadu. | Tento systém musí být dostupný prostřednictvím síťové infrastruktury státu ve všech obslužných místech veřejné správy, agendových i univerzálních. Musí být uzpůsoben k integraci na lokální i na celostátní aplikační komponenty pro obsluhu klientů (FO), pro lokální společné funkce zázemí agend (platby, vedení spisu apod.) (BO), zejména pak musí být integrovatelný na lokální spisovou službu, lokální saldokontní účetnictví klientů a lokální EkIS úřadu. | ||
Řádek 307: | Řádek 306: | ||
Uživatelské rozhraní těchto centrálních AIS musí být zařaditelné a volatelné z jednotné transakční navigace v centrálním portálu úředníků (intranetu veřejné správy) i (dočasně) v lokálním intranetu úřadu. | Uživatelské rozhraní těchto centrálních AIS musí být zařaditelné a volatelné z jednotné transakční navigace v centrálním portálu úředníků (intranetu veřejné správy) i (dočasně) v lokálním intranetu úřadu. | ||
- | Pro aplikační architekturu úřadu potom platí, že úřad musí buď: | + | Pro aplikační architekturu úřadu potom platí, že úřad musí pro logicky centralizovaný AIS buď: |
- | a) využívat tuto centrálně sdílenou aplikační komponentu, tj. poskytnout uživatelům úřadu uživatelský přístup k této komponentě prostřednictvím JIP/KAAS a integrovat tuto komponentu na Back-Office s ostatními nezbytně místními komponentami úřadu, jako je spisová služba úřadu nebo systém řízení obsluhy klientů. | + | - využívat tuto centrálně sdílenou aplikační komponentu, tj. poskytnout uživatelům úřadu uživatelský přístup k této komponentě prostřednictvím JIP/KAAS a integrovat tuto komponentu na Back-Office s ostatními nezbytně místními komponentami úřadu, jako je spisová služba úřadu nebo systém řízení obsluhy klientů. |
+ | - b) využívat vlastní standardizovaný agendový systém úřadu pro tuto agendu (nebo multi-agendový), | ||
- | b) využívat vlastní agendový systém | + | Pro obě varianty platí závazně jak pro věcného správce centrálního systému, tak pro lokální |
- | Pro obě varianty platí závazně jak pro věcného správce centrálního systému, tak pro lokální úřad s tím, že jak jejich interní zaměstnanec, | + | Výše uvedená centrální odborná agendová aplikace musí být správcem (ohlašovatelem agendy) poskytnuta včetně samoobslužného zákaznického portálu |
- | Výše uvedená centrální odborná agendová aplikace musí být správcem (ohlašovatelem agendy) poskytnuta včetně samoobslužného zákaznického portálu občana/ | ||
+ | ==== Pravidla pro aplikace agendového zázemí (BO) ==== | ||
- | ===== Pravidla pro aplikace agendového zázemí (BO) ===== | ||
- | + | Pokud úřad je činný ve více agendách, které všechny vedou na obdobné funkce zázemí agend (BO), například vedení spisu, příjem poplatku, výplata dávky, apod., bude pro tyto funkce užívat sdílené řešení (spisovou službu, saldokontní účetnictví, | |
- | Pokud úřad je činný ve více agendách, které všechny vedou na obdobné funkce zázemí agend (BO), například vedení spisu, příjem poplatku, výplata dávky, apod., bude pro tyto funkce užívat sdílené řešení (spisovou službu, saldokontní účetnictví, | + | |
Klíčovou komponentou této oblasti z pohledu klientů i úřadu je komponenta pro vedení kmene klientů a jejich pohledávkových/ | Klíčovou komponentou této oblasti z pohledu klientů i úřadu je komponenta pro vedení kmene klientů a jejich pohledávkových/ | ||
Řádek 330: | Řádek 328: | ||
- | ===== Pravidla pro aplikace spisové služby | + | ==== Pravidla pro aplikace spisové služby, správy případů |
+ | Odlišné procesní nároky pro správu klientských případů a spisů, jednoznačně vztažených ke klientům (data vlastněná klienty a propůjčená do správy úřadům) a případů a spisů interní správy OVS (bez vazeb na klienta). Je doporučeno uvědomit si tyto odlišnosti, | ||
- | Každý úřad by měl pro evidenci všech | + | Z pohledu zákona o archivnictví a spisové službě existuje tzv. kategorie „určených původců“, |
- | Pokud úřad pro své agendy vede více dokumentů | + | Pokud úřad pro své agendy vede více dokumentů |
+ | Elektronický nástroj pro workflow by měl podporovat oba základní typy předávání práce: | ||
+ | * transakční workflow – kdy mezi pracovníky přechází odkaz na rozpracovanou transakci v agendovém nebo provozním IS, společně s odkazy na odpovídající | ||
+ | * dokumentové workflow – kdy mezi pracovníky přechází jenom odkaz na dokument nebo spis ve spisové službě, případně, | ||
+ | Uživatelský klientem pro workflow by měl(o) být současně (optimálně): | ||
+ | * uživatelské rozhraní aplikace AIS, provozního systému nebo spisové služby, to podle typu workflow, viz výše | ||
+ | * společné rozhraní přistupující do „workflow-inboxu“ v Portálu úředníka, | ||
+ | * rozhraní pro mailovou schránku úředníka umožňující práci s workflow obou typů" | ||
- | ===== Pravidla pro kategorii znalostních systémů | + | ==== Pravidla pro kategorii znalostních systémů ==== |
- | Znalostní systémy v úřadu musí být konsolidovány tak, aby všechny informace a znalosti úřadu, s výjimkou informací o individuálním výkonu moci v agendě a klasifikovaných informací, byly dostupné pro vzdělávání a podporu výkonu služeb pro všechny zaměstnance úřadu, se společným vyhledáváním informací v intranetu úřadu. | + | Znalostní systémy v úřadu musí být konsolidovány tak, aby všechny informace a znalosti úřadu, s výjimkou informací o individuálním výkonu moci v agendě a klasifikovaných informací, byly dostupné pro vzdělávání a podporu výkonu služeb pro všechny zaměstnance úřadu, se společným vyhledáváním informací v intranetu úřadu |
Pro informační systémy poskytující informace o platném, historickém i připravovaném právu platí, že v úřadech mohou být provozovány jenom takové systémy a pouze pro takové funkce, které nejsou podporovány centrálním systémem eSbírka/ | Pro informační systémy poskytující informace o platném, historickém i připravovaném právu platí, že v úřadech mohou být provozovány jenom takové systémy a pouze pro takové funkce, které nejsou podporovány centrálním systémem eSbírka/ | ||
- | ===== Pravidla pro identity management (IDM) ===== | + | ==== Pravidla pro identity management (IDM) ==== |
- | Každý úřad je povinen zvážit ve své architektuře pořízení řešení pro centrální správu identit a oprávnění uživatelů((také zvané IDM (Identity Management), | + | Každý úřad je povinen zvážit ve své architektuře pořízení řešení pro centrální správu identit a oprávnění uživatelů (také zvané IDM (Identity Management), |
- | * Povinnost napojení | + | * Povinnost napojení |
+ | * Povinnost napojení identifikace, | ||
* Doporučení realizovat centrální správu identit úřadu (IDM), napojenou u úředníků na HR (HCM) | * Doporučení realizovat centrální správu identit úřadu (IDM), napojenou u úředníků na HR (HCM) | ||
- | Zde bude doplněno. | + | ==== Pravidla pro integrační platformy ==== |
- | + | ||
- | + | ||
- | ===== Pravidla pro integrační platformy ===== | + | |
- | Častým problémem je, že u správců ISVS jsou tyto informační systémy budované jako autonomní bloky, které nejsou řádně a správně propojeny a integrovány s dalšími informačními systémy a komponentami v úřadu. Je nutno na to myslet již při sestavování prvotní architektury a důsledně zajistit tyto integrace, a to formou otevřených, | + | Častým problémem je, že u správců ISVS jsou tyto informační systémy budované jako autonomní bloky, které nejsou řádně a správně propojeny a integrovány s dalšími informačními systémy a komponentami v úřadu. Je nutno na to myslet již při sestavování prvotní architektury a důsledně zajistit tyto integrace, a to formou otevřených, |
Každý informační systém veřejné správy musí být integrován s: | Každý informační systém veřejné správy musí být integrován s: | ||
- | * Elektronickým systémem spisové služby | + | * Elektronickým systémem spisové služby |
* Provozními systémy typu IDM a monitoringu | * Provozními systémy typu IDM a monitoringu | ||
* Auditovacími a logovacími systémy - pro zajištění logování nakládání s údaji evidovanými v ISVS včetně ale nikoliv pouze osobních údajů | * Auditovacími a logovacími systémy - pro zajištění logování nakládání s údaji evidovanými v ISVS včetně ale nikoliv pouze osobních údajů | ||
Řádek 371: | Řádek 374: | ||
Preferovaným způsobem integrace aplikací je využití standardní integrační platformy (též Enterprise Application Integration, | Preferovaným způsobem integrace aplikací je využití standardní integrační platformy (též Enterprise Application Integration, | ||
- | Každý úřad bude využívat vlastní nebo sdílenou EAI propojenou na centrální eGSB. | + | Každý úřad bude využívat vlastní nebo sdílenou EAI propojenou na centrální |
Tato pravidla v souladu s NAP předpokládají vícestupňovou hierarchickou strukturu integračních platforem. | Tato pravidla v souladu s NAP předpokládají vícestupňovou hierarchickou strukturu integračních platforem. | ||
- | Pro zapojení úřadů do sdílení v rámci propojeného datového fondu je vybudována centrální integrační platforma eGSB (eGovernment Service Bus). Na ni se úřady přednostně napojují prostřednictvím korporátních integračních platforem resortů (krajů, ORP) nebo prostřednictvím vlastních EAI, pokud takovou mají. | + | Pro zapojení úřadů do sdílení v rámci propojeného datového fondu je vybudována centrální integrační platforma |
Korporátní EAI slouží primárně pro potřeby interní integrace v rámci kapitoly nebo veřejné korporace, jako externí integrace pro úřad ministerstva nebo územního celku a jako sdílená služba pro podřízené organizace korporace, pro které není výhodné vybudovat EAI vlastní. | Korporátní EAI slouží primárně pro potřeby interní integrace v rámci kapitoly nebo veřejné korporace, jako externí integrace pro úřad ministerstva nebo územního celku a jako sdílená služba pro podřízené organizace korporace, pro které není výhodné vybudovat EAI vlastní. | ||
Řádek 382: | Řádek 385: | ||
- | ===== Pravidla pro systémy zveřejňující a využívající otevřená data ===== | + | ==== Pravidla pro systémy zveřejňující a využívající otevřená data ==== |
- | Jako otevřená data jsou v kompletní podobě zveřejňovány údaje evidované v ISVS, které: | + | Jako otevřená data jsou v kompletní podobě zveřejňovány údaje evidované v ISVS, pro které |
+ | * povinnost zveřejnění v podobě otevřených dat je výslovně stanovena právním předpisem; nebo | ||
+ | * jde o ISVS, jehož obsah je zcela či zčásti veřejný a zároveň se nejedná o předchozí případ. V tomto případě je nutné provést posouzení, zda zveřejnění údajů v této formě nebude mít za následek nepřiměřený zásah do práva na ochranu osobních údajů, popř. se jím významně zvýší možnost narušení bezpečnosti ČR.; nebo | ||
+ | * jde o údaje, které by bylo možné poskytnout na základě žádosti podle předpisů upravujících svobodný přístup k informacím (srov. § 5 odst. 7 zákona o svobodném přístupu k informacím) a zároveň se nejedná o předchozí dva případy. V takovém případě zveřejní údaje ve formě otevřených dat jen v rozsahu, v jakém by bylo možné je poskytnout, pokud by byly předmětem žádosti podle zákonů upravujících svobodný přístup informacím, | ||
- | * u nichž je povinnost zveřejnění v této formě výslovně stanovena právním předpisem; nebo | + | Zveřejňovat údaje z ISVS jako otevřená data znamená povinnost poskytovat je všem odborníkům na zpracování dat (programátorům, |
- | * jde o ISVS, jehož obsah je zcela či zčásti veřejný a zároveň se nejedná o předchozí případ. V tomto případě je nutné provést posouzení, zda zveřejnění údajů v této formě nebude mít za následek nepřiměřený zásah do práva na ochranu osobních údajů, popř. se jím významně nezvýší možnost narušení bezpečnosti ČR.; nebo | + | |
- | * | + | |
- | * jde o údaje, které by bylo možné poskytnout na základě žádosti podle předpisů upravujících svobodný přístup k informacím (srov. § 5 odst. 7 zákona o svobodném přístupu k informacím) a zároveň se nejedná o předchozí dva případy. . V takovém případě zveřejní údaje ve formě otevřených dat jen v rozsahu, v jakém by bylo možné je poskytnout, pokud by byly předmětem žádosti podle zákonů upravujících svobodný přístup informacím, | + | |
- | + | ||
- | Zveřejňovat údaje z ISVS jako otevřená data znamená povinnost poskytovat je všem odborníkům na zpracování dat (programátorům, | + | |
V případě, že jsou z ISVS zveřejňovány údaje v podobě otevřených dat, je též naplněn případný legislativní požadavek poskytnutí veřejného dálkového přístupu k těmto údajům. | V případě, že jsou z ISVS zveřejňovány údaje v podobě otevřených dat, je též naplněn případný legislativní požadavek poskytnutí veřejného dálkového přístupu k těmto údajům. | ||
- | Sdílení veřejných údajů evidovaných v ISVS mezi orgány veřejné správy musí být zajištěno prostřednictvím otevřených dat ve SVDF. Orgán veřejné správy, jehož evidence údajů v jím spravovaném ISVS je primární evidencí, je musí zveřejňovat jako otevřená data. Orgán veřejné správy, který tyto údaje využívá v jím spravovaném ISVS, je musí získávat jako otevřená data, pokud jsou jako otevřená data zveřejňovány. | + | Sdílení veřejných údajů evidovaných v ISVS mezi orgány veřejné správy musí být zajištěno prostřednictvím otevřených dat ve VDF. OVS, jehož evidence údajů v jím spravovaném ISVS je primární evidencí, je musí zveřejňovat jako otevřená data. OVS, který tyto údaje využívá v jím spravovaném ISVS, je musí získávat jako otevřená data, pokud jsou jako otevřená data zveřejňovány. |
- | Tytéž údaje je možné ve veřejné správě zveřejňovat jako otevřená data pouze jednou. V případě, že údaje vedené v ISVS jsou předávány do jiného ISVS za účelem shromažďování údajů od různých | + | Tytéž údaje je možné ve veřejné správě zveřejňovat jako otevřená data pouze jednou. V případě, že údaje vedené v ISVS jsou předávány do jiného ISVS za účelem shromažďování údajů od různých |
- | + | ==== Pravidla pro využití SaaS služeb eGC ==== | |
- | ===== Pravidla pro využití SaaS služeb eGC ===== | + | |
Řádek 409: | Řádek 409: | ||
- | ===== Další oblasti pravidel aplikační architektury … ===== | ||
+ | ===== Pravidla datové architektury IS VS ===== | ||
- | * Správa zdrojů | ||
- | * Podpůrné systémy | ||
- | * správa nemovitostí | ||
- | * Platforma GIS | ||
- | * Mobilní platformy | ||
- | * … | ||
+ | <WRAP center round tip 60%> | ||
+ | Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap-dokument: | ||
- | ===== Pravidla pro identifikaci ISVS ===== | + | Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap-dokument: |
+ | Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. | ||
+ | </ | ||
- | Identifikace ISVS a jejich | + | <WRAP center round info 60%> |
+ | Datová architektura IS VS je formálně | ||
+ | </ | ||
- | ====== Pravidla datové architektury IS VS ====== | + | Tato pravidla aktuálně nepředepisují žádné povinně standardizované individuální prvky datové architektury veřejné správy s výjimkou těch, které jsou postupně publikovány jako součást referenčních a agendových |
- | + | ||
- | + | ||
- | Tato pravidla aktuálně nepředepisují žádné povinně standardizované individuální prvky datové architektury veřejné správy s výjimkou těch, které jsou postupně publikovány jako součást referenčních a autoritativních | + | |
Zásadním požadavkem informační koncepce je adopce (uplatnění) společného přístupu k datové architektuře pro všechny orgány veřejné správy. Správce každého informačního systému musí vědět: | Zásadním požadavkem informační koncepce je adopce (uplatnění) společného přístupu k datové architektuře pro všechny orgány veřejné správy. Správce každého informačního systému musí vědět: | ||
* **Jaké** údaje (data) se vyskytují v informačních systémech veřejné správy, které jsou využívány pro podporu agendy | * **Jaké** údaje (data) se vyskytují v informačních systémech veřejné správy, které jsou využívány pro podporu agendy | ||
- | * **Odkud** tato data pochází. Tedy zda jde o údaje vytvářené v rámci činnosti agendy, získané ze základních registrů, | + | * **Odkud** tato data pochází. Tedy zda jde o údaje vytvářené v rámci činnosti agendy, získané ze základních registrů, |
* **Komu** údaje poskytuje (ať už na základě oprávnění o využívání údajů jiné agendy nebo na žádost) | * **Komu** údaje poskytuje (ať už na základě oprávnění o využívání údajů jiné agendy nebo na žádost) | ||
* **Jak zabezpečuje ochranu** údajů ať už při přístupu k údajům, tak vedené záznamů (logů) o těchto přístupech a ochrana těchto logů. | * **Jak zabezpečuje ochranu** údajů ať už při přístupu k údajům, tak vedené záznamů (logů) o těchto přístupech a ochrana těchto logů. | ||
Řádek 443: | Řádek 440: | ||
Každý správce ISVS, který obsahuje nějaký datový fond, je povinen zajistit (správce ISVS musí): | Každý správce ISVS, který obsahuje nějaký datový fond, je povinen zajistit (správce ISVS musí): | ||
- | + | | |
- | | + | |
- **Jednoznačnost -** rozdělit si datový fond na části | - **Jednoznačnost -** rozdělit si datový fond na části | ||
- | |||
- | |||
- **Referenční údaje** – musí být v souladu se základními registry | - **Referenční údaje** – musí být v souladu se základními registry | ||
- | + | | |
- | | + | - **Vlastní údaje agendy** – údaje vytvářené v rámci agendy (mohou být dále poskytovány jiným agendám jako agendové) |
- | + | - **Bezpečnost** – musí být zajištěna jak z hlediska ochrany osobních údajů, tak i z hlediska zabezpečení proti ztrátě či neoprávněnému pozměnění údajů | |
- | - **Vlastní údaje agendy** – údaje vytvářené v rámci agendy (mohou být dále poskytovány jiným agendám jako autoritativní) | + | |
- | + | ||
- | + | ||
- | - **Bezpečnost | + | |
Řádek 466: | Řádek 455: | ||
- | ===== Rozdělení / klasifikace dat ve veřejné správě | + | ==== Rozdělení / klasifikace dat ve veřejné správě ==== |
IKČR ukládá úřadům udržovat aktuální klasifikace základních informačních (datových) objektů architektury úřadu. Tyto identifikované objekty musí být klasifikovány do následujících kategorií a je nutné s nimi v aplikační architektuře nakládat způsobem, odpovídajícím jejich klasifikaci. | IKČR ukládá úřadům udržovat aktuální klasifikace základních informačních (datových) objektů architektury úřadu. Tyto identifikované objekty musí být klasifikovány do následujících kategorií a je nutné s nimi v aplikační architektuře nakládat způsobem, odpovídajícím jejich klasifikaci. | ||
- | Všechny údaje spravované v IS úřadu, tvoří tzv. **datový fond úřadu**. Základní existenciální (statické, kartotéční) údaje o subjektech (klientech, dodavatelích, | + | Všechny údaje spravované v IS úřadu, tvoří tzv. **datový fond úřadu**. Základní existenciální (statické, kartotéční) údaje o subjektech (klientech, dodavatelích, |
- | Zásadním požadavkem informační koncepce z hlediska klasifikace dat ve veřejné správě je zavedení pojmu **autoritativní | + | Zásadním požadavkem informační koncepce z hlediska klasifikace dat ve veřejné správě je zavedení pojmu **agendový |
Použitím výše uvedených principů můžeme údaje vedené v datovém fondu informačního systému veřejné správy (agendě), a souhrnně v datovém fondu úřadu, rozdělit z několika hledisek. Prvotním hlediskem je klasifikace datových objektů z hlediska zodpovědnosti za jejich validitu, viz výše bod **jednoznačnost.** | Použitím výše uvedených principů můžeme údaje vedené v datovém fondu informačního systému veřejné správy (agendě), a souhrnně v datovém fondu úřadu, rozdělit z několika hledisek. Prvotním hlediskem je klasifikace datových objektů z hlediska zodpovědnosti za jejich validitu, viz výše bod **jednoznačnost.** | ||
Řádek 482: | Řádek 471: | ||
* Transakční data individuálních řízení v agendách | * Transakční data individuálních řízení v agendách | ||
* Dokumenty | * Dokumenty | ||
+ | * Prostorová data | ||
* Analytická (agregovaná, | * Analytická (agregovaná, | ||
* Signálová data (datový proud v reálném čase) | * Signálová data (datový proud v reálném čase) | ||
- | * Metadata analytických dat, dokumentů a multimediálních objektů | + | * Metadata |
* Provozní a bezpečnostní auditní data (logy) | * Provozní a bezpečnostní auditní data (logy) | ||
- | * Parametrizační, customizační data, řídící číselníky (jazyky, měny, směrovací čísla, typy daní, kategorie sazeb, druhy paliv, kategorie vozidel, NACE, atd.) | + | * Parametrizační data, řídící číselníky (jazyky, měny, směrovací čísla, typy daní, kategorie sazeb, druhy paliv, kategorie vozidel, NACE, atd.) |
* Data programového kódu (zdrojový kód v databázi) | * Data programového kódu (zdrojový kód v databázi) | ||
- | Zásadní | + | Další zásadní |
* Obsahující osobní údaje | * Obsahující osobní údaje | ||
- | * Obsahující citlivé osobní údaje | + | * Obsahující |
* Neobsahující osobní údaje. | * Neobsahující osobní údaje. | ||
- | Zásadním | + | Základním |
- | V rámci RPP jsou udržovány informace o takto poskytovaných a využívaných údajích z legislativního hlediska, tj. tak jak jsou uvedeny v odpovídajícím právním předpisu. Z hlediska technického využití je pak správce ISVS, který údaje poskytuje prostřednictvím eGSB publikovat odpovídající technický předpis jak XML šablonu v rámci WSDL předpisu využívání publikovaných služeb eGSB. | + | V rámci RPP jsou udržovány informace o takto poskytovaných a využívaných údajích z legislativního hlediska, tj. tak jak jsou uvedeny v odpovídajícím právním předpisu. Z hlediska technického využití je pak správce ISVS, který údaje poskytuje prostřednictvím |
- | Z technického hlediska je tedy závazný předpis, jakým jsou data publikovány pro využívání na rozhraní Informačního systému základních registrů a eGSB. Tím je sjednoceno referenční rozhraní veřejné správy a zajištěna jednoznačná technologická prezentace právních pojmů z hlediska přenášených údajů. | + | Z technického hlediska je tedy závazný předpis, jakým jsou data publikovány pro využívání na rozhraní |
- | Současně | + | Současně |
- | Informační koncepce přepokládá novelizaci vyhlášek o datových prvcích informačních systémů (496/2006 Sb.) a referenčním rozhraní (53/2007 Sb.) tak, aby reflektovaly výše uvedené zásady. | ||
- | + | ==== Pravidla pro číselníková data ==== | |
- | ===== Pravidla pro číselníková data ===== | + | |
Řádek 522: | Řádek 510: | ||
- | ===== Pravidla pro referenční a autoritativní | + | ==== Pravidla pro referenční a agendová |
- | V rámci svého lokálního informačního systému mohou, respektive musí být úřadem pro výkon agendy využívány referenční a autoritativní | + | V rámci svého lokálního informačního systému mohou, respektive musí být úřadem pro výkon agendy využívány referenční a agendové |
- | **Autoritativní | + | **Agendový |
- | * Vzniká v dané agendě její činností (definováno příslušným zákonem) a správce agendy je zodpovědný za jeho správnost – autoritativní | + | * Vzniká v dané agendě její činností (definováno příslušným zákonem) a správce agendy je zodpovědný za jeho správnost – agendový |
* Je využíván v jiných agendách – současný stav (agenda má při své činnosti oprávnění využívat údaje jin agendy) | * Je využíván v jiných agendách – současný stav (agenda má při své činnosti oprávnění využívat údaje jin agendy) | ||
- | * Jeho použití z autoritativního | + | * Jeho použití z agendového |
- | **Povinnosti z hlediska | + | **Povinnosti z hlediska |
- | * Správce (agendy) registruje u Registru práv a povinností údaj jako autoritativní | + | * Správce (agendy) registruje u Registru práv a povinností údaj jako agendový |
- | * Správce publikuje údaj v rámci vybraného kontextu s vazbou na subjekt/ | + | * Správce publikuje údaj v rámci vybraného kontextu s vazbou na subjekt/ |
- | * Správce publikuje změny | + | * Správce publikuje změny |
- | * Správce přijímá reklamace na stav autoritativního | + | * Správce přijímá reklamace na stav agendového |
- | * Agenda využívající | + | * Agenda využívající |
- | * Agenda využívá údaj prostřednictvím eGSB | + | * Agenda využívá údaj prostřednictvím |
* Pokud agenda ukládá ve svém datovém fondu tento údaj, pak ho udržuje v souladu se skutečností odběrem změn | * Pokud agenda ukládá ve svém datovém fondu tento údaj, pak ho udržuje v souladu se skutečností odběrem změn | ||
* Pokud je při činnosti agendy zjištěna pochybnost o správnosti údaje, pak oznámí správci údaje | * Pokud je při činnosti agendy zjištěna pochybnost o správnosti údaje, pak oznámí správci údaje | ||
- | Z hlediska efektivity výkonu veřejné správy je zásadní, jak efektivně jsou referenční a autoritativní | + | Z hlediska efektivity výkonu veřejné správy je zásadní, jak efektivně jsou referenční a agendové |
- | a) Pokud nejsou tyto údaje ve větším množství v rámci agendy využívány, | + | - Pokud nejsou tyto údaje ve větším množství v rámci agendy využívány, |
+ | - Pokud jsou tyto údaje využívány agendou ve větším množství, nebo v případě nedostupnosti centrálních systémů hrozí nebezpečí z prodlení, pak je efektivní údržba lokální kopie referenčních a agendových údajů o subjektech a objektech agendy pro potřeby jejího výkonu. V tomto případě je nezbytně nutná systematická údržba těchto údajů tak, aby byly **v souladu** s údaji vedenými v základních registrech a agendových zdrojů. Za tímto účelem je nutné využívat procesu [[nap: | ||
- | b) Pokud jsou tyto údaje využívány agendou ve větším množství, nebo v případě nedostupnosti centrálních systémů hrozí nebezpečí z prodlení, pak je efektivní údržba lokální kopie referenčních a autoritativních údajů o subjektech a objektech agendy | + | Princip [[nap: |
- | Princip notifikace je zásadně typu **pull** a bez předávání údajů při notifikaci. Tedy agenda | + | V případě, že OVS využívá více než jeden vlastní |
- | V případě, že OVS využívá více než jeden vlastní (lokální) agendový informační systém a využívá referenčních a autoritativních kmenových údajů, musí být implementováno lokální řešení správy kmenových dat, které po iniciálním ztotožnění udržuje přijímáním notifikací z PPDF kmenová data úřadu aktuální a nezatěžuje PPDF (a ISZR s eGSB) průběžnými on-line dotazy. Osobní údaje získané tímto způsobem jsou uloženy mimo jednotlivé informační systémy a jednotlivými systémy jsou využívány pouze v případě potřeby. Tím je zajištěno oddělení a zabezpečení osobních údajů s nezpochybnitelným auditem přístupu k osobním údajům. | ||
+ | ==== Pravidla pro otevřená data (OD) ==== | ||
- | ===== Pravidla | + | Pro OVS platí povinnost publikace údajů VS v podobě otevřených dat dle následujících pravidel: |
+ | * Při publikaci veřejných informací určených k širokému použití veřejnosti je nutné dodržovat pravidla stanovené | ||
+ | * Při publikaci veřejných informací určených ke sdílení mezi veřejnoprávními subjekty navzájem i pro sdílení veřejných údajů mezi veřejnoprávní a soukromoprávní sférou, je nutné dodržovat pravidla stanovená pro veřejný datový fond (VDF). | ||
- | Otevřená data musí především naplnit legislativní požadavky. Navíc musí jejich | + | Otevřená data musí především naplnit legislativní požadavky |
* Otevřená data musí být katalogizována v NKOD v podobě jednotlivých datových sad. | * Otevřená data musí být katalogizována v NKOD v podobě jednotlivých datových sad. | ||
- | * Datová sada musí být tvořena logicky souvisejícími údaji logicky organizovanými do záznamů se stejnou datovou strukturou. | + | * Datová sada musí být tvořena logicky souvisejícími údaji, logicky organizovanými do záznamů se stejnou datovou strukturou. |
* Z datové sady nesmí být záměrně odstraňovány vybrané údaje nebo celé záznamy, které zveřejněny být mohou. | * Z datové sady nesmí být záměrně odstraňovány vybrané údaje nebo celé záznamy, které zveřejněny být mohou. | ||
- | * Datová sada musí být poskytována v podobě jednoho či více datových souborů ke stažení | + | * Datová sada musí být poskytována v podobě jednoho či více datových souborů ke stažení |
* Distribuce datové sady se smí vzájemně lišit pouze v datovém formátu, nikoliv ve svém obsahu. Každá distribuce musí obsahovat kompletní množinu záznamů tvořících datovou sadu. | * Distribuce datové sady se smí vzájemně lišit pouze v datovém formátu, nikoliv ve svém obsahu. Každá distribuce musí obsahovat kompletní množinu záznamů tvořících datovou sadu. | ||
- | * Alespoň jedna z distribucí musí být poskytována v otevřeném a strojově čitelném formátu ve smyslu definice otevřených dat podle § 3 odst. 11 zákona č.106/1999 Sb a musí: | + | * Alespoň jedna z distribucí musí být poskytována v otevřeném a strojově čitelném formátu ve smyslu definice otevřených dat podle § 3 odst. 11 zákona č.106/1999 Sb a musí: |
- | * Být opatřena podmínkami užití, které neomezují žádné (legální) užití jejího obsahu, především nesmí zamezovat | + | * Být opatřena podmínkami užití, které neomezují žádné (legální) užití jejího obsahu, především nesmí zamezovat komerčnímu užití |
* Musí být poskytována bez zbytečných překážek. Není možné podmiňovat přístup k distribuci registrací, | * Musí být poskytována bez zbytečných překážek. Není možné podmiňovat přístup k distribuci registrací, | ||
- | * Musí být publikována dle otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím, | + | * Musí být publikována dle otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím, |
* Každá distribuce v otevřeném a strojově čitelném formátu musí být opatřena logickým datovým schématem vyjádřeným ve vhodném a běžně používaném jazyku pro popis datových schémat, pokud takový jazyk pro daný formát existuje. Logické datové schéma popisuje reprezentaci datové struktury záznamů tvořících datovou sadu v příslušném formátu. Distribuce musí být vůči svému logickému datovému schématu validní. | * Každá distribuce v otevřeném a strojově čitelném formátu musí být opatřena logickým datovým schématem vyjádřeným ve vhodném a běžně používaném jazyku pro popis datových schémat, pokud takový jazyk pro daný formát existuje. Logické datové schéma popisuje reprezentaci datové struktury záznamů tvořících datovou sadu v příslušném formátu. Distribuce musí být vůči svému logickému datovému schématu validní. | ||
* Datová sada musí být detailně zdokumentována především za účelem maximálního možného zamezení dezinterpretace jejího obsahu. V případě, že z datové sady byly před jejím zveřejněním odstraněny některé údaje nebo celé záznamy z důvodu nemožnosti jejich zveřejnění, | * Datová sada musí být detailně zdokumentována především za účelem maximálního možného zamezení dezinterpretace jejího obsahu. V případě, že z datové sady byly před jejím zveřejněním odstraněny některé údaje nebo celé záznamy z důvodu nemožnosti jejich zveřejnění, | ||
* Obsah distribucí datové sady musí být aktualizován dle periodicity, | * Obsah distribucí datové sady musí být aktualizován dle periodicity, | ||
- | * Jsou povoleny pouze zpětně kompatibilní změny v datové struktuře záznamů tvořících datovou sadu((Změna ve struktuře datové sady je zpětně kompatibilní, | + | * Jsou povoleny pouze zpětně kompatibilní změny v datové struktuře záznamů tvořících datovou sadu. Změny v datové struktuře musí být implementovány do logických datových schémat distribucí. |
* V případě změn, které nejsou zpětně kompatibilní, | * V případě změn, které nejsou zpětně kompatibilní, | ||
* U datových sad, jejichž distribuce již nejsou aktualizované, | * U datových sad, jejichž distribuce již nejsou aktualizované, | ||
- | + | ==== Pravidla pro data veřejného datového fondu ==== | |
- | ===== Pravidla pro otevřená data VDF (VDF-OD) ===== | + | |
Datová sada zveřejněná jako otevřená data ve VDF musí k výše uvedeným podmínkám pro otevřená data splňovat ještě následující doplňující podmínky, které zajistí použitelnost a důvěru v data ve VDF: | Datová sada zveřejněná jako otevřená data ve VDF musí k výše uvedeným podmínkám pro otevřená data splňovat ještě následující doplňující podmínky, které zajistí použitelnost a důvěru v data ve VDF: | ||
- | + | | |
- | | + | * V případě duplicit u publikovaných datových sad, nebo doplňování údajů různými publikujícími ke stejné publikované entitě je nutné doplnit vazby na již publikované údaje ve VDF. Povinnost doplnění vazeb spadá na toho publikujícího, |
- | * V případě duplicit u publikovaných datových sad, nebo doplňování údajů různými publikujícími ke stejné publikované entitě je nutné doplnit vazby na již publikované | + | * U každé datové sady publikované do VDF musí být uvedena informace o [[nap: |
- | * U každé datové sady publikované do VDF musí být uvedena informace o notifikačním mechanismu o změnách dle příslušné OFN uvedené na Datovém portálu (DP). | + | * OVS, který datovou sadu zveřejňuje, |
- | * Orgán veřejné správy, který datovou sadu zveřejňuje, | + | |
- | * Datová sada je dostupná, pokud je trvale dostupná s maximálně N výpadky během jednoho T1, přičemž 1 výpadek trvá maximálně T2. | + | |
* Správce ISVS, ze kterého je datová sada získána, zodpovídá za věcnou správnost obsahu datové sady. To znamená, že zodpovídá za: | * Správce ISVS, ze kterého je datová sada získána, zodpovídá za věcnou správnost obsahu datové sady. To znamená, že zodpovídá za: | ||
* správnost jednotlivých záznamů tvořících datovou sadu a jednotlivých údajů, které ji tvoří, | * správnost jednotlivých záznamů tvořících datovou sadu a jednotlivých údajů, které ji tvoří, | ||
Řádek 591: | Řádek 578: | ||
* pravidelnou aktualizaci datových sad, | * pravidelnou aktualizaci datových sad, | ||
* předávání oznámení o aktualizacích notifikačnímu HUBu. | * předávání oznámení o aktualizacích notifikačnímu HUBu. | ||
- | * Číselníky | ||
- | |||
- | |||
- | ===== Pravidla pro data VDF s řízeným přístupem (VDF-ŘP) ===== | ||
- | Data VDF s řízeným přístupem jsou z principu otevřená data, která splňují podmínky definované zákonem č.106/1999 Sb., avšak z nějakých důvodů je jejich použití limitováno omezením přístupu k jejich distribucím. Z tohoto důvodu je nelze poskytovat anonymně komukoliv a tak se může vyžadovat případná registrace, nebo povolení publikující organizace k jejich užití. | ||
- | Pro tato data platí stejná pravidla jako pro otevřená data s výjimkou neomezeného přístupu, která je nahrazena pravidlem: | ||
- | * Orgán veřejné správy, který datovou sadu zveřejňuje, | ||
- | * seznam omezujících podmínek, | ||
- | * způsob požádání o povolení přístupu k datové sadě, | ||
- | * kontakty na příslušné autority schvalující přístup k datové sadě. | ||
- | ===== Pravidla pro analytická data ===== | ||
+ | ==== Pravidla pro analytická data ==== | ||
- | Každý úřad, který ze zákona udržuje primární individuální evidenční data o subjektech či objektech práva ve svých agendových systémech, | + | Každý úřad, který ze zákona udržuje primární individuální evidenční data o subjektech či objektech práva ve svých agendových systémech, |
Anonymizované statistické údaje jsou tříditelné podle všech parametrů (klíčů), které nejsou údaji specificky chráněnými a nezakládají možnost profilace. | Anonymizované statistické údaje jsou tříditelné podle všech parametrů (klíčů), které nejsou údaji specificky chráněnými a nezakládají možnost profilace. | ||
Řádek 621: | Řádek 598: | ||
Statistické údaje, které mohou orgány nyní ze zákona pověřené sběrem takových statistických údajů získat z jejich primárních evidencí, nesmějí být duplicitně získávány sběrem od subjektů. | Statistické údaje, které mohou orgány nyní ze zákona pověřené sběrem takových statistických údajů získat z jejich primárních evidencí, nesmějí být duplicitně získávány sběrem od subjektů. | ||
+ | ==== Pravidla pro prostorová data ==== | ||
- | ===== Pravidla pro geo-data ===== | + | Každý agendový informační systém spravující prostorová |
+ | * Být obsahově popsán do úrovně datových prvků v informačním systému o informačních systémech veřejné správy do úrovně datových prvků. Datový prvek odpovídá třídě prostorových dat v geografických informačních systémech. | ||
+ | * Publikovat služby sdílení prostorových dat | ||
+ | * Datové prvky prostorových dat, které jsou ve vztahu příbuznosti, | ||
- | Doplníme ve spolupráci s ČÚZK | ||
- | ===== Hierarchie povinnosti využívání údajů dle jejich závaznosti | + | ==== Hierarchie povinnosti využívání údajů dle jejich závaznosti ==== |
- Propojený datový fond | - Propojený datový fond | ||
- Referenční údaje ze základních registrů (využívá se [služeb ISZR) | - Referenční údaje ze základních registrů (využívá se [služeb ISZR) | ||
- | - Údaje publikované agendami a jejich AISy (využívá se [rozhraní | + | - Údaje publikované agendami a jejich AISy (využívá se [[:nap:egsb|eGSB / ISSS]]) |
- Veřejný datový fond | - Veřejný datový fond | ||
- Veřejné rejstříky a seznamy publikované způsobem umožňujícím dálkový přístup) | - Veřejné rejstříky a seznamy publikované způsobem umožňujícím dálkový přístup) | ||
Řádek 639: | Řádek 619: | ||
- | ====== Pravidla technologické architektury IS VS ====== | + | ===== Pravidla technologické |
+ | <WRAP center round tip 60%> | ||
+ | Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap-dokument: | ||
+ | Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap-dokument: | ||
- | ===== Klasifikace IT technologické | + | Zapracování pravidel této vrstvy |
+ | </ | ||
- | Klasifikaci prvků IT technologické architektury, | ||
+ | ==== Klasifikace IT technologické architektury ==== | ||
- | ===== Pravidla návrhu a využití On-Premise architektury | + | |
+ | IT technologická architektury (také jako " | ||
+ | - Výpočetní výkon, | ||
+ | - datová úložiště, | ||
+ | - koncová zařízení (Firewall, Switch, obecně aktivní prvky). | ||
+ | |||
+ | |||
+ | ==== Pravidla návrhu a využití On-Premise architektury ==== | ||
Řádek 661: | Řádek 652: | ||
- | ===== Pravidla využití PaaS a IaaS služeb eGC ===== | + | ==== Pravidla využití PaaS a IaaS služeb eGC ==== |
- | PaaS a IaaS služby eGC mohou být využity pro nahrazení kterékoliv služby na technologické vrstvě architektury úřadu, resp. interní implementace dané služby („funkce“ z pohledu architektonického modelu) může být nahrazena služnou PaaS nebo IaaS. Na PaaS a IaaS služby eGC budou kladeny stejné architektonické požadavky jako na platformy provozované on-premise. Pro služby eGC a on-premise budou stejné i bezpečnostní požadavky odpovídající úrovni hodnocení bezpečnostních dopadů ISVS tyto platformy využívající. | + | PaaS a IaaS [[nap: |
Praktické využití PaaS a IaaS služeb je očekáváno zejména ve formě skupin služeb odpovídajících provozní platformě určitého ISVS nebo provozního informačního systému, případně jeho jasně definované části (např. web front-end), a to buď na úrovni plně spravované technologické platformy včetně správy OS (PaaS), nebo na úrovni virtualizovaných výpočetních a diskových zdrojů (IaaS), jejichž správu bude úřad provádět vlastními silami nebo s využitím služeb třetí strany. Z pohledu eGC je pro dosažení vyšší úrovně efektivity preferováno použití služeb PaaS. | Praktické využití PaaS a IaaS služeb je očekáváno zejména ve formě skupin služeb odpovídajících provozní platformě určitého ISVS nebo provozního informačního systému, případně jeho jasně definované části (např. web front-end), a to buď na úrovni plně spravované technologické platformy včetně správy OS (PaaS), nebo na úrovni virtualizovaných výpočetních a diskových zdrojů (IaaS), jejichž správu bude úřad provádět vlastními silami nebo s využitím služeb třetí strany. Z pohledu eGC je pro dosažení vyšší úrovně efektivity preferováno použití služeb PaaS. | ||
Dalším příkladem využití PaaS služeb je využití plně spravovaných platforem databázových nebo aplikačních serverů včetně zajištění SW licencí. | Dalším příkladem využití PaaS služeb je využití plně spravovaných platforem databázových nebo aplikačních serverů včetně zajištění SW licencí. | ||
+ | |||
+ | ==== Pravidla pro režim Active - Active jednotlivých výpočetních uzlů ==== | ||
+ | |||
+ | Staví-li se výpočetní platformy v režimu Active - Active je nezbytné mít zajištěny minimálně 3 lokality, kdy 2 lokality slouží pro samotné výpočetní platformy a třetí lokalita pro umístění technologií dohledující zbylé lokality a rozhodující o jejich chování. | ||
+ | |||
+ | |||
+ | |||
+ | ===== Pravidla fyzické a komunikační infrastruktury IS VS ===== | ||
+ | |||
+ | <WRAP center round tip 60%> | ||
+ | Popis centrálně poskytovaných systémů a jejich služeb, funkčních celků a tematických oblastí je popsán v části [[nap-dokument: | ||
+ | |||
+ | Pravidla pro jednotlivé sdílené služby, funkční celky a tematické oblasti jsou popsány v části [[nap-dokument: | ||
+ | |||
+ | Zapracování pravidel této vrstvy architektury popíše úřad do své informační koncepce. | ||
+ | </ | ||
+ | |||
+ | |||
+ | KIVS/CMS je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů subjektů státní správy a samosprávy ke službám (aplikacím), | ||
+ | |||
+ | Připojení k CMS je možné realizovat prostřednictvím: | ||
+ | |||
+ | * Neveřejného KIVS operátora (Krajské sítě, Metropolitní sítě, ITS Ministerstva vnitra a další) | ||
+ | * Veřejného KIVS operátora (Soutěž KIVS operátora přes centrálního zadavatele MVČR) | ||
+ | * IPsec VPN | ||
+ | * SSL VPN | ||
+ | |||
+ | Pro OVS jsou přípustné pouze první 2 varianty - Neveřejný a veřejný KIVS operátor, komunikace mezi jednotlivými OVS je tak vedena výhradně prostřednictvím KIVS/CMS, tzn. jednotlivé OVS mají povinnost přistupovat k informačním systémům veřejné správy (ISVS) pouze prostřednictvím KIVS/CMS. | ||
+ | |||
+ | S výjimkou tzv. provozních informačních systémů, které jsou uvedeny v § 1 odst. 4 písm. a) až d) zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), je § 6g odst. 3 tohoto zákona správcům ISVS uložena povinnost poskytovat služby informačních systémů veřejné správy prostřednictvím CMS. Organům veřejné správy je prostřednictvím § 6g odst. 4 ZoISVS uložena povinnost využívat sítě elektronických komunikací CMS.¨ | ||
+ | |||
+ | Protože skrze CMS se publikují služby tzv. [[nap: | ||
+ | |||
+ | S ohledem na výše popsané vlastnosti CMS, jakož i s ohledem na výše popsané právní aspekty, lze také dodat, že využívání, | ||
+ | |||
+ | |||
+ | ===== Specifická pravidla pro architekturu úřadů ===== | ||
+ | |||
+ | |||
+ | ==== Pravidla pro architekturu dle velikosti a možností úřadů ==== | ||
+ | |||
+ | |||
+ | Pro obce 1. a 2. typu má vize architektury veřejné správy následující podobu: | ||
+ | |||
+ | Architekturu IT úřadu obce 1. a 2. typu (do určité velikosti, viz níže) tvoří pouze koncová zařízení pro uživatele, síťovou infrastrukturu jim jako sdílenou poskytuje kraj, aplikační služby pro státní správu v přenesené působnosti poskytnou ohlašovatelé agend a aplikační služby pro samosprávní působnost poskytne vyšší stupeň územní samosprávy (ORP, kraj) jako sdílenou službu. | ||
+ | |||
+ | Pro oblast samosprávy tak vychází koncepce z následujících principů: | ||
+ | |||
+ | |||
+ | - NAP je závazný pro všechny subjekty samosprávy, | ||
+ | - Informační systémy pro činnosti a agendy v přenesené působnosti přebírají v plném rozsahu od centrálních úřadů. Samosprávné činnosti si každý územněsprávní celek zajišťuje sám. | ||
+ | - Subjekty s méně než 10 zařízeními si pořizují pouze uživatelský HW a SW, tj. tato koncová zařízení, | ||
- | ====== Pravidla | + | ==== Pravidla |
+ | Úřady, zodpovědné ze zákona jako věcní správci sdílených prvků služeb eGovernmentu, | ||
- | ===== Klasifikace fyzické | + | Úřady, užívající služeb sdílených prvků eGovernmentu, |
+ | Úřady zodpovědné za implementaci a provoz centrální registrů a AIS pro služby v přenesené působnosti, | ||
- | Klasifikaci prvků fyzické (stavební, technologické) a komunikační infrastruktury vydá jako další akcelelrátorů OHA poté, co bude možnost zobecnit a sdílet zkušenost z dostatečného množství individuálních architektur úřadů v této oblasti. | + | Úřady užívající tyto centrální AIS pro služby v přenesené působnosti, nemodelují ve svých architekturách úřadu tyto jako aktivní prvky (nemají je ve své zodpovědnosti), nýbrž jako služby těchto systémů a rozhraní vlastních komponent na tyto systémy. |
+ | ===== Pohledy celkové skladby architektury veřejné správy ===== | ||
- | ===== Pravidla využití sdílených prvků infrastruktury ===== | + | ==== Pohled úředníka |
+ | {{ : | ||
- | KIVS, CMS, krajské konektory | + | ==== Pohled klienta - právnické osoby ==== |
- | Jste-li obcí, pak se připojujte se na CMS přes krajský konektor. | + | {{ :nap-dokument: |
- | Jste-li krajem, poskytněte obcím krajskou síť, protože je to bezpečné, spolehlivé a cenově efektivní. | + | ==== Pohled klienta |
- | Využitím služeb eGC zároveň dochází k fyzickému přemístění provozovaných služeb do datových center poskytovatele eGC a je třeba řešit související otázky připojení úřadu k poskytovateli eGC … bude doplněno | + | {{ : |
- | < | ||