To si podla mna zasluzi aj ofic. tlacovu spravu za slovensko.digital.
Neviem ake boli zvysne nominacie, je naozaj mozne, ze toto bolo najlepsie. 
Spomenme si na jar 2015 http://www.itapa.sk/chceli-by-ste-spoznat-tvorcov-vitaznych-projektov-ceny-itapa-2015/
eID … milionty vlastnik eID karty a ine bullshity …
zvíťazil projekt “Implementácia elektronickej identifikačnej karty”, ktorého cieľom bolo zavedenie elektronickej ID karty (eID) ako jednotného prostriedku pre identifikáciu a autentifikáciu fyzických osôb v rámci prostredia eGovernmentu, eHealth a v iných oblastiach verejných aj súkromných služieb.
Zvýraznenie je od autora tohto príspevku.
2 Likes
Síce sa to trocha skomplikovalo, aj nejakí aktivisti sa do toho vložili a tak, ale nakoniec to tak bude.
Akí sú na tom MV vizionári!
1 Like
Keď tak čítam všetky príspevky, skúsim prispieť svojim názorom.
Zrejme sa zhodneme, že synchronizovať dáta pod AIS-y potrebujeme, inak nebude “1x a dosť”, občan bude v elektronickom svete stále poštár a celá tá budúca pridaná hodnota z elektronických služieb, nebodaj z ich automatizovania či spájania do životných situácií ostane mimo dosah. Ochutnávku, čo na to občan sme už mali možnosť zažiť po prvom pokuse za 1mld.
Myslím si, že sme sa aj zhodli na ďalšom bode - a to je, že služby poskytovania dát (pre konzumentov) by mali mať jednotné API/formáty. Aby, keď sa potrebujem pripojiť na 3 registre som si nemusel študovať a implementovať 3 úplne odlišné implementácie napojenia sa. Zámerne neuvádzam či to majú byť web služby alebo dátová synchronizácia (podľa môjho názoru budeme potrebovať oba spôsoby), hovorím len že by to malo byť jednotné API - lebo tak sa pochopiteľne dosť veľa peňazí ušetrí pri vývoji a následnej údržbe integračných väzieb.
Otázka, ktorá sa začala (podľa mňa správne) riešiť - ktorou cestou sa vybrať a akú úlohu v danej alternatíve bude zohrávať centrálna úroveň. Ak som správne pochopil, príspevky sa viac či menej točia okolo dvoch variantov.:
-
Centrálna úroveň bude plniť úlohu metodického centra, to znamená bude usmerňovať cez výnosy a štandardy a pod. Ďalej môže zastrešovať tvorbu zmluvných vzťahov medzi PO, ktoré si poskytujú dáta. Môže disponovať rozpočtom na “program vypublikovania dát” a tie rozdeľovať medzi PO postupne ako sa budú pripájať. Skutočný implementačný výkon poskytovania dát si bude realizovať každá PO samostatne. Každá si obstará vlastné nástroje ak to uzná za vhodné (napríklad na čistenie dát, na dátovú synchornizáciu a pod.), každá si vyrieši (sme na cloude) škálovanie prístupových bodov a všetci si napíšu a budú udržiavať vlastnú implementáciu jednotného API.
-
Centrálna úroveň okrem úlohy metodického centra (a majiteľa programu 1x a dosť, prípadne čistoty dát) poskytne aj jednotné nástroje napr. na čistenie dát, resp. platformu na dátovú synchronizáciu. Ďalej jednotnú implementáciu poskytovania dát cez služby, čím si jednotné API nie len vyžiada (cez usmernenie), ale vie vynútiť a vie ho garantovať (napríklad aj jednotný autorizačný model prístupu na dáta medzi akýmkoľvek poskytovateľom a konzumentom). Implementáciu a údržbu zaplatia daňoví poplatníci len raz. “Pripojenie sa” stále zostáva v réžii PO, ktorá dáta poskytuje, akurát priestor pre nechcenú heterogenitu pri konzumovaní dát je výrazne okresaný. Rovnako tak náklady.
No a teraz k argumentom, ktoré zazneli (bez nároku že som vymenoval všetky, ak som na niečo zabudol a vás to zaujíma, dajte prosím do reply a pokúsim sa zodpovedať).:
A. Centralita vs. Decentralita. Nevidím rozdiel, pretože jedno aj druhé riešenie beží v cloude, teda prvý argument by mohol byť, že toto za nás predsa rieši cloud o vrstvu pod nami a nemusíme viesť diskusiu o SPoF. Pokúšam sa si predstaviť, čo by sa v decentralizovanom variante (v budúcnosti, keď sú všetci prepojení) stalo, ak by niekto vypol nejaký základný register (lebo údržba alebo technické problémy). Vychádza mi, že “stop the world” pre celý eGov, teda rovnaký armagedon, ktorý vyčítame variantu s centrálnou platformou. Myslím si, že centrálny bod tu nezhoršuje situáciu, keďže tá nie je optimálna doménovo, veď máme “základné” registre, od ktorých bude závisieť väčšina agend.
B. Budú sa kopírovať dáta alebo nie - resp. budeme riešiť eventuálnu konzistenciu? Ak chceme 1x a dosť, celý eGov bude distribuovaný systém, s centrálnou platformou alebo bez nej. A CAP v distribuovanom systéme si tu zrejme nemusíme opakovať. V momente ako niekto urobí systém pre svoju primárnu evidenciu, začne jeho dostupnosť a odozvy “chrániť” tým, že “dopytovacie služby” (pre neho sú to externí konzumenti) vystrčí z iného bodu, nad inou DB (lebo availability) - čím musí obetovať konzistenciu. Ak chceme rozmýšľať nad nástrahami eventuálnej konzistencie v procesoch, zamyslime sa najprv ako je systém voči tomuto chránený dnes. Opäť sa dopracujeme len k tomu, že situáciu centrálnou platformou nezhoršujeme, naopak vieme ju v mnohých prípadoch zlepšiť.
C. Vendor lock-in je podľa mňa treba riešiť mimo diskusiu o alternatívach, pretože sa dotýka oboch (aj v decentralizovanom variante ak všetci použijú nejaký nastroj a vendor odrazu výrazne zdraží alebo zanikne). Ako napísať integrácie tak, aby sme v budúcnosti zvládli prechod na niečo iné bez toho, aby bolo potrebné všetko prepisovať. Opäť, mnoho vecí je možné vyriešiť štandardmi a určite budú také, ktoré vyriešiť vieme len draho (ergo budeme musieť s nimi žiť).
Zatiaľ všetko, ospravedlňujem sa, že som nevedel prispieť skôr, dúfam, že táto téma ešte úplne nevychladla.
3 Likes
Asi sa nepodari presadit jeden koncept centralizovany vs. decentralizovany gov system. Vzdy to bude hybrid uz len koli skalovaniu a dostupnosti cloudu. Zaroven gov systemy budu v buducnosti stale viac integrovane so servismi a datami mimo samotny eGov cize sa neda nariadit, ze vsetko in/out musi byt na gov cloude. Uz len EU level bude prinasat stale viac online integraci o komercnych sluzbach nehovoriac.
Nadhodim este jednu dolezitu temu - proces opravy/upravy dat.
Pre data je klucova otazka master dat, ich ochrany a oprav. Ak dizajnujeme system zdielania dat ako RPO, ci CSRU je potrebne doriesit pokial mozno jednotny proces a api rozhrania pre “opravu/upravu dat”
- proces nahlasenia “incidentu” cez overenie zodpovednou instanciou az po upravu v master systeme. Toto by podla mna mala byt jedna z centralnych funcii projektov centralizujucich data.
Mozno by stacil jeden system, ktory udrziava metadata na to aby to zabezpecil. Moj osobny nazor je, ze Metais obsahujuci data o systemoch a datach popisujuci v podobe unikatnych identifikatorov jednotlive datove zdroje dokaze poskytnut unikatny zoznam tychto zdrojov s ich URI. V ramci data.gov.sk je mozne evidovat potrebnu vzorku metadat k tymto datovym zdrojov. Kombinacou tychto dvoch systemov vznika informacia, ktora by mohla byt dobry zaklad k mapovaniu dat a datovych zdrojov a rovnako by to bol dobry zaklad pre API nahlasovnia a vybavovania navrhov na upravy v datach. Cez taketo api by mohli prispvievat gov systemy, obsluha, obcania a komercne aplikacie. Crouwdsourcing cez aplikacie pouzivajuce data moze vyrazne zrychlit cistenie dat…
Jeden system nahlasovania incidentov v datach a mozno aj sirsie a sledovanie ich vybavovania by bol asi velmi uzitocny. Na druhej strane ale vyrazne pozera na prsty jednotlivych prevadzkovatelov systemov… neviem ci z ich urovne nebude privelky odpor.
Len pre zaujimavost venujem sa projektu Europeana.eu kde sa na EU urovni orchestruju metadata zo vsetkych digitalnych archivov kulturneho dedictva v EU. Testujeme tam pristup ktory some pracvne nazvali Acurator. Ide o proces/moznost centralizovane nahlasovat potrebu opravy/obohatenia atd. informacie a tento zaznam putuje do master systemu, kde to obsluha spracovava ako issue. Po oprave v master syteme sa data dostavaju opravene na centralnu uroven. Nechcem spominat Europeanu ako etalon dokonalosti. len naznacujem, ze tato tema je klucova a centralizaciu zberu dat a ich kvalitu nerisime len na Slovnesku … Cize sa da poobzerat a prebrat co sa da.
1 Like
-
Mohol by si prosim rozvinut (vysvetlit, mozno som zle pochopil) co presne znamena argument "vzdy to bude hybrid uz len koli skalovaniu a dostupnosti cloudu"? Samozrejme, ze niektore data neopustia zdrojovy system - ale kvoli ich citlivosti, nevidim dovod preco by to malo byt kvoli “skalovaniu”…
-
Externe data by som teraz do diskusie nepridaval (a na ich zaklade nerobil nejake zavery smerom k poziadavkam na riesenie) - diskusia je o datach referencnych (aspon podla nadpisu temy). Nemusime hladat jednotne riesenie pre akykolvek typ dat. Vyriesme najprv tie, ktore su v sprave statu a z pohladu agend ktore vyuziva obcan su potrebne najviac (= jedenkrat a dost). Tie (data) budu sediet tak ci tak na cloude (ak nie od zaciatku, tak cielovo) - ci v centralnom “hub-e” alebo v jednotlivych systemoch.
-
Centralny proces/nastroje pre cistenie udajov a MDM suhlasim, len si nemyslim ze to skonci len pri centralnom toole a mapovani API na datove zdroje - pricom pristupove body - teda API implementacie si budu musiet vsetci vlastnici budovat samostatne a palit na to x-krat peniaze za nieco, co mohlo byt vybudovane len raz.
K 2. ano. Nechajme v tejto debate externe data bokom.
K 1. a 2. podstatna je agenda v ramci ktorej vznikaju master data a zodpovednost tej ktorej role za ich udrzbu. Mnohe agendy reguluje legislativa atd. cize zmeny sa budu musiet robit v zdrojovych systemoch.
K 1. skalovanie atd. vacsina dat sa zdiela v “offline” mode, teda, zdrojovy system vyexportuje z jeho pohladu konzistentne data do zdielatelnej podoby a dalej ich spristupnuje z tohto zdroja - koli vykonu, nekonzistencii produkcnych dat atd… dovodov je viacero. jeden nich je dostupnost a zataz zdrojoveho systemu.
Ako hybrid chapem aj nasadenie x agendovych systemov v jednom cloude. V tomto kontexte si kazdy system zije svojim zivotom. Systemy su na roznej technologickej urovni… preto to dlho budu ostrovy.
K 3. Ako pisem v uvode procesy zmien udajov sa riadia v kazdom agendovom systeme svojim wf, ktore sa tazko bude unifikovat v jednej centralnej aplikacii. Cize preto vidim priestor na centralizacie v oblasti zjednotenia formy nahlasenia incidentu a evidovanie jeho vybavenia, ale samotne vybavenie je vecou tej ktorej agendy. Nezda sa mi realne toto pokryt centralizovane.
Nespochybňujem nič z predpokladov, ktoré uvádzaš. Áno, master dáta sú v zdrojových systémoch a ich PO sú za ne stále (a aj v budúcnosti budú) zodpovedné. Rovnako tak platí, že tieto systémy sú na rozdielnej technologickej úrovni.
Ale nič z tvojej argumentácie nebráni pripojiť tieto heterogénne zdrojové systémy do centrálneho riešenia, ktoré bude mať unifikované rozhranie na poskytovanie dát (nie len v rovine definície API - čo je výrazná úspora nákladov oproti distribuovanému variantu, kde na to páli hodiny každý vlastník ref. dát, ďalej jasne pomenovanie zodpovedného za sprístupňovanie referenčných dát, atď…). Prekrývanie heterogénnych vrstiev štandardizovanou fasádou je niečo, čo sa robí v IT bežne a nevidím dôvod, prečo by to nemalo pomôcť aj tu. Aspoň zatiaľ som argument - prečo by to nemalo byť centralizované - nezachytil.
K bodu 3. - len rozvíjame základný predpoklad heterogenity zdrojových systémov, z ktorej vyplýva, že niektoré detailné kroky môžu byť asi pre daný systém iné. Presne si to vyjadril, že je to momentálne v rovine “nazdávania sa”. Ja sa môžem nazdávať opačne - že aj toto sa dá centrálne pokryť - asi nie jedným - ale sadou/katalógom štandardných krokov pokrývajúcich drvivú väčšinu situácií. A asi ťažko to jeden druhému v tejto úrovni ponoru vyvrátime. Navrhujem preto nesnažiť sa dopredu “orezávať” centralizované riešenie na základe nejasných predpokladov alebo skorých záverov - čisto preto, že z pohľadu vynaložených prostriedkov je ako také najhospodárnejšie. A nech sa v detailnejšom rozpracovaní ukáže, čo presne riešiť centralizovane je nevýhodné.
3 Likes
Suhlas. Uz chapem. Co sa tyka publikovania suhlasim, je vysoka pravdepodobnost, ze vacsinu pripadov dokaze obsluzit centralizovane riesenie. Ja som pisal celkovo o zdrojovych systemoch a ich centralizacii a v uvahach idem nad ramec CSRU, mozno by som sa mal presunut do temy openapi nech tu neodklanam pozornost od podstaty prispevkov. sorry. Uz len dovysvetlim moj pohlad. Co sa tyka publikovania dat tak ma centralizacia jednoznacne zmysel v rovine metadat a katalogov.
Uz som par api realizoval a nemam ten pocit, ze existuje take cudo co by vedelo fungovat ako univerzalne api. Pokial sa pozerame na data ako na jednoduche tabulky tak by to slo. Ak ide o komplikovanejsie data s vnutornou logikou a prepojeniami tak api silne zalezi od tejto struktury, typu a samotnej domeny.
V nejakej inej teme by bolo mozno dobre prediskutovat co vlastne ocakavame od OpenAPI. Ak len zakladne funkcie poskytnutia datasetu a metadat, tak nam staci naplnit contentom data.gov.sk a pouzit DCAT rozhranie.
Ak ocakavame domenovo specificke api povedzme pre geo data z agentury zivotneho prostredia je otazne ci centralizacia ako taka neznizi level mozneho. AZP nam asi vie dat lepsie API do buducna ako nejaka centralizovana instancia.
Nevylucujem, ze rozumnou analyzou vie nejaky dodavatel, alebo team na strane statu nadizajnovat taky prienik api rozhrani, ktore dokazu pokryt poziadavky pre vacsinu posktytovatelov a konzumentov dat. Trendy sa ale rychlo menia a reagovat dokaze lepsie ten kto sa danej domene venuje ako niekto kto je na top urovni a hlada cestu prieniku. Niektore specificke oblasti bude rozumnejsie nechat v spominanom hybridnom mode. Teda v mode, ze data mozu byt dostupne cez centralizovane riesenie, ale navrhujem nezatracovat moznost poskytovat data aj samotnou organizaciou, ktora ich produkuje. Ich api moze mat vyssiu pridanu hodnotu ako univerzalne riesenie.
Teóriu a diskusiu zvládame.
Teraz pripomienkujme dokument, kde sa to má riešiť. Tu: ÚPVII Pracovná skupina K9.4 Lepšie dáta
2 Likes
Podla mna su varianty tri:
- centralny komponent - nieco ako CSRU - ktory data zhrava k sebe a publikuje jednotne api.
- decentralizacia a silna standardizacia - kazdy si to riesi po svojom a tlaci sa na jednotne api len standardami
- standardizovany komponent, ktory si vie nasadit u seba kazdy (predstavit si nieco ako open data node od @gla) a poskytuje jednotne API. Ak sa niekto rozhodne, ze to chce robit po svojom, bude musiet dodrzat standard ako v 2. a ukazat, ze na tom nieco usetri. podla mna win-win. Toto je inak cesta ktorou sa vybralo UK openregister · GitHub
Pre zaujimavost - tu je podobna situacia v uplne inom kontexte - vladny cloud (zmurk @zyx) Choosing Cloud Foundry for the Government Platform as a Service - Government as a Platform
@kyselat - mna by zaujimalo ake su vyhody centralneho riesenia (oproti inym pristupom). Lebo to co zacalo robit CSRU - vytvarat biznis logiku nad datami uplne ineho gestora je nieco comu naozaj nerozumiem preco by malo byt dobre.
3 Likes
Velky suhlas.
Jeden zo systemov, nech sa kludne vola CSRU moze cez jednotne API robit vyhladavanie sluzieb a ich API a kludne napr. aj bajne zivotne situacie na urovni “daj mi vsetky sluzby, ktore obcan X potrebuje ohladom dani” => “zoznam: API1, API2, API3”.
-
Na úvod - nemám žiaden problém s tým, aby sme rozšírili a evidovali/posudzovali možnosti tri. Tá tretia možnosť je ale v mojom pohľade len slabý odtieň (v zmysle príchuť, nie odvar
) jednotky. Publikovanie dát je sám o sebe proces, ktorý tak či tak robí (a je zodpovedný) vlastník predmetných dát - teda nie centrálna úroveň. Takže, či k tomu dostane nejaký download link na jednotné riešenie - s ktorým môže publikovať cez jednotné API, alebo dostane k ruke z centrály človeka, ktorý s publikáciou pomáhal už na x-tom úrade a ten mu pomôže daný kus jednotného riešenia “rozbehať” - rozdiel je už len koho “virtuálka” to bude (a tu zase platí, že je aj tak všetko na cloude). Necítim žiadne veľké víťazstvo decentralizácie, ak to bude bežať vo virtuálkach konkrétnych úradov, namiesto vo virtuálkach niečoho čo pracovne nazývame centralizované riešenie (rozdiel bude v organizačnej zodpovednosti a tam mám pocit, že zase bude centralizovaná zodpovednosť ďaleko efektívnejšia). -
CSRU a biznis logika - nie som hovorcom dodávateľa, azda by sa mohol niekto od neho vyjadriť. Preto nasledovná úvaha bude krátka a berte ju s rezervou. Podklady, ktoré som (len nedávno) videl ja (tuším to bol dokument - architektúra), pod názvom “biznis logika” uvádzali - ak som správne pochopil - maticu oprávnení k prístupu na konkrétne dáta pre konkrétnych odberateľov. Ak by to ostalo naozaj len v tejto rovine, tak je tu samozrejme pojem “biznis logika” nesprávny - ale nastavovať autorizáciu v centralizovanom riešení by som ako vlastník publikujúci dáta očakával, že budem môcť. Ak to zašlo ďalej - do naozajstnej biznis logiky (osobne odhadujem a zdieľam tvoju obavu, že zašlo), tak súhlasím - je to podľa môjho názoru chyba a nepochopenie úlohy/hraníc tejto vrstvy. Myslím, že my dvaja si v tomto rozumieme, ale pre istotu sem napíšem: To, že nejaká dnešná implementácia z predchádzajúceho obdobia, ktorá má dnes zhodou okolností k akémusi centralizovanému konceptu najbližšie - niečo porušuje, ešte neznamená, že je zlý koncept centralizovaného riešenia ako taký.
) jednotky. Publikovanie dát je sám o sebe proces, ktorý tak či tak robí (a je zodpovedný) vlastník predmetných dát - teda nie centrálna úroveň. Takže, či k tomu dostane nejaký download link na jednotné riešenie - s ktorým môže publikovať cez jednotné API, alebo dostane k ruke z centrály človeka, ktorý s publikáciou pomáhal už na x-tom úrade a ten mu pomôže daný kus jednotného riešenia “rozbehať” - rozdiel je už len koho “virtuálka” to bude (a tu zase platí, že je aj tak všetko na cloude). Necítim žiadne veľké víťazstvo decentralizácie, ak to bude bežať vo virtuálkach konkrétnych úradov, namiesto vo virtuálkach niečoho čo pracovne nazývame centralizované riešenie (rozdiel bude v organizačnej zodpovednosti a tam mám pocit, že zase bude centralizovaná zodpovednosť ďaleko efektívnejšia).
2 Likes
- dnes som sa dozvedel, ze na spustenie prevadzky RPO cez CSRU nie je financne krytie
- CSRU pri rozhovoroch vzdy zdoraznovalo, ze udaje z RPO budu referencne iba vtedy, ked budu spristupnene cez CSRU
- MetaIS ako referencne udaje identifikuje data z RPO, cez MUK MF SR, teda CSRU https://metais.finance.gov.sk/refregisters/detail/80d31646-5ca4-47f4-87fa-8fc3210769a6?page=1&count=10&sorting[order]=asc&tab=basicForm
- RPO ma vlastne API, ktore je v prevadzke
Moja otazka, ci chapem spravne aktualny stav…Teda v SR v zmysle platnej legislativy aktualne nemame ziadne referencne udaje o pravnickych osobach…chapem to spravne?
6 Likes
pravnik by potvrdil ze to chapes spravne… technici sa prisposobia tomu co je dostupne …
Nie som síce právnik, ale keď pozerám do zákona, na takto vyhranenú otázku nevidím dôvod.
-
Či existujú referenčné údaje o právnických osobách: jasné že áno, ref. register/údaje sú vyhlásené, sú vedené v RPO ktorý je v normálnej prevádzke.
-
Či a kedy tieto údaje môže niekto použiť, napr. na referencovanie či stotožnenie: samozrejme že áno, konštrukcia šiestej časti zákona o eGov je taká, že je to povinnosť vykonávať bez ohľadu na spôsob ako sa k údajom dostanú (samozrejme musí to byť legálne)
-
Ako sa k referenčným údajom dostať: ak tomu dobre rozumiem, tak povinnosť použiť MÚK je dosť slabá (vyplýva z §51.2.e, §60a.2 - je k tomu ešte niečo ďalšie?) Napríklad ak sú údaje vymieňané ináč ako v elektronickej forme (napr. papierovo, alebo hoc aj telepaticky), tak to tieto ustanovenia nijako neobmedzujú. Pokiaľ neide o “výkon verejnej moci elektronicky”, detto. Alebo ak stačí prístup k údajom o právnických osobách z RPO (nie ako referenčné údaje), tak tiež zrejme nie je problém.
Výsledok: ak RPO nie je dostupné cez MÚK, musí si z neho údaje každý zohnať sám inou legálnou cestou.
Btw. v zákone nevidím pre správcu MÚK povinnosť sprístupniť v ňom referenčné údaje, prípadne dokedy to má zabezpečiť, takže MF (či ÚPVII?) sú asi v pohode…
Čudné a neefektívne? rozhodne. Prekvapivé v súčasnom chaose - bohužiaľ nie.
Som velmi zvedavy kto sa prihlasi do verejnej sutaze na servis.
1 Like
logicky (v privatnej sfere je to predsa prirodzene - a na SLA ani nove obstaranie podniky nerobia) ze povodny dodavatel.
Vsak kto zdrojaky a prostredie pozna lepsie ?
Kazde ine riesenie (len preto ze niekto da o 1000 Eur nizsiu cenu v EKS) je nelogicke, vydieracske a ani nebude fungovat …