INTEGROVANÝ REGIONÁLNÍ OPERAČNÍ PROGRAM SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE SPECIFICKÝ CÍL 3.2 PRŮBĚŽNÁ VÝZVA Č. 23 PŘÍLOHA Č. 4 PRAVIDLA PRO VYDÁNÍ STANOVISKA ODBORU HLAVNÍHO ARCHITEKTA EGOVERNMENTU PLATNOST OD 24. 2. 2016 Strana 1 z 6
Způsb pdání žádsti Žádst vydání stanviska je pdána Ministerstvu vnitra, Odbru Hlavníh architekta egvernmentu (OHA) prstřednictvím Infrmačníh systému datvých schránek (ID DS: 6bnaawp). Přílhu žádsti je Studie prveditelnsti vypracvaná v suladu s níže uvedenými pravidly. V případě že Studie prveditelnsti překračuje pvlenu velikst datvé zprávy, je mžné ji dručit sbně na sekretariát dbru na adresu nám. Hrdinů 1634/3, Praha 4. Lhůty pr vydání Stanviska OHA vydá Stanvisk nejpzději d 15 pracvních dnů. Další infrmace V rámci Stanviska mhu být nad rámec architektnickéh a technlgickéh řešení uplatněna další dpručení k prjektvému záměru. P dhdě je mžné pskytnut ze strany OHA knzultaci k prjektu v nutném rzsahu. Knzultace je bezplatná. Stanvisk OHA k prjektům IROP nenahrazuje stanvisk OHA ve smyslu usnesení vlády ze dne 2. 11. 2015 č. 889 a jeh přílhy č. 2 Základní zásady pstupu při čerpání finančních prstředků na výdaje suvisející s ICT s hdntu nad 6 mil. Kč rčně (resp. 30 mil. Kč za 5 let). Pdrbnsti a další infrmace jsu průběžně zveřejnvány na adrese http://www.mvcr.cz/clanek/agenda-dbru-hlavnih-architekta-egvernmentu.aspx. Technické a technlgické řešení prjektu (pžadavky na zpracvání Studie prveditelnsti) Sučástí předkládané studie prveditelnsti prjektu musí být vždy i dpvídající architektnické výstupy spjené s prjektem. Je pžadván, aby byly d studie zapracvány architektnické diagramy (phledy) dprvázené vysvětlením. Architektnický bsah je nezbytný zejména pr prkázání, že při návrhu prjektu byl uplatněn celstní architektnický přístup, byly uplatněny stanvené architektnické principy egvernmentu a jim dpvídající návrhvé vzry. Pvinné architektnické vzry jsu vypracvány na různých úrvních detailu, architektury úřadu i architektury řešení. Pr mdelvání a grafické vyjádření architektury úřadu (EA dle TOGAF) je dpručen pužívat nemdifikvanu ntaci jazyka ArchiMate 2.1, který se pstupně (s drbnými úpravami) stane pvinnu sučástí metdiky tvrby Nárdní architektury VS ČR. Strana 2 z 6
Enterprise architektura prjektu samtnéh prkázání ddržení metdik, standardů a vzrů Nárdníh architektnickéh plánu veřejné správy ČR Enterprise Architektura prjektu. Odpvídá capability architecture 1 úřadu dle TOGAF a připravvané metdiky NA VS ČR. Pstihuje relevantní díl všech struktur a vztahů z enterprise architektury úřadu 2, zahrnutých d prjektu neb s ním bezprstředně suvisejících. Úklem předkladatele je v tét architektuře představit prvky řešení na všech vrstvách tzv. čtyřvrstvé vize architektury egvernmentu 3, jejich stávající a plánvanu existenci a vzájemné vztahy. Zejména je ptřebné uvést: funkce, prcesy a služby veřejné správy (externí a interní), které budu řešením pdprvány. Rle uživatelů řešení a kmunikační rzhraní, kterými budu klienti službu veřejné správy využívat. Aplikační kmpnenty pdprující služby veřejné správy, jejich základní aplikační funkce a aplikační rzhraní na statní kmpnenty (interní a externí z phledu úřadu). Technlgické kmpnenty a platfrmvé (IT) služby datvéh centra využívané pr příslušné aplikační kmpnenty. Technlgické kmpnenty a služby kmunikační infrastruktury využívané pr příslušné aplikační kmpnenty. Pzice navrhvanéh řešení v kntextu strategické a aplikační architektury úřadu a navazujících subjektů veřejné správy Pzici (kntext) navrhvanéh prjektu ve strategické (celkvé) architektuře úřadu, resp. resrtu neb vyššíh správníh celku. Pr kntext úřadu je nutné na každé z vrstev architektury umístit prvky architektury, zahrnuté d prjektu, d celkvé mapy příslušné vrstvy architektury úřadu a ukázat na suvislsti. Například jak suvisí implementvaná služba s statními službami úřadu, jak nvá služba využívá sdílené kmunikační kanály úřadu (přepážky, CzechPOINT, prtál apd.), zda nvě implementvaná aplikační kmpnenta je první svéh druhu v úřadu neb zda vzniká duplicita, multiplicita (dsud chybně čast v případě spisvých služeb, prtálů, analytických nástrjů apd.). 1 Z angl. rig. Capability Architecture 2 Z angl. rig. Enterprise Architeture 3 Viz například Přílha 1 dkumentu Návrh patření ICT : http://www.mvcr.cz/subr/1-zasedaniprilha-c-1-pdf.aspx Strana 3 z 6
Způsb využití sdílených prvků architektury úřadu a egvernmentu Pr kntext s celkem egvernmentu je nutné demnstrvat (textem a diagramem) vztah prvků architektury prjektu k centrálním a sdíleným kmpnentám a službám egvernmentu. Zejména je třeba v aplikační vrstvě mdelu architektury vyjádřit vztah k následujícím existujícím a připravvaným systémům a prjektům: ZR (ISZR, ROB, ROS, RUIAN, RPP, ORG), egsb; Agendvé systémy přispívající d Prpjenéh datvéh fndu; CMS/KIVS, NDC, CzP, egsb, JIP/KAAS, Nárdní identitní autrita, ISDS, elegislativa a esbírka, OpenData, PVS. Je nutné vyjádřit vztah prcesů a služeb veřejné správy zahrnutých d prjektu k existujícím neb plánvaným sdíleným službám veřejné správy. V technlgické vrstvě je třeba vyjádřit vztah prjektu k existujícím neb připravvaným sdíleným IT službám Nárdních (resp. reginálních) datvých center, případně k dalším sdíleným IT službám. Ve vrstvě kmunikační infrastruktury je třeba vyjádřit využití sdílených prvků kmunikační infrastruktury egvernmentu. Přehled nahrazvaných prcesů a technlgických prvků a začlenění navrhvanéh řešení d stávajícíh prstředí úřadu a egvernmentu Architektura řešení prjektu 4. Ukazuje, jak bude prjekt realizván, shrnuje v mdelech tzv. funkční a ne-funkční specifikaci prjektu. Architektura řešení je nutná zejména pr: dlžení, jak jsu ddrženy Závazné architektnické vzry MV-OHA, které jsu a budu publikvány jak závazné vzry příslušných kmpnent architektur řešení; dlžení jak je realizvána a jak bude fungvat realizvaná sdílená služba v rámci prstředí prpjenéh datvéh fndu veřejné správy. Stanvení úrvně ddávky služeb realizvaných prjektem s ddržením minimálních pžadvaných standardů Stanvení úrvně ddávky služeb jedntlivým skupinám kncvých uživatelů připravvanéh řešení včetně rzhraní pr příjem a pskytvání dat jiným infrmačním systémům veřejné správy. Minimálně je nutné uvést: 4 Z angl. rig. Slutin Architecture Strana 4 z 6
Dstupnst dané služby v kntextu dby, kdy je služba dstupná (např. 24x7, v pracvní dbu ) případně vliv prjektu na zlepšení tht parametru vůči sučasnému stavu. Úrveň dstupnsti služby s hledem na skutečnu délku pskytvané služby vzhledem k plánvané (např. 95 %) případně vliv prjektu na zlepšení tht parametru vůči sučasnému stavu. Maximální dba bnvení ddávky služby (za jaku maximální dbu d zahájení výpadku služby je bnvena ddávka tét služby) případně vliv prjektu na zlepšení tht parametru vůči sučasnému stavu. Je nutné rzdělit ddávku služby prstřednictvím uživatelskéh rzhraní (uživatelem je člvěk) a prstřednictvím kmunikačních rzhraní (uživatelem je jiný infrmační systém). Přehled způsbu realizace pvinných a případných dalších kmunikačních kanálů Ppis kmunikačních kanálů pr přístup uživatelů a jiných infrmačních systémů. Pkud je uživatelem jakékli služby veřejnst, pak musí být splněny tyt pvinné kmunikační kanály: Pdání frmulář musí být realizvatelné s využitím infrmačníh systému datvých schránek a prtálu veřejné správy. Offline frmulář musí být realizvatelný jak digitálně pdepsaný dkument zaslaný standardní elektrnicku pštu. Frmulář může být dále realizván interaktivním prcesem v rámci prtálu řešení. V případě, že jsu vytvářeny nvé sdílené kmunikační kanály, pak jejich ppis, příns a předpkládané využití. Ppis základních živtních situací s ptvrzením ddržení minimálních standardů Identifikace a autentizace sb musí pdprvat aktuální stav implementace Nařízením EU 910/2014 elektrnické identifikaci a službách vytvářejících důvěru pr elektrnické transakce na vnitřním trhu a zrušení směrnice 1999/93/ES (eidas) Je uveden ppis jedntlivých živtních situací (use case) s uvedením případných becných standardů (jak zákn je 181/2014 Sb. Zákn kybernetické bezpečnsti) či specifickým standardům zadavatele. Zvláště pr nvě vytvářené sdílené služby. V případě mdernizace či aktualizace stávajících služeb je nutné uvést příns prjektu pr tyt živtní situace. Strana 5 z 6
Ppis následné technické a technlgické pdpry realizvanéh řešení a způsbu jejíh zajištění Uvádí ppis realizace technické a technlgické pdpry realizvanéh řešení. Zvláště uvádí realizaci předpkládané dstupnsti a pdpry úrvně dstupnsti služeb dle zvlenéh mdelu dstupnsti služeb. Musí být uvedena vazba na ddržení pžadavků kybernetické bezpečnsti dle výše uvedenéh zákna a vyhlášky během prvzu. Musí být uvedena exit strategie při uknčení dby udržitelnsti či případnéh uknčení smluvy pdpře ddanéh díla. Dpručený přístup k mdelvání Pr mdelvání v jazyce Archimate MV OHA využívá bezplatný nástrj Archi, dstupný z adresy http://www.archimatetl.cm/. Tent nástrj pdpruje univerzální výměnný frmát ArchiMate Mdel Exchange File Frmat Strana 6 z 6