Pridam moj pohlad na stretnutie, kedze zapis je trochu riedky.
Zástupca SD p.Suchal uviedol, že z jeho skúseností považuje integráciu na ÚPVS za veľmi náročnú aktivitu, ktorá vyžaduje náročnú prípravu (apeloval na rozsiahlu dokumentáciu, ktorú považuje za zbytočnú).
Toto som samozrejme nepovedal, povedal som, ze vacsinu procesu DIZ (dohoda o integracnom zamere) povazujem za komplikovanu, zbytocnu a riesitelnu inak - tak ako to je uplne bezne v komercnom svete.
Zástupca IT komunity p.Slovík uviedol širšie podmienky a dôvody, na základe ktorých boli zavedené formálne požiadavky v rámci procesu integrácií zo strany MF SR ako inštitúcie, ktorá koordinovala informatizáciu na národnej úrovni počas implementácie OPIS a ktoré sú dodnes záväzné aj pre NASES – išlo najmä o potrebu koordinácie enterprise architektúry na úrovni architektonickej a programovej kancelárie, na čo reflektuje aj projekt META IS.
@vojtech.slovik uviedol ciele preco vlastne nieco ako DIZ vzniklo. Podstatou bolo, ze kym nebol vynuteny DIZ, k integraciam vlastne neexistovala dokumentacia, netusilo sa ake sluzby ktory system vlastne vyuziva a ked sa robila zmena neboli jasne dopady. S tymto nemal nikto problem, s dodatkom, ze predstava ake je toto jednoduche sa vyrazne lisi od skusenosti v realite (nielen moja skusenost). Ako priklad som uviedol nutnost uvadzat k vyuzivanym sluzbam aj endpointy a kadeco ine - co nie je nikde ucelene dohladatelne. Zastupca dodavatela (globaltel) uviedol, ze toto sa zmenilo a DIZ uz obsahuje tabulku, kde si clovek len vyberie sluzby, ktore chce vyuzivat (ano je to tak).
NASES si uvedomuje, že integrácia je náročný proces a prijme opatrenia pre zjednodušenie orientácie sa na PFP či v dokumentácií všeobecne, avšak je potrebné si uvedomiť, že je potrebné vyvinúť úsilie aj na strane dodávateľov integrácií konzumentov služieb ÚPVS, kde NASES eviduje že nie sú zdieľané skúsenosti ani v rámci viacerých tímov u jedného dodávateľa a je potrebné posilniť úlohu analytika pred samotným vývojom na strane integrátorov.
S tymto sa da suhlasit len ciastocne, toto nemusi byt len dosledok toho, ze ludia su lenivi a necitaju, ale jednoducho preto, ze dokumentacia je tazko pristupna, neexistuje nejaka zdielana znalostna baza. Uz len samotny format dokumentacie (word) znemoznuje v nej efektivne vyhladavat alebo nebodaj sa na nieco odkazovat z webu.
Zo strany SD a p.Kohauta bola vznesená požiadavka otvoriť PFP (prístup bez prihlásenia) s cieľom odkazovať sa na jednotlivé dokumenty v rámci zdieľania skúseností v IT komunite. NASES prisľúbil zefektívnenie usporiadania dokumentácie, rozdelenie dokumentácie podľa pozícií v rámci integračných tímov (PM, vývojár, infra…), vytiahnutie časti dokumentácie na stránku NASES bez potreby prihlásenia a tiež boli vysvetlené dôvody, prečo nie je možné publikovať všetku integračnú dokumentáciu verejne.
Tie dovody sice vysvetlene boli, ale nasledovne: NASES potrebuje mat pod kontrolou jedno miesto kde bude oficialna dokumentacia lebo ta sa vyvija a chcu zamedzit, aby sa ich ludia pytali na veci, ktore najdu niekde po internete a budu stare. Toto nikto nerozporoval, ale nie je to v ziadnom protiklade so zverejnenim dokumentacie bez potreby prihlasenia. Naopak, prave zverejnenie bez prihlasenia a moznost odkazovat sa rozumne na dokumentaciu by uplne zamedzilo zbytocnemu duplikovaniu dokumentov, ktore sa deje dnes.
Zo strany SD a p.Kohauta bola vznesená požiadavka na otvorený issue tracker na strane NASES, prípadne inú formu zdieľania skúseností medzi integrátormi, zástupcovia GlobalTel odprezentovali súčasný stav (Service Desk pre PROD prostredie, Kontaktné centrum, emailová a telefonická komunikácia navonok v rámci DEV a TEST prostredia, Jira pre interné sledovanie taskov).
Toto stale povazujeme za dobry napad - minimalne zaviest issue tracker aj pre DEV/TEST (v klude s inymi SLA). Co sa tyka otvorenosti issue trackera - od dodavatela bola vznesena namietka, ze tam mozu byt citlive informacie. Oponoval som tym, ze otvoreny issue tracker je bezna vec v komercii a pokial pouzivatel vie, ze je otvoreny, da si pozor co tam zdiela + dobry issue tracker umoznuje podat request aj privatne.
Zo strany SD a p.Kohauta bola vznesená požiadavka na zrušenie DIZ – zástupcovia GlobalTel a NASES vysvetlili dôvody potreby tohto dokumentu a tiež potrebu akceptácie UAT testov formou protokolu.
Toto bolo v navaznosti najme na pravnicke osoby (aj ked nas ciel nie je to zjednodusit len pre pravnicke osoby, ale vsetkych integratorov). Potreba akceptacie UAT protokolov bola uvedena nasledovne “potrebujeme vediet ci rozhrania pouzivate spravne, inak by ste nam mohli nadmerne vytazovat PROD”. Namietal som, ze je uplne bezne dat rate limiter na kriticke endpointy, nemozeme predsa cakat, ze nejaky IS sa nikdy nezacne spravat nepredvitatelne. Navyse IS predsa musi ratat aj s nedostupnostou integracneho endpointu. Zastupca dodavatela uviedol, ze v realite s tym IS netaju (WTF?) ale si vie predstavit toto riesit nejakymi vseobecnymi podmienkami pouzivania. Dalsi zastupca dodavatela uviedol, ze pripadne nadmerne vyuzivanie monitoruju. Ale mam z toho pocit, ze je to reaktivne, nie automaticke.
Nasledne padli zo strany NASES navrhy, ze by bolo vhodne spravit ukazkove DIZ resp vzory pre typicke integracie. Dodavatel oponoval, ze okrem schranok je vyuzitie velmi variabilne a typizovane vzory vela nevyriesia. S tym sa da suhlasit.
Vzhladom na toto nase navrhy trvaju:
- Zaviest issue tracker aj pre DEV/TEST prostredie (ale nech ostane aj komunikacny kanal email - dobry issue tracker toto vie sam).
- Otvorit issue tracker verejnosti (mat moznost vsak zadat issue privatne).
- Otvorit a zmenit sposob publikovania integracnej dokumentacie (musi byt jednoducho vyhladavatelny a linkovatelny zvonka). Napriklad verejna wiki - moze posluzit metais confluence?
- Zjednodusit proces integracie - DIZ minimalizovat na komunikacnu maticu, zhrnutie, vyuzivane sluzby a popis toho ako budu sluzby pouzivane. UAT testy nahradit vseobecnymi podmienkami a rate limiterom.
@peterk v klude nech doplni navrhy za seba.
@jsuchal prepacte ale neda mi, preco ste kolegyni napisali ked Vam poslala mail so Zaznamom zo stretnutia “za mna Ok”, preto aby ste to teraz spochybnovali?
Jedine co som spochybnil je prva odrazka, ktoru som si vsimol poriadne az ked som email odoslal. Zvysok je len doplnenim pre ludi, ktori by chceli vediet viac ako je v zapise. Nic z toho co u napisane nie je nove, vsetko som povedal na stretnuti viac krat, do zapisu ste to nedali - tak som to sem dal ja.
Ak tam vidite nieco co som nepovedal alebo bolo vysvetlene inak na stretnuti, tak prosim napiste co, nemam problem to uviest na pravu mieru. Dakujem.
Mame novinku, isto ste zachytili, ze NASES zmenil dost vyrazne proces integracie. Mame v tom prsty, robili sme to totiz my na objednavku NASESu.
Moj historkovy status k tomu:
Ako to funguje? S.D dostalo priame zadanie? Alebo nases zamestnal fyzické osoby na DoVP? Alebo ste to urobili pro bono?
SD dostalo priame zadanie kedze je to zakazka pod 5k.
To znamena, ze integracia priamo na UPVS je porovnatelna s integraciou cez ekosystem? Ak by si to vedel porovnat v dvoch cislach, tak aky je effort cez UPVS a cez ekosystem?
Urcite nie. 
Toto ani nebolo ucelom spoluprace s NASES a naozaj sme nemenili endpointy.
V skratke co sme urobili:
- zobrali sme vsetky integracne zamery co sme kedy robili a vytvorili z nich vzorove procesy + testovacie scenare.
- DIZ a UAT sa zmenili tak, ze staci odkazovat na tieto vzory a nemusi to clovek vypisovat a vymyslat. zaroven sa z UAT vyhodilo kopec veci co uz netreba testovat + clovek vie co ma testovat.
- vznikol teda jeden novy dokument, kde si clovek vie vybrat “z vykladu”, ze co chce robit a rovno to ma ako na podnose. Zaroven vie, ze co vsetko sa da robit.
Nas komponent na slovensko.sk je do velkej miery opensource, cize ak sa niektomu nechce babrat so SOAPami, tak si ho rozbehne a moze fungovat.
V skratke: My sme riesili tu procesnu a papierovu cast, nie programovaciu. Ak by chcel NASES roztocit niekde ten komponent, tak im branit nebudeme 