Nerozumiem uplne preco prechadzaju na toto, napadaju ma vseliake dovody - centralizacia analytiky, zdielanie cookies, pouzivatelia mozno boli zmateni z inej subdomeny (netusim).
No asi by sme mali rozlisovat FE a server-side end-pointy. Co sa tyka end-pointov tak podobny scenar uz mame porkyty v ramci MC a IaO, ci ?
API GW zakryva centralne a agendove front-office mikrosluzby, cez ktoru su standardizovane vystavene do kanalov. Tzn. teraz ten routing vykonava API GW, ale ako standardny middleware (bez dodatocnej biznis logiky, robi nativne funkcie). Ak sa rozhodneme ten routing dopnit o nejake biznisove funkcionality napr. aproximacia cookies, vieme takuto proxy posunut nizsie do centralnych mikrosluzieb ako end-point a z nej realizovat routing.
K tym FE a publishingu contentu - vyzera to zaujimavo, mohli by sme to prejst na PS. Ked sa pozries tak modre stickers su apps a funckie, tak je to trocha Archimate…
Podla mna toto je cisto o frontende a je to len reakcia na tu vec z PS - “Budeme mat lepsie hodnotenie, ked to bude na jednom portali.” – pricom koncoveho pouzivatela to podla mna vobec nezaujima, jeho zaujima ci to je konzistetne (vyzera a sprava sa to rovnako = dizajn manual) a az potom mozno niekde v dialke riesi, ze ci to je rovnaka url.
API pokial spravne pozeram oni vobec necentralizuju (mozno tam pridu).
Ano, prave som to precital… Pokusim sa nieco z toho pripravit na ten workshop k centralny vs. specializovane portaly a ako by ta interakcia a redirect mohol vyzerat z pohladu FE.
Existuje malá skupina služieb štátu, ktorá si vyžaduje osobné overenie jej iniciátora (žiadateľa/navrhovateľa). Samozrejme, okrem overovania totožnosti kvôli dvom dokladom totožnosti - pas a eID, ktorá je nevyhnutná.
Tou prvou je zapis do katastra nehnutelnosti a druhou do evidencie vozidiel. Obidve by v normalnejšej spoločnosti mohli byť od iniciácie až po výstup, realizované plne elektronicky, ale keďže u nás sa podvádza aj v listinnom svete, tak na tieto dva úkony by som stále vyžadoval osobné overenie notárom/úradníkom.
Problémom zapisu do katastra nehnutelnosti nie je problém samotného vkladu, ale byrokratický vstupný formular, ktorý brani zjednoduseniu celeho procesu…pritom by stačilo málo - jednoznacny identifikátor nehnutelnosti a tým by sa vstupne udaje zostihlil o 3/4…
Z toho mne vyplyva ze to je v uplnych zaciatkoch, cize dalsi rok sa bude definovat a potom sa zacnu riesit IT projekty? Akoze moja spatna vazba je, ze treba aspon vylepsovat co uz existuje a nestavat si vzdusne zamky. Nehovorim, ze som spokojny s tymi sluzbami ale vyuzivam ich a ocenil by som keby sa kontinualne zlepsovali.
Zle som sa vyjadril. MV toho ma uz (podla ich slov) vela spraveneho, ale niekedy naozaj nie je zrejme kde je zaciatok ZS. Lebo z pohladu OVM to vyzera inak ako z pohladu cloveka. Napriklad narodenie dietata. Zacina to pre cloveka ovela skor ako narodenim. Vid https://smartstart.services.govt.nz/
Tehotenstvo je samostatná životná situácia - skús www.modrykonik.sk - majú namapovane jednotlive etapy a pomerne slušne.
Samozrejme je to iba stará škola, my sme pri metodických pokynoch ďalej - pri IoT, cloud a Big Dáta a jednoducho toto treba zohľadniť!
V eHealthe musia byť záznamy ešte nenarodeného dieťaťa, BI spolu AI budú vedieť vyhodnocovať pripadne rizika, choroby, buďme vedieť predikovať a chorobnosť populácie ako celku.
A narodením plynule prechádzame do novej životnej situácie …
What you’re seeing there is two different types of services.
The “settle in the UK” page takes you into what we called a “smart answer” - it’s a simple decision tree to help you navigate to the information relevant to you. Those are hosted within www.gov.uk and the traffic is directed by the GOV.UK router to the right microservice within GOV.UK.
Transactional services (which loosely means those that collect users’ data) are run by the departmental teams responsible for them. They sit on subdomains of service.gov.uk which allows us to delegate domains to the relevant service team and make use of browsers’ security separation to keep the services independent.
Does that help?
a
The smart answers are run by GDS, they don’t collect anything we considered personal data, and the only state they maintain is in the URL, which all makes it easy to run as part of the main www.gov.uk service.
The transactional services are mostly run by different departments around government and it’s very helpful to have them more clearly distinct. While we could in theory have proxied www.gov.uk/transaction-name to the transactional service, doing that would mean the GDS team would need to handle a lot of operations for the hundreds of government agencies running the services. It would also mean that cookies created for one service would be accessible across all of them (something that it was very important we avoid to meet our privacy and security principles) and introduce a few similar security dependencies.
If the government estate were significantly smaller or was already running in a more consistent way we might have made a different decision, but this was the best compromise we could find.
Takze suma sumarum. Router pouzivaju len na interne veci co ma pod kontrolou priamo tim GDS. cc @ret
Za SUXA prezentoval @michalblazej a Martin Krupa ich pohlad cestu pouzivatela ako pre prechodny tak pre cielovy stav. V skratke (pripadne nech Michal sem hodi ich prezentaciu)
navrhuju vytvorit podstranky pre zivotne situacie ktore budu pre normalnych ludi s odkazmi na jednotlive podania.
navrhuju pridat pri prechode na podanie specializovany portal hore dat nejaky pasik, nech to aspon vyzera, ze clovek je na slovensko.sk a co robi. (Upozornil som, ze ked toto nebude iframe, tak to znamena change request na vsetky statne weby ktorych sa to tyka)
navrhuju sa zamerat hlavne na texty, dizajn je druhorady. problem je taxonomia a pouzivanie domenovo specifickych nazvov, ktore ludia nepouzivaju
Nasledne bola prezentacia pana z NASESu, ktoru som velmi nepochopil. Podla mna by sa toto malo riesit skor na PS architektura. Z toho co som pochopil:
cielovy stav je, ze podania/resp. zivotne situacie sa budu riesit orchestraciou alebo idealne propagaciou eventov. kym sa tam dostaneme bude potrebne vela formularov previest do nejakej rozumnejsej podoby ako dnes (nechapem uplne preco)
prechodny stav ma byt ze sa budu do centralneho uloziska (asi formularov) budu namiesto formularovej technologie pouzivat single page apps (SPA), ktore - tak ako v pripade formularov - dnes robi dodavatel agendoveho systemu. Je logicke, ze to ma robit dodavatel agendoveho systemu, pozna celu domenu, biznis logika je u nich, etc.
kontainerizacia - toto som vobec nepochopil. cielom ma byt vytvorit nejake lahke kontainery - v nich mikrosluzby, ktore sa deploynu napriklad k IOM a budu tie potom SPA aplikacie pouzivat. Proxy v kontaineri bude volat vseliake interne veci z govnetu. Toto ma byt variant kym sa spravi API gateway.
riesil sa autosave (ukladanie rozrobeneho podania) - dlha diskusia s nejasnym zaverom.
potom som musel odist, dieta v skolke nepocka.
Moje poznamky k tomu:
SPA - Z mojho pohladu to neriesi vobec nic a je to prilis velka zavislost na technologii. Co sa tyka SPA, som konzervativec - su vhodne na “high-fidelity” apps (nieco co sa defacto sprava ako desktopova app) a offline apps. Nic z toho podla mna podanie ani ZS nie je. Ak ma byt formular inteligentny, tak bude musiet ist do online validacii a dotahovanie dat a nakoniec sa to aj tak cele online centralne podpise. Vobec nic sa tym neziska.
Kontainerizacia: Asi velmi nestastny nazov, kedze je to len forma deploymentu. Pointa - ak to spravne chapem - bola urobit nejake proxy co bude prekladat kosate SOAPoviny na nejake normalne REST API pre SPA. Ak si odmyslime to SPA, tak v tom problem velmi nevidim, ale nevidim taktiez zmysel preco by sa toto nemohlo nasadit niekde na nejaku subdomenu register-a-agenda-adries.slovensko.sk/api a nech si to tam odtial vola hocikto. Bezne to takto funguje na celom internete, treba len doriesit ziskavanie access tokenov.
Z celej tejto “haluze” okolo SPA a kontainerov som mal pocit, ze sa ide hackovat cely system kvoli projektu IOM a UPVS. Podania resp. zivotne sluzby sa maju robit v nato urcenych agendovych systemoch a tie zabezpecuju cely pouzivatelsky zazitok (resp. v pripade ZS vystavia von sluzby cez open api a orchestruju o level vyssie). IOMO je zo svojho principu - zastupovanie osoby - cize … open API. Cize nie vsetci sa maju prisposobovat IOMO, ale jedine co treba je, aby pre vsetky sluzby podani (ci uz cez gui alebo systemove volania) bolo dostupne zastupovanie. To sa da vyriesit na urovni prihlasenia cize tipnem niekde pri UPVS IAM (WS-Security + on behalf of tam je, pripadne openid connect) alebo priamo na MV. Teta za prepazkou pre IOMO sa proste prihlasi za obcana, a pracuje s potrebnou aplikaciou ako kazdy iny obcan. Ak IOMO ma byt nejako optimalizovane (nevidim uplne dovod) tak nech si to to GUI urobia ako kazda ina tretia strana sami. Nebudu vsetci im stavat SPA a tlacit to centralne, aby s tym nemali robotu.
Autosave - stale si myslim, ze tu sa miesaju dva koncepty. jeden je naozaj autosave - ked nieco rozrobim a chcem to dokoncit neskor. toto si podla mna riesit kazdy agendovy system sam a len tam kde to ma naozaj zmysel (imho uzky scenar). druhy scenar je napriklad podpisovanie viacerimi konatelmi (na toto by bolo ovela lepsie dat do centralnejho komponentu ktory bude riesit autorizaciu podani (to sa tak ci onak musi spravit)), scenar, ze si nieco chcem podat a musia to podpisat traja. Tak sa vytrhne len tato cast autorizacie do centralneho bloku, nie komplet autosave - bolo tam viacero vyhrad, ze toto extremne skomplikuje robotu vyvojarom ak by to bolo centralne.
Highlight stretnutia: Miso nevedel najst kontektor na projektor a po chvili behania zadrel “Fakt som ho tu mal… Sa tu asi kradne.”
Mal som možnosť zúčastniť sa stretnutia, tak doplním niekoľko poznámok.
Na PS Architektúra sa (zatiaľ interne) pripomienkuje dokument “referenčnej architektúry IISVS”, ktorý sa problematike eFormov tiež v nejakej miere venuje. Základným princípom (a chcem zdôrazniť že v tom sa s Janom plne zhodujeme) je, aby tvorca služby dostal “maximálnu” (pod maximálnou rozumej programátorskú) kontrolu ako pripraví UI vypĺňania podania nad svojou službou. Iba tak sa dostaneme k službám, ktoré budú asistovať vo vypĺňaní tak, ako keď mi asistuje dobrý portál pri rezervácii hotela (dáta ktoré o mne vie si nepýta, rezervácia je rozdelená do jednoduchých (aj vizuálne) logických krokov, podľa toho čo si objednávam (a čo o mne portál vie) si postupne volím doplnkové služby, platiť môžem výberom zo spôsobov, ktoré som už predtým použil a pod.).
Najjednoduchším riešením je, že toto povolíme (zviažeme tvorbu UI len soft-ovo - metodikou, dizajn/UX manuálom, prípadne open knižnicou grafických prvkov - na štýl gov.uk). Problém je, že toto zrejme nesedí do IOM a ÚPVS, resp. hlavne do IOM (podľa pripomienok čo som dostal). A vždy musíme myslieť aj na tie PO, ktoré vlastný systém nemajú, programovať UI nebudú ale služby nejaké majú a potrebujú ich publikovať. Pre tie poskytuje dnešný eForm akúsi podporu - problém je, že (technologicky) proprietárnu. Takže skúsme zhodnotiť kam sa týmto riešením dostaneme. Kto chce bude si programovať UI na svojej infra (môže využiť SPA, môže využiť iný koncept). Kto nechce využije proprietárny eForm ako je dnes. Predpokladajme, že sa UPVS/IOM upravia tak, aby vedeli využiť oba spôsoby (dnes myslím ak chce vlastník služby naprogramovať rozhranie, musí ešte minúť v projekte peniaze na publikáciu do eFormu - predpokladajme, že tohto sa nám podarí “zbaviť”). Budeme udržiavať štandardné prepojenie (metodika, technológia) prepojenia z centrálneho bodu na rezortné portály, platiť prevádzku UI rezortných portálov (na niečom to predsa bude bežať a bude sa o to treba starať) a zároveň inovovať a rozvíjať proprietárnu eForm technológiou. Vôbec mi to neznie hospodárne. Naopak, znie to ako dosť veľa prečerpaných peňazí, ktoré by sa zišli inde. Pozrime sa na inú alternatívu.
Povedzme, že vlastníci služieb si môžu naprogramovať UI ale A) Povinná jazda - sú to otvorené technológie, nezvýhodňuje to výrazne len niekoho kto pozná proprietárny kód (checked - SPA), B) toto UI nepotrebuje pri svojom behu vyťažovať akúkoľvek infraštruktúru - pretože beží v prehliadači klienta tak aby si nemusel nič inštalovať (HTML5/CSS/JS - checked) a za C) toto UI je rovno prepoužiteľné aj na ÚPVS/IOM (zase nezaťaží infra, takže neospravedlní veľké nákupy), resp. už sa tieto projekty (a organizácie za nimi) nemôžu tváriť, že najlepšie bude ak UI k službám budú robiť výhradne oni - checked (a toto je na nezaplatenie).
Ja osobne nesúhlasím s názorom, že SPA je len “huncútstvo” pre špeciálne prípady. Bežné formulárové = zadávacie - appky, či už pre utility alebo pre finančné inštitúcie (úplne hardcore sú poisťovne) sa už robia cez SPA. Vynútil si to používateľ, ktorý chce komfort okamžitých odoziev pri modelovaní cien poistného, prognózy faktúry za elektrinu pri rôznom nastavení doplnkových služieb (ako inteligentná domácnosť) a pod - tých prípadov je x. Samozrejme hovorím to len za seba, z mojej skúsenosti - ale tá je, že ak by sme sa na SPA ako dodávateľ neprispôsobili dostatočne rýchlo, tak by sme o niektoré existujúce príležitosti prišli a niektoré nové nezískali. Takže v komerčnom svete sa koncept SPA presadil už širokospektrálne (nie len pre služby ako Facebook).
A este by som doplnil ze tymto pristupom prinutime by default vystavovanie APIs ci uz z centralnych alebo agendovych IS, cim opat utilizujeme aj koncept OpenAPI.
Co sa tyka SPAs a technologickych platforiem pre aplikacie typu FE, suhlasim ze su velmi dynamicke, ale ak budeme mat upratanu servisnu architekturu FE sa da vzdy prerobit do toho co bude v danom case ficat…
Ahojte, presli sme si toto v SD interne. Tu su nejake otvorene otazky a veci co potrebujeme na skupine bud ps arch alebo ps lepsie sluzby otvorit.
Všeobecne
Často dochádza k neefektívnemu vysvetľovaniu, kedže nie sú jasne spísané používateľské scenáre a požiadavky (viď formuláre a IOM), ktoré má cieľový stav podporovať.
Tieto scenáre treba následne komunikovať primárne do skupiny PS architektúra, prípadne s navrhnutými variantami riešenia. Oni sú zodpovední za návrh a súlad architektúry.
Používateľské scenáre a požiadavky musia byť základom, keďže je veľké množstvo variantných riešení a niektoré riešenia sú veľmi nákladné.
Za nás systémový prístup je pre identifikované scenáre/požiadavky určiť zhruba ich používanosť (dôležitosť) a nákladnosť riešenia a na základe toho rozhodnúť ktoré z nich majú byť podporované
centrálnym riešením
v kompetencii správcov agendových systémov (prípadne k tomu môže existovať podporný
centrálny komponent, ktorý správcovia môžu použiť)
aplikáciami tretích strán (nezávisle od eGov, napr. cez OpenAPI)
nepodporované vôbec
Formuláre
Nie je zrejmé odkiaľ vychádza potreba pre Single page aplikácie (SPA). Pre aký scenár je toto potrebné?
Z akého dôvodu je potrebné vytvárať “proxy mikroslužby kontainery”?
SPA sú prílišné zviazanie na technologické riešenie. Používateľovi je jedno, či ide o SPA alebo server-side aplikáciu.
Je potrebné jasne oddeliť tvorbu podania (nejde nutne o vypĺňanie formulára aký poznáme z papierového sveta), autorizáciu/podpis a samotné podanie. Tvorba podania je v zodpovednosti AISu prípadne tretích strán. Samotný “formulár” je potrebný len ako štandardizovaný výmenný formát a prislúchajúce html a pdf vizualizácie k nemu, ktoré sa využívajú pre autorizáciu.
Ak ide o podpisovanie viacerými podpismi je potrebné identifikovať nakoľko toto má byť funkcionalita centrálneho prvku pre autorizáciu. Alternatívy: 1) nechať to na ľudí 2) nechať to na AIS, kedže ide o špeciálny prípad.
Autosave - nechať na zodpovednosť jednotlivých AIS, robiť len tam kde je to potrebné. Rozlišovať medzi autosave podania a “autosave” zreťazených podaní. To prvé by malo byť v kompetencii AISu, to druhé centralizovane. Scenár, že niečo rozrobím na mobile a chcem to ísť dorobiť do IOMu je veľmi úzky a existuje elegantnejšie riešenie.
Zreťazené podania - životné situácie - TODO listy
Jasne pomenovať scenáre, ciele a požiadavky pre centrálne komponenty. Toto je veľmi nejasné, čo to má vlastne poskytovať za služby.
Požiadavky za nás:
K podaniu pridať identifikátor “ŽS ku ktorej patrí” - kvoli monitoringu aj GUI (chcem vidieť čo ešte treba pre “založenie živnosti”.
Toto musí byť niekde centrálne evidované aj príznakom podania/vybavenia.
IOM/JKM
Čo je cieľom tohto kontaktného miesta? Assisted digital? Ako to má fungovať?
Aký je ideálny používateľský zážitok z pohľadu občana vs. úradníka?
Návrh: IOM je len využívanie existujúcich služieb v zastúpení. T.j. jediné čo treba rozšíriť je autentifikačný modul o podporu prihlásenia v zastúpení občana. Na MV alebo UPVS.
@ret a @kyselat vieme sa o tomto pobavit tu resp. na skupine?
Asi to skor prejdeme na stretnuti, myslim ze hovorime o tom istom.
Co sa tyka ps arch aj dnes som to spominal, ze ak su k navrhovanej architekture pre SP interakcia s VS aj pripomienky clenov ps arch, budeme ich riesit v ramci workshopov ps lepsie sluzby. Lebo toto je miesto kde sa ma tato architektura navrhnut. Ps strategicka architektura robi strategicku architekturu.
@jsuchal@ret
Sú to samozrejme všetko validné otázky, a mali by sme si ich zodpovedať, ak sa chceme zodpovedne dohodnúť na budúcom riešení.
Potreba scenárov - súhlas. Nech už sa následne architektúra diskutuje na PS Architektúra (tak sme to na začiatku očakávali), alebo je to zorganizované skrz skupiny (terajší stav) už je teraz jedno, hlavne že vieme kde sa čo diskutuje a nie sme limitovaní účasťou (nezakazujú nám vedúci zúčastniť sa, naopak povzbudzujú aby sme prišli keď sa diskutuje téma).
Zrejme nie celé scenáre, ale časti scenárov budú v kompetencii rôznych správcov (centrálnych komponent, agendových systémov, aplikácií tretích strán a pod.)
Formuláre - nechcem byť hovorcom návrhu (a prizvem do diskusie Martina, ktorý návrh prezentoval). Dočasne by som to (keďže asi chceme zatiaľ diskutovať) aspoň sformuloval takto.:
Vznáša sa okolo nás požiadavka na “vstavateľnosť” (embeddable) technológie do rôznych GUI prostredí (ako som sa zatiaľ dozvedel - hlavne pre systém IOM - ale nepočul som relevantné zdôvodnenie, takže môže sa ukázať že tam je aj že tam nie je).
Druhou požiadavkou je, že formuláre musia vedieť bežať aj v móde “offline”. Samozrejme vtedy nie sú k dispozícii priebežné validácie. Zrejme si takýto “offline” formulár chcem vedieť stiahnuť aj s “predvyplnenými” dátami (teda aspoň do nejakej miery formulár nemusí kopírovať papierový svet, ale je vďaka dátam inteligentný/interaktívny - presne ako v “online” režime). Ak nechcem tento “offline” mód podporovať špeciálnou technológiou (a robiť teda pre každú službu ešte špeciálny “offline” formulár čo služby predražuje), tak sa mi zoznam technologických možností zužuje. Napríklad práve SPA toto spĺňa (jedna definícia, aj offline mód, ľahko vstavateľné). Ale stále mám aj možnosť vypustiť požiadavku na “offline” - len upozorňujem, že dnes existuje - a vtedy sa mi (ak vstavateľnosť do IOM sa ukáže že už nie je problémom) zoznam možností rozširuje na prakticky akúkoľvek web (server) technológiu (vstavateľnosť cez redirect). Oproti SPA ale treba vyriešiť to, kde “pobežia” tie server prostredia GUI (SPA beží v prehliadači). Treba takúto infraštruktúru platiť (investične aj prevádzkovo). Ale možno vo vládnom cloude mať server runtime pre web technológiu bude tak lacné (ako je bežne na trhu), že toto nebude argument.
Čo sa týka “proxy mikroslužieb kontajnerov” - mám pocit, že toto bola len dočasná alternatíva k API ak nebude publikované cez OpenAPI GW (rozhodne nesúvisí s SPA ani s inou front-end technológiou) - ale priznám sa, zatiaľ som nepochopil prečo by sme mali uvažovať o alternatíve k OpenAPIGW. Nemá veľmi zmysel investovať do dočasných riešení. Možno už aj Martin medzičasom túto vetvu uzavrel - musíme sa opýtať jeho.
Z pohľadu súčasnej legislatívy zrejme ani nie (nie je povinnosť). Vo výnose 55/2014 sa hovorí o publikácii “najmä cez on-line” (takže len on-line je prikázaný). Možno by bolo vhodné aby sa vyjadril niekto ďalší, zatiaľ teda (aspoň za mňa) beriem požiadavku na off-line (späť) - nie je to argument.
Zdravim Kolegovia,
Stretnutie tento stvrtok rusime. Budem sa Vas snazit informovat o dalsom postupe PS buduci tyzden, ak budem mat nove informacie od vedenia UPPVII.
