presne tymto smerom som chcel aby sa ta diskusia uberala
Tato diskusia rozhodne nie je dobre miesto kde tie problemy rozoberat. Toto nie je nieco co sa da navrhnut za hodinu. Ani za den. Ani za tyzden. Uz aj zodpovedne review navrhu by trvalo urcite niekolko dni. Viem o com hovorim. Tu sa rozpravame o dost velkej a velmi odbornej praci. Nebolo by lepsie dat to niekomu kto vie co robi aby to urobil profesionalne?
(Aby som hned vyvratil pochybnosti: tym nemyslim seba. Ja mam kopec lepsej prace.)
Mozno by stacilo pomenovat tie problemy, navrh nechame na niekoho ineho.
Uz som ich tu pomenoval celkom dost, nie?
Okrem toho sa oplati nastudovat si ako IDM systemy funguju. Literatury nie je vela, ale tuto napriklad z vlastnej zahradky:
Nenechajte sa odradit nadpisom. Prva kapitola je uplne vseobecna a midPoint sa tam skoro ani nespomina. A aj dalsie kapitoly vysvetluju vela vseobecnych principov.
alebo (trocha starsia) TL;DR verzia:
https://wiki.evolveum.com/display/midPoint/Enterprise+Identity+Management
Ak je plan spoliehat sa na nieco ako OAuth/OIDC (ako je dnes v mode) tak toto je dobre citanie:
https://wiki.evolveum.com/display/midPoint/Access+Management+and+Provisioning
Problemy s jednotnym datamodelom som spomenul. Na to bohuzial lepsi writeup nemam. Ale to snad kazdy skuseny architekt uz musel v istej forme zazit. Takze tu snad staci povedat, ze si na to treba dat pozor a do predu zanalyzovat reprezentativne vzorky existujucich dat - a hlavne dynamiku ich vyvoja do buducnosti. Hlavny problem byva velka vseobecnost spolocneho dataveho modelu a teda nasledna nizka interoperability implementacii. Lebo tu bude zrejme vela implmentacii, kedze kazdy urad musi urobit mapping svojho modelu na ten spolocny a kazdy to urobi inak. My to riesime tym, ze midPoint ma (dost komplikovany) support pre velmi dynamicky schemu (predpokladame u kazdeho klienta inu) a potom transformacia cez star (hub&spoke) topologiu vo vnutri midpointu (kniha to vysvetluje). To je dobre riesenie, ale rozhodne nie jednoduche. A pri cross-org nasadeni bude este tazsie. Takze treba poriadne zanalyzovat prostredie, mozno sa bude dat najst nieco lahsie. Ale pristup “unifikovana schema a API to vyriesi” je velmi naivny. Ten nefunguje.
Tiez pozor na data protection (a.k.a. GDPR strasiak). To je dost gamechanger. Nutne dobre nastudovat. Ak chceme zachovat dataprotection tak niektore pristupupy co sa dnes bezne pouzivaju sa po “GDPR” budu dat len velmi tazko pouzit (ako napr. typicky fire-and-forget create-on-demand kvazi-provisioning co sa bezne pouziva pri SSO/AM).
Ale hovorim, uplne najlepsie by bolo zapojit do teamu niekoho, kto ma za sebou aspon jeden velky IDM projekt. Idealne v pozicii architekta. Toto naozaj nie je na diskusiu cez Internetove forum. To tu mozem tie problemy popisovat dva dni a aj tak vam z polovica z nich ujde. Najdite si niekoho kto vie co robi. To je jedina rozumna cesta.
Ja sa priznam, ze ti nerozumiem. Ako toto suvisi vlastne s IDM? Je to podobne? Urcite? V tomto pripade totiz su jedny master data = referencny register. Ak mas nejake konflikty so svojou db, tak plati to, co je v ref. registri. Bodka.
3 Likes
To co robis je IDM na steroidoch. Ano, mas (asi) jednoduchsiu korelaciu lebo RC (alebo ekvivalent). Ano, mas (teoreticky) autoritativny zdroj pre kazdu informaciu. Ale inak je to IDM (alebo MDM). Musis tie data presuvat. Musis manazovat kde su kopie, ako ich aktualizovat, ako ich zmazat. Toto je to co IDM realne robi (nie, IDM nie je to iste ako SSO alebo OIDC). Tie data budu mat roznu schemu (budu, aj napriek pokusom o zjednotenie). Ta schema sa bude casom menit (ovela viac ako teraz cakas). Budes musiet spajat data z roznych registrov a transformovat ich. Iste, mozes tuto zodpovednost alibisticky schovat za API a vytlacit to ako zodpovednost jednotlivych uradov. Ale to ten problem nevyriesi. Len ho schova. Preto sa tesim na dobre zisky. Lebo to znamena, ze kazdy urad bude potrebovat IDM system …
Ale co nakoniec zistis, ze data prejdu aspon tak cez 4-5 transformacie cez asi 3 data modely roznej vseobecnosti v aspon 2 roznych intermediary systemoch (plus aspon jeden pre ten meta-register) na ktorych spolupracuje tak 8-10 roznych dodavatelov. No, nechcel by som tam diagnostikovat problemy.
Preco by som to musel robit? Ja som referencny register, ak niekto chce data odo mna, nech si ich odo mna taha a da mi pokoj. Ja nie som zodpovedny za udrziavanie konzistencie dat mojich konzumentov alebo nebodaj to, ci ich po pouziti zmazu, na to nech maju oni svoje procesy v sulade s GDPR. Ano, ked zmenim schemu (breaking change), tak sa to konzumentom to rozbije a je to moja chyba, ale tak to je snad vsade a aj keby to bolo cele naopak.
Toto je presne ten problem. Tento pohlad na vec. Ano, ty si referencny register. Ty sa nestaras co sa deje. Lenze tu nejde o to aby referencny register fungoval. Ludia nepotrebuju referencny register. Ludia potrebuju aby od nich kazdy urad nechcel to iste lajstro zas a znova. Tu nejde o referencny register, ale o cele statne IT. Ano, urobit idealny, jednoduchy a lacny referencny register je (velmi) lahke. Lenze ono to takmer urcite vyprodukuju obrovsku pracu na “druhej strane API”. Cize na uradoch. To je presne to co sa deje v tych “teoreticky idealizovanych” IDM projektoch. Tam si tiez ludia myslia, ze “zadefinujeme jednotne API, vsetky aplikacie to naimplementuju a problem solved”. No, a potom im zacnu chodit odhady od dodavatelov aplikacii kolko ta implementacia (a udrzba!) API bude stat. Naklady sa kopia … nie vsetky naraz, ale postupne. Nepozorovane. A potom pridu implementacie. A surprise surprise, oni tie implementacie akosi nechcu spolu fungovat. Tam sa zacne prestrelka medzi dodavatelmi a architektmi. A kedze realna datova topologia nie je start ale mesh, tak to bude prestrelka s kvadratickou zlozitostou. A kazdy dodavatel ma super job security asi tak na najblizsie storocie. A samozrejme ty ako referencny register das od toho ruky prec. Lebo ved to je problem medzi poskytovatelom dat a pouzivatelom dat. Referencny register s tym nema nic.
To bude pekna komedia. Videl som ju sice uz viac krat, ale zakazdym to ma nejaku zaujimavu novu zapletku. A toto bude dobry velkofilm. Vysokorozpoctovy. Asi budem potrebovat velkododavatela na pukance.
Rado, problém vidím aj v tvojom pohľade na vec. Príliš rýchlo “skáčeš k uzáveru”, pritom o problematike (referenčných registrov) nemusíš vedieť dosť na to, aby tvoj príspevok bol prinajmenšom “uchopiteľný”. Už len toto:
Môžeš teda skúsiť vysvetliť, prečo máme po toľkých rokoch vyhlásené presne 4 referenčné registre, keď je to také jednoduché urobiť? Zámerne hovorím o vyhlásení, lebo tam ti predsa stačí pohľad - ktorý nám všetkým tlačíš do úst - toho “slepého”, ktorý vypublikuje a nestará sa.:
https://metais.finance.gov.sk/refregisters/list?page=1&count=20
Stále si myslíš, že primárny problém je v “shared schema” a problémoch, s ktorými (môžem odhadovať - ale zase nevytvárajme obraz, že tu diskutujúci ľudia nezažili IDM projekt) zápasí IDM architekt, keď sa mu všade “kopíruje” organizačný model (ktorý všetky aplikácie považujú za “svoj”, keďže ho chcú natívne využívať napr. aj na prideľovanie, alebo manažment svojich interných oprávnení)? Práve toto napríklad nie je “default” situácia pri referenčných údajoch. To nie sú “tvoje” údaje. Na tieto údaje nemáš prečo pozerať sa cez “svoj” model (napríklad pri tvorbe rozhodnutia). V zásade by si si ku svojmu modelu mal “dlhodobo” poznačiť len referenčný identifikátor údaju, ktorý si využil. Ak si tie údaje pretransformuješ do “svojho” modelu - je to tvoja zodpovednosť a musíš vedieť čo robíš. Ak to robíš kvôli nejakej dávke (napríklad rozposlanie výziev na očkovanie) - je to v pohode, tie údaje sú platné len v čase, kedy si výzvu pripravil (nebudeš sa na ne odvolávať v čase inom - na konci dňa platí, že si poznačíš len referenčný identifikátor). Ak si skopíruješ údaje do svojho modelu dlhodobo - no tak si prestal používať referenčný údaj, ale skopíroval si si dáta (tak sa musíš začať starať). Ale nehovorme si, že toto je primárny scenár použitia referenčných údajov.
Myslím, že by sme v tejto diskusii rýchlejšie iterovali k vzájomnému pochopeniu, keby sme mohli prediskutovať svoje pohľady a skúsenosti osobne. Ale k tomu nestačí, že si tu ľudia prečítajú priložené linky a knižku “practical IDM” (inak ja som ju a najmä úvodnú kapitolu čítal už skôr). Chce to aj stranu “IDM Architektov”, aby buď začali viac čítať dokumenty na informatizacia.sk, alebo sa kde-tu zastavili na architektonickej pracovnej skupine, alebo (v tomto prípade) skupine lepšie údaje. 
Keďže ťa profesionálne poznám dlhé roky a veľmi si ťa vážim - viem že by to bolo pre eGov veľmi, veľmi prospešné.
Mozno mame tych referencnych registrov tolko, lebo je lahke ich vyrobit? Ale referencny register sam o sebe problematiku neriesi? Nie je to jedno z pravdepodobnych vysvetleni?
Co sa tyka shared schema, tak si dovolim vsetkych odkazat na knihu co som spominal. Ale chapem, ze ju asi nikto neprecita. Nevadi, TL;DR: problem nie je v samotnej scheme, samozrejme. Problem je, v myslienke, ze jedna schema dokaze popisat vsetky data co sa budu presuvat (co nedokaze) alebo ze definicia spolocnej schemy bude dostatocne presna na interoperabilitu (co nebude). Takze, budeme potrebovat extensibilnu schemu ktora sa bude (aspon najblizsich par rokov) relativne casto menit a upresnovat. Ano, ja chapem, ze schema referencneho registra nebude (uplne) popisovat tie “skutocne” data co sa budu presuvat. Ale to ten problem iba zhorsi. Lebo prakticke datove schemy sa budu robit ad-hoc, a teda aj integracia bude ad-hoc na kazdy zdroj dat osobitne. Takze mas mesh datovu topologiu s radovo desiatkami organizacii. To je navod na katastrofu. Co je na tom najzabavnejsie je, ze v takom pripade ten referencny register vlastne strati vyznam. Lebo pre urad (konzument dat) bude lahsie hardcodovat integraciu priamo na iny urad (poskytovatel dat) a vsacina tych meta-meta-dat v referencnom registry bude pri tom iba zavadzat. Aj tak tomu nedaju ziadnu skutocnu flexibilitu.
“Ak si tie údaje pretransformuješ do “svojho” modelu - je to tvoja zodpovednosť a musíš vedieť čo robíš.” … ale toto je presne ten problem. Existujuce aplikacie nezmenis. Transformovat budes musiet. A je tu moj model, tvoj model, jeho model, integracne modely, rozsirene modely, prisposobene modely … zrazu tu mas tolko modelov, ze sa to nebude dat zvladnut. Ten problem tu bude a tym ze to odsunies za API alebo ze sa tvaris ze to nie je tvoj problem ale jeho problem nic nevyriesi. Aj ty aj Jano pozerate len na to ako implementovat referencny register a navrhnut schemy a API. Ale nepozerate na to, co bude musiet urobit urad aby dokazal v tejto architekture prakticky fungovat. Lebo vacsina nakladov pri takychto projektoch nie je v centre. Odtial ich pohodlne vysuniete, lebo to je uz za API, to je “jeho model” a to nie je problem referencneho registra. Vacsina nakladov dopadne na periferie systemu. Lebo tam odsuniete vsetku zlozitost.
Ked sme uz pri tom, urobil niekto aspon predbeznu analyzu kolko bude stat pripojenie takeho typickeho uradu do tohto systemu? Alebo nas zaujima len cena referencneho registra?
Naozaj. Skuste si vycistit hlavy a pozriet sa na to cele z pohladu architekta na urade ktory poskytuje data zlozene z inych dat z inych uradov. Ale pozor, toto cvicenie je len pre silne povahy 
Ale aby som len nefrflal: Skuste sa pozriet na podobne projekty. Staci uz aj pohlad na vacsie enterprise IDM projekty. Tam su tie problemy miernejsie, ale su podobne. Skusenosti su aplikovatelne. Co je pri enterprise velmi poucne je, ze vsetky naklady sa platia z jedneho vrecka (IDM aj “periferie”), takze tam vidno kolko to cele naozaj stoji. A nie len kolko stoji to centrum (ktore je typicky najlacnejsie). Ale ked chcete vidiet prakticke cross-org tak vid. napr. eduGAIN. Tam pouzivaju ine technologie, ale problemy s ktorymi zapasia su velmi podobne. Pozrite si hlavne ako dlho eduGAIN funguje a ako “daleko” sa dostali so spolocnou schemou. Asi by bolo dobre poucit sa od ludi co su v tomto dalej predtym ako sa odsuhlasi potencionalne velmi draha katastrofa.
EduGAIN je federacia naozaj nezavislych organizacii, oni preto musia ist cez spolocnu, standardizovanu schemu, meta-registre a podobne. Tam ina cesta nie je. Navrhovany pristup referencneho registra je architektonicky velmi podobny (aj ked technologie a velkost su ine). Tak preto je dobre pozriet sa na eduGAIN aby ste videli co vas asi caka. Co ja chcem povedat je, ze u nas sa mozno da tymto problemom vyhnut. Pretoze co my mame nie je uplne cross-org. Asi by sa dalo urobit hybridne riesenie.
Ale ako hovorim, mne to moze byt viacmenej jedno. Ja na tej katastrofe pravdepodobne zarobim. Robim IDM uz nejaky ten cas, tento scenar som videl niekolko krat, videl som ako to dopadne. Tak som na to chcel upozornit. Aj ked tym idem v podstate sam proti sebe. Ale uz koncim. Budem sa spravat rozumne. Idem kupit pukance.
Toto som nepochopil. Prvá veta odpovede mi nedáva zmysel vo väzbe na vecný stav (máme dnes ref. registrov žalostne málo). Druhú si (možno len nechápe) vysvetľujem, že netreba odpovedať na otázku, lebo referenčný register aj tak (za žiadnych okolností) nič nerieši. Nesúhlasím - aspoň pre referenčný register ako ho chápem ja a možno aj ďalší, a čoraz viac mám pocit že tu môže byť jadro problému - ty pod tým chápeš niečo iné. Uvidíme.
Poďme od začiatku. Si v štátnej správe (samosprávu nachvíľu dajme bokom, kedže tam sú “úrady” zvrchované - to viac pripomína “enterprise” svet, kde sa dvaja môžu flexibilne dohodnúť). To, že úrad A potrebuje nejakú informáciu (papierové rozhodnutie v papierovom svete, nejaký aktuálny údaj z jeho evidencie v svete elektronickom) k výkonu verejnej moci z Úradu B, je napísané v zákone. Aj čo je to za informácia. Keď to budeš chcieť zmeniť, musíš zmeniť zákon (to je tak ročný cyklus, keď si super flexibilný, a potom prídu na rad účinnosti “až od” - aby sa okolie vedelo prispôsobiť - prechodné ustanovenia a podobné nástroje). Z tohto pohľadu to celý odstavec o flexibilne rozširovateľných schémach, ad hoc kontraktoch a mesh dátových topológiách renderuje ako mimo realitu štátnej správy. Toto je skôr aplikovateľné v prostredí heterogénnych autonómnych organizácií, ktoré sa kedykoľvek rozhodnú, že si idú niečo vymieňať. Ale mimo realitu referenčných údajov a referenčných registrov.
A teraz poďme na jednoduchý príklad. Možno sa aj mne rozjasní. Úrad A je Sociálna poisťovňa (SP). Úrad B sú policajti - evidencia vozidiel. Sociálna poisťovňa má na stole od občana žiadosť o dávku v hmotnej núdzi. Vo svete tohto jednoduchého príkladu, potrebujú okrem svojej evidencie (či už občanovi dávku predtým nepriznali a nežiada o druhú) vedieť, či náhodou občan nevlastní auto (v zmysle logiky - kto má auto, nie je v hmotnej núdzi). Referenčný údaj z registra evidencie vozidiel nech je počet áut. Keď SP rozhoduje o dávke, odčíta si cez API referenčný údaj a rozhodne. Predstavme si teraz pre jednoduchosť, že nič iné v štáte nie je potrebné prepojiť, len tieto dva systémy. Otázky:
- Kde presne sa prejaví “shared schema” problém? Čím konkrétnejšie, tým skôr ťa pochopím(e).
- Ako presne mi pomôže v tomto prípade prístup eduGAIN? Nepoznám problematiku do hĺbky, ale čo som zatiaľ videl (okrem federovaného AM) - ide o “zjednocujúci model identity”. Podľa mňa to nie je to, čo sa rieši v eGov s referenčnými registrami. Autá sa neevidujú aj v SP, a preto nepotrebujeme zjednocovať model evidencie áut medzi SP a Evidenciou vozidiel. Je to viac o tom, čo som už písal o IDM (že v enterprise prostredí sa takmer všetky aplikácie cítia ako vlastníci organizačného modelu napríklad), alebo to viac pripomína problémy, ktorým čelí vzťah “zdrojový vs. referenčný register” (kde napríklad RPO sa snaží mať unifikovaný model pre ORSR, živnostenský register, ale aj register architektov, advokátov, exekútorov). Ale to sme o vrstvu nižšie (už neriešime referenčné údaje, ale vzťah zdrojový vs. referenčný register).
3 Likes
Hlavna otazka tu je: kolko dat ma mat referencny register?
Alternativa A: ziadne. Referencny register iba odkazuje na ine sluzby (ma len meta-*-meta-data). Sam ziadne data neposkytne. Register nevie co je to pocet aut.
Alternativa B: ciastocne data. Cize mam pocet aut, ale nemam ich ev.cisla a pod.
Alternativa C: vsetky. Tu referencny register uz nie je tak uplne referencny. V skutocnosti je to centralizovany register (realne ekvivalent enterprise IDM). Ale povedzme ze aj to prezijeme … pre ucely diskusie.
V pripade A je referencny register dost nanic. To je extremny pripad tej ad-hoc integracie co som spominal.
Alternativy B a C maju problem so schemou. Lebo v tychto pripadoch musi referencny register definovat co je to auto. A to nie je len schema kde mas jeden single-value atribut typu integer. Musis zadefinovat vyznam. Co to znamena “auto”. Je aj skuter “auto”? Aj privesny vozik je “auto”? Jeden urad bude chciet pocet vsetkych registrovanych vozidiel, iny moze chciet len pocet motorovych vozidiel, dalsi pocet motorovych vozidiel nad 7.5t … Toto treba niekde velmi presne zadefinovat, lebo policia to moze naimplementovat jednym sposobom (“pocet registracii”) a socialka to moze interpertovat inym sposobom (“pocet motorovych vozidiel”). Toto nie je lahka praca, lebo tu mas jedny data a vela konzumentov (co je fundamentalny vyznam referencneho registra, vsakze). Musis urobit schemu co vyhovuje vsetkym. A musi byt presna. A to nie je vobec lahke (real-worl priklad: LDAP). Ak to zanedbas co i len trocha tak na problem sa pride az pri testovani a … vieme ako to potom dopadne. A toto je naozaj trivialny priklad. Realita bude o niekolko radov horsia.
Dalsi problem je, ktore data vobec do referencneho registra davat a ktore nie. Lebo zrejme v pripade B nema zmysel davat tam data co maju ziadneho alebo jedneho konzumenta. Cize musis zlozit spolocnu schemu. To je presne to kde sa daju pouzit skusenosti z edugain. Lebo tam vidno nakolko je tu spolocnu schemu mozne/efektivne zostavit.
Este vacsi problem je, ze na toto sa neda pozerat len z pohladu terajsieho stavu. Lebo zakony sa menia. A teda aj ta schema sa bude menit. Cim viac dat ten register ma tym horsie to bude. Kto bude tie schemy definovat? Kto to bude udrziavat? Ako flexibilne to bude? Bude treba na kazdu trivialnu zmenu schemy changerequest na 100 clovekodni draheho konzultanta s kravatou?
A co aktualizacia dat? Mozno je zivnostnik v hmotnej nudzi prave preto, ze mu exekutor zobral auto a teda nemoze dalej podnikat. Ale referencny register stale tvrdi, ze auto ma. Ako rychlo sa tie data budu aktualizovat? Aka bude moznost opravit nepravdive informacie?
A teraz si predstavme, ze pocet aut je majetkova informacia a teda je citiliva. A ze z pohladu ochrany udajov musime evidovat kde sa ta informacia udrziava. Vieme, ze je ta informacia na socialke? Lebo socialka si urcite urobi (priamo ci nepriamo) kopiu tej informacie do svojich tabuliek. Nie je realne, ze kazdy GUI request zo systemov socialky by tahal informacie z referencneho registra. Kto bude evidovat, ze na socialke sa udrziava infomacia o pocte mojich aut. Co ked na statnu spravu poslem nieco taketo?
https://www.linkedin.com/pulse/nightmare-letter-subject-access-request-under-gdpr-karbaliotis/
Ano, socialka ma teoreticky pristup k mojim datam. Ale odkial zistis, ci moje data naojzaj su na tej socialke alebo nie? Alebo este okrem referencneho registra budeme stavat dalsi system za 100M eur na tracking udajov? Ano, chapem. Statna sprava si to nejako osetri aby to nemusela robit. Aspon na chvilu. Takze toto odlozime ad acta ako problem buducnosti. Ale ono to skor ci neskor pride …
A vobec, budu tie data v referencnom registry vobec stacit na integraciu? Naozaj to vyriesi nejaky problem? E.g. naozaj socialke staci pocet aut? Nepotrebuju presnejsie data? Lebo ak potrebuju, tak pre nich bude lepsia cesta integrovat sa len na policiu. A usetria zbytocnu integraciu na referency register. Bude nakoniec niekto vobec ten register pouzivat?
Vela otazok. Zamyslel sa niekto nad nimi?
Trpezlivosť sa zrejme na konci vyplatí, myslím, že sa blížime k bodu, odkiaľ si sa vydal vo svojich úvahách zlou cestou. Z tvojho príspevku vyplýva pohľad, že “referenčný register” je systém, ktorého vlastník/gestor “prevzal” zodpovednosť za publikované údaje (napríklad od polície v prípade evidencie vozidiel). A pýtaš sa ako s tou zodpovednosťou naloží - čo všetko sprístupní, či to bude stačiť konzumentom, ako si zabezpečí aktualizáciu údajov atď. Dovoľ mi potiahnuť túto (dopredu hovorím nesprávnu) predstavu ďalej. To znamená, že by (cez legislatívu) musela vzniknúť “super-inšitúcia”, ktorá by mohla prevziať zodpovednosť a kompetencie za publikáciu a poskytovanie referenčných údajov od všetkých úradov. Máš pocit, že sa také niečo v legislatíve udialo? Ak áno, vieš nám ukázať konkrétnu novelu?
Zatiaľ poďme naspäť do (praktickej) reality.:
-
Rule #1: Za publikáciu a vecnú správnosť údajov je vždy zodpovedný ich vlastník (vyplýva zo zákona). Policajti vedú napríklad evidenciu fyzických osôb a vozidiel. Štatistický úrad evidenciu právnických osôb. Atď. Všetko je dané zákonom (kto a čo presne eviduje a aj platnosť). Takže primárny vlastník definuje schému (inak je to jednoduchý zoznam atribútov, nehrajme sa, že je to niečo extrémne zložité), zodpovedá za úplnosť a správnosť údajov, atď. Vlastník nemôže sprístupňovať (ako referenčný) údaj, ktorý nie je v jeho kompetencii evidovať (ako referenčný).
-
Rule #2: Žiadny úrad inému úradu svojvoľne žiadne referenčné údaje neposkytuje. (Inak otázka pod čiaru.: Už si videl nejaký úrad, že robí niečo, z čoho vyplýva zodpovednosť a čo mu zákon vyslovene neprikazuje?)
-
Rule #3: Na to, aby nejaký úrad poskytol inému úradu referenčné údaje, musí existovať zákon, podľa ktorého tak musí urobiť. A v tom zákone je presne napísané komu a čo. Takže ak chce nejaký vlastník vedieť, aké údaje sú používané - hádaj čo. Pozrie sa do platnej legislatívy. Z nej (keď si sumarizuje požiadavky) vie odvodiť, ktoré atribúty má “jeho” schéma obsahovať. Ak sa časom zmení legislatíva (už som spomínal ročné cykly? ak áno, tak by bolo dobré začať s nimi pracovať - a to sme v prípadoch, keď sa menia podmienky veľmi flexibilne) tak v novelizácii pridá nový atribút. A časom (v tej istej novele nastaví prechodné obdobia, účinnosti od-do → teda podmienky pre “phase-out”) prestane poskytovať starý atribút . Ďalej: keďže vlastník vidí, kto všetko a na čo jeho referenčné údaje potrebuje tak ani report pre GDPR nie je problém. Inak ten “list” som čítal už takmer pred rokom a apelujem, aby sme sa bavili pragmaticky - sám vieš, že každá regulácia má nejakú filozofiu, niečo, čo chce vylepšiť - určite to nie je “paralyzovať” informatizáciu nie len vo verejnej správe. Takže bavme sa o praktických dopadoch. “Nightmare letter” viem vyrobiť aj pre PSD2, a dal sa vyrobiť aj pre “Data Protection Directive”, ktorá tu je/bola pred GDPR.
Na to, aby každý úrad niesol zodpovednosť za svoje referenčné údaje - si nemusí budovať zakaždým nový systém, pomocou ktorého ich bude publikovať a zdieľať. Môže využiť centrálny uzol (kde má fázu publikácie, aktualizácie aj komu sa čo a akým spôsobom sprístupňuje - plne pod kontrolou - a nerobí to nikto za neho). Ber to ako ekvivalent fungovania obyčajného agendového systému - napríklad evidencie vozidiel. Môžeme konštatovať, že zodpovednosť za správnosť evidencie vozidiel nesie príslušný rezort, resp. jeho minister. Ale nie je to tak, že minister sám si po večeroch píše IT systém evidencie vozidiel. Rezort, alebo úrad si na to obstará nejakú IT firmu, ktorá ten systém vyrobí a prevádzkuje (ktorej zodpovednosť je, aby systém fungoval), ale nič to nemení na fakte, že zodpovednosť za správne údaje v ňom stále nesie vlastník.
Tak toto už fakt nechám na teba, aby si si zodpovedal. Priznám sa, že nie som veľmi fanúšik postov, v ktorých sa podsúva, že všetci naokolo sú (diplomaticky povedané) “padnutí na hlavu” len ja som “lietadlo”. Preferujem prístup v ktorom sa najprv snažím pochopiť ako to kde je vymyslené (napríklad že prídem popočúvať na nejakú pracovnú skupinu, alebo naštudujem dostupné materiály a dám si aspoň jedno stretnutie s niekým, kto sa téme venuje) a potom dávam odporúčania podporené získanou znalosťou o doméne.
Samozrejme, nikto z nás nemôže garantovať, že sa aj dobrá myšlienka v implementácii nezvrtne na veľko-výpravnú tragikomédiu. Čo však povedať viem, že “shared-schema” problém nie je hlavný a najvypuklejší architektonický problém dnešných eGov údajov. Najväčším problémom je, že údaje sú v takom stave (= nevyčistené), že nám len ich “vyhlásenie za referenčné a zdieľanie” žiadny problém nerieši - pretože nie je možné sa na ne pri výkone verejnej moci spoľahnúť. Z toho vyplýva, že najžiadanejšie skillsy sú dnes tie v dátovej integrácii, čistení a konsolidácii údajov - už len do centrálnej dátovej kancelárie na ÚPPVII. Skúsenosti s problémom “shared schema” by (ako som už spomínal) mohli byť zase dobre využiteľné tam, kde nejaký vlastník a zodpovedný za referenčný register má pod sebou niekoľko zdrojových registrov (RPO, RFO napríklad). Tam sa presne vyskytujú takmer všetky problémy o ktorých píšeš. Ale tie boli do eGov privodené zavedením “agregujúcich referenčných registrov”. V čistej podobe (bez agregujúcich) referenčných registrov sú tieto problémy minimálne (ak vôbec nejaké).
1 Like
Ano, ja to chapem co pises.
Problem je, ze ty hovoris o zakonoch a o tom ako by to teoreticky malo byt. A na zaklade toho sa navrhlo riesenie, ktore niekto povazuje za idealne vzhladom na poziadavky (zakony).
A ja ti hovorim, ze ta teoreticky idealna architektura sa skusa zas a znova uz viac ako desatrocie. A zas a znova nefunguje (alebo fungule len na zlomok povodnych ocakavani).
Problem je, ci to naozaj je dobra myslienka. Stale mi hovoris o refencnom registry. Ja hovorim, ze schema bude problem. A ty mi hovoris, ze to nie je problem referencneho registra. Ano, v tom pripade ako to popisujes to naozaj nie je problem referencneho registra. Lebo (ako stale tvrdim) to odsunies “za API” a nestaras sa. Nech sa staraju urady. Chcem od teba, aby si sa na to pozrel z pohladu toho uradu. Ale ty mi stale tvrdis, ze to nie je tvoj problem. No, asi naozaj nie je. Ale tym ten problem nezmizne. Nie je vyrieseny. Je len neviditelny.
No, a co sa tyka implementacie: mas uz za sebou dlhu prax ako architekt. Urcite vies, ze architektura silne ovplyvnuje to ako kvalitne bude urobena implementacia. Niektore architektonicke napady sa v realnom svete velmi tazko implementuju. Tie napady mozu byt techicky uplne skvele. Ale v praxi narazia na komunikacne problemy, organizacne problemy, nekompatibility, nesulad planov, na problemy dynamiky prostredia, alebo na obycajne ludske nedostatky. Netechnicke problemy. A ja sa ti snazim cely cas vysvetlit ze toto je takmer urcite ten pripad. Mozno dokonca modelovy pripad architektury, ktora tie problemy zosiluje. A cely cas ti hovorim, ze pozri si vacsie IDM projekty. Tam sa s tym bojuje cely cas. Chces spolucnu schemu? Alebo aspon ciastocne koordinovanu schemu? Proces pre governance a udrzbu tej schemy musi (!!!) byt sucastou architektury. Je kriticky. A musi sa odprototypovat. Jednoducho povedat ze to je out of scope je nedostatocne. Nechces spolocnu schemu? Tak naco ten register je? Nestacila by sada doporuceni a specifikacii ako publikovat jednotlive sluzby na uradoch? A zase sme pri governance. Nakoniec rovnake doporucenia a specifickacie budes potrebovat aj v pripade tej tvojej centralizovanej-necentralizovanej schemy. A nie, nestaci povedat, ze governance je “podla zakona”. Zakon ti nepovie nic o verzii datovych modelov, zivotnom cykle schem, doporucenej reprezentacii dat (tak aby zohladnovala limitacie uradov) a podobne. Toto su tie tazke problemy. Nieco o tom viem. Zijem v tom hlboko namoceny uz aspon 7 rokov. A to nase IDM je vacsinou len v jednej organizacii. Toto tu bude este radovo horsie. Prave na tych “netechnickych” problemoch. Kedze referencny register (zjavne) nebude robit transformaciu/mapovanie dat tak jeho technicka cast je naozaj velmi lahka. Cela zlozitost bude na uradoch. Pozor, “system” tu nie len samotny register. “System” je register+urady. A kedze je to (ciastocne) cross-org tak netechnicke aspekty (hlavne governance) toho systemu su ovela dolezitejsie ako samotna technicka architektura. Inak z toho vznikne nieco ako “interface na vsetko” od nasich kamaratov Poliakov, ktory si obaja este dobre pamatame.
BTW: neuniklo mi, ze moje otazky o konzistencii, spravnosti a data protection si pohodlne odignoroval. Ale to som cakal
Naozaj, najdite si niekoho kto uz presiel cez nejake velke IDM. Alebo MDM. Robite navrhy, ktore teoreticky vyzeraju dobre. Ale v praxi to funguje inak. Velmi vidno ako tu tie skusenosti chybaju. Citim sa ako by som vysvetloval preco nie je dobry napad stavat ponorku z LEGO kociek. Ale ako keby sme hovorili inym jazykom. No nic, viac uz nemam k tomu co povedat. Vratime sa k tomu asi tak za 5 rokov. To uz tie skusenosti mozno budete mat (aj ked sa ti asi nebudu pacit). Ak ten projekt dovtedy prezije.
1 Like
Rado, takže zhrniem.:
- Hovoríš, že v “teoretickej rovine” sa zrejme nedá návrhu nič vytknúť ale máš pochybnosti či je to vôbec dobrá cesta.
- Problém vidíš v “netechnickom” aspekte, kde skúsenosti z okolia hovoria o tom, že governance model je často podcenený a že sa to zvyčajne vypomstí. S tým ťažko nesúhlasiť. Samozrejme, že governance model nebude ponechaný len na legislatívu a bude tam koordinačná aktivita ÚPPVII (dátová kancelária VS). Možno teraz lepšie chápem, že ťa hore v diskusii niektoré zjednodušujúce vyjadrenia vytáčali. Ale bez zjednodušenia ťažko vysvetliť čo sú fundamenty v štátnej správe a jej fungovaní. Bez problémov beriem názor, že sú v IDM a MDM projektoch (mimochodom návrh referenčných registrov svojho času revidovali firmy, ktoré MDM a dátovú konsolidáciu robia komerčne dlhé roky a na trhu sú špička) príklady dobrej praxe, ktoré je možné využiť na to, aby sa niečo v governance nepodcenilo. O tom už ďalej nemusíme diskutovať, to si z tvojho príspevku odnášam. Ale vo vzduchu sa kde-tu vznáša aj náznak nejakého argumentu proti samotnej myšlienke referenčných registrov? Ak áno, tak ho sformuluj konkrétne (najlepšie aj s návrhom ako to urobiť inak).
Ja si myslím, že som ti odpovedal - ak nie, tak skúsme najprv vyriešiť otázku, aké konkrétne problémy (v oblasti konzistencie, správnosti a data protection) som do toho zaviedol, keď som povedal, že vlastníci údajov publikujú svoje referenčné údaje cez svoje referenčné registre (napríklad cez centrálne technologické riešenie). Voči tomu, keď si budú publikovať všetci svoje služby svojpomocne.
BTW. Ja zase evidujem, že si mi celý čas neodpovedal na otázku, či si naozaj myslíš, že máme po rokoch až 4 referenčné registre, lebo schéma (a jej governance) registrov je problém? Lebo “referenčný register možno nič nerieši” nie je odpoveď. Doteraz si úrady mohli vymieňať údaje aj ad-hoc a napriek tomu žiadne nové referenčné údaje nepribudli. Toto “pohodlné odignorovanie” som zase čakal ja
Keď to skrátim. Čo konkrétne navrhuješ (okrem upozornenia, že bacha na governance - to samozrejme beriem)? Keď hovoríš, že celý návrh nie je možno dobrý tak aká je podľa teba alternatíva? Skús to na praktickom príklade tej SP a policajtov - nech to máme plasticky.
Alternativa je napriklad nestavat register. Zamerat sa na governance sluzieb. Vytvorit referencnu architekturu ako by sluzna na zdielanie udajov mala vyzerat. Cize priklad API, zdokumentovat doporucenia. Idealne ako pilot medzi dvoma uradmi a potom to zovseobecnit. Realne, aj ked bude referencny register, kazdy urad co bude “publikovat” aj “konzumovat” data si musi urobit implementaciu. Trpaslici tie data prenasat nebudu. Nakodovat sa to musi. Otazka je, aku hodnotu by do tohto referencny register vobec priniesol?
Dalsia alternativa je (aspon teoreticky) centralny “register” s mapovanim dat a la midPoint (deklarativne). Tu by som intuitivne povedal, ze na toto este technologia nedozrela. A moze to mat aj negativne dopady. Ale rad by som videl, ze sa o tom uvazovalo a preco sa to zamietlo.
Analyzoval vobec niekto alternativy?
Vidim tu frflanie na centralizaciu. Ale preco? Len z nejakeho spiritualneho principu ze vsetko centralizovane je zle a vsetko distribuovane je dobre? Super, tak tam dajme blockchain 
Vidim tu zjavne nedomyslene veci. Vidim snahu problemy schovavat “za API” a neriesit. Toto vsetko su pre mna obrovske cervene svetla. Toto vacsinou indikuje nedostatok skusenosti s problematikou. Nedomyslene dosledky.
Nevrdim, ze register je fundamentalne zly napad. Co sa snazim povedat je, ze na zaklade toho co vidim sa mi to zda zle (malo) zanalyzovane. A ze nevidim ziadnu silnu motivaciu register stavat. A pri architekture by default rozhodnutie malo byt nerobit to co nutne netreba. Komponent, ktory neexesituje je postaveny najrychlejsie, je najlacnejsi a aj najspolahlivejsi.
A navrh riesnia? Podla mna sa musi zacat od dat. Zistit ake data vlastne mame, ako sa v case menia, aky bude trend do buducnosti, ako su komplexne, ako by sa dali rozumne reprezentovat. A pozriet na urady: ake urady su dotknute, ake maju technologicke limitacie. Tiez sa pozriet na to, co nas caka v blizkej dobe. Lebo kym toto naplno nabehne prejde par rokov. A ocakavana zivotnost je (dufam) desatrocia. A veci ako GDPR mozu navrh zasadne zmenit. A potom navrhnut governance dat. Lebo vsak cele je to o datach, nie o tom aka bude logicka topologia, ci to bude rejoiner, Oracle alebo whatever. Potom pozriet okolo kde podobne riesenia funguju … a hlavne kde a preco nefunguju. A az potom robit zasadne architektonicke rozhodnutia (centralizacia vs distribucia). A validovat to cele prototypmi predtym ako sa to nanuti kazdemu uradu. A hlavne pozerat na cely system, nie len na register. Zrejme sa to dotkne velmi vela uradov, takze cena registra je takmer zanedbatelna oproti nakladom co to vyprodukuje na uradoch.
Cize, podla mna, ak sa teraz diskutuje ci centralizacia alebo distibuovanost tak zacinate uplne zo zleho konca.
1 Like
@semancik mozno mas zly predpoklad, tu sa davno nezacina. Tu sa davno uz vie, co sposobi centralne riesenie (vid CSRU - hadaj co znamena skratka - centralna sprava referencnych udajov ), governance na udaje uz nejaky existuje (vid metais a standardizacne skupiny), UK ide tiez cestou ref. registrov a zatial ich ulozisko necentralizuje.
Inak skusme to co navrhoval @kyselat. Zoberme si teda opacny extrem - jedno centralne ulozisko. Ako tam prosim pekne vyriesis data protection pri prvom konzumentovi? Uplne rovnako ho nevyriesis. V momente ked od teba zoberie konzument jeden bit informacie, stracas nad nim kontrolu a jedine na co sa mozes spolahnut je jeho dobre slovo a modre oci (teda podpis zodpovednej osoby na bezp. projekte a krvou podpisane procesy GDPR a urcite nejaky certifikat ISO).
Co keby som ti povedal, ze jeden referencny register stoji 10+ milionov eur a jedna integracia konzumenta 30-50k eur?
Prepac, ale trochu sa smejem, lebo zatial tu z mojho pohladu pises banalne rady v style: 1) pozor je to problem! zanalyzujte ten problem 2) navrhnite riesenie, idealne s niekym kto o tom nieco vie 3) profit!
Ale ja netvrdim, ze centralne ulozisko je urcite dobre riesenie. Tvrdim, ze nemusi byt zle. A ze to stoji za to poriadne to zvazit kym sa to zhodi zo stola len preto, lebo je to “centralizovane”. Aj ked svoje vyhody ma. Centralny register vie, kam data poskytol. Vie manazovat aj “kontrakty” na kopie dat, manazovat notifikacie o aktualizaciach, erasure a podobne. Sme v IT svete, ked konzument zoberie bit informacia tak nad nim stracas kontrolu tak ci tak. Kym nepojde na DRM tak to nevyriesis (a ani s DRM v skutocnosti nie). Vzdy sa musis spolahnut na “dobre slovo”. A kedze tu sme len ciastocne cross-org tak to zrejme ma riesenie. A tom data protection je. A prave z pohladu data protection je centralizacia prave velmi zaujimava alternativa (ale pozor, ubezpec sa prosim ze chapes rozdiel medzi data protection a information security). Aj ked, stale netvrdim, ze pre tento pripad dobra. Co tvrdim je, ze by sa nemala zmiest zo stala len preto ze fuj fuj zla centralizacia.
Ale skor by som ako nadejny videl opacny extrem: ciastocne unifikovane sluzby bez potreby registra. Cize kazdy urad by vystavil sluzbu na zdielanie dat. Vsetky by si boli podobne: rovnaky princip na mamazovanie kopii dat, rovnaky princip notifikacii, idealne unifikovane API a zkladna schema, sposob ako manazovat custom schemy. Potom by mozno ani ten register nebol potrebny.
Co chcem povedat: skusme najprv zistit co vlastne potrebujeme. A potom podme robit vazne arcitektonicke rozhodnutia ktore zasadne ovplyvnia pravdepodobne najdolezitejsi integracny bod v celom statnom IT.
Bingo. Teraz si skus nalistovat teraz toto a toto a chap to ako presne ako takyto navrh (inak je to len skrateny opis toho, co je v schvalenych dokumentoch, kde pracovne skupiny diskutovali o tom, ze aky je problem a co treba riesit a kde to moze zlyhat. (Preto aj poznamky od @kyselat, ze by velmi pomohlo sledovat tie PS. Chapem, ze cas nemas, ale potom sa tu budeme tocit v kruhu.)
No za prve ten bod uz dnes nejaky bohuzial existuje a za druhe, je celkom jasne, ze co je problem a co potrebujeme. Len - paradoxne - o tom nemas nastudovane dost skor ty.
Ja som presvedceny, ze toto nie je ITckarsky problem. Koncept ref. registrov, ktory toto mal riesit tu mame roky, nikomu nikto nebranil vyhlasit ref. register, zacat zdielat aj neunifikovane data pre ine urady, ktore ich potrebuju. Proste tu to zlyhalo na tom, ze kazdy rezort si siel svoje a 1x a dost sa nikdy nedostalo dalej ako za slub roznych politikov a sefov informatizacii. Lebo vycistit data je problem a motivacia odbremenit obcana nosit vypisy bola mala. Proste ziadny data protection, ani to, ze by sme nemali centralne ulozisko tuto nikdy nebol problem, tak si ho tu prosim este nepridavajme.
Tak sme si zavolali, tak sme si to vysvetlili. Uz to to chapem. Aj to dobre, aj to zle. Tak asi mozeme uzatvorit diskusiu.
3 Likes