Tak uz mam takmer vsetky infoziadosti uzavrete, trochu to tu uletelo inym smerom, skusim to tu upratat a zosumarizovat po jednotlivych fazach projektu.
Štúdia uskutočnitelnosti
Dávam do pozornosti zdôvodnenie prečo máme centrálne riešenú dátovú časť.
a
Z toho čo sa tu popísalo a čo sa mi podarilo dlhými diskusiami s konzumentami dát zistiť by som s takouto štúdiou nesúhlasil hneď v niekoľkých bodoch.
Vzhľadom na množstvo uzlov kde údaje vznikajú ako i množstvo uzlov pre distribúciu, je
dvojstranná výmena (na úrovni dvoch subjektov) neefektívna, nevyhovuje platnej legislatíve
(eGovernment), vyvoláva dodatočné náklady pri spracovaní, riešení nezrovnalostí
Problém nie je počet uzlov. Ak sa potrebuje nejaký IS integrovat na 5 webovych sluzieb alebo datovych zdrojov, tak sa bude integrovat na 5 webovych sluzieb aj ked to bude jeden system alebo 5 systemov. Problem je inde. To co CSRU centralizaciou dokazalo je, ze netreba riesit vsetku tu byrokraciu (DIZ), VPN tunely okolo. Z diskusii s konzumentami dat vyplynulo, ze toto je najvacsia brzda.
CSRU sa rad prirovnava k MUK (modul uradnej komunikacie) a ten zase k estonskemu x-road. Ak si pozriete zdrojaky x-roads alebo si o tom aspon nieco precitate (co by som cakal od autorov studie) tak zistite, ze cely slavny X-Road vobec ziadnu datovu cast neriesi, dokonca neriesi ani pridelovanie prav. Jedine co to riesi je podpisovanie sprav a ich vymenny standardny format. Ovela blizsie ako centralnemu datovemu modulu to ma teda k g2g modulu na UPVS.
Tento decentralizovany variant v studii uplne absentuje. Pritom je zrejme, ze estoncii aj uk to robia prave takto. A tento pristup je bezny aj v komercii - napr https://getkong.org/
Víziou cieľového stavu je centrálny systém riadenia referenčných (zdieľaných) údajov VS,
v ktorom sa nachádzajú referenčné údaje VS rovnako referencované všetkými subjektmi VS
a ktoré umožňujú jednotlivým subjektom VS pracovať s údajmi, ktoré sú:
kompletné, tzn. obsahujú všetky dostupné informácie existujúce vo VS;
časovo aktuálne, tzn. vyjadrujú poslednú platnú informáciu zdroja dát;
preukázateľné, tzn. obsahujú priamu referenciu na zdroj informácií .
S tymto zasadne nesuhlasim. Zoberme si situaciu, keby ziadne CSRU neexistovalo a vsetci sa (jednoducho!) vedeli integrovat na referencne registre. Vysledok by bol uplne rovnaky. Ako uz bolo povedane, CBA tohto projektu stoji na vode, kedze si pripisuje setrenie casu, ktore sa udeje niekde uplne inde - vyhlasenim referencneho registra.
Studia je z mojho pohladu nepoctiva, kedze nenavrhuje alternativy, ktore su zname z toho ako sa to riesi v inych krajinach. Resp. Nenasiel som ani neferenciu, ze by sa takto centralne data niekde vobec niekde inde riesili.
Obstaravanie
Boli velmi nestandardne obstarane tri projekty naraz, ktore spolu nemaju nic spolocne. MetaIS, CSRU a IOMO.
Realizacia
Boli tu vyjadrene velke pochybnosti o tom ako bolo mozne v tak kratkom case vyfakturovat take objemy prace a co vlastne system okrem kupeneho Talend robi (myslia sa tam sluzby, ktore sa realne pouzivaju). Akceptacne protokoly su tu. Btw projekt riadil Anext.
Centralizaciou dat a tvorbou sluzieb na centralnej urovni vznika obrovske riziko vendor locku a nasledna udrzba bude komplikovana. Akakolvek zmena na urovni producentov dat si vyziada change request na CSRU a pripadne aj na strane producenta. Poskytovatelom sluzieb inych rezortov sa stava MF/UPVII (!) co bude cely proces komunikacie komplikovat a spomalovat. Namiesto toho, aby sa vytvorila sluzba na strane gestora, tak sa bude vytvarat sluzba / export pre csru a nasledne sluzba na CSRU a MF/UPVII. Skor ci neskor vznikne nevymenitelny monolit mnozstva biznis sluzieb.
Suma sumárum, centrálne dátové úložisko je velmi nesystémové a zlé riešenie problému, ktorý tu máme. Komplikovaneho a zdĺhavého procesu integrácie. Taketo riesenie prinesie ovela viac problemov ako ich vyriesi.
Co s tym?
Riziko vendor locku je obrovske, cize ak chceme tento centralny komponent nechat tak, bolo ako uplne minimum vidim vhodne uvolnit von zdrojove subory a na pripadne change requesty tak robit skutocnu sutaz a nie PRK alebo to lepit cez servisne zmluvy. Neriesi to vsak systemove problemy uvedene vyssie (monolit, poskytovane sluzby pre ine rezorty, vynutene zmeny vo viacerych systemoch pri zmene, zlozitejsi deployment a vsetko co z toho plynie)
Z mojho pohladu treba vyriesit uplne iny problem (komplikovanu integraciu a byrokraciu) a ist naozaj cestou silnej standardizacie. Presne tak ako xroad.
Dufam, ze pani HPE, ktori to tu isto sleduju maju dostatok inspiracie na prezentaciu na ITAPA. Rad sa to tam spytam, ak sa to neda diskutovat verejne tu.
Poznamka pod ciarou. Infoziadost na akceptacne protokoly dopadla tak, ze som tam musel ist osobne lebo slo o rozsiahly material. UPVII si vyziadalo materialy z MF, na UPVII to museli pozakryvat (podpisy) a nasledne tam pri mne sedeli cely cas dve osoby, ktore na mna dohliadali. Ja som bol schopny si to za necelych 15 minut nafotit komplet. V ramci efektivity by som uradu odporucal to nafotit rovnako a poslat nabuduce emailom. Budete mat viac času na zaujimavejsiu pracu.
