Generický register

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

2 Likes

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:

V zasade teda snaha o stary dobry modularny design. A zaroven zhruba to, o co ide pri poziadavke S.D o rozdrobenie mega IT projektov na mensie.

Na zaciatok teda od nich mozeme mnohe odpisat, neskor mozno aj spolupracovat? :slight_smile:

1 Like

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.

1 Like

13 posts were split to a new topic: Meranie progresu informatizácie

Š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ť.

3 Likes

Toto nie je vobec zly napad. Vies dat nejaky prvy nastrel co by si si pod tym predstavoval ty?

Áno, presne toto očakávam že bude rozpracované ako časť referenčnej architektúry.

1 Like

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.

1 Like

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

Databázová časť v tomto skutočne nie je problém…

1 Like

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.

Tak teda aké časti to potrebuje pokryť: - úvodný draft, doplňte

  1. spisová služba / DMS / príručná registratúra (pracovne to nazvime JIRA*)
  • nástroj na modelovanie procesného modelu
  • predpripravené GUI komponenty
  • prepojenie na vstup/výstup dokumentov, overovanie platnosti, autorizáciu - minimálne el. podateľňa
  • riadenie prístupu používateľov - prepojenie na IAM (zamestnancov VS)
  • dlhodobé riadenie dokumentov - prepojenie na archív, dlhodobé úložisko
  1. báza údajov registra (pracovne to nazvime MariaDB)
  • založené na RDBMS
  • vstup/výstup údajov z/do iných evidencií/orgánov - pripojenie na platformu zdieľania údajov

Pri vytváraní inštancie generického registra:

  • určiť a implementovať procesný model z pohľadu spisu / dokumentov
  • priradiť role
  • pripraviť el. formuláre a iné typové dokumenty, šablóny
  • definované údajové štruktúry a zavedené do DB
  • iniciálne naplnenie údajmi
  • konfigurácia pripojenia komponentov okolo

*) = úmyselná provokácia

1 Like

preco je tu registratura spominana? je to stale k tomu generickemu registru, alebo je to ta referencna architektura?

Generický register. Práve tá DMS časť je zložitejšia a pre vedenie registra podstatná.

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.

ja to skor vidim takto:

ucastnici

  • spravca platformy
  • spravca dat - gestor
  • konzument dat
  • ziadatelia/obcania/firmy

procesy

  • data registrov:

  • ziadost o zapis do registra

  • ziadost o zmenu v registroch

  • ziadost o vyranie z registra

  • 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)

  • spustanie procesov spracovania ziadosti

  • definovanie procesu spracovania ziadosti

  • sprava procesov

  • gui rozhranie na vsetky ukony

  • ws rozhranie na vsetky ukony

  • monitoring:

  • logovanie zmien

  • logovanie vytazenosti

  • varovanie pred pretazenim

poziadavky na data

  • historicky dohladatelne
  • relacie medzi registrami - semanticky?
2 Likes

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