Dátová integrácia (Konsolidácia nosnej údajovej základne pre sprístupnenie formou otvorených údajov)

Čo sa deje v e-Governmente
8

No tak podme na to:

  • pre realizáciu princípu „Jeden krát a dosť“ a sprístupňovanie otvorených údajov pre „kritickú masu“ OVM.

ciele:

  • zavedenia manažmentu údajov vo VS (data governance)
  • implementácie master data managemet pohľadu na dáta VS
  • riešenia dátovej kvality

Nepredpokladá sa zmena platformy pre dátovú integráciu, dátovú kvalitu a ani pre manažment údajov (TALEND). Taktiež sa nepredpokladá zmena na úrovni technologickej architektúry.

vystupy:
Služby pre virtualizáciu dát
Zápisová služba pre komunikáciu zdrojového a referenčného registra
Priamy „push model“ distribúcie údajov
Mechanizmus komunikácie o zmenách údajov
Služby manažmentu a distribúcie kmeňových údajov (číselníky, MDM)
Služba vyhľadávania Zabezpečenie údajov pre službu „Moje dáta“
Nástroje pre správu oprávnení
Vytvorenie GUI pre prístup k registrom a referenčným údajom
Vytvorenie platformy generického registra Služby manipulácie, anonymizácie (pseudoanonymizácie) a transformácie údajov
Služba poskytujúca údaje pre nadstavbový modul „Moje dáta“

Co je to virtualizacia dat?

Dôležité je, aby bola podporená automatizácia zdieľania údajov medzi jednotlivými informačnými systémami verejnej správy a súvisiace odstránenie manuálnych činností pracovníkov verejnej správy (prepisovanie údajov z jednej aplikácie do druhej)

Toto prosim pekne kto dnes takto robi?

Tieto údaje budú na jednom mieste čistené na duplicity a chyby a budú poskytované konzumentom už som zabezpečenou kvalitou. Zapojenie nového poskytovateľa teda v praxi znamená integrácia, čistenie údajov, štandardizácia, vyhlásenie údajov ako referenčných.

Tato predstava je zaujimava, avsak v praxi ju vidim velmi tazko vykonatelnu. CSRU 2.0 resp. platforma datovej integracie sa dostane do podobnej situacie ako RPO - budu mat u seba kopec “spinavych” dat z roznych zdrojov, ktore vycistit NEmozu, lebo zodpovedny za data je niekto iny.

Pripájanie tejto kritickej masy bude riešené centrálne a systematicky. Samotný proces dátovej integrácie sa výrazne zjednoduší a automatizuje. Zavedie sa nový biznis model riadenia služby. Zámerom je, aby bolo možné pripojiť konzumenta údajov do jedného týždňa a poskytovateľa údajov do dvoch týždňov.

Ciel je dobry, ale preco na toto potrebujeme centralne riesenie? Co brani mat jeden tvrdy standard API na rozne trebars aj decentralizovane endpointy? Alebo urobit mikrosluzby na ciastkove veci? Nebolo by lepsie skor spravit nejaky jednotny proces integracneho zameru, ktory bude velmi jednoduchy? Z mojej skusenosti toto bol ovela vacsi problem ako technicke problemy alebo aj rozne API.

Prvá fáza (prvých 9 mesiacov) bude zahŕňať poskytovateľov vysokej priority a konzumentov údajov už evidovaných. Znamená to, že sa integrujú inštitúcie ako MV SR, MS SR, MF SR, MŠVVaŠ SR, ÚPSVaR, GP SR, ÚGKK SR a ďalší. Po skončení fázy 1 budú vytvorené podmienky pre použitie objektov evidencie ako sú údaje fyzickej osoby v RFO…

O tomto MV alebo take MZ vie? Predstava, ze cez nejaky centralny komponent na UPVII potecu data o fyzickych osobach sa mi nejako spaja s ich paranoiou.

V praxi sa ukázala potreba rozšírenia tejto množiny konsolidovaných údajov použiteľných na právne účely z dôvodu zefektívnenia procesov verejnej správy, a to ich poskytovaním na jednom centrálnom mieste.

Citation needed! Kde v praxi?

Alternativy

Alternatíva: A - „Ponechanie súčasného stavu",
Alternatíva: B - „Vybudovanie nového systému pre konsolidáciu nosnej údajovej základne pre sprístupnenie formou otvorených údajov“,
Alternatíva: C - „Využitie existujúceho IS CSRÚ ako základu pre konsolidáciu nosnej údajovej základne pre sprístupnenie formou otvorených údajov“,
Alternatíva: D - „Realizovanie integrácií jednotlivých OVM priamym prepájaním integrujúcich sa systémov VS“.

Pre decentralizovany system D su oznacene tieto ciele ako nesplnene (N). Povazujem to z velkej casti za uplnu blbost, alebo nieco kardinalne nechapem. Takze postupne jednotlive ciele

  • Aby údaje boli k dispozícií v konaniach verejnej správy – preco? Dodnes to fungovalo ako? Nedalo sa to bez CSRU? Dalo. Urcie nie N.
  • Aby verejná správa dokázala využívať svoje údaje v rozhodovacom procese – Opat to iste. Urcite nie N.
  • Eliminácia duplicitných informácií evidovaných o subjektoch vo verejnej správe – Nezmysel. Duplicity sa odstranuju tym, ze vyhlasime registre za referencne, cistime ich a jasne urcime co kde kto eviduje a ma na zodpovednosti. Nema to vobec nic spolocne s tym, ze ci sa na tieto registre integrujeme many to many alebo hviezdou.
  • Aplikovanie jednotnej platformy integrácie údajov. – v klude moze byt aj cez decentralizovany model. Akonahle mame platformu ako SaaS sluzby v cloude napr.
  • Jednotný centrálny model údajov – Samozrejme nezmysel, model mozeme vynucovat aj standardizaciou v uplne decentralizovanom variante.
  • podpora pre Open Data (Open API, otvorené štandardy) – WTF??? Ved otvorene standardy vznikli presne pre to, aby decentralizovane systemy sa mohli spolu dohovarat.
  • úspora času občanov a ostatných používateľov služieb – mozno Riziko, urcite nie showstopper
  • používateľsky prívetivé́ elektronické́ služby – uplna blbost.
  • aplikácia princípu jedenkrát a dosť – prosim? samozrejme ze nie je problem aj uplne decentralizovanom modeli!
  • Centrálne riešenie bezpečnosti, auditovateľnosti a nepopierateľnosti údajov - riesitelne aj v decentralizovanom modeli. vid estonsky x-roads (nie je centralizovany)
  • Spoločné využívanie aplikácií (SaaS služieb) pre verejnú správu - ??? naopak, SaaS sa da pouzit najme pri decentralizovanom modeli.
  • Zabezpečenie dostupnosti údajov verejnej správy v otvorenom formáte - urcite nie nemozne, treba len standardizaciu.
  • Zabezpečenie dostupnosti relevantných údajov centrálne na jednom mieste pre občanov a podnikateľov. – EHM, preco to chceme centralne a co su to revelvantne udaje? samozrejme, ze ked povieme, ze to chceme centralne, tak sa decentralizovana alternativa rovno odpada.
  • Využitie vládneho cloudu - uplna blbost. ved OVM taktiez mozu (musia!) svoje decentralizovane IS migrovat do cloudu.

Alternatíva „Vybudovanie nového systému pre konsolidáciu nosnej údajovej základne pre sprístupnenie formou otvorených údajov“ predpokladá vybudovanie samostatného informačného systému, ktorý zabezpečí vytvorenie požadovanej údajovej základne, v ktorej budú zahrnuté ako údaje aktuálne obsiahnuté v IS CSRÚ tak aj identifikované nové požiadavky na prístup k údajom. Údaje aktuálne obsiahnuté v IS CSRÚ budú získavané priamo zo zdrojových systémov.

Chapem spravne, ze vsetky tieto udaje sa budu zhrnat na centralne miesto? O_O Toto zavana pruserom.

Budovanie nových prepojení medzi IS VS za účelom vzájomného poskytovania referenčných údajov je v rozpore s integračnou architektúrou NKIVS 2014-2020, ktorej cieľom je optimalizovať ad-hoc integrácie medzi systémami a zabrániť dramatickým nárastom zložitosti či nákladom na údržbu prepojení. Z toho dôvodu je toto riešenie zamietnuté.

Toto povazujem za neuplne. Prechod na centralne riesenie nie je nutnou podmienkou na toto. Samozrejme ad-hoc integracie sa vypomstia rychlo, ale nie je nutne na toto mat centralne riesenie. V klude na toto vie byt lokalne instalovane balikove riesenie. Podobne ako open data node.

Preco centralny projekt? - ake su usecasy?
Co su to konsolidovane udaje? a kto a ako ich bude vlastne pouzivat? nie su to jednoducho tie bajne referencne udaje, ktore maju odkazy na ine referencne udaje? Toto nam prinasa vyhlasenie ref. registra a ref. udajov aj v uplne decentralizovanom modeli.

Co ja povazujem za skutocne vyhody centralizacie:

  • economy of scale
    • centralny modul moze riesit high availability a skalovanie na jednom mieste. netreba to robit po x roznych custom systemoch. Takto staci z kazdeho producenta dat iba “jedna rura do centraly”.
    • centralizacia procesov pripajania - odhlahcenie prace pre uradnikov na OVM, nasledna specializacia a zrychlenie procesov na UPVII.

A teraz, aby som nefrflal, ale aj pomohol:

Naprv predpoklady:

  • predpokladam, ze existuje nejaky scenar, kde potrebujem na vystupe dostat data z roznych registrov/systemov a tieto data spolu nikde neexistuju. Napriklad chcem data o nejakej pravnickej osobe a tam k nej aj adresy z registra adries.
  • V decentralizovanom modeli, by som potreboval integracie dve - na RPO a RA a spajat to u seba. Za predpokladu, ze v oboch registroch sa drzia iba udaje a potom referencia na iny referencny udaj. V praxi je uplne bezne, ze aj RPO bude chciet dotiahnut data z RA, cize tam budu, ale ticho teraz predpokladajme, ze chcem nieco co tam nebude a je to len v RA.

Prizmurim teda oko a budem hladat nejaky ekvivalent v komercii, kde taketo nieco existuje. Je to Facebook a jeho GraphQL len to funguje trosku inak. Je to centralne API, ktore riesi autentifikaciu/bezpecnost/logovanie/jednotne API, avsak vo vnutri moze dopytovat uplne rozne backendy.

Napriklad tu je priklad ako to spravit pre jedno volanie co ide na 3 rozne backendy REST, SQL aj Mongo Tutorial: How to build a GraphQL server - Apollo GraphQL Blog

Cize query na Slovensko.Digital, ktora nieco vytiahne z RPO, RA, statistickeho uradu (ciselniky), dokonca posty (PSC) ci financnej spravy (DIC/ICDPH) by mohla vyzerat nejako takto:

query {
  legal_subject(cin: 50158635) {
    name,
    tin,
    vatin,
    address {
      street_name,
      street_number,
      street_registration_number,
      postal_code
      municipality
      country
    },
  }
}

A na toto tie data vobec nemusia byt lokalne a vobec to nemusi byt take pomale ako to vyzera. vid napr https://youtu.be/etax3aEe2dA?t=18m3s - ciselniky sa daju cachovat atd.

Suma sumarum:

  • Robit studiu pokym nemame aspon trosku jasne scenare je chyba. Bolo by fajn neist zase OPIS stylom (dame tabulecku sluzieb co nikto nechape), ale aby zo studie bolo jasne ake sluzby ocakavame (az na uroven usecasov!).
  • Absolutne netusim ako bude realne vykonatelne cistenie a konsolidacia udajov. Toto sa moze robit len v zdrojovych registroch garantom a niekedy ani garantom nie - vid pripady z RPO - kde zapisuju do ZR myslim sudcovia, ale ani ti to neopravia lebo vraj je za to zodpovedny clovek co to sudcovi dal. UPVII ma ambiciu nahanat vdaka tomuto projektu tychto ludi?
  • Nepacia sa mi sumy za zapajanie novych konzumentov producentov. Toto betonuje dodavatela. Kazdu jednu zmenu kazdeho konzumenta a producenta bude riesit jeden dodavatel? Zlata bana. Pri pouziti graphql si viem predstavit nejaky opensource model, kdeby vedeli dorobit konektor/resolver viaceri dodavatelia (pripadne rovno dodavatel daneho IS konzumenta producenta). Toto by som cakal, ze sa objavi v rizikach a pridu alternativy.
  • Spomina sa tam genericky register ako aj nejaky sposob distribucie zmien v udajoch. Zatial co zmena zmien v udajoch je povedzme kafka alebo iny message bus, tak genericky register je velmi hmlisty. Bude to obsahovat aj workflowy? To mal byt uplne separe projekt, sem to fakt netahajme.
  • Predstava, ze sa budu niekde centralne zhravat data (MV, MZ a financnej spravy) je podla mna v slovenskej realite utopia a trosku aj bezpecnostne riziko (pokial sa nemyslia len open data). Dufam, ze to tak bolo myslene.
  • Bolo by fajn, aby sa niekde objavil skutocny zoznam sluzieb CSRU. Lebo podla studie to malo sluzit ako platforma, ktora pomoze cistit data jednotlivym OVM ale ocividne to uz davno pravda nie je. Zacina z toho rast monstrum na vsetko.
  • Rad by som vedel ako tato datova platforma zapadne do celkovej architektury hlavne v kontexte otvorenych dat - mame predsa data.gov.sk - v com bude toto ine, lepsie, vonavejsie? A vlastne to co NASES chysta (nove centralne komponeny pre opendata) s tymto ako suvisi? Nie je to duplicita? Bozechran pri kontrole z EU!
3 Likes