Jasné že celý projekt nie je len postavenie registra. Jano len hovorí že či nevieme práve tento kúsok s jeho štandardným okolím spraviť efektívnejšie ako ako klasických >1M€.
Ku obslužným činnostiam - veď ten register môže poskytovať aj štandardizované funkcie do vnútra organizácie.
Mozno som celkom teraz nechopil pointu, tak mam tieto otázky:
cieľom by bolo vytvorenie standardu alebo priamo app na prevadzku registra a veci okolo? Nejake cd, ktoré by si organizácia ktorá chce prevadzkovat register stiahla a nainstalovala a v vytvoril podstate len opravila popisky poli?
kto a ako by ho vytvoril, kto by to financoval, upravoval, supportoval, pomahal konfigurovat a pod pre všetky ovm
reálne každý subjekt ma inú platformu u seba, niekto .net, java, oracle, ms sql a pod, na com by bežala? Je otazne ci by cieľom bolo vytvorenie vzoroveho standardu alebo priamo tej appRegister
kto by skolil a za co implementatorov, dokedy by bolo to riešenie hotové a kedy by mohlo byt k dispozícii. Aj dnes sú zrejme uz dostupné licencie a zdrojaky pre opis projekty, neviem si ale predstaviť kto a ako bY ich všetky otvoril a preanalyzoval a posudzoval, ktoré sú lepšie “napisane”. Lebo co programator, to iný pohľad… Nehovoriac o architektoch a analytikoch
v rámci VO zrejme nie je možné v podmienkach stanovenie presne názvu aplikacie ale len popis jej funkcionality, aby to nebolo diskriminačné, aby kritérium mohlo byt len cena. Teda reálne ak dodávateľ vyuzije napr. Hypoteticky tu appRegister, ok, ale ak to nakoduje cele sam, neviem na základe čoho mu to zakazes… Lebo cena diela je okrem implementacie aj analýza a návrh, testovanie a nasadenie+ riadenie, co podľa mojich prepoctov zo starých opis projektoch býva cca 60-70%nakladov. Teda reálne projekt impementovany za 1mil by bol za 3-4mil.ak však k tomu pridas aj napr. Integracie a migraciu dat, narocnost môže ďalej stupat, ak si vezmeš koľko je povinných osôb, ako dlho trvá s nimi komunikácia, cistenie dat do registra a pod.
Ako som zachytil niekde v diskusiach, riesili sa tu možné spôsoby nacenovania app a mozno cesta by bola skor o tomto ako o vytvoreni jedného kodu, ktorý by bolo problematický “pretlacit” ako jediný povinný.tiez v posudzovani návrhu aplikacii, t.j. Zverejňovanie a oponovanie DFS ako to ma aj s.d v tezach. Prikazanie jednej konkrétnej app by mohlo potom strhnut zo sebou dalsie problémy (co ak nebude pokryvat celú pozadovanu funkcionalitu, kto ju dokoduje na projekte a za co, co ak nebude fungovať správne ako sa bude riešiť reklamacia a s kým? Lebo iné je mať hotovú kompletnú ako SM UPVS a iné len nejake jadro.
Zrejme by bolo dobre spísať pod seba základné požiadavky na tieto registre a k tomu dva stlpce, čo by sa malo urobiť ako core app a co nechať na kustomizaciu, len tak by sa zrejme dali urobiť porovnanie a najdenie uspory resp. vyhody.
Hovorí sa tu, že generický register máva problémy s tým, že nevyhovuje úradníkom, resp. skôr to DMS. To plne chápem, sám neviem nájsť rozumné DMS pre klienta, ale tento generický register si predstavujem úplne inak… len ako v podstate databáza a nad tým API, ktoré použijú ďalšie systémy, každý úradník tak môže mať svoje vlastné UI, akurát dáta polezú z hlavného registra. Čiže generický register by bol ten hlavný register s API a klientské library (v rôzných jazykoch napr.) pre nadstavbové systémy, nech sa s napojením trápia čo najmenej. Nad tým nech už si robia logiku a UI. Register a knižnice by sa potom rozvíjali podľa potrieb jednotlivých projektov, kde by API nestačilo, dorobiť, aby stále bežali nad týmto základom. A základ môže bežať krásne v štátnom cloude, žiadne ďalšie železo.
Tak opat UK: Vyzera, ze sa snazia o to iste co pises, t.j. oddelit register od zbytku, jasne povedat co je register, co ma (a nema) robit, atd. A nasledne ak uz nie naimplementovat jeden genericky register, tak aspon vyprodukovat nejaku spolocnu bazu (kniznice, API principy, …) pre vsetky/vacsinu UK registrov, vid:
Oddelenie business logiky spravcu registra od casti uchovania a poskytovania dat tretim stranam by podla mna dokazalo usetrit mnozstvo prace a znizit narocnost integracie.
Ci to stavat ako skladacku rieseni je otazne. Spolocna metodika by sa minimalne hodila. Metodika k API co ma minimalne poskytovat API - sluzby, formaty, atorizacia, bezpecnost atd.
Škoda, že táto téma skončila. Neverím síce na generický register, ale aj zadefinovať čo je register, čo agendovy systém, aké sú tam spoločné moduly, aké sú požiadavky čo musí každý register podporovať… Mohol by to byť zaujímavý pohľad na referenčnú architektúru zo strany s.d. Niečo bolo definované v nkivs, asi by mala niečo robiť pracovná skupina pre architektúru, toto by bola alternatíva ako sa na to pozrieť.
Pridam sem feature request na hypoteticky genericky register. cc @vojtob
Priklad: Zober si ze mas RPO. A chces tam pridat jeden jednoduchy stlpec - napr. ziadatel o 2%, alebo v katastri, rozlohu bytu. Proste lahka klasika, ale ma to iny gestor. Toto je dost caste a vznika z toho milion miniregistrov. Toto by genericky register mal nejako velmi lahko umoznit. Napojenie na existujuce ref. data a ich rozsirovanie o dalsie datove prvky.
V idealnom pripade by to znamenalo toto: V nejakom deklarativnom jazyku napisem nove datove prvky, ich referencie na existujuce ref. registre. Genericky register tie data replikuje lokalne (ak treba kvoli vyhladavaniu, atd). Keby som velmi chcel, tak nejako deklarativne popisem aj workflow agendy k tymto prvkom. Co nie je genericke pripadne dokodim a hotove. Novy register s hotovymi API a napojeniami na ine registre je hotovo. Toto by nemuselo tak strasne boliet.
To zadanie temy, mi prijde trochu zmatocne… biznis (logika), aplikacia a techlnologia v jednom texte. Treba vsetky tri casti osobitne riesit a nie hned napisat “drupal”…
Cize by som zacal s business poziadavkami: pre koho to ma byt urcene, do coho to ma zapadnut, co od toho potrebuje, do kedy to potrebuje.
Cele mi prijde ako problematika master data managementu https://en.wikipedia.org/wiki/Master_data_management a definovat procesy a standardy je to najtazsie.
Niekde som tu cital, ze CSRU to ma implementovane technologicky cez Talend, to je dobry technologicky zaklad, ale bez vymyslenych procesov, standardov a governance je to len tazko pouzitelna db.
Jano zober ako príklad ten nový RPVS. Je to relatívne malý register, s jednoduchou štruktúrou údajov. Väčšina štruktúr údajov sú dávno známe veci - adresa, fyzická osoba, právnická osoba.
Čo to u nich obnášalo:
nový zákon, resp. zavedenie nového registra v zákone
určenie (v tom zákone), aké údaje sú predmetom registra
definovanie procesov, ako sa tam ktoré údaje dostanú, zmeny, kto zapisuje
riešenie okrajových prípadov, odvolania, opravy
Obraz týchto vecí sa potom implementoval.
A pokaziť sa to môže hocikde po ceste, napr. v tom RPVS nieje poriadny identifikátor fyzickej osoby (nie je tam RČ ani ekvivalent).
Ak to nie je problem, je pre mna zahadou preco nieco taketo davno nemame a platime za registre desiatky milionov eur za kus. A nie tam sa neplati za novy zakon, ake udaje su predmetom registra, definovanie procesov a ani riesenie okrajovych pripadov. Vsetko toto by totiz malo vstupovat do zadania. Cize suhlasim, ze analyticka faza a pripravna faza je ovela dolezitejsia, ale pointa prispevku je prave v tej technologickej casti.
Je mi jasne, ze vsetko toto vchadza do zadania[quote=“peterk, post:22, topic:2495”]
Treba vsetky tri casti osobitne riesit a nie hned napisat “drupal”…
[/quote]
Ach. Prosim aspon sa snazme citat s porozumenim. To bol priklad, nie navrh, ze robme to v Drupale. Niekedy mam pocit, ze si tu vyberieme jedno slovicko z celeho textu uplne mimo kontextu.
Suvisi to, ale nie.
Takze skusme sa posunut.
Lebo presne to som ja (asi nesikovne) hned v uvode urobil. Tocime sa v kruhu s takymito radami.
Sprava registra je vacsinou specializovana agenda (zvlast modul/system) a je integrovana na registraturu na prijmanie ziadosti/ich spracovanie a nasledne vytvorenie rozhodnutia o zapise. Niekedy je to riesene dakym procesom v ramci SOA.
Je to viac modulov spolu by som ich neriesil, aj ked an dakej vyssej urovni tam daky medzimodulovy biznis proces bude. V tomto sa prelinaju hranice aplikacii.
automaticke vyradenie z registra - casom/inym vstupom v medzirezornom procese
automaticke zaradenie do registra - napr v ramci vacsieho medzirezortneho procesu
metadata registrov:
ziadost o vytvorenie registra
ziadost o pridanie/odstranenie/presun autorizacie k registru
ziadost o rozsirenie cudzieho registra?
ziadost o pridelenie procesov spracovania registru
ziadost o sledovanie zmien dat registra
funkcionalita
bezpecnost:
autentifikacia gui - integracia na iam - ad/upvs iam
autentifikacia ws - integracia na pki/oauth/sts?
sprava pristupov
autorizacia na urovni registrov - citanie/zapis
autorizacia na urovni atributov dat registov - citanie/zapis
integracie autorizacii na existujuce systemy - ldap?
gui rozhranie na vsetky ukony
ws rozhranie na vsetky ukony
metadata registrov:
sprava registrov
pridelovanie prav ucastnikom
gui rozhranie na vsetky ukony
ws rozhranie na vsetky ukony
data registrov:
vytvaranie/aktualizacia dat registrov
vyhladavanie dat registrov
publish/subscribe model - online, formou dennych davok
verzionovanie?
gui rozhranie na vsetky ukony
ws rozhranie na vsetky ukony
spracovanie ziadosti:
prijatie elektronickej ziadosti cez ws - z registratury (nie je ulohou spravy registra sa starat o spravne dorucenie v orgarnizacii a archivovanie)
prepis ziadosti z papierovej podoby
vytvorenie rozhodnutia + podpisanie rozhodnutia?
odoslanie rozhodnutia cez registraturu (nie je ulohou registra starat sa o podpisovanie, obalkovanie, odosielanie a spracovanie dorucovania, archivovanie, atd…)
procesy - toto by tu nemuselo byt, ak by boli vsetky interaface dosutpne cez ws, tak riadenie/spustanie procesov sa da riesit na dakej uz existujucej platforme (soa/esb)
Ja si myslím, že to tu príliš komplikujeme v tomto kroku. Na začiatok by úplne stačilo vytvoriť ten register. V zásade všetko v tomto štáte je viazané na niekoľko objektov (fyzická osoba, právnická osoba - akákoľvek (veď typ je len príznak), adresa, nehnuteľnosť, automobil, …). Potom je to už len o dopĺňaní stĺpcov do databázy a vzájomných závislostí. Súhlasím s @Lubor aj @jsuchal že doplniť ďalší stĺpec nevyžaduje úplne novú databázu ako sa nám to tu úradníci s ich poradcami snažia nahovoriť. Problém ale asi je v tom, nikto to takto nechce, lebo sa nepredajú ďalšie licky na sql, or, db2,… Ono by sa to úplne kludne dalo vytvoriť z nejakej existujúcej databázy, registra. Napr. z RFO príp. dátovo uprataného RPO
no ano, technicky je to jednoduche…ale tej byrokracii okolo sa vyhnut podla mna neda, rozne organizacie, rozne poziadavky na registre. Najvacsi problem je vzdy zodpovednost, kto bude za co zodpovedny, to musi byt jednozacne. Ci uz za data alebo prevadzku. To ze je to len v inej db alebo to bude ako dalsie stlpce tak to nema velky vplyv an finalnu narocnost a celkovo cenu. Nuz Enterprise svet ma uplne ine pravidla:)