Slubene materialy. Stretnutie prebiehalo podla ocakavania, pripomienky som mal najma ja.
K dopytovej vyzve su tie KPI podla mna zrele na komplet prekopanie, takto to moze dopadnut tak, ze vyhodu budu mat sluzby, ktore migruju existujuce systemy do cloudu a lepsie by bolo ich trebars zahodit a kupit krabicu. Tym, ze je tam tak vela kriterii je to extremne nachylne na nejake spekulacie + takmer isto do dopadne tak, ze keby sme zoradili projekty podla prinosov z CBA a tychto kriterii tak nebude rovnake poradie (co povazujem, za dost neziaduce). MIRRI vsak je naklonene zmene.
Ku kvalite kodov som sa pytal, ze ci by nebolo dobre tam dat vacsi doraz na testovanie a spustitelnost testov. Je zrejme, ze toto videli najma bezpecaci (co je super, ale je to len jeden rozmer kvality kodu). MIRRI prislubilo, ze sa zamysli, ze ako to tam dostat.
Ku vyhlaske som mal blbu kacirsku otazku, ze ci nahodou takato formulacia (401/2023 Z.z. - Vyhláška Ministerstva investícií, r... - SLOV-LEX) neznamena, ze cokolvek z toho nesplni, tak to uz NIE JE projekt podla tejto vyhlasky a teda sa na neho nevztahuje. To by bolo naozaj nemyle, ale logicky mi to tak vychadza. Som vsak zvyknuti na to, ze zapis logiky pravnikmi je v rozpore so zapisom, ktory poznam z informatiky a niekedy dokonca aj bezneho zivota. MIRRI povedalo, ze urcite to takto nebolo myslene, ale teda preveria.
Iba otazka. Nieje dobre sa v tomto texte rovno opriet o nejaky otvoreny standard? SPDX, CycloneDX ? Nech to je unifikovane a nieje v tom potom bordel? Lebo si kazdy vytvori svoj format (zbytocne).
A kontajnerizacia je kde? Ak mi niekto povie ze je to ako virtualizacia, a teda je to vec “runtime”, tak ho “skaredo zranim” :-). Ak kontajnerizaciu niekto v roku 2023 (teda uz 2024) opomenie, tak z pohladu mnohych veci tykajucich sa zavislosti, dodavania, verzovania, nasadenia, prevadzky … si vyraba pruser.
Za mna zbytocna vec cele toto. Ak toto bude pozadovane od dodavatelov, tak sa zase iba zdrazi vyvoj a bude plac preco je statne IT take drahe. Zaroven sa este viac “roztvoria noznice” medzi VS a komernym sektorom, pretoze na strane statu na toto nebudu ludia.
Ja to poviem z ineho odvetvia. PCI DSS dlho riesilo prave tuto temu. A nakoniec je to kompletne oddelena cast - samostatny dokument. Kontajnerizacia je pre mna osobne komplexna zalezitost, ktora by sa musela dotknut nielen kvality zdrojakov a software ale musela by ist srkz vela vrstiev. Ide defacto o dynamicke infrastruktury ktore u nas stale nemaju vela pochopenia. Tam sa otvara kopec veci.
Ale ano… videl ze prave tato tema je dost anarchia a zasluzila by si aspon ake take metodicke usmernenie. Vela ludi ma pocit ze mam container image a tam pribeh konci.
Inac toto ma dnes zaujalo Do urovne U3 sa veselo da EKS
Dostal som odpoved k tejto veci z novembra. Kopirujem:
Diskusia k bodu 2:
p. Ján Suchal: Upozornil, že kritériá pre hodnotenie projektov žiadateľov by mohli byť náchylné na manipuláciu a mohli by byť skôr byť motiváciou na zachovanie vendor-locku.
Odpoveď:
V niektorých prípadoch zvolenej formy realizácie projektov a plnenia podmienok výzvy môže byť sekundárnym dopadom riziko vzniku alebo pokračovania vendor-locku. Kritériá ale boli navrhnuté s cieľom zamerať sa hlavne na pozitívne prínosy v oblasti poskytovania služieb a procesov a nie na elimináciu problému vendor-locku. A ak sa má dosiahnuť čo najväčší efekt v oblasti digitálnej transformácie nemôžeme vylúčiť z riešenia projekty, ktoré majú pozitívny efekt na služby a procesy verejnej správy, len kvôli existujúcemu alebo potenciálnemu vzniku vendor-locku. Z podmienok výzvy a hodnotiacich kritérií boli vylúčené prípady zamerané len na zmenu prevádzkového prostredia migráciou na cloudové služby (rehost), ktoré najviac podporovali zachovanie vendor-lock-u. Pre prípad rehost môžu potenciálni záujemcovia využiť výzvu PSK-MIRRI-604-2023-DV-EFRR - Zvýšenie dostupnosti systémov verejnej správy (https://www.itms2014.sk/vyzva?id=f028e4c1-18e2-49e5-b9e3-fd6bf8ed80f8 ). Zároveň je potrebné brať do úvahy, že problém zabezpečenia potrebných práv nakladania s výsledkami projektu by si nakoniec mal v súlade so zákonom 95/2019 a zmluvami o poskytnutí príspevku vyriešiť realizátor projektu, aby si zabezpečil potrebnú hospodárnosť projektu a udržateľnosti dodaného riešenia. Zároveň táto podmienka je súčasťou schvaľovacieho procesu projektov podliehajúcich Vyhláške 401/2023, kde sa pri hodnotení predloženej projektovej dokumentácie berie do úvahy faktor vendor-locku.
V prílohe posielam aktuálne upravené kritériá hodnotenia návrhov projektov výzvy pre financovanie digitálnej transformácie z POO. Ešte stále je možnosť ich nejako upraviť, ak by ste mali nápad, ako niektoré kritériá upraviť. Len ako som napísal vyššie, nie je primárnym ani sekundárnym cieľom výzvy eliminácia vendor-lock, takže nemyslím si, že by tam pre tento účel malo byť kritérium typu K.O alebo také, že výrazne zníži význam kritérií ostatných potenciálnych prínosov.
Diskusia k bodu 3:
p. Ján Suchal: Upozornil, že podľa jeho výkladu vyhlášky je definícia projektu v základných ustanoveniach §2 ods. 1 písm. x taká, že by sa niektorý subjekt VS mohol pokúsiť vyhnúť postupu podľa vyhlášky tým, že by poukázal na to, že jeho aktivita nemá niektoré z podrobných charakteristík projektu v bodoch 1a až 7a a teda nemusí aktivitu realizovať podľa vyhlášky 401/2023.
Odpoveď:
Konzultovali sme otázku s odborom legislatívy a potvrdili, že charakteristiky projektu uvedené §2 ods. 1 písm. x sú kumulatívne a spoločne vytvárajú základnú charakteristiku projektu a jeho minimálne náležitosti pre účely vyhlášky, a pokiaľ ich projekt nemá, mal by subjekt, ktorý realizuje zmenu svojho informačného systému skôr zabezpečiť nápravu podmienok pripravovanej investície a zmeny a nie pokúsiť sa využiť vynechanie týchto charakteristík na to, aby sa vyhol postupu podľa tejto vyhlášky. V opačnom prípade subjektu realizujúcemu takýto neúplne pripravený „projekt“ hrozí, že buď mu nebudú schválené investičné prostriedky, napr. z EU prostriedkov, alebo riziku postihov od kontrolných orgánov. Táto charakteristika projektu bola podobne uvedená aj v predchádzajúcej verzii vyhlášky 85/2020 a v praxi sa nepotvrdilo jej využitie na vyhnutie sa postupu podľa tejto vyhlášky. Úplne zabrániť takejto situácii vieme až budúcou novelizáciou nastavením definície/podmienok tak, aby boli napr. alternatívne a nie kumulatívne. Zároveň sa na vás obraciame s prosbou o spoluprácu vo veci návrhu formulácie novej definície, ktorá by bola jednoznačná a zamedzila by možnosti vyhnúť sa dodržaniu postupu podľa vyhlášky.
Co sa tyka NKIVS, tak sa to rozbieha, dodavatelom je Alistiq (@juraj.bardy) je tam taky dotaznik, ze co by sa v novej NKIVS malo diat.
K PS arch veduci prezentoval v podstate tak informativne, ze ake spolocne moduly pre zivotne situacie budu a kedy snad budu vyobstaravane.
Otazka od ineho OVM bola, ze kedy budu tieto centralne komponenty dostupne pre ine OVM, kedze aj oni si potrebuju planovat obstarka/projekty.
Za mna je dolezite, ze v architekture vlastne vznikli dva nove komponenty, ktore ma pod palcom MV avsak mali by byt minimalne centralne riadene produktovo.
mobilne SDK - nevyzera, ze by sa to rozvijalo dalej, MV nekomunikuje.
doklady v mobile - v podstate nevieme ako to dopadne, ci to bude EDIW a ci sa to bude dat pouzivat len “pre policajtov” alebo sirsie. Predpokladam, ze ocakavanie bude “idem na urad a ukazem mobil”. Presne toto sa stalo v CR a bolo to dost tazke komunikovat, ze to odrazu nefunguje vsade.
Pristavim sa k jednej veci z NKIVS25 prezky: slide 10: “Algoritmické rozhodovanie”
Ak sme v situacii, ze nevieme riadne zdokladovat a vysvetlit rozhodnutia zivych uradnikov tak, aby tomu obcania rozumeli a doverovali, tak ako budeme dokladovat a vysvetlovat rozhodnuntia robotov?
Tym teraz ani tak nenarazam na povedzme “AI ako black-box, o ktorom nik nevie povedat, preco dal vysledok aky dal”, ale poukazujem na to, ze tu skratka bezne X ludi veri klamstvam (“mis-” aj “dez-” info) a stat (=voleni a nimi menovani uradnici) s tym nic nevie (a mozno ani neche) robit.
Alebo este inak: Kym teda neverime zivym uradnikom, asi by som na urady ziadne roboty nedaval.
Presiel som to, velakrat v tom dotazniku podla mna sa neda vybrat, kedze
moznosti nie su vylucujuce, mal by to byt multichoice
zalezi od kontextu a situacie - neda sa rozhodnut od stola
Z celeho mam najvacsi problem s pohladom (vyzera, ze je to pohlad MV), ze sa tu ide robit integracia primarne cez MOU - digitalnu penazenku, co je velmi obmedzeny pohlad a vlastne uz dnes nepokryva vacsinu scenarov. MOU je za mna len uzka podmonozina spristupnovania API, ktore by malo byt viditelne z pohladu obcana na jednom mieste (digitalna penazenka to nie je).
Open data = verejne udaje, read only, ziadne riadenie pristupu
MOU = osobne udaje, read only, riadenie pristupu suhlasom osoby - pristupne pre komerciu
Referencne registre = osobne aj ine udaje, read only, riadene primarne zakonmi (antibyro, 305) - primarne pristupne len pre OVM a velmi obmedzene pre komerciu
open api = read & write, vsetky udaje aj sluzby - pre komerciu aj OVM (podla toho co sa moze a nemoze alebo sa da suhlas) - priklad: api pristup k schranke na slovensko.sk - ako toto pokryje MOU? Nijako, su tam aj write pristupy (prebratie dorucenky, presun sprav, mazanie), nie su to primarne osobne udaje (spravy obsahuju aj vselico ine ako osobne udaje)…
Určite sú tam ešte fajnovosti, napríklad zdravotnícke data sú často vyčleneňované z osobných, lebo sú často ešte citlivejšie.
Mne takto nahrubo spísaný koncept vyhovuje. Navyše by to ani nikomu nemalo vadiť (čo je pre priechodnosť užitočné), lebo majú dobre definované hranice, každé z toho má zmysel, nelezú si navzájom do scope.
Práveže by som povedal, že mou má scope svoj, kde to je o potvrdeniach a dokladoch, lenže to má strašne okrajové použitie. Preto sa mi to obmedzovať na túto množinu read only osobných údajov zdá slabé.
