Spat k pracovnej skupine. Kratky zapis zo stretnutia vo stvrtok:
diskutoval sa dokument ref. architektura ISVS v cloude - vid nizsie. Cielom je zaviest best practices ako povinne pre systemy ISVS v cloude (tj. vsetky).
Otazka: Ovplyvňuje arch nejako opensource licenčný model? Odpoved: Toto je uloha na obstaravanie/governance/etc nie je potrebne riesit tu.
Sú body z 12 factor/resp. tohto dokumentu must have alebo optional? Pocita sa s must have, samozrejme, v kritickych pripadoch, alebo ked nebudu este dostupne napr PaaS, tak sa bude riesit osobitne.
Problem sú licenčné podmienky lebo pre on premise a cloud su rôzne ceny/podmienky. Moze to sposobit problemy pri migracii do cloudu.
Je povinna kontainerizacia alebo staci ked to je nejako naskriptovane. Odpoved: Cielom je priblizit sa idealu napr. autoscaling, cize image/kontainer/cokolvek musi byt spustitelny takmer okamzite. Kontainery su na toto prirodzene riesenie.
Vznesena vazna vyhrada, ze toto vsetko je ok a vlastne nikto voci pravidlam velke vyhrady nema (su to rozumne veci) ale pokym bude treba na restart masiny dvihnut telefon, alebo na VPS v cloude prejst schvalovanim, tak je to cele o nicom. => Musi to byt jasne aj personalne/procesne podchytene a zmenit sa myslenie ludi => na dlho.
Momentalne sa tvori dokument Referenčná architektúra Informačného systému verejnej správy v cloude, ktoreho draft mam od veduceho @kyselat povolene sem zverejnit na pripomienkovanie. Zatial ide len o uvodne kapitoly. Tento pristup vsak chvalim, cim otvorenejsi pristup, tym vacsia sanca, ze vystupy na konci lahsie prejdu a budu kvalitnejsie.
Vkladám linku na zoznam materiálov vo finálnej verzii pred rokovaním RV pre digitalizáciu a DSM (bude sa konať 10.11.), kde sa nachádza aj touto PS vypracovaný (a tu priebežne zverejňovaný) dokument.:
Že tu bola dosť intenzívna diskusia o budúcnosti el. formulárov, tak len pre informáciu, ÚPVII “niečo” v tejto veci podstatne pomenilo v novele výnosu o štandardoch, ktorej práve končí MPK.
Priznám sa, nemal som čas zložiť si výsledok z tých zmenových bodíkov. Škoda že to nebolo vôbec vopred komunikované - snáď ešte bude.
Pripomienok prišlo viac ako 250, veľa aj k formulárom.
Trochu nerozumiem preco sa to zameriava na softverove licencie a nie sluzby, pripadne nejake KPI na otvorene licencie (ked uz sa tvarime, ze ideme podporovat opensource).
Statne CI - povazujem za zly krok a nepodstatny detail. CD - nie je zrejme co si pod tym predstavit.
Tato skupina sa opat ozivi na urade. Ak su navrhy na temy co by bolo treba prediskutovat tak sem s nimi.
Ja vidim nateraz z toho co chodi do studii problemy:
MV chysta nejaku mega orchestraciu, nie je mi zrejme ako toto ma fungovat. Ci to nebude centralizovat biznis logiku niekde na centralu kde nema co hladat. Treba jasne povedat co sa riesi eventovo a co orchestraciou a kedy.
workdesk uradnika (MV), portfolio klienta (NASES) sa chystaju robit nejake widgety, nie je zrejme ako toto ma fungovat a integrovat ine AIS.
BPaaS a spolocne bloky spravneho konania (MV) - vobec nie je zrejme ako sa toto ma integrovat do buducich IS a ich backoffice.
ja by som si rad vyjasnil, ze co budu zabezpecovat tie spolocne platformy, ktore su v architekture nakreslene farebnymi ramcekmi:
API GW,
Platforma datovej integracie,
Orchestracna platforma.
demonstrovat si to na konkretnych prikladoch…napr. na nejakej zivotnej situacii, ze ci to vobec potrebujeme a ak ano, co z toho je must a co je nice to have, pripadne co chyba
pre PS Governnance by som potom ocakaval, ze na zaklade toho spracuje plan realizacie jednotlivych casti, napr. tych must, kedy maju byt dostupne
→ mne osobne by to pomohlo, keby som mal planovat nejaky novy, upgrade existujuceho IS VS
Presne tak. Toto aj od začiatku hovoríme. Ešte roku pána 2015 sme sa tento pohľad snažili vložiť do NKIVS (viď. kap.7, najmä 7.5). Potom to mal byť “akčný plán”, čo však tiež nejako nevyšlo.
Teraz sa ako jedna z úloh pre PS Governance dohodlo, že sa pripraví zoznam míľnikov - jednak “do kedy” je treba nejakú povinnosť splniť/ funkčnosť sprístupniť a aj “od kedy” bude pre všetkých dostupné/povinné určité centrálne riešenie. V tomto prehľade sa nemajú vymýšľať žiadne nové veci, iba pozbierať čo kde už je schválené.
@kyselat prezentoval draft “Pravidla publikovania sluzieb do multikanaloveho prostredia eGovu”, ktoreho cielom je dat OVM nejaky navod, aby vedeli co maju vyzadovat konkretne od dodavatelov a s cim ratat v projektoch. Akonahle bude draft zverejnitelny tak ho sem dam alebo mozno aj sam Tomas. V principe ide o to spravit podobnu “kucharku” ako maju v Gov.UK na APIs, ako sa maju dokumentovat (open api 3.0), ako sa ma riesit autentifikacia (oauth2/openid connect) a kopec dalsich veci. Miestami to uz zachadzalo do detailov, ktore by som cakal skor v standardoch. Padla zhoda, ze z tohto dokumentu sa to do standardov musi potom preniest (cc @stefan.szilva)
Viem, ze to je bez draftu asi tazko, ale v klude piste navrhy, co by tam nemalo chybat.
K referencnym registrom: dnes sa vyzaduje aby vsetko bolo ciste pred vyhlasenim za referencny, nie je to realisticke tu sa to ma zmenit.
vyjadrena bola obava, ze mozno zistime, ze nejake OVM maju sice IS ale vlastne funguju stale papierovo - napr. pri podaniach. Skutocna elektronizacia je mozno daleko.
K metodike modelovania udajov:
Datove prvky resp. hruby domenovy datovy model bude modelovany uz v studii. Bola vznesena obava, ze ci to vlastne niekto bude vediet urobit a ci sa to nedeje az pri kompletnej analyze co dnes robi dodavatel. (Za mna dobre, ak OVM nema jasno co chce robit, nemal by velmi robit ani nejake fixed-price projekty)
Nasledne sme presli len zlahka obsah dokumentu o spristupnovani sluzieb v multikanalovom prostredi (je to na internom pripomienkovani, na poziadanie viem poslat keby niekto chcel)
Nie je to protizakonny stav ? nema to riesit v tom pripade UPVII ako vlastnik 305/2013 ?
No a sucasny stav ? vyzadovane ArchiMate diagramy nevie urobit skoro ziaden autor studie a tak sa tam kreslia voloviny …
Mozno je dobry cesky model, kedy do verejneho obstarka uz ide kompletny PIM (platformovo nezavisly analyticky model) … Ale kto by pri dnesnom stave personalneho obsadenia dokazal u nas take obstarko pripravit … neviem … pravdepodobne aj oni na analyzu obstaravaju zvlast speci firmy a az ten vysledok potom daju do obstarka pre implementaciu …
Niekolko rokov dozadu som robil na slovenskom eGov, takze do toho trochu vidim aj zvnutra. Vtedy snaha robit veci lepsie napriek velkej snahe nepresla. Tak uvidime ako to pojde zvonku.
V diskusii sa spomina, ze je rozdiel medzi pravidlami a standardom. Neviem aky je to rozdiel, takze to ani v texte nerozlisujem.
V DXC (predtym HP) mam menovca architekta, ktory tiez robil na eGov, ale nie sme ta ista osoba
Keďže mám pocit že zľadovanie jednotlivých pracovných skupín nie je úplne na 100% funkčné, a je to tak trošku o samostatnom prístupe, dovolím si tu uviesť presah štandardov elektronických služieb na skupinu PS1.
Rýchlo som si to preletel a našiel som tam nejaké “bezvýznamové URI” … Čiže toto ešte musím pochopiť
Tak či onak, môžem len veriť že je to v zhode jednak s používaním URI identifikátorov služieb v MetaIS,
Priznám sa, že som celkom nepochopil, kde by sa to mohlo prekrývať. Tie linky čo si dal, viac-menej súvisia s príkladom definície/popisu “entít” v danej službe, prípadne ešte s vecným zaradením, resp. katalogizáciou služby samotnej. To znamená nejaká vnútorná kategorizácia a katalogizácia v rámci MetaIS. Pričom dokument vyššie rieši pravidlá pri publikovaní služieb (ich fyzických rozhraní cez web služby) poskytovaných do multikanálového prostredia (teda OpenAPI).
Celkovo k výstupom z PS1 môže chýbať kontext (keď pozerám tú sprievodnú wiki). Do značnej miery sa veľmi rýchlo ide ku konkrétnym príkladom, pričom chýba informácia - čo to je (metapopis - asi cielený na MetaIS?), načo to je (kto to bude využívať a na čo?), prečo by sme to mali robiť takto (zrejme to má aj svoje limity a ako každý spôsob - určite existujú prípady, kedy to používať nie je vhodné) a až potom konkrétne príklady.
Takto nám neostáva zrejme nič iné, len počkať, kým si výstup z PS Architektúra (kde okrem príkladov je aj kontextová informácia) naštuduješ ty, resp. niekto z PS1 a začneme riešiť konkrétne pripomienky.
Verím že tu neskĺzneme k nejakým osobným nezrovnalostiam na to čas nemá asi nikto z nás.
Určite si musím viac naštudovať tento dokument, resp. pochopiť o čo ide, oprašujem moje kóderské schopnosti, takže inú možnosť mať tak či onak nebudem.
Chcel som naozaj hlavne poukázať na to, že mám pocit že jednotlivé skupiny idú svojim vlastným životom, a bolo vy asi efektívnejšie keby sa teda aspoň v niečom prekrývaly. Sám sa pýtaš že
SP Lepšie dáta, či SP Otvorené dáta stavia na zavedení jednotných URI identifikátorov (globálne identifikátory v ISVS), tak aby bolo možné pracovať s verejnými dátami ako s jedným celkom. PS1 ich schvaľuje a postupne sa začínajú používať (MetaIS je len príklad)URI majú aj konkrétne entity (právne subjekty, adresy, zmluvy). V uvedených strategických dokumentoch sa aj definuje používanie týchto identifikátorov v službách, je to aj v checkliste pre nové štúdie, atď. čiže URI majú predstavovať globálne používané identifikátory naprieč ISVS.
Čiže napr. uvedený štandard CPSV-AP-SK predstavuje dataset pre publikované elektronické služby,a pridal som aj príklad jednej konkrénej (z metais v tomto prípade), ale má to platiť na všetky datasety o elektronických službách.
Skutočne chcem len podotknúť, že mám pocit, že celková spolupráca medzi skupinami má mušinky, a to platí tvojej strany na moju, ale aj opačne.
Formálnejsie:
K9.3 -------saNieÚplneZľaďujeS-------->K9.4,
pričom relácia saNieÚplneZľaďujeS je krásne symetrická.
čo ale asi nechceme.
