Problem: Treba novy register. Ako casto treba novy register? Castejsie ako by sa zdalo. Napriklad:
Vzniknúť by mal aj Centrálny informačný systém štátnej služby pozostávajúci z viacerých registrov (registra výberových konaní, registra úspešných absolventov, registra nadbytočných štátnych zamestnancov, registra štátnozamestnaneckých miest a registra štátnych zamestnancov). Nový zákon o štátnej službe má priniesť väčšiu profesionalizáciu a odpolitizovanie - SME
Pricom velakrat z datoveho hladiska naozaj v principe ide len o prilepenie zopar tabuliek k existujucemu referencnemu registru. Biznis logika registra je z velkej casti takmer smiesna CRUD aplikacia, pripadne s nejakym workflowom na schvalovanie, pripadne pridelovanie nejakeho ciselka - vid pridelovanie ICO/IPO v registri pravnickych osob.
Ake su moznosti taketo nieco vybudovat?
Spravime to na zelenej luke, kazdy register inak. Dnesny stav.
Prilepime to k existujucemu registru. Do velkej miery nerealizovatelne kedze “nove data” registra bude mat asi ineho gestora. Plus zabetonovavanie existujuceho dodavatela registra donekonecna. Podobne riziko vidim pri CSRU.
Urobime genericky register, rozsiritelne jadro, ktore bude mat vsetko co register bezne potrebuje, to dame ako opensource von. Rozbehnutie noveho registra bude otazkou konfiguracie a trochu vyvoja custom funkcionality. Vsetky registre budu mat rovnake API.
Aku by to malo mat funkcionalitu?
moznost zadefinovat objekty
zakladne CRUD operacie, historia zmien.
open data modul - napriklad export do data.gov.sk
napojenie na UPVS - podania, vypisy do schranky etc
nejakemu tomu podpisovaniu vypisov ZEPom sa urcite nevyhneme
konfigurovatelny workflow
backoffice pre spracovanie podani - v klude napojenie trebars aj na JIRA
“pluginy” na integracie na ine referencne registre na “jeden klik”. Napr RPO, RA, RFO atd.
V principe to moze byt aj nejake CMSko typu Drupal.
Utopia? gov.uk robi nieco co sa vola OpenRegister openregister · GitHub, ale skor ako zacneme skakat od radosti, tak si treba pozriet zdrojaky a clovek rychlo zisti, ze to vlastne nie su ani tak registre ako akesi jednoduche ciselniky, ktore operuju nad velmi jednoduchou metatabulkou (co je imho rychla cesta do pekla). Vyzera to takto https://country.register.gov.uk/
Co Vy na to? Je este nejaka funkcionalita, ktoru by to malo mat? Ake vidite rizika? Kto to so mnou naprogramuje ako opensource a ponukneme to statu, aby sme uz nikdy v zivote ziadny register neobstaravali?
Teraz budem ironický, ale to som naivne predpokladal, že to je základom informatizácie - referenčný register napojený na eID ako základ a k tomu prilepené tabuľky, v ktorých by v podstate boli len údaje, ktoré už nie sú v ostatných prilepených registroch. Teda jeden krát a dosť aj na dátovej strane. Nech si ďalšie IS robia vlastné pohľady nad dátami ako potrebujú. Ale to zjavne by bolo dosť lacné, takto to riešiť
viem si predstavit, ze z existujucich IS by sa dali vyextrahovat aj vyssie popisovane funkcionality…napr. taky ten konfig workflow, pekne urobene podpisovanie, atd
Z Tvojho zoznamu je zopár vecí čo by mali mať štandardné implementácie aj mimo projektu generického registra:
“napojenie na UPVS” a “pluginy na ref. registre”:
Toto je jasný kandidát. Plus integrácie zamerané na synchronizáciu údajov by mali prejsť na silne štandardizované jednoduché API.
“open data modul”:
Na to jedno generické riešenie už je implementované, v rámci projektu eDemokracia, postavené je to na báze OpenDataNode z prj. Comsode, @hanecak vie o tom všetky detaily. Táto aplikácia je voľne dostupná pre každý úrad.
“nejaké to podpisovanie”:
V zásade na overenie podpisu, pečať a časové pečiatky to je štandardný komponent “elektronická podateľňa”, do budúcnosti by to teda mala byť jedna konkrétna centrálna elektronická podateľňa na ÚPVS. Podpisovanie osoby (úradníka) sa robí krabicovým softvérom na PC.
Pozrime sa, čo zostalo - jadrové veci:
“konfigurovatelny workflow” + “backoffice na spracovanie podani”:
Toto je v podstate ľubovoľný vhodne customizovaný DMS. Treba to prepojiť s registratúrou organizácie, alebo to spĺňa parametre na registratúru samo. Takéto predpripravené riešenia aj existujú. Je to kľúčový komponent pre efektívnu prácu úradníka. Čiže to musí byť spravené čo najviac upravené pre danú agendu, plus pre SW prostredie daného úradníka. Vrátane “drobností” ako autentifikácia, riadenie prístupu, UX.
Viackrát som videl ako použitie customizovaného generického nástroja bolo v protiklade s efektívnou/pohodlnou prácou úradníka (podľa ich vlastných hodnotení).
“moznost zadefinovat objekty” + “zakladne CRUD, historia zmien”:
A toto je zasa ľubovoľná databáza, keďže register je vždy (až na výnimky) sada tabuliek, tak relačná. Štruktúra objektov je vždy iná (pokiaľ sa registre príliš podobajú niekde sa stala chyba). Máločo sa tu dá zmysluplne genericky predpripraviť.
Hm, celkom si to viem predstaviť. Otázka je, koľko práce by vyžadovalo dorobenie pre konkrétny register. A následné riešenie servisu centrálneho/generického riešenia vs. servis inštancií.
Chalani, vaše úvahy by isli spravnou cestou za predpokladu, ze by dane projekty naozaj riesili len samotne registre.
Z pohľadu informarizacie je to však malo, aby to malo aj ten reformny prvok, musia tam byt elektronizovane tzv.obslužné cinnosti vyplyvajuce zo zákona a často ak organizácia nemá dostatočný backoffice, tak aj toto.
Zial cesta jedného riešenia pre cely stat bola nacrtnuta v rámci NKIVS1 ale zlyhala a pretromfol ju rezortizmis (vid využitie spolocnych modulov upvs), takže kazdy ma iný systém. Co by nebolo na škodu, ak by platilo:
maju standardizovane rozhranie na svoje okolie
sú efektívnejšie vybudovane ako iné riešenia
sú udrzatelnejsie a prinasaju pridanú hodnotu.
Kazd register totiž ma okolo seba aj ďalšie procesy, ktoré by mal projekt registra elektronizovat. Casto však prave tym, ze sa to rozkuskuje na také obsluzne procesy, iné procesy a register podla mna dochádza ku komplikaciam. Typickym pripadom sú RPO a zdrojove registre (živnostensky, orsr, reg.neziskoviek a oz atd…), to iste regop rfo ifo a pod…
CISŠ v skutočnosti ako som pozeral reformny zámer a návrh zákona o štátnej sluzbe, registre ss zda ze nie sú len jediná vec, majú tam aj iné veci co chcú robiť a zrejme podla návrhu zákona toho tam bude úrad vlády ako prevadzkovatel musiet procesov elektronizovat dosť.
No ved skusme co by to bola taka obsluzna cinnost a ci si to tam nevieme predstavit. Mojou pointou nebolo oddelit register ako datove ulozisko a vsetko ostatne dat niekde inde. Len ta agenda sa podla mna z velkej casti opakuje.
Dalsia vec je rezortizmus vs spolocne moduly. Krasa tohto riesenia z UK je, ze kazdy register si vlastne zije svoj zivot. Len pouizvaju spolocne jadro na urovni kodu - nie nejaka SaaS sluzba. Tam sa mozno dostanu potom, ale nie je to nutne na uvod.
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.
