K9.5 - Pripomienkovanie Strategická priorita Multikanálový prístup

Pripomienkovanie
1

Dokument na pripomienkovanie do 4.1. Pridavajte komentare do dokumentu alebo sem do fora.

  • Primarne nas zaujima, ci je pokryty scope. Je vsetko co ocakavame?
  • Sekundarne - vsetko ostatne.
  • Kapitola Realizacia sa bude dorabat.
2

Dopisal som ako komenty do dokumentu nejake vyhrady a poznamky.

Nejake TODO a dalsie poznamky mimo doku:

  • scope -
  • co bude so specializovanymi portalmi, budu sa rusit ci ostanu - aka je strategia?
  • formularova technologia - co ostava a co sa zmeni?
  • 4.2.5 - strategia pre tradicne kanaly - toto nebolo pokial viem v PS prebrate.

TODO

Pomoc vitana.

3

Spisal som zatial pripomienky sem. Posielam ich na skupinu. Necakam, ze to je finalny stav.

2.2 - Stakeholderi a ich zaujmy

  • “Sprístupniť služby OVM cez čo najväčšie spektrum komunikačných kanálov s relevantnou úrovňou autentifikácie a autorizácie”

Z diskusie PS bola zvolena strategia, kde budu sluzby spristupnovane nie strategiou vsetko vsade, ale tam kde je identifikovana relevantna potreba pouzivatelov.

  • “Zabezpečiť jednotne spravovaný a bezpečný autentifikačný mechanizmus pre všetky komunikačné kanály.”
  • “Zabezpečiť bezpečný spôsob elektronickej autorizácie pre elektronické komunikačné kanály”

Nie je zrejme, o ktoru uroven autentifikacie a autorizacie ma ist. Pre autorizaciu bol navrhovany centralne riesit len level 3.

  • “Mať možnosť využívať aj viacero kanálov v rámci jedného podania”

Mame za to, ze ide je velmi uzky scenar, pricom nie je zrejme kde vznikla potreba na tuto funkcionalitu a nasledne centralny prvok.

“Nutným predpokladom pre schválenie implementácie natívnej mobilnej aplikácie by mali byť:
Dostupnosť služieb cez rezponzívne webové rozhranie
Dostupnosť Open API pre služby v gescii daného OVM”

  • Suhlasime, ak sa doplni, ze toto ma platit nielen pre koncove sluzby aj pre aplikaciu sluziacu na autentifikaciu a autorizaciu. (OpenAPI)

Stratégia pre tradičné kanály (osobne, listinne, telefonicky)

  • Nebolo v PS vobec diskutovane. Kedze ide o najfrekventovanejsie kanaly. Nie je zrejme odkial ide potreba napr. na SSO a prepojenie dochadzkovych, vyvolavacich a agendovych systemov, centralizaciu tlace a podobne.

Autentifikácia pomocou mobilného zariadenia a spôsob autorizácie služieb

  • Konkretny sposob by mala riesit PS bezpecnost, vidime ako riziko rozpracovavat takto nizke technicke a implementacne detaily v strategickom dokumente.

“eID karta bude vždy vydávaná ako primárny autentifikačný prostriedok, pomocou ktorého bude možné aktivovať mobilnú autentifikáciu samoobslužným procesom a prípadne iné autentifikačné mechanizmy.”

  • nie je mozne aktivovat mobilnu autentifikaciu aj bez eID? Preco? IOMO?

5.3. Aplikačná vrstva

  • Centralne spolocne bloky (frontoffice mikrosluzby) sa daju implementovat rozne. 1) Standardizacia a decentralizacia 2) Centralny prvok 3) Genericka platforma v sprave gestora. Pre vsetky spolocne/centralne bloky je nutne zvazit vsetky tieto varianty. Napr. centralna validacia je duplicitou validacnej logiky v agendovych systemoch. Tu navrhujeme ako vhodnejsi decentralizovany (na urovni agendovych systemov) a standardizaciu.

  • Niektore spolocne moduly navrhujeme vypustit (Nastavenie personalizačných preferencií, Evidencia personalizačných preferencií)

  • nie su doriesene zasadne otazky v architekture a mala by zodpovedat PS architektura skor (!!!) ako sa tento dokument schvali.

    • co budu centralne bloky, co sa bude implementovat decentralizovane na urovni agendovych systemov.
    • je vhodne vytrhavat biznis logiku do orchestracnej platformy? pre ake pripady a za akych podmienok?

  • su otvorene otazky k ZS

    • kto bude mat zodpovednost za jednotlive ZS? budu to jednotlive aplikacie per ZS? Na PS bola zhoda, ze ano. Alebo centralny komponent? Z dokumentu nejasne. kto bude gestor? Ake bude mat paky na zabezpecenie sucinnosti s inymi potrebnymi agendovymi systemami v gescii inych OVM?

Celkovo - kapitola Realizacia zatial chyba, nie je mozne zatial uzavriet ako celok, su tam stale z nasho pohladu nedoriesene (resp. nejasne) dolezite veci na urovni architektury.

2 Likes
4

Je tu nova verzia: UPVII_SP_Multikanalovy_pristup_v03.docx - Google Docs

Hlavne zmeny v dokumente:
· Prehodnoteny multikanalovy variant na alternativu A
· Aplikacna architektura zuzena na potreby multikanalu a zohladnujuca decentralizovany model FO mikrosluzieb.
· Navrh statneho messengera pre podporu kolaboriacie a proaktivity v kanaloch
· Doplnenie aktivit realizacie v kapitole 6

Pripomienky do stredy 15:00.

Co mna trosku zaraza je zmena varianty na alternativu A - t.j. realizacia vsetkeho na vsetkych kanaloch. @michalblazej rozumies tej argumentacii? Na PS si pamatam zhodu, ze je nezmysel tlacit vsetky sluzby do vsetkych kanalov - ale tlacit do kanalov len take, ktore ludia cez ten kanal ocakavaju a chcu ich robit. Aby sa z elektronizacie tlaciv v OPISe nestala v OPII elektronizacia podani pre vsetky kanaly a o 7 rokov zistime, ze to nikto nechcel.

1 Like
5

Tu su pripomienky vsetky od zucastnenych stran https://docs.google.com/spreadsheets/d/13AHzgua_HtV4Nrup8hR4WWvEiCjtHMDyRfXz-s0Dqnk/edit?usp=sharing

PS. Boli podla pokynov odstranene pripomienky, ktore sa sa tykaju inych strategickych priorit a budu sa riesit inde.

6

Kratke postrehy zo stretnutia k pripomienkam k dokumentu:

  • zapracovanie pripomienky - ci je potrebne v kanali vsetko, pridat tam podmienku kedy sa ma a nema robit sluzba v danom kanali
  • diskusia - pridat podmienku na utlmenie papierovej formy, nech sa to pohne od papiera do el. formy
  • diskusia - open api - naco tam je certifikacia? treba vyhodit
  • potreba vyhodit naviazanie na remote signing - zovseobecnit na lubovolnu autorizaciu
  • naviazat stavebne bloky na ciele a ukazovatela - aby to bolo jasne

Nova verzia dokumentu:

7