MIRRI Pracovná skupina K9.3 Strategická architektúra

Pracovné skupiny
#5

Kratky zapis z 29.06.2017

  • diskusia o tom co moze ist do cloudu (rozhodujuce sa zdaju byt data a ich rezim) priklady: register ludi s infektcnymi chorobami, agenti na vnutre

  • identita - kazdy system to potrebuje ako sa zapojim

    • centralne vs federovany pristup
    • identita uradnika - eid vs. iny sposob (notari a sudcovia maju problem s eid)

  • nekonecna tema “formulare na slovensko.sk”

    • ked sa presunie vyplnacia cast (gui) na dodavatelov, tak je riziko, ze sa zatvoria systemy navonok (napr. validacia)
    • musi byt velmi jednoduche vypublikovat openapi (aby to nedopadlo ako formulare alebo DIZ)

  • open api

    • otvarat uplne vsetko je hlupost - treba hlavne prioritizovat ako v open data (na toto musi byt nejaky organ)

za OP EVS malo prezentaciu MV

  • ich pohlad na spolocne bloky
  • BPaaS vs. SaaS

Moje poznamky pod ciarou:

Idea spolocnych blokov podla MV je pre mna zatial velmi hmlista. Cisto z IT pohladu musia byt spolocne bloky “high cohesion, low coupling” inak to bude katastrofa integrovat. Preto ked si pozriete “spolocne bloky” z gov.uk, tak tam najdete notifikacie, autentifikaciu/verifikaciu identity, platby a koniec (cloud je IaaS/DBaaS a registre su SaaS). To, co maju tieto moduly spolocne je extremny low coupling. Platby su jasne ohranicene, notifikacie su este jasnejsie ohranicene (to je dokonca jednosmerne) a autentifikacia je jasne ohranicena (prihlasim sa, dostanem token a hotove).

MV na to ide uplne inak, snazi sa “refaktorovat” procesy. Potial dobre. Napr. predstava, ze bude spolocny blok “priestupkove konanie” na prvy pohlad znie lakavo, ale naozaj zivo si neviem predstavit ako sa na toto bude dat zaintegrovat. Pretoze z IT pohladu je tam hrozne vela vazieb (gui, prechody stavmi, permissions). Predstava, ze idem robit svoj IS a “sa zapojim” na spolocny modul priestupkoveho konania mi pride ako utopia. Nevidim pridanu hodnotu, naopak vsetko to hrozne skomplikuje. Pre porovnanie mi to pride ako sa snazit napasovat SAP modul na HR do uplne ineho systemu - napr. JIRA.

Iny priklad bolo vymahanie pohladavok, toto ma vraj aj procesne cele na starosti nejaka institucia. Tuto “spolocny blok” zmysel dava, kedze z integracia by vyzerala nasledovne “vystrelim poziadavku, ze chcem vymahat xyz eur kvoli abc”, institiucia to riesi, sem tam posle update stavu, na konci posle peniaze, ze hotovo. Medzi tym sa nic nedeje. Tolko zjednoduseny pohlad. Low coupling jasny.

@anton.janos a @juraj.bardy toto myslim riesite na digitalizacii agiend, aka je predstava, ze taketo “procesne spolocne bloky” sa budu integrovat do ISVS?

1 Like
#6

Obávam sa, že tak ďaleko nie sme…
Z 5ich zasadnuti sa metodika riesila na 2och, zvysne boli uz len o vyplnani dvoch stlpcov v tabulke, ktorou sa urcoval gestor (rozumej objednávateľ riešenia) zdielanej SaaS aplikácie RM_SaaS_v2.4.xlsx (50.4 KB) a to, ci je možné jej hybridné poskytovanie…

#7

@anton.janos, tento zoznam prešiel aj nejakým serióznym “sitom pripomienkovania/posudzovania”? Lebo ja sa určite hlásim pobaviť sa o zmysluplnosti/inom pohľade na niektoré položky. Hovoril som o tom aj s @juraj.bardy

#8

Pokiaľ viem, všetko v tej PS boli iba návrhy, ani nie draft celkového dokumentu. Pochybnosť o tomto prístupe mám aj ja.
Celkovo k uchopeniu témy SaaS, aj k rozdeľovaniu projektov takýmto spôsobom.

#9

Tak ako hovori @Lubor, zatial su to len navrhy, ktore ale mali byt vystupom PS.
S cim mam, o.i. ineho problem ja, je to, ze podstatou vystupu mala byt jasna a zrozumitelna metodika a nie dva stlpce v tabulke…

Na zamyslenie je aj fungovanie skupiny, ktore ak by sa dalo hodnotit od 1 do 5, tak trojka za organizaciu a aj za obsah (sorry @juraj.bardy, musime si vediet povedat veci na rovinu, viac osobne).

#10

V Rade vlády sa momenálne schvaľuje dokument Referenčná architektúra integrovaného informačného systému verejnej správy.
Tento dokument bol vytvorený v PS o ktorej sa diskutuje v tomto topicu. Nevšimol som si však, že by sa tu preberal draft a pripomienky.

Sú teda nejaké zásadné výhrady k dokumentu?

#11

Ja som sa k tomu dokumentu paradoxne dostal az teraz niekedy a spravim nieco co nerobim casto: Pochvalim!

Velmi chvalim:

  • decentralizacia - ais centricky pristup - ked sa pozrime do UK, hocikam, toto je cesta ako z pruseru von.
  • decentralizacia formularov (smerom k aisom) - centralizacia spolocnych modulov (autentifikacie atd) - ano ano. centralne maju byt support sluzby, take, ze to tvorcom AISov pomaha, nie ich to brzdi.
  • open api - bez debaty
  • velmi chvalim potrebu maximalne limitovat orchestraciu procesov.
  • kratky dokument, napisany ludsky

Komentare:

  1. Všetky asistované kanály (klientske pracovisko, IOM…) by mali byť zdokonaľované súčasne so samoobslužnými kanálmi.

Moj nazor na IOM je ze ten princip ako sa urobil u nas je uplne zly - asissted digital treba vyriesit autentifikaciou a splnomocnenim, nasledne ostava uplne vsetko rovnake. pridana hodnota - uradnik to vie ukazat, netreba robit duplicitne aplikacie (ktore nebodaj nemaju ani rovnakeho vlastnika).

“9. Oddelenie kontextového a obslužného významu termínu životné situácie”

Toto som nepochopil.

“10. Legislatíva nemôže byť bariérou pre efektívne procesné riešenia”

amen.

"Uvažovať o podpore životných situácií cez iné spôsoby (napríklad cez procesnú orchestráciu) je možné až keď sú možnosti tohto konceptu vyčerpané - podpora životných udalostí by mala primárne reagovať na zmenu údajov v zdrojových referenčných registroch. "

amen!

ad Frontendova integracia - rozumiem preco to treba, avsak (aj ked to bolo viac krat v dokumente spomenute, vzdy vzdy vzdy tu treba prizvukovat to, ako to najprv skusit urobit automatizovne. ak zacneme orchestrovat podania, pre obcana to bude vyzerat dobre (aj ked to bude pomale). Pre uradnika sa nezmeni nic. Neusetrime tam kde by IT malo setrit primarne skoro nic. Prestane byt verejny tlak na vylepsovanie, uradnici sa zblaznia a sme skoncili.

Celkovo: Som spokojny, hlavne ciele toho co aj my presadzujeme sa tam dostali.

3 Likes
Rada vlády Slovenskej republiky pre digitalizáciu verejnej správy
MIRRI Pracovná skupina K9.5 Lepšie služby
#12

Ja zopár pripomienok mám:
Ad: decentralizacia - ais centricky pristup - ked sa pozrime do UK, hocikam, toto je cesta ako z pruseru von
Áno, decentralizácia, ale nie smerom, že tvorca AIS vytvorí prostredie pre vypĺňanie údajov do “formulára”, teda doťahovanie dát, validácia, … bude zapúzdrená v komponente od tvorcu AIS. Ako sa potom budú dať tvoriť nové riešenia, podporovať nové platformy, … aj tretími stranami? Zakomponovať nejaký .NET komponent do appky na Android-e alebo iOS-e asi nebude moc použiteľné. Tiež integrácia do produktov tretích strán takto môže utrpieť (zoberme si že by MF vydalo komponenty na vypĺňanie formulárov daňových priznaní v nejakej webovej technológii a ničom inom (v dokumente sa spomína, že môže poskytnúť a nie musí aj metódy na získavanie údajov a validáciu aj inak ako cez ich komponent (“Samozrejme je možné tieto validácie sprístupniť formou web služieb z AIS-u do vyšších vrstiev …”).
Je treba metódy pre doťahovanie údajov a validáciu údajov sprístupniť povinne aj prostredníctvom API služieb.

Ad: decentralizacia formularov (smerom k aisom) - centralizacia spolocnych modulov (autentifikacie atd) - ano ano. centralne maju byt support sluzby, take, ze to tvorcom AISov pomaha, nie ich to brzdi.
Bola vôbec zvažovaná možnosť rozšírenia existujúcich technológií tak, aby centrálne komponenty nebrzdili tvorcov AIS ale im pomáhali? V pracovných skupinách komisie pre štandardy sa už preberali možnosti napríklad podpory xform pre formulárovú technológiu. Nebolo by lepšie zaviesť nejaké štandardné riešenie pre vypĺňanie formulárov, ktoré umožní všetko čo je požadované, ako umožniť tvorcom AIS-ov zabetónovať seba a svoju technológiu všade kde sa dá?

Ad: open api - bez debaty
Súhlasím. Cez open api by toho malo byť prístupné čo najviac, aby tretie strany vedeli bez problémov integrovať svoje aplikácie a tvoriť aj nové. A bez obmedzenia na “vybrané” technológie. Tento dokument síce spomína, že niektoré veci sa môžu sprístupniť aj cez open api, ale len môžu! Takže bude na tvorcovi AISu, ako sa zachová.

Ad: velmi chvalim potrebu maximalne limitovat orchestraciu procesov.
Toto som tam akosi nenašiel. Ak tým myslíš, že sa snažia dať do popredia dátovú integráciu pred procesnou, tak to tam je. Ale procesná integrácia nie je len o kompozitných službách, ako sa snaží dokument podľa mňa navodiť.

Ad: kratky dokument, napisany ludsky
Áno, dokument je krátky, ale umožňuje rozličnú interpretáciu niektorých častí. Takže každý si tam nájde to čo chce.

2 Likes
#13

@kyselat urcite potvrdi, ze toto bola moja prva reakcia, ked som robil “diablovho advokata”. Taky je plan a myslim, ze sa to riesilo uz aj v dokumente SP integracia orchestracia. Vid
image

Lenze ten problem je principialny, ak mas domenovo specificku validaciu (biznis logiku) v AISe, tak vytahovat ju do nejakeho centralneho komponentu je imho hlupost. Uplne zbytocna duplicita a nema to velmi ako lepsie fungovat. Neviem co ste riesili na PS v standardizacii, som otvoreny napadom ako z tohto von. Snazit sa vytvorit nejaky formularovy framework, ktory bude lepsi vonavejsi je imho pre stat nemozne z principu. Technologie (a frontendove duplom) idu tak extremne rychlo dopredu, ze neni sanca drzat krok. Rozhodnutie robit ‘soft’ standardizaciu na urovi UX/dizajn manualu povazujem za ovela jednoduchsiu a realizovatelnejsiu.

Vid vyssie, ale suhlasim. Ono zase opacny extrem a paralela s open data je tu na mieste. Chceme najskor api, ktore ma zmysel. nie ekvivalent api k datasetu o uskladneni jablk a hrusiek.

Rozvin tuto myslienku, nerozumiem.

Ja som si nasiel, som spokojny. :smiley: Niekedy mam pocit, ze by chceli ludia dokument kde je vsetko jasne, ale teda zase nie moc, aby to moc nezvazovalo, mal by byt kratky, ale teda hlavne tam ma byt vsetko. :smiley:

1 Like
#14

Ano, potvrdzujem - je to od začiatku tak (zachytené už aj v dokumente SP Integrácia a orchestrácia) - v tomto kontexte je v dokumente Referenčnej architektúry IISVS, v princípe č.3 (na záver) uvedené nasledovné:

Tým sa zabezpečí, že všetky služby, ktoré táto vrstva potrebuje, budú automaticky z AIS-u dostupné aj pre iné kanály, napríklad pre OpenAPI

#15

Inak pravda je, ze tych dokumentov je tak strasne vela, ze hladat to tam mam uz problem aj ja. Co som vlastne bol pri ich tvorbe od zaciatku.

1 Like
#16

To snáď nemyslíš vážne. Kto z tohto vyčíta, že je povinnosť poskytovať tie služby aj prostredníctvom open api? Buď neviem čítať, alebo som sa už načítal takýchto dokumentov natoľko, aby som si to vedel vyložiť aj tak, že toto mi nič vlastne neukladá za povinnosť?

#17

No, keďže je to v “kontexte toho, čo je napísané v dokumente SP Integrácia a orchestrácia” (viď Janov post) tak si musíš (chcieť) prečítať aj ten. Čo je presne nezrozumiteľné na “Špecificky všetky služby IS, ktoré sú dostupné cez grafické rozhranie, majú byť dostupné aj otvoreným aplikačným rozhraním”?

#18

Aka je pak predstava z pohladu toho co by malo tvorit eformular ? z tohto navrhu je zrejme ze editacna transformacia by tam nebola, nuz ale pak nam tam zostavaju transformacie - podpisova, html, pdf,… tj pokial balik eformulara bude mat len suvisiace dokumenty pre prezentaciu datovej XML struktury tak to uz nie je formular v pravom zmysle slova.

Myslim ze dnes nie je hlavny problem na UPVS editacna transformacia, ked uz tak problem je technologia ktoru UPVS pre editacnu technologiu si zvolilo a jej obmedzenia ktore sebou priniesla. V tom case vsak ziadny projekt tohto typu realizovany nebol, tym chcem povedat ze nebolo na com stavat. Casom sa zial ukazali nedostatky , tie vsak mam pocit ze je snaha riesit opacnym extremom. tj nech si to kazdy realizuje jak chce…

V podstate to co sa tymto navrhom popisuje je len existujuci stav kde uz teraz je hromada proprietarnych rieseni kde si vyplnaju eformulare vylucne na institucii, nerozumiem teda revolucnosti tohto vnimania

Nepaci sa mi tvrdenie ze standardizaciu staci realizovat na soft urovni UX/dizajnu, ked prehnity dom pekne vymalujem tak neznamena to ze sa mi nerozpadne. Tym ze bude v ramci statu kazda organizacia pouzivat vlastne riesenie postavene na proprietarnej technologii sa skorej ci neskorej dostane nejaka organizacia do stavu ze ten system bude prerabat na iny, napr aj z dovodu ze spolocnost ktora system dodala uz danu instituciu nebude mat ako vyciciavat a prestane mat zaujem o dany system - to sa tu uz na viac projektoch deje…

technologie akekolvek idu dopredu, uvaha o tom ze nestandardizovat nejaku technologiu len z dovodu ze bude niekedy nahradena inou nikoho nikam neposunie. Pak netreba standardizovat ani HTML, XHTML a pod…

Dnes na UPVS je hromada eformularov, ktore riesia kdejake spolocnosti a velka mnozina z nich nebola vytvorena v UPVS technologii, je uplne jedno aky dovod to bol, tj ci uz komplikovanost vyvoja daneho formulara, nemoznosti implementovat sofistikovanejsie formulare a podobne. Proste tie formulare ktore sa dodavaju na UPVS a nie su v eform technologii su mnohokrat chybne v uplne inych veciach. HTML vizualizacie su chybne, PDF vizualizacie nei su XSLT subory, podpisove transformacie su plain text subory - vobec nie XML,XSLT, proste dummy text… V reale teda uvaha ze kvoli “sofistikovanosti formulara” je lepsie spravit jeho vyplnanie len na ISVS je uletena pokial dodavatel nie je schopny spravit ani ine dokumenty - ovela jednoduchsie dokumenty z pohladu implementacie, tj HTML vizualizacia a podobne

Na druhej strane eformulare maju podporu aj na predvyplnanie, v ramci UPVS aktualne sice sluzba MEF predplna len vybranu mnozinu udajov z IAM, avsak ta podpora bola nastavena tak eform balik v ramci slovnika vie kategorizovat datovy zdroj. To ze UPVS tuto podporu nerozvijalo je druha vec… Priklad tohto vyuzitia mame na MHSR, kde eformulare sa predplnaju z niekolkych datovych zdrojov, tj IAM pre ziadatela, zastupujucu osobu, dalsiu instituciu vstupujucu do procesu, dat z backend systemov a podobne. Jo obmedzenie UPVS ze nepodporuje externe datove zdroje pre vyplnanie nam zial nedovoluje formulare prevadzkovat na UPVS a mame ich u seba a jasne nie su to formulare vo verzii eform dizajnera 1.18 ale v2 ktory ma par veci naviac ale generuje aspon cca. rovnako “kvalitny” balik . ale toto je zas ina diskusia preco … zial kazdopadne je to uzavreta technologia z pohladu editacnej schemy aj preto je vnimana negativne.

Poprosil by som ak ma niekto priklad nejakeho formulara, ktory proste nevie spravit inak ako vo vlastnej rezii vo vlastnej technologii ak moze mi nejaky taky form ukazat budem mu vdacny, pokusil by som ho spravit ako xforms aby som prezentoval ze je aj ina cesta. fakt nenasiel som doposial ziadny taky co by sa nedal spravit. Stretol som sa na jednom projekte s pripadom ze sa realizuje eformular na inej proprietarnej technologii a mam pocit ze formular co sa da spravit za tyzden sa realizuje mesiac

btw ak sa pozerame ako to robia mimo SR, nuz napr tie xforms su pouzivane ministerstvom financii v Polsku, v statnom sektore v Taliansku a Uruguay, pouziva ho napr aj system Svajciarskeho socialneho zabezpecenia…

Zákon o e-Gov - novela 2017
#19

Predstava je nasledovna - z formularov ostane len ten vymenny format (kontainer ci ako sa to vola) a html vizualizacia (kvoli schrankam) povinne. Tym sa zabezpeci, ze zobrazit to nejako bude vediet hocikto a zaroven vymenny format bude relativne standardizovany a strukturovany.

Toto je ale zle prirovnanie, lebo HTML, XHTML je uplne na inej urovni. Tu sa snazite standardizovat nieco ako boostrap alebo foundation + k tomu vsetky mozne aktivne interakcie. Ja to povazujem za extremne zvazujuce a tlaci to dodavatelov do jednej technologie (jedno ci proprietarnej ci nie).

Ta otazka ktora tu neustale nepadla je… preco povazujeme tuto centralizaciu za dobry napad? Ja som patral po tom, ze odkial tato idea centralizovanych formularov vlastne vznikla a ta historia mi bola prezentovana nasledovne: Existuje mnozstvo subjektov, ktore by chceli komunikovat elektronicky ale nemozu/nechcu robit vlastne sidlo, podatelnu, etc. Pre nich bol vymysleny form designer kde si primitivny formular vyklikaju a mozu zacat fungovat s UPVS. Koniec. Toto dava zmysel, ale absolutne to nedava zmysel pre OVM kde su zlozite interakcie vo formularoch (viackrokove, dynamicke, kadejaka logika).

Z mojho pohladu je toto jednoducho regulacia, ktora len obmedzuje konkurenciu. Firmy dnes v komercii ficia povedzme na react/angular/ember/… vlozili do toho velke investicie a maju v tom skusenosti a my tu ideme vymyslat nejaky frontendovy framework na formulare lebo… preco vlastne? Bude to po nich niekto prerabat? Bude to opensource? Proste nevidim vyhody.

Ked si pozrieme US, UK, AUS tak vsetci idu soft regulaciou na urovni dizajnu lebo to pre koncoveho “vyzera rovnako” ale vnutro je uplne hociake a v hocicom.

Toto je velmi zaujimava ponuka. Podme to skusit: @vojtob @anton-somora @kyselat ? Vy ste v tom zbehlejsi, dajte (proti)priklady.

Elektronické služby v treťohorách
#20

nespravna uvaha, prosim pozrite si https://www.w3.org/TR/xforms pripadne https://www.w3.org/community/xformsusers/wiki/XForms_2.0

Dokument definuje xforms a popisuje ako ho mate implementovat. nedefinuje vsak technologiu aku mate pouzit na implementaciu tohto standardu.

Implementacie su rozne, je implementacia komercna v IBM , implementacia opensource orbeon, viete si spravit vlastnu implementaciu napr s pouzitim angular a podobne…

Tj je zmyslom standardizovat implementaciu ale definiciu, implementaciu nech si kazdy naprogramuje aku chce, podstatne je aby dodrzal nejaky definovany standard.

XForms berte ako priklad, je uplne jedno aky iny standard by sa spravil, pokial niekto o lepsom vie kludne nech ho prezentuje. Ja sa domnievam ze lepsie je implementacia zalozena aspon na nejakom standarde ako anarchia resp stav ze stat na miesto jedneho nekvalitneho eform riesenia zaplati dalsich 20 proprietarnych nekvalitnych rieseni ktore su vzajomne nevymenitelne

#21

Ale tá “regulácia” ale má aj svoje výhody. Napríklad systém IOM si naintegruje jednu centrálnu formulárovú technológiu, ktorú napojí prostredníctvom API GW na poskytované služby jednotlivých poskytovateľov a môže riešiť všetky typy podaní bez toho, aby bol nútený integrovať kvantá rozličných technológií dodaných rozličnými dodávateľmi AISov.

Nikto pritom ani teraz nenúti, aby si poskytovateľ služby nepoužil svoju vlastnú technológiu na formuláre. Ale poskytnúť aj túto jednotnú (regulovanú) formu má aj svoje výhody.

#22

Mimochodom, tá regulácia sa dotkne aj jednotlivých AISov, ktoré, ak budú potrebovať prostredníctvom svojho AISu riešiť podania voči iným AISom (poskytovateľom služieb), budú musieť integrovať komponenty tých cieľových AISov. Čiže to vlastne bude také krížové používanie komponentov ostatných AISov.

#23

kde vnimate regulaciu ? na UPVS je 25% eformularov, kde institucie resp implementacne spolocnosti pouzili vlastnu technologiu, tj kde na urovni institucii su uz dnes pouzite proprietarne technologie.

Pekna otazka "Bude ich prerabat ?"
Viete je tu ina diskusia kde sa uvazuje o tom ako ma vypadat “jednotne” eformular z pohladu toho kde bude napoveda, ako sa ma zobrazit chyba a podobne. mate pocit ze ked sa toto standardizuje tak co bude s existujucimi cca 3500 eformularmi ktore sa pouzivaju ? tie bude niekto prerabat ? mate predstavu kolko kapacit/financii to v ramci tych projektov v SR bude ? Viete aky financny dopad by malo zmenenie hoc i jedneho eformulara, napr dorucenky ?

Na margo tohto pouzitie napr jednotnej technologie napr. xforms nevylucuje to aby formular nepredplnala institucia u seba a nie v UPVS. Tu hlavny message bol ten aby sa nerobilo desiatky rieseni ktore kazde funguje inak. Pretoze pokial do tohto strategickeho planu opisete stav ako to v reale dnes funguje tak ste sa nikam neposunuli, proste len opisujete realitu ako to tu funguje par rokov

#24

Napriklad ten system IOMO sa uz aj niekde pustil? Kde to bezi a co to vie? Mozem to vidiet? Na poste ocividne bezi nieco co si spravila posta davno predtym sama a vie to tie 4 vypisy. Na to naozaj elektronicke formulare robit netreba. Ja osobne tak ako je IOMO povazujem za uplne nepochopenie toho co to ma vlastne robit assisted digital. Ale to je ina tema.

Nejake dalsie vyhody?