Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z

Transkript

1 Vydávání stanovisek k ICT projektům dle usnesení vlády č. 889 z část 2: Motivace k architektuře úřadů OHA, Ing. Pavel Hrabě, PhD. Externí poradce Odbor hlavního architekta egov MV ČR

2 Obsah prezentace 1. Úvod do problematiky Motivace k architektuře úřadů Přehled principů a aktuálních výstupů Národní architektury VS ČR (NA VS ČR) 2. Detail Obsah žádosti a postup při vydávání stanoviska OHA 2

3 1. Úvod do problematiky Přehled Národního architektonického rámce (NAR), principů a aktuálních výstupů Národní architektury VS ČR (NA VS ČR) 3

4 Enterprise Architecture Enterprise architecture (architektura úřadu) jako manažerská metoda je prostředkem pokorného a celostního poznávání organizace na podporu rozhodování, zejména při plánování strategických změn. Architektura úřadu představuje popis struktury a chování úřadu (kdo jsme), plánovaných změn (odkud a kam jdeme) a jejich informatické podpory (k čemu nám je a má být ICT). 4

5 Funkce útvarů architektury úřadů Architekti v týmu útvaru architektury úřadu, musí naplňovat nejméně těchto pět rozdílných, ale vzájemně se doplňujících a podmiňujících funkcí: Lokální (interní) Enterprise Architekt úřadu a těch organizací úřadu (resortu), které jej o to požádají a kde nepostačí předchozí role rádce. Enterprise a Solution Architect architektur (byznys, aplikačních, datových i technologických) centrálních sdílených (nebo jednotných) služeb a centrálních sdílených (nebo standardizovaných) systémů Governmentu (egovernmentu) na úrovni resortu (úřadu). Přirozený vzor a leader (metodik) tvorby Enterprise a Solution architektur v jednotlivých OVM v resortu (úřadu), tj. tvůrce a vykladač přizpůsobené metodiky, správce resortních sdílených znalostí (vzory, návody, referenční modely a praktické příklady) a správce prostředků pro sdílení architektonických znalostí (architektonické úložiště, portál, wiki, diskusní fóra, ) Kontrolní orgán (jako stavební úřad) předběžně kontrolující vybrané vlastnosti v rámci resortu (úřadu) předkládaných IT projektů vůči zásadám NAP (vůči územnímu plánu) a vůči vyhlášeným standardům architektury řešení (jako ve stavebnictví vůči tzv. regulačnímu plánu). Auditní orgán stanovující požadovanou úroveň architektonické zralosti jednotlivých organizací resortu (úřadu), jejich architektonického oddělení a jeho procesů a governance a orgán kontrolující dosažení této úrovně v požadovaném čase a její zachování. 5

6 Národní architektura ICT VS ČR názvosloví NA, NAR a NAP Národní architektura (NA) je uplatněním metod a myšlení podnikové architektury na veřejnou správu ČR. Představuje souhrn lokálních architektur OVM a centrálních architektur egovernmentu. Národní architektonický rámec (NAR) představuje myšlenkový koncept, metodiku postupu, sadu standardů, pomůcek a návodů pro tvorbu a údržbu NA a NAP. tj. pravidla tvorby a nástroje Národní architektonický plán (NAP) je popisem plánovaného cílového stavu NA v určitém čase a současně plánem cesty, tj. implementačních kroků (programů a projektů), vedoucích ze současného stavu k dosažení stavu cílového. NAP nedělá jen OHA, je to soubor architektonických modelů a diagramů, udržovaných společně OHA a OVM, členěný na: architektury sdílených řešení architektury úřadů 6

7 Východiska pro návrh metodiky TOGAF - je mezinárodně uznávaný rámec pro řízení tvorby enterprise architektury ve společnostech využívajících prostředků informačních technologií. Původní koncept vznikl v USA, ale již více než deset let se používá po celém světě včetně České republiky. jak dělat architekturu, vrstvy atd. ArchiMate - je nezávislý grafický modelovací jazyk. Spravuje ho konsorcium Open Group, vyhlášen jako standard pro popis enterprise architektury. objekty a jak modelovat 7

8 Vztah rámce a obsahu architektury 8 Petr Klučka 2013 TOGAF - je mezinárodně uznávaný rámec pro řízení tvorby, správy a údržby architektury v organizacích využívajících prostředků informačních technologií ArchiMate - je nezávislý grafický modelovací jazyk pro popis a vizualizaci architektury

9 Cyklus tvorby architektury 1. Získání podpory organizace pro tvorbu architektur 4. Řízení změn a zlepšování schopností 3. Uvedení návrhů do života 2. Návrh varianty změn architektury 9

10 Technologie Aplikace Byznys Shrnutí základu ArchiMate Pasivní struktury Chování Aktivní struktury 10

11 Klíč k architektuře egovernmentu Jak je služba VS dostupná v kanálech egovernmentu? Základní meta-model NA VS ČR Jak to nabízí výš? Služba Co to dělá? Funkce 11

12 Architektura strategie a směřování Architektura výkonnosti Architektura rizik a bezpečnosti Architektura shody s pravidly Struktura domén obsahu Národní architektury ICT VS ČR Architektura výkonu a provozu veřejné správy Architektura informačních systémů Architektura IT (SW/HW) technologické infrastruktury Pavel Hrabě 2014 Architektura komunikační technologické infrastruktury Otázky: Jaké funkce a služby VS děláme, jaké (sdílené) informační systémy nám v tom pomáhají, na jakém HW a SW platformách, na jaké komunikační infrastruktuře VS a v jakých datových centrech. Kam chceme jít, jak dobří v tom chceme být, čeho se při tom bojíme a co proti tomu budeme dělat, jakými pravidly jsme svázáni. 12

13 Vrstvy architektury Historie Vize Celostní pohled Detailní přehled o doméně / segmentu Prostředí Co a proč máme, chceme mít? Podniková architektura (EA) Návrh řešení pro jednotlivé iniciativy / požadavky / projekty Design / konstrukce řešení prvku Jak to funguje, má fungovat? Architektura řešení (SA) Jak se to dá vytvořit? Design řešení (SD) 13

14 Pyramidální model architektur úřadu / podniku Architektonická vize Celostní pohled na organizaci Mapa segmentů & schopností Podniková ontologie Slovník pojmů /Thesaurus Detailní doménové a segmentové architektury Průřezové segmentové architektury ( pro sekce, odvětví, ) Motivační architektura Výkonnostní architektura Byznys architektura Architektura IS (datová & aplikační) Architektura technologické infrastruktury Bezpečnostní architektura Architektura pravidel a standardů Motivační architektura Výkonnostní architektura Byznys architektura Architektura IS (datová & aplikační) Architektura technologické infrastruktury Bezpečnostní architektura Architektura pravidel a standardů Průřezové architektury řešení ( pro iniciativy, projekty, ) Architektury řešení pro domény, strategické iniciativy a projekty Design / konstrukce řešení prvků Pavel Hrabě 2014 Pavel Hrabě 2014 Pavel Hrabě

15 Definice rozsahu modelů - 1 Architektury (na úrovni enterprise) se modelují výhradně pro nějaký úřad, a to na libovolné úrovni hierarchie veřejného sektoru. Výjimkou je modelování: klíčových centrálních sdílených informačních systémů egovernmentu ČR, viz výčet vybraných klíčových prvků architektury EU jako jsou společné procesy, služby a aplikační nebo platformové komponenty na úrovni EU architektury na straně obecného (typové) klienta veřejné správy. Zde nejde o individuální, ale o referenční model. Výčet tzv. povinných subjektů (po etapách zavádění NA VS ČR) bude dán právním předpisem (nařízením vlády, vyhláškou). 15

16 Definice rozsahu modelů - 2 Každý úřad bude vytvářet až tři samostatné modely rozdílného rozsahu z hlediska velikosti modelovaného enterprise: VLST - Vlastní model architektury úřadu (OVM) SPOL - Společný model úřadu a všech jím kontrolovaných (a metodicky vedených) organizací ROZS Rozšířený model řadu s prvky od spolupracujících organizací, úřadů, kdekoli v systému veřejné správy (případně soukromé sféry) 16

17 Úroveň Segmentace Národní architektury VS ČR Šířka Čas Segmentová Strategická architektura architektura úřadu Segmentová architektura Schopnostní Schopnostní Schopnostní Schopnostní architektura Schopnostní architektura Schopnostní architektura Segmentová Schopnostní architekturasegmentová Schopnostní architektura architektura architektura Schopnostní Schopnostní architektura Schopnostní Schopnostní architektura Schopnostní architektura Schopnostní architektura Schopnostní architektura Schopnostní architektura architektura architektura architektura Schopnostní Schopnostní Schopnostní Schopnostní architektura Schopnostní architektura Schopnostní architektura Schopnostní architektura Schopnostní architektura Schopnostní architektura architektura architektura architektura Strategická architektura vždy obsahuje v modelu celý úřad. Strategická architektura slouží ke strategickému plánování rozvoje informatiky na několik let dopředu. Segmentová architektura slouží modelování částí úřadu, které mají společné mechanismy fungování nebo budou předmětem společné změny několik vzájemně kolmých dimenzí segmentace Např. agendová, funkční (odvětvová) Architektura schopností je dílčí architektura určité oblasti externích, interních nebo průřezových schopností úřadu.. Je nejčastěji vytvářena ve spojení s nějakou změnou a pro ni plánovaným projektem realizace. 17

18 Hledisko Rozhodování, Informování Soudržnost Pohledy Moje role a odpovědnost Moji podřízení, jejich kompetence Definované ekonomické procesy Používané IS Změny v procesech Zainteresovaní, hlediska a pohledy Společný model Specifická hlediska Individuální pohledy na model Hledisko Rozhodování, Přehled Pohledy Služby zajišťované úřadem Struktura útvarů a oddělení Hledisko Informování, Detail Pohledy Personální funkce Personální IS Hledisko Navrhování, Soudržnost Pohledy Kancelářský SW Koncové stanice Telefony a tiskárny Hledisko Informování, Detail Pohledy Monitoring HW CPU Load, Vydávání FW stanovisek k ICT projektům, OHA MV ČR Petr Klučka 2016 Zdroj: Petr Klučka, projekt MPO, 2016 Hledisko Informování, Soudržnost Pohledy Interní audit Komunikace Ochrana dat 18

19 Aktuálně definovaná hlavní hlediska NAP 19

20 Rozsah pohledů podle detailu prezentovaných informací L0 Přehledová úroveň pohledu na architekturu úřadu - nejvyšší úroveň pohledu na modelovaný úřad jako celek. Představuje vyjádření principu nebo přehledu modelu. Pro zdůraznění strategického principu vyzdvihuje pouze podstatné výskyty určitých konceptů modelu a ty méně podstatné vynechává. L1 Základní úroveň - běžná úroveň pohledu na příslušnou strategickou, segmentovou nebo schopnostní architekturu modelovaného úřadu. Vizualizuje všechny inventurou nalezené nebo do budoucna projektované výskyty určitých konceptů (prvků) modelu a vazby mezi nimi. Obvykle se zaměřuje pouze na několik vybraných konceptů architektury úřadu. Například na aplikační komponenty, jejich služby a rozhraní. L2 - Detailní úroveň pohledu - rozvíjí do ještě většího (plného) detailu přidáním dalších konceptů metamodelu a jejich atributů strategický, segmentový pohled ale zejména schopnostní pohled na jednotný celostní model architektury úřadu. Například v aplikační architektuře přidává spolupráci aplikací a více úrovní vnitřních funkcí aplikací. 20

21 Architektonické principy VS ČR 2016 Název principu Znění principu 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 sdílení Elektronické služby veřejné správy jsou navrhovány a budovány primárně na principu 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ů. 21

22 Architektonické vzory Sdílených služeb egovernmentu 22

23 Ukazatel TCO pro ICT VS ČR Legenda: Jednorázové náklady Průběžné náklady A. Předběžné analýzy, zadání, výběr a nákup B. Pořízení Hardware/ Software (ne SaaS) C. Vývoj, imlementace / integrace a zk. provoz F. Projekty postupného zlepšování řešení (částečně pro SaaS) G. Projekty Upgrade (ne SaaS) I. Konzervace a ukončení řešení (ne SaaS) Model TCO pro ICT VS ČR verze 3.5 A1. Předběžné studie (proveditelnosti, ) A2. Náklady na proces zadání, výběru a nákupu B1. Technická infrastruktura (HW, sítě, ) B2. Stavební infrastruktura (budovy, chlazení ) B3. Systémové SW licence B4. Vývojové SW licence B5. Aplikační SW licence C1. Projektové řízení C2. Návrh změněných procesů C3. Řízení organizačních změn (OCM) C4. Technické nastavení řešení C5. Obsahové (aplikační) nastavení řešení C6. Vývoj aplikace nebo úprav na míru C7. Realizace rozhraní C8. Pořízení / Migrace dat C9. Testování C10.Školení C11.Předání do provozu a ověřovací provoz F1. Funkční (procesní) zlepšování F2. Technické zlepšování F3. Roll-out projekty F4. Projekty (nákladové) optimalizace řešení G1. Aplikační upgrade G2. Upgrade systémového SW G3. Technologický upgrade G4. Infrastrukturní upgrade I1. Útlum a archivace řešení I2. Příprava dat pro migraci I3. Likvidace zařízení D. Provoz a podpora řešení (ne SaaS) E. Hardware/Software údržba a úpravy (ne SaaS) H. Zvýšené náklady užívání řešení X.Předplatné na služby (pouze SaaS) Z. Ostatní režijní náklady Pavel Hrabě 2014 D1. Provoz budov a technologií dat. centra D2. Provoz a podpora IT tech. syst., OS a DB D3. Provoz a podpora aplikací E1. Údržba technologické infrastruktury E2. Údržba systémového SW a DB E3. Údržba aplikačního SW E4. Průběžné úpravy řešení /aplikačního SW H1. Náklady ze ztráty produktivity H2. Náklady spojené s užíváním řešení X1. Nákup aplikačního SW jako služby (SaaS) Z1. Ostatní provozní režie Z2. Ostatní správní režie 23

24 Děkujeme za pozornost tým OHA 24