IS CSRU - Rozbor

Integrita dat v distribuovanom systeme je proces. Nie stav. Vo velkych rieseniach mame vacsinou otazku polozenu tak, ze co vyhlasujeme za thrue a nie co je thrue. Bezna otazka napriklad v DWHckach. Kedy je uzavierka?
Ale k teme. Podstatne je, ze ak dojde k situacii konfliktu proces nezakape, ale iteruje dalej k arbitrovi (zvacsa je to datovy kurator mastrer dat o ktore sa jedna) a ten zabezpecuje napravu.
Pruser je, ak neintegrita vznika a system o jej vzniku nevie, pripadne je neintegrita uz v datach importovanych do systemu pri starte.

1 Like

No presne. Ale ak mame nakúpené niekde Oracle SOA, alebo MDM(Talend), ci BPMN suity, tak by som čakal ze prevezmú aj úlohu strážiť konzistenciu transakcie (presnejšie údajov procesu), ktorá ide cez 3-4 softvérové aplikácie. Aj s tým, že do tých aplikácií sa budú musieť naimplementovať nejaké rollbackové endpointy. Napríklad, toto som očakával od toho zázraku SAP NW PI v Datacentre MF SR. Ten softvér také veci vie a preto stojí čo stojí. Ale videl som len procesy, ktoré sa dali naimplementovať pomocou jednoduchého file exchangera (bohapustá výmena XML medzi systémami) - čiže BPMN nástroj použítý na Data Integration scenár. Chcem len povedať, že pri troche chcenia sa z týchto typov nástrojov dá vyžmýkať aj ich pridaná hodnota.

1 Like

Urcite na to nastroje su, moj point vsak bol, ako si spravne poznamenal, ze ziadne rolbback endpointy, ani kompenzacne endpointy tie aktualne sluzby nemaju.

Dôsledok je ten, že ADMINI na svoje triko (občas kryté príkazom) potom vymazávajú v lepšom prípade cez appku, v horšom priamo v databázach … a to akože máme zachovať…

A toto sa bude diat aj s elektronickymi zdravotnymi zaznamami? :open_mouth:

Ja by som tu len dal do pozornosti, že v PS “Lepšie dáta” chceme k správe údajov, 1x a dosť atď. dať aj konkrétne návrhy čo riešiť a ako by to malo byť, viď. tu:

CSRU získal 1. miesto na ITAPA!

"V kategórii Nové služby pre spoločnosť odborná komisia Ceny ITAPA hodnotila projekty, ktorých cieľom je prispieť k lepšej a fungujúcej spoločnosti.

1. miesto v tejto kategórii získal projekt Centrálna správa referenčných údajov pre Ministerstvo financií SR. Projekt, ktorý pripravil Hewlett Packard Slovakia, prepája informačné systémy až 15 štátnych inštitúcií, ako napríklad MF SR, Sociálnu poisťovňu SR či Finančnú správu SR. „Občan poskytne štátu údaje len raz, potom už všetko za neho vyrieši štát,“ povedal na Galavečere ITAPA pri vyhlásení výsledkov Zdenko Böhmer, country manager Hewlett Packard Slovakia. To znamená, že ľudia sa nemusia pripájať na viacero informačných systémov jednotlivých inštitúcií, všetko nájdu na jednom mieste."


Perlička: 2. miesto v kategórii “Nové služby pre občana” "získal projekt Smart Sociálna Poisťovňa. Citujem z oficialnej spravy: “(…) Ide o nový spôsob registrácie zamestnancov do Sociálnej poisťovne, ktorý zvládne bez potreby zaškolenia každý používateľ smartfónu. (…) Tri KLIKNUTIA v MOBILE, a je to.:wink:

2 Likes

Touto cestou by som rad pozdravil sutaznu porotu, ktora za tento projekt hlasovala.

3 Likes

…hmm…zacinam byt mierne zmateny…my ako konzument dat sme cca 2-3mesiace dozadu dostali prislub, ze sluzby/data Socialnej poistovne v ramci CSRU budu pre nas pripravene v 12/2016…v zmysle clanku a ceny si teda uz buduci tyzden mozem vklude vypytat dokumentaciu k datam Socialnej poistovne…

1 Like

To si podla mna zasluzi aj ofic. tlacovu spravu za slovensko.digital.

Neviem ake boli zvysne nominacie, je naozaj mozne, ze toto bolo najlepsie. :wink:

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.

:smiling_imp:


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.:

  1. 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.

  2. 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
  1. 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”…

  2. 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.

  3. 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.