Integrácia ISVS vs. Byrokracia

1

Oceňujem otvorenosť, len tak ďalej. Ale priznám sa, po prečítaní tohto textu - časť o integráciách, mám kyslú príchuť na jazyku. Lebo tento popis (ktorý má ukázať aká zmysluplná bola činnosť Pg/A kancelárií) ukazuje, že sa nesmierne veľa mandayov strávilo prácou, ktorá by za normálnych okolností vôbec nemala byť potrebná.

Väčšina integrácií sú predsa jednoduché jednokrokové, bezstavové gettery či settery. Žiadne zložité procesné mapy, distribuované transakcie, či algoritmická zložitosť. Kde sa teda stala chyba? Iste, centrálna metodika je lepšia ako nič, ale súčasne treba povedať, že to čo je vydané z veľkej časti zbytočná byrokracia naozaj je. Pritom úplne chýba centrálna koordinácia technických riešení, kde by sa silnou štandardizáciou mala veľmi zjednodušiť implementácia bežných integrácií.

2 Likes
2

Z tohto citit naozaj odbornu IT komunitu s integracnymi skusenostami.

ak sa za byrokraciu povazuje to ze:

  1. su jednoznacne urcene zodpovedne osoby za integraciu
  2. su popisane biznis procesy integrujucej sa strany spolocne s identifikaciou vazieb na externe sluzby poskytovatelov
  3. je dohodnuty casovy harmonogram
  4. je zdokumentovane datove mapovanie struktur evidencie voci poskytovatelovi
  5. a su dohodnute podmienky prevadzkovania

je to zmysluplna byrokracia, ktorej benefity prevysuju implementacne naroky.

3

Ja by som poprosil ukážku kde to takto rieši komercia.

4

Komercia sa integruje formou mergera / akvizicie. Uoss zvycajne nemergruju ani sa navzajom nekupuju.

6

V pripade komercneho sektora treba rozlisovat intra-enterprise integraciu a B2B integraciu na partnerov, ale kroky su rovnake pri B2B este nejake navyse.

  1. organizacia si urci strategicke ciele z coho definujeme portfolio zmien na dane casove obdobie
  2. tie sa pretavia do projektov a chrs, kde maju priradenych PMs, CHMs
  3. pri analyze jednotlivych pracovnych balikoch sa urcia dopady na vrstvy architektury (biznis, aplikacie, infra, sec, data)
  4. navrhnu sa to-be stavebne bloky architektury (napr. upraveny biznis proces s napojenim na nove aplikacne sluzby)
  5. overi sa dostupnost zdrojov aplikacnych vlastnikov a vytvori sa casovy plan implementacie
  6. v pripade integracnych zmien aplikacni vlastnici realizuju dohodu o sposobe integracie a designe sluzieb poskytovatelovej strany integracie
  7. vykona sa datovy mapping integracie
  8. prebehne vyvoj/ konfiguracia
  9. testy
  10. handover do prevadzky spolocne s upravou/vznikom novych SLA

v pripade B2B integracie su este formalne kroky, kde sa na zaciatku s integrujucou sa stranou podpise agreement a po ukonceni implementacie “integracna” SLA.

Tymto procesom je zabezpecene, ze znalosti neostavaju iba v kode a hlavach vyvojara, ale organizacia si buduje znalostnu bazu a minimalizuje riziko vendor lock-in. Ale toto hlavne nevyhovuje IT vendorom vo VS a preto bola integracna metodika tak nenavidena :slight_smile:

7

Nedá sa nesúhlasiť s Luborom, ze vela usmerneni bola casto formálne “výborne” spracovaná aké v praxi ťažko vykonatelna… Nehovoriac ze nebola aktualizovana a dnes po skončení OPISu uz sú nepouzitelne tie usmernenia. Lebo v skutočnosti sa mali standardizacne veci davat do vynosov a metodik štandardov pre celé isvs a nie len pre OPIS. Ten skončil a s nimi aj tieto dokumenty…

Tiež podiel prace interných a externých ludi na pgk a akvs by bol na samostatnu temu (nie je to nič osobne voči žiadnemu človeku)… Moj názor je ale, ze nie je podstatné ci interný alebo externý človek, podstatne je posúvať veci vopred. Prave externé kapacit môžu vypomlct v čase spicky alebo pre specificke prace, tak ako písal suchal nemali by to byt pravidlo na obchadzanie zamestnavania a honorovania interných ludi.

Dodnes mi unika motiv a teda prinos z môjho pohľadu rozhodnutia týchto “kľúčových” ludi odísť z mifi /uradu podpredsedu a ponechať tak nové vedenie " s nohami vo vode" :blush: prečo takto manifestačne?

8

No tak uz chapem. Tuto sa motaju pod slovicko integracia minimalne dve rozne veci a jedna uplna haluz (zmurk @IvanK).

  1. Integracia v mojom svete je integracia nieco kde si precitam dokumentaciu o tom co to API vie, nasledne ho zacnem pouzivat. Koniec. Ak treba nejake konto, tak si ho vytvorim. Priklad, ze to ide aj v egov prostredi? https://gds-payments.gelato.io/docs/versions/1.0.0/quick-start-guide Ak mi tam nieco chyba, tak napisem feature request a potom sa dohodneme.

  2. Integracia dvoch systemov kde este neexistuju sluzby. Tam cele to kolecko co spominas ma zmysel, nech su tam zodpovednosti, terminy, vsetko. Sice si to viem predstavit aj bez takehoto papierovania, ale ok. enterprise musi byt.

Priklad ktory mal asi @lubor na mysli. Integracie ktore su pre nas bezne su cisto typu 1. - konzument. Tam naozaj vyplnat dohodu o integracnom zamere, cakat x tyzdnov kym si to niekto precita na 3 urgovania (zmurk NASES) je uplna zhyralost. Lebo a) dokument tu ma vlastnost, ze od momentu podpisu zacina zastaravat, cize cokolvek co tam napisem zajtra s realitou nemusi mat nic b) minuta ticha za vsetky komercne systemy co by takto prudili svojich zakaznikov. c) naozaj sa snazim hladat na co by toto poskytovatelovi bolo. A jedine na co som dosiel je … zistit na co to pouziva a aj to je take, ze skor zo zaujimavosti. Ok este v metais by bolo fajn vediet, ktora sluzba pouziva aku sluzbu, ale tak to sa asi da zistit aj z toho ako tie systemy realne volaju tie sluzby.

Normalne vo svete komercie je vystavit API a dokumentaciu verejne, ak sa nieco meni na deprecated tak upozornit odberatelov s nejakou fajn grace period - a feature requesty riesit na fore napriklad takto https://platform.github.community/

Z toho ako tu funguju integracie by sa tu fakt hodil nejaky statny stack overflow, lebo je uplne bezne, ze integraciu na system XYZ zvladnete bez trhania vlasov len ak mate na telefone kamarata, ktory uz vlasy nema. Samozrejme spravcovia systemu XYZ na to bud dlabu alebo ich to nebavi uz po milionty krat opakovat alebo si napisu na nejaku obskurnu stranku FAQ do Excelu.

Inak toto by si zasluzilo samostatnu temu. Integracie ISVS vs. byrokracia. Oddelim?

9

Toto plati, ale aj tak by som trval na designe consumer side logiky. Pri jednoduchych operaciach to ide, ale ako nahle vznikaju orchestracie a sekvencie volani je nutne to formalizovane zachytit. Co ked by sme ta chceli nahradit :wink: ? Ako to niekto preberie ?

Provider-side sedi. Vystavit. Otvorit. Pouzivat. Merat. Zlepsovat.

Toto sa vyriesi v standarde riadenia IT projektov, do ktoreho sa zakomponuje aj integracia a urci sa “miera byrokracie” podla velkosti realizovanych zmien a bude sucastou projektovej dokumentacie.

10

Tomuto asi nerozumiem. Ved spravim nove API, konzumentom poslem, ze stare API je deprecated a 1.1.2020 konci - tuto mate nahradu a bude sa to po novom robit takto a takto, kricat mozete do 1.1.2020. Ten kto ma bude chciet nahradit bude nutne musiet aj tak nejako vymysliet “prechodne obdobie” a na to mu velmi mapa toho ako si to konzumenti na zaciatku vymysleli asi velmi nepomoze.

Inak ked sme pri tom, tie DIZ (dohoda o integracnom zamere) dokumenty koncia kde a co sa s nimi robi?

11

Vyssia ako potrebna miera byrokracie/narocnosti bola uz identifikovana, takze po novom sa maju DIZ robit viac elektornizovane a koncit tu Testovaci DIZ v metais
Inak rozdelenie tohto threadu na viacere temy by mozno nezaskodilo…

1 Like
12

Toto je ako nova vec?

13

Ano, lenze tym ze to bolo hotove az na konci OPIS obdobia, tak v ostrej verzii nic nie je. Tento “elektronicky” sposob vyplnania sa tyka studii, DIZ a aj SLA medzi tymi co sa integruju. Tak aby co najviac veci bolo pokope na jednom mieste a elektronicky (predtym bola povinnost evidovat to v metais, v roznych pomocnych integracnych dokumentoch a v samotnom DIZ).

Ohladom narocnosti usmernenia k integracii - podla mojho nazoru bolo take robustne aj z toho dovodu, ze sa javilo, ze integrujuce sa strany sa obcas snazia zo svojich povinnosti vyzut - a toto bola paka na to, ako ich donutit k nejakej systematickej realizacii.

14

Imho základná chyba bola postaviť integráciu ako voľnú (avšak zmluvne záväznú?) dohodu dvoch nezávislých subjektov. To nevyhutne viedlo k tomu, že čo integrácia, to samostatné “vyjednávanie”. V prostredí jednej verejnej správy, ktorá funguje v uniformnom prostredí (v medziach zákonov), však so zreteľom za efektívnosť to nedáva zmysel. Samozrejme že subjekty musia vedieť čo sa deje, komunikovať spolu a mať možnosť vylúčiť excesy (úmyselne nepíšem schvaľovať riešenie). Komunikačná matica a eskalačný mechanizmus sú výborné časti dnešných “ISL agreement kontraktov”.

Ja by som integrácie ISVS neprirovnával ani tak ku komerčným B2B, ale skôr k vnútro-koncernovým prepojeniam. Z pekného zoznamu čo poslal @ret sú 1-3 predsa riešené na úrovni riadenia informatizácie verejnej správy (napr. strategické dokumenty, schvaľovanie projektov, štúdie), 3-7 je v rámci analytickej etapy projektu a zachytené v súvisiacej projektovej dokumentácii, 8-10 je štandardná projektová postupnosť, zachytená v riadiacej dokumentácii projektu. Veď sa aj všetka tá dokumentácia zbierala na jednom mieste, všakže ASPR.

Ďalšia kľúčová vec je silná štandardizácia.
Jasné že sú a budú aj úplne špecifické prepojenia, ale väčšinou ide fakt o generické “zápis údajov X”, alebo “poskytnutie údajov Y”. Pre takéto funkcie treba predpísať konkrétne API, dátové štruktúry, riadenie prístupu, centralizovať riadenie zmien atď. Čakám @ret na tie príklady množstva už v integrácii realizovaných orchestrácií a sekvencií volaní - ono totiž fungovanie verejnej správy as-is je dosť optimalizované na vylúčenie takýchto komplikovaných interakcií.

SLA sú dnes v podstate bezzubé. Zatiaľ som nevidel nieže vzájomné sankcie za porušenie SLA, ale ani poriadne monitorovanie plnenia výkonnosti/parametrov (obvykle sa “monitoruje” reportovaním hlásení) a mám tušenie, že málokedy sa na strane konzumenta na základe hodnôt v SLA vôbec robili nejaké rozhodnutia (okrem doby štandardnej odozvy). Treba minimálne určiť štandardizovanú zodpovednosť/správanie v prípade nedostupnosti (keď už nie priamo BCM) a spôsob monitorovania/riešenia vzájomných väzieb.

To len zopár úvah… Ozaj si pamätám, keď v 2014 tu spomínané usmernenie k integrácii bolo vydané, s akým očakávaním po ňom veľa ľudí siahlo (vrátane mňa) - lebo bolo jasné že postup ako dovtedy je chaos. Veľmi nepomohlo.

Ináč pre tých čo nepoznajú - tu je diagram všetkých integrácií ku 31.12.2015, vrátane plánovaných aj už zrušených. Obrázok vznikol ako súčasť “analýzy stavu informatizácie”, keď bol ešte plán zachrániť pôvodnú verziu NKIVS takýmito …doplnkami.

15

Skusim odpovedat na obidva dopyty. @jsuchal - nie je to o provider side integracie to sedi, ale consumer side je to co som spominal aj v pripade integracie na existujuce sluzby.

takze velmi high level AS-IS flow niektoreho eGov podania

  1. redirect portalu na IdP vratane overenia platnosti SSO, ak nie je session prihlasenie a vydanie access tokenu
  2. volanie sluzby pre ziskanie identifikacnych udajov identity
  3. volanie sluzieb referencnych registrov za ucelom predvyplnenia formulara referencnymi udajmi
  4. volanie sluzieb agendovych evidencii za ucelom predvyplnenia specifickych udajov do podania (napr. ziskanie niektorych udajov z predchadzajuceho podania)
  5. volanie sluzieb pre validaciu udajov, ktore zadal obcan/podnikatel (validaciu robime server-side vsakze ;))
  6. volanie internej utility pre autorizaciu podania (moze byt nahradene opat server-side implementaciou)
  7. volanie sluzieb podatelne pre posunutie podania na spracovanie na strane OVM
  8. volanie sluzby schranky, aby sa podanie dostalo do sekcie odoslanych sprav (chceme aby obcania videli co poslali OVM, ci ? )

… pokracuje servisna orchestracia v moduloch OVM
9) overenie platnosti cerfikatov podpisu napr. volanim OCSP
10) volanie sluzby pre nastartovanie procesneho enginu
11) procesny engine vola automatizovanu kompozitnu sluzby pre automaticke rozhodnutie pripadne doplnenie udajov potrebnych pre ludske rozhodnutie
11) ak nedoslo k automatizovanemu rozhodnutiu process engine realizuje priradenie na spracovatelsku rolu (Human Task)
12) vykonanie manualneho rozhodnutia a zapis udajov rozhodnutia do evidencie (@Lubor - tu je ten zapis co spominas)
13) volanie transformacnej sluzby pre pripravene rozhodnutie (chceme pekne pdf)
14) opat autorizacia rozhodnutia mandatnym podpisom, pouzijeme PADES
15) volanie sluzby schranky pre zaslanie rozhodnutia

… takze tych sekvencii a orchestracii je v end-to-end procese vybavenia sluzby pre obcana a podnikatela dost. Su decentralizovane a hardcodnute v komponentoch, ktore dodavaju rozni vendori. Cielom bolo mat tuto implementaciu zdokumentovanu a dat pomocnu ruku OVM, aby vedeli tieto veci vynutit od dodavatelov. DIZ a ISLAK boli len formalne uvodne a ukoncovacie casti integracie. Dolezity mal byt ten obsah medzi tym.

@jsuchal - ak my oznamis, ze sluzba formatovania sa stava deprecated a 1.1.2020 konci, takto moj novy vyvojar vie, ze tuto sluzbu volame v 13 kroku procesu, ma k dispozicii datovy mapping a vie velmi rychlo zareagovat na tvoju zmenu :wink: pripadne najst novsie a lacnejsie riesenie tohto procesneho kroku.

pevne verim ze v pripade TO-BE implementacie ZS sa podari orchestraciu centralizovat a podla flow-u ZS pripajat jednotlive sluzby agendovych ISVS pre vybavenie ziadosti obcana/podnikatela standardizovane a so zapojenim poriadneho monitoringu typu BAM.

Tak to nie som potom rad, budem sa snazit zistit, ci to nepomohlo kvoli contentu dokumentu, alebo kvoli pristupu integracnych stran k svojim povinnostiam a pripadne zozbierat feedback pre dalsi update, ktory by sa uz zakomponoval do standardu.

16

do debaty…nase skusenosti

2 Likes
17

Presne tak aby to cele fungovalo, este vela prace, drobnej a uzitocnej

API - chyba verejny pristup k api a jeho dokumentacii - katalog api rozhrani a ich popisu. mame nato miesto, v metais by mohlo byt nieco ala swagger

demo/vyvoj prostredia - velmi by pomohlo, keby vyvoj prostredia boli vystrcene do internetu ako to ma napr. nases, nases okrem toho by mohol: dorobit na vyvoj/test moznost vytvorenia si testovacej identity (kludne nech je platna obmedzene) a validator formularov (nech pripadne chyby nemusime riesit cez service desk, urcite by to odbremenilo ich support)

katalog referecnych udajov - kedy?

kto uz konecne vylozi ten sporny zakon o ochrane osobnych udajov, ktorý bráni uplatňovať jedenkrát a dosť? @skdd tuším §12 ods. 2

1 Like
19

myslel som zakon 122/2013 ktory je podla viacerych ministerstiev v rozpore s ustanovenim 315/2013

20

Ja by som im odporucil aj nejaky normalny tiketovaci system, lebo to co tam predvadzaju s tou ich politikou “do nazvu predmetu napiste identita xy - zzz - yyy - predmet problemu” a namiesto toho, aby ked to clovek posle zle, si to proste interne (ako kazda normalna firma co robi support pre klientov) preklasifikovali, tak budu vypisovat naspat maily, ze to nema spravny format.

A inak statny stackoverflow by sa tiez uzivil. Discourse je opensource, plugin na spravnu odpoved tam je. Netreba ani vymyslat koleso a obstaravat drahe veci.

2 Likes
21

Ak hovorime o statnom stackoverflow, tak mozno by sa uzivila aj nejaka statna a verejna bugzilla / JIRA na nahlasovanie chyb.
A myslim ze na pouzitie by malo byt k dispozicii toto https://wiki.finance.gov.sk

1 Like
22

ako to zazdielat tak, aby sa o tom dozvdelo co najviac ludi? pripadne aj ine vyklady co budu v buducnosti? Financny spravodajca? Aktuality na informatizacia.sk?