1 Řešení Oracle pro Technologická centra ORP Technology Sales Consultant2 Přehled Výzva Technologická centra pro ORP Celkový koncept řešení Detaily k...
Řešení Oracle pro Technologická centra ORP [email protected], Technology Sales Consultant
Přehled • Výzva Technologická centra pro ORP • Celkový koncept řešení • Detaily k jednotlivým částem • Shrnutí
2
• Výzva Technologická centra pro ORP • Celkový koncept řešení • Detaily k jednotlivým částem • Shrnutí
3
Výzva Technologická centra pro ORP
• Část I.: Zřízení technologického centra ORP, včetně zajištění povinných služeb • Část II.: Pořízení elektronické spisové služby ORP a řešení pro obce ve správním obvodu • Část III.: Vnitřní integrace úřadu ORP • Služby zblízka • Proces, jak žádat o dotaci
4
Strategické cíle
• Zefektivnit činnost úřadů veřejné správy, • snížit finanční nároky na chod administrativy • a zajistit transparentní výkon veřejné správy
vytvoření robustní, bezpečné a efektivní infrastruktury, schopné zprostředkovat přístup k datovým zdrojům s potenciálem dalšího rozvoje
5
Část I.: Zřízení technologického centra ORP • hardware, software, aplikační vybavení, technologie pro zajištění povinných služeb – zejm. negarantovaného úložiště dat jako výstupů ze systémů elektronických spisových služeb • typových projektů samospráv • systémových služeb a dalších aplikací provozovaných pro potřeby samosprávy měst a obcí • centrálních projektů, zejména pro implementaci potřebných komponent základních registrů • max. velikost dotace 2,8 mil. Kč
6
Část II.: Pořízení spisové služby • Zákon 499/2004 Sb. (190/2009 Sb.) Archiválie
Národní digitální archiv
Vyřízené a uzavřené spisy Nevyřízené a neuzavřené spisy
Technologické centrum Kraje
Technologické centrum ORP DMS
APV
Obec
Odeslání
Vyřízení
Postoupe ní
Zápis do deníku
SPSSSL
Datové schránky adresátů
Uložení do pracovního úložiště
Vlastní datová schránka
Čtení elektronického dokumentu
DMS - elektronická spisovna
7
Část II.: Pořízení spisové služby
• 1 mil. Kč na vlastní el. sp. služby • + 60 tisíc Kč na každou obec s matrikou a stav. úřadem, která o zajištění přístupu projeví zájem • + 35 tisíc Kč na každou obec s matrikou • + 19 tisíc Kč na každou obec zákl. typu
8
Část III.: Vnitřní organizace úřadu
• • • •
„kultivace“ vnitřních systémů komponenty pro zpracování agend vazby na ekonomiku a správu aktiv vazby vůči základním registrům
• SOA, minimalizace TCO, technologie middleware • max. velikost dotace je 1,3 mil. Kč
9
Negarantované úložiště (DMS)
• Velmi důležitou povinnou službou TC je také zřízení negarantovaného (u TC ORP) úložiště dat jako výstupů z elektronické spisové služby. Negarantované úložiště, umístěné na TC ORP, je určeno pro ukládání nevyřízených a neuzavřených a spisů pořízených nebo přijatých jak samotnou ORP , tak spádově všemi obcemi ve správním obvodu ORP.
10
Czech POINT@home – „portál úředníka“ • Propojení elektronických, navenek poskytovaných služeb s portálem Czech POINT@home • Rozsah podporovaných oblastí odpovídá poskytovaným elektronickým službám centrálního portálového řešení Czech POINT@home • elektronickou službu rezervace času úředníka, • elektronickou podatelnu • a elektronickou úřední desku
11
Návaznost na KIVS
• Investice do komunikačních sítí pro připojení ke KIVS • (adresářové služby, Identity Management, jmenné služby DNS, služba přesného času) • (poštovní server, antivir, centrální dohledový systém – kontroluje dostupnost a umožňuje správu eGON center)
12
Další požadavky
• garantovaná doba odezvy do 1 resp. 4 hodin • garantovaná doba obnovení funkce do 4, 6, resp. 24 hodin • Na úrovni ORP je nutné zajistit dohled a servis nad provozem po dobu 12 hodin, 5 dní v týdnu. • integrace přes WS, XML resp. datový soubor s jasně definovanou strukturou
13
Infrastruktura
Centrální backup
14
Popis serverové části • minimálně dva fyzické servery pro služby typu aplikační server a DB • I když budou oba servery identicky nainstalovány, bude veškerý provoz typu DB směřovaný na jeden z nich a provoz služeb aplikačního serveru na druhý • vzhledem k počtu a různorodosti provozovaných projektů a aplikací, musí podporovat nejrozšířenější typy operačních systémů (UNIX, Linux, MS Windows) • Nejméně 1 CPU čtyř jádrový s 64-bitovou architekturou, frekvence nejméně 2 GHz, nejméně 8 GB RAM s možností rozšíření na nejméně 32 GB 15
Popis úložiště • NAS (Networked Attached Storage) popř. SAN (Storage Area Network), s implementovanou TIER architekturou a HSM (Hierarchical Storage Management) designem. Produkční data ukládat na TIER 0 na rychlé FC disky (nebo rychlejší) diskového úložiště (např. rychlost pro 4KB bloky alespoň 60 tis. IOPS pro RAID 6, R/W sekvenčně) • Propojení serverů a diskového pole bude redundantní pro zajištění vysoké dostupnosti dat. • Čistá využitelná kapacita: 1TB 16
Předpoklady pro žádost
• Projektový záměr – s vazbou na strategický dokument (Integrovaný operační program) • Studie proveditelnosti – realizovatelnost a ověření smysluplnosti projektu • Kvantifikace cílů – monitorovací indikátory výstupu • Nezapomínat na ostatní (např. popis struktury a zapojení projektového týmu)
17
• Výzva Technologická centra pro ORP • Celkový koncept řešení • Detaily k jednotlivým částem • Shrnutí
18
Nabídka kompletního řešení integrace hardware aplikace
technologie
software
metodika
spolupráce s partnery 19
Struktura partnerské spolupráce
• • • • •
Vaši současní dodavatelé Partneři na implementaci spisové služby Partneři pro metodiku Dodavatel(é) SW Dodavatel(é) HW
20
Vyzkoušený model
21
Další výhody nabídky
• Znovupoužitelnost: • Maximální využití stávajících investic • Připravenost na budoucí projekty, škálovatelnost
• • • •
Otevřené standardy – možnost výběru subdodavatelů Zabezpečení proti výpadku služeb či ztrátě dat Přístup z libovolného Web prohlížeče Možnost postupné optimalizace procesů
22
Řešení Oracle pro TC ORP
23
• Výzva Technologická centra pro ORP • Celkový koncept řešení • Detaily k jednotlivým částem • Shrnutí
24
Spisová služba - termíny
• Kdo nevykonával, bude muset do 1.7.2010 • Kdo vykonával jen v listinné podobě, bude muset od 1.1.2010 vést evidenci i elektronických dokumentů • Do 1.7.2012 bude muset spisová služba splňovat požadavky Národního standardu pro elektronické spisové služby
25
• §69a, odst. 8 : Neprokáže-li se opak, dokument v digitální podobě se považuje za pravý, byl-li podepsán platným uznávaným elektronickým podpisem nebo označen platnou elektronickou značkou osoby, která k tomu byla v okamžiku podepsání nebo označení oprávněna, osoby odpovědné za převedení z dokumentu v analogové podobě nebo změnu formátu dokumentu v digitální podobě nebo osoby odpovědné za provedení autorizované konverze dokumentů a opatřen kvalifikovaným časovým razítkem. Ustanovení věty první se vztahuje i na dokumenty vzniklé z činnosti původců, kteří nejsou určenými původci.
26
• §69a, odst. 3 : Uchovávání dokumentu v digitální podobě provádí určený původce postupem zaručujícím věrohodnost původu dokumentu, neporušitelnost jeho obsahu a čitelnost dokumentu, a to včetně údajů prokazujících existenci dokumentu v digitální podobě v čase. Tyto vlastnosti musí být zachovány po dobu skartační lhůty dokumentu. Je-li potřeba zachování věrohodnosti původu dokumentu kratší než skartační lhůta dokumentu, uvede to určený původce ve svém spisovém a skartačním plánu.
Uspořádání do spisů Podpora skartačního řízení (spisový plán) Kontrola a bezpečnost přístupu (audit) Evidence (jedinečné pořadové číslo ad.) Povinná metadata Národní specifika (datové schránky, vyznačení právní moci či vykonavatelnosti) • a další...
29
Nebezpečí
Současná eSSL
Nová eSSL
Jedna velká aplikace
30
Koncept řešení Oracle
Současná eSSL
Nová eSSL
ERMS - EDMS Infrastruktura
Komponentová architektura
31
Srovnání variant
„Jedna velká aplikace“
„Komponentová architektura“
• vše od jednoho dodavatele
• možnost více dodavatelů
• není třeba vnitřní integrace
• otevřené standardy
• úložiště degradováno na minimum
• úložiště plně využito
• otázka integrace s okolím
• integrace s okolím přes standardy
• proti principům SOA (a výzvy)
• plně dle principů SOA (a výzvy)
• umí jen to, co si zaplatíte
• nabízí kompletní funkčnost ECM (je však možné „začít v malém“)
• otázka podpory pro další projekty („Portál úředníka“)
• podpora pro další projekty
32
Životní cyklus dokumentů
Stoupa
Evidence, vyřízení,
Dokument uložen v archívu
vyhotovení, odeslání
(neměnný, dohledatelný, audit)
Skartační řízení
Národní archív
33
EDMS vs. ERMS
EDMS
ERMS
• opatření dokumentu metadaty, • implementace workflows, • požadavky na zabezpečení (či přístup) k dokumentu, • vyhledávání • ....
34
Garantované vs. Negarantované úl. • Zákon nezná termíny „Garantované“, resp. „Negarantované úložiště“ (ani „úložiště“) • Jedinými známými termíny jsou: • spisovna, jako „místo určené k uložení, vyhledávání a předkládání dokumentů pro potřebu původce a k provádění skartačního řízení,“ • správní archiv, jako „součást původce určená k dohledu na spisovou službu původce a k uložení, vyhledávání a předkládání dokumentů se skartační lhůtou delší než 5 let,“ • Národní standard pro eSSL pak zná ještě termíny ERMS, EDMS, resp. CMS 35
Srovnání „Negarantované úložiště“
„Garantované úložiště“
• musí splňovat požadavky zákona 499/2004
• vše, co negarantované úložiště
• tj. spolu se spisovou službou vyhovovat Národnímu standardu (norma MoReq2) • zejm. pak zajistit • věrohodnost • neporušitelnost • čitelnost • uspořádání do spisů atd. po celou dobu skartační lhůty, a to do 5 let
+ podporu pro skartační lhůty větší než 5 let (v přípravě je koncept implementující normu OAIS) + zaručit větší kapacity (5 + 20 + 40 TB)
36
Infrastruktura - HW
• Nabídka připravena pro Datové schránky (spolu s partnerem Sun Microsystems) • Obsahuje: • 2x QC, 16 GB RAM • Diskové pole s požadovanými vlastnostmi (kap. až 2TB) • Zálohování na pásky
37
Infrastruktura - schéma
Centrální backup
38
Infrastruktura – role DB
Server 1
Server 2
Spisová služba
Spisová služba
Úložiště (DMS)
Úložiště (DMS)
Apl. Server / Middleware
Apl. Server / Middleware
Databáze
Databáze
39
Infrastruktura – role DB
Server 1
Server 2
Spisová služba
Spisová služba
Úložiště (DMS)
Úložiště (DMS)
Apl. Server / Middleware
Apl. Server / Middleware
Databáze
RAC
Databáze
40
Srovnání
Bez RAC
S RAC
• postačující ve smyslu výzvy
• vysoká dostupnost na db vrstvě (zejm. bude-li aplikací více)
• při výpadku je třeba pustit db na druhém serveru cca. 10 minut výpadek • není možné škálovat výkon
• pro db se sčítá volný výkon na obou serverech (výkon) • škáluje výkon • v případě potřeby je možné přidat třetí a další servery
41
Obecný problém integrace
Aplikace 1
Aplikace 2
Aplikace 3
Aplikace 4
Aplikace 5
Aplikace 6
42
Nevýhody
• Pro 4 a více propojených aplikací je nákladnější (na vývoj i na údržbu) • Často se využívají proprietární protokoly • Při chybách či změnách není zřejmé, kdo by měl být odpovědný • Ztrácí se viditelnost (co se vůbec v organizaci děje) • Pomalá reakce na nové potřeby
43
Integrace pomocí „sběrnice“
Aplikace 1
Aplikace 2
Aplikace 3
Sběrnice služeb
Aplikace 4
Aplikace 5
Aplikace 6
44
Výhody
• Každé propojení existuje právě jednou • Je možné oddělit požadavky na • směrování a tranformace zpráv • bezpečnost • přepínání standardních protokolů
• Možné vytvořit katalog služeb • Možné centralizovat správu (monitoring, SLA)
45
• Výzva Technologická centra pro ORP • Celkový koncept řešení • Detaily k jednotlivým částem • Shrnutí
46
Co nabízí Oracle?
Řešení, • které kompletně pokrývá požadavky výzvy, • které respektuje finanční mantinely dané výzvou • které je postaveno na spolehlivých standardních produktech, • které je postaveno ve spolupráci s partnery • výběr partnerů je primárně Vaše volba
47
Jak dále pokračovat? • kontaktujte [email protected], • vyplňte dotazník, • respektujeme Vaše preference při výběru partnera, od kterých budete chtít dodat celé nebo jen část řešení
