Red Flags: Centrálna API manažment platforma (API GateWay)

Názov: Centrálna API manažment platforma (API GateWay)

Garant: Úrad podpredsedu vlády SR pre investície a informatizáciu

Stručný opis: Vybudovanie centrálneho komponentu v zmysle NKIVS, referenčnej architektúry eGovernmentu, ktorého cieľom je publikovanie API pre subjekty verejnej správy a aj pre subjekty mimo verejnej správy, t.j. pre súkromný sektor vo forme otvorených API (OpenAPI).

Náklady na projekt: Štúdia uskutočniteľnosti 7,5M Eur (investície) + 5,6M Eur (prevádzka 10 rokov) s DPH

Aktuálny stav projektu: Obstarávanie/nákup

Čo sa práve deje:

  • príprava verejného obstarávania na “API Manažment Platforma”
  • príprava verejného obstarávania “PUBLICITA pre projekt”
  • príprava verejného obstarávania “Metodika pre monetizáciu využívania API rozhraní elektronických služieb IS VS”
  • príprava verejného obstarávania na “Dokumentácia”

Zhrnutie hodnotenia Red Flags: Štúdia uskutočniteľnosti je v určitých častiach pomerne dobre a detailne rozpracovaná. Tento fakt súvisí s tým, že predmetom je technologický komponent. Problémy vidím v určitých oblastiach ako sú alternatívy a stanovenie nákladov. Z hľadiska biznis požiadaviek je možné sa s väčšinou požiadaviek stotožniť, otázne sú špecifikácie modulu monetizácie, využitia výsledkov projektu vo forme PaaS a prioritizácie publikovania pilotných služieb/API. Ako dôležitý míľnik vnímame akceptáciu a overenie aktuálne vznikajúceho riešenia MUK-P, ktorého pokračovaním je projekt opísaný v štúdii uskutočniteľnosti. Pred akceptáciou by mala byť zhodnotená biznis stránka projektu (biznis a funkčné požiadavky), náklady a zvolené technológie (štandardnosť riešenia, použité technológie, kvalita zdrojového kódu a dokumentácie, možnosť substitúcie) MUK-P.

Stanovisko Slovensko.Digital: So zameraním navrhovaného projektu súhlasíme, ide o vybudovanie centrálneho riešenia/bloku eGovernmentu pre OpenAPI, čo je koncept za ktorého realizáciu sa aj Slovensko.Digital dlhodobo zasadzuje. Pri viacerých okruhoch biznis požiadaviek projektu vidíme potrebu detailnejšieho a konštruktívnejšieho dialógu v rámci relevantných pracovných skupín. Odporúčame štúdiu uskutočniteľnosti schváliť s podmienkou overenia vhodnosti MUK-P a budovania ďalších častí projektu nad týmto riešením.

:triangular_flag_on_post: HODNOTENIE RED FLAGS

I. Prípravná fáza


Reforma VS :star::star::grey_star::grey_star:

Reformný zámer existuje a schválený.

Vhodné by bolo, aby jasne popisoval procesy dátovej kancelárie na UPVII, ktorá by mala vystupovať ako biznis owner Centrálnej API manažment platformy. Integračná kancelária by mala pôsobiť ako koordinátor publikovania API, mala by realizovať prieskumy požadovaných API, realizovať ich prioritizáciu a pod. Bez týchto aktivít sa ťažko dosiahnú želané a potenciálne úspechy, ktoré otváranie API so sebou prináša.


Merateľné ciele (KPI) :star::star::grey_star::grey_star:

Reformný zámer definuje aktivity a teda aj KPI pre širšiu skupinu aktivít a projektov ÚPVII. Ako rizikové vnímame naplnenie relevantných ukazovateľov spojených s týmto projektom v roku 2020.

KPI_1


Postup dosiahnutia cieľov :star::star::grey_star::grey_star:

Harmonogram implementácie by mohol byť detailnejší a viac zameraný na fázu implementácie projektu, miľníkov a pod.

Kľúčový krok predstavuje dodanie a otestovanie pilotného riešenia (MUK-P) a vyhodnotenie, či spĺňa definované požiadavky a je vhodné nad ním budovať ďalšiu funkcionalitu plánovaného projektu.

Harmonogram implementácie by mal rešpektovať iteratívnejší prístup, t.j. plánovanie projektu a jeho výstupov by malo byť zamerané na dodávanie vertikálnych rezov potrebnej funkcionality v čase.

Harmonogram by mal jasne identifikovať dodanie “must have” funkcionality a následne “nice to have” funkcionality. “Nice to have” funkcionalitu má význam dodávať až po reálnom používaní “must have” funkcionalít, aby požiadavky na rozširovanie vyplývali z reálneho používania a reálnych potrieb.


Súlad s KRIS (nie je zatiaľ vyhodnotený)

hodnotenie


Biznis prínos :star::star::star::grey_star:

Projekt plní záväzok a ciel z NKIVS.
Projekt predstavuje centrálny komponent referenčnej architektúry eGovernmentu.
Z pohľadu biznis prínosov, biznis požiadaviek kriticky vnímame moduly:

  • monetizácie,
  • API GW ako PaaS,
    Navrhujeme, aby tieto moduly boli predmetom diskusií v rámci pracovnej skupiny Lepšie služby, overili sa dané biznis požiadavky a v prípade potreby sa definovali potrebné postupy, metodiky pre tieto témy. Takýto postup zabezpečí širší dialóg a identifikáciu reálnych problémov v rámci daných tém.

Oceňujeme plán a ambíciu publikovania pilotných agendových služieb/API do vytvoreného riešenia. Dôležité je, aby boli publikované služby s pridanou hodnotou a potenciálom na vysokú adopciu, ich využitie spolu s inými službami do komplexnejších služieb. Preto navrhujeme, aby bol zo strany UPVII vedený dialóg a prioritizácia služieb pre pilotné publikovanie. Publikovanie služieb/API systému ITMS2014+ nepovažujeme úplne za vhodné, skôr odporúčame publikovanie vhodných služieb/API UPVS.

Publikovanie pilotných služieb vnímame ako možnosť demonštrácie procesu, postupu, nákladov pre ďalšie OVM, ktoré budú povinné služby/API svojich agendových IS publikovať do Centrálnej API manažment platformy. Referenčné náklady môžu slúžiť ako vstupy do pripravovaných dopytových výziev pre OVM.


Príspevok v informatizácii :star::star::star::grey_star:

Projekt predstavuje centrálny komponent referenčnej architektúry eGovernmentu v SR.

Projekt napomáha k:

  • plneniu cieľov NKIVS,
  • zabezpečuje a vynucuje požadované architektonické princípy,
  • podporuje a vytvára prostredie pre vznik nových inovatívnych a komerčných služieb,
  • poskytuje nástroje na monitorovanie využívania jednotlivých služieb/API,
  • efektívnejšej alokácii finančných zdrojov na strane štátu (zníženie nákladov na integrácie, alokácia zdrojov na služby, ktoré sú používané a pod.)

Štúdia uskutočniteľnosti :star::star::grey_star::grey_star:

Štúdia je spracovaná v zmysle pokynov, postupov a definovaného formuláru.

Oceňujeme rozdelenie štúdie na logické celky/moduly navrhovaného projektu, pokus o definovanie “must have” a “nice to have” funkcionality jednotlivých modulov, posúdenie možností implementácie jednotlivých modulov (existujúce riešenie/produkt vs. custom vývoj), atď.

Oceňujeme snahu o komparáciu existujúcich riešení/produktov dostupných na trhu a riešenia MUK-P medzi sebou na základe definovaných požiadaviek. Na druhú stranu sme názoru, že určité vyhodnotenia nie sú korektné a zároveň MUK-P je možné voči daným požiadavkám hodnotiť len na papierovej úrovni, nakoľko dané riešenie sa ešte len implementuje.

V štúdii chýba detailnejší popis MUK-P ako riešenia, nad ktorým sa má budovať projekt. MUK-P predstavuje riešenie, ktoré ešte len vzniká. Štúdia obsahuje minimum informácií o danom riešení. Štúdia by mala jasne popísať:

  • služby, ktoré bude MUK-P poskytovať,
  • technológie, ktoré sú použité pri budovaní MUK-P,
  • náklady plánované na vybudovanie MUK-P,
  • náklady na prevádzku MUK-P.

Tieto informácie by prispeli k lepšiemu rozhodovaniu a posúdeniu vhodnosti MUK-P.


Alternatívy :star::grey_star::grey_star::grey_star:

Alternatívy pokrývajú základné koncepty prístupu k realizácii a implementácii projektu:

  • A - nerobí sa nič,
  • B - realizovanie API manažment platformy nad existujúcimi riešeniami,
  • C - alternatíva B rozšírená o ďalšie funkcionality, t.j v plnom rozsahu,
  • D - využitie dostupných služieb (SaaS) na budovanie alternatívy v plnom rozsahu.

Sme názoru, že kvôli objektívnosti a správnemu rozhodnutiu by napomohlo, keby alternatíva B (budovanie nad existujúcim riešením) mala 2 podalternatívy, t.j.:

  • budovanie nad MUK-P,
  • budovanie nad konkurenčným produktom/riešením voči MUK-P, t.j. produkt/riešenie dostupné na trhu, napr. Kong, Tyk, apigee.

Sme názoru, že porovnanie týchto 2 podalternatív je logické a žiadané, aby sa jasne určil interval nákladov, rizík vo vzťahu k použitým technológiám a pod.

Alternatívu D vzhľadom na možnosti použitia EÚ finančných prostriedkov považujeme za irelevantnú. Zároveň nie je možné očakávať, že služba dostupná ako SaaS pokryje kompletne všetky požiadavky, nakoľko je jasné, že niektoré požiadavky sú špecifické a je potrebný aj custom vývoj.

Oceňujeme snahu v kapitole 2.4.2.3 Mapovanie funkčných požiadaviek s špecifických požiadaviek na existujúce riešenia posúdiť/otestovať vhodnosť existujúcich riešení ako Kong, Tyk, apigee voči požiadavkám. Ale sme názoru, že určité požiadavky neboli vyhodnotené korektne a že nesplnenie niektorých požiadaviek by malo mať dopad na vylúčenie konkrétneho riešenia (niektoré požiadavky vnímame ako nie veľmi dôležité). Zároveň sme názoru, že nakoľko MUK-P ešte len vzniká, tak je ťažko zhodnotiť, či by tiež splnil všetky definované požiadavky.

V štúdii chýba detailnejší popis MUK-P ako riešenia, nad ktorým sa má budovať projekt. MUK-P predstavuje riešenie, ktoré ešte len vzniká. Štúdia obsahuje minimum informácií o danom riešení. Štúdia by mala jasne popísať:

  • služby, ktoré bude MUK-P poskytovať,
  • technológie, ktoré sú použité pri budovaní MUK-P,
  • náklady plánované na vybudovanie MUK-P,
  • náklady na prevádzku/liecenciu MUK-P.

Je potrebné zdôrazniť, že projekt/aktivity vyplývajúce zo štúdie budú predmetom verejnej súťaže a teda je potrebné zabezpečiť, aby MUK-P bol vysoko štandardný produkt/riešenie, aby jeho prevzatie víťazom verejného obstrávania mohlo byť bezproblémové alebo ak sa bude poskytovať vo forme licencie, tak nech cena za takúto licenciu je obdobná komerčným produktom s obdobným rozsahom funkcionality a nech prípadná substitúcia tohto produktu/riešenia je čo najjednoduchšie realizovateľná.


Kalkulácia efektívnosti :star::grey_star::grey_star::grey_star:

Rok návratnosti projektu považujeme za nie reálny. Vo vzťahu k stavu ostatných plánovaných agendových IS VS, k architektonickým princípom použitých v rámci existujúcich IS VS, k plánu financovania vytvorenia chýbajúcich služieb/API a ich publikovania cez dopytové výzvy vidíme riziko, že nebudú naplnené prínosy v tak krátkom čase. V rámci aktuálnej dopytovej výzvy na Malé zlepšenia eGov nie je predložená ani jedna ŽoNFP.

Vybratá alternatíva počíta s použitím MUK-P a teda budovania projektu nad týmto riešením. Sme názoru, že pre správne zhodnotenie z ekonomického pohľadu by mali byť výdavky na MUK-P zahrnuté do TCO projektu. Riešenie MUK-P je financované zo štátneho rozpočtu. Ide o relevantný náklad, ktorý by mal byť započítaný do TCO. Keby sa zvolila alternatíva, že sa projekt ide budovať nad existujúcim riešením dostupným na trhu, napr. Kong, Tyk, apigee, tak licenčný poplatok za takýto produkt by vstupoval do TCO projektu. Teda analogicky sme názoru, že náklady na MUK-P by mali byť zahrnuté do TCO projektu.

Zo štúdie uskutočniteľnosti a ani z CBA nie je úplne jasný postup a spôsob určenia pracnosti/počtu človekodní na jednotlivé moduly. Zverejenenie spôsobu a určenia pracnosti jednotlivých modulov by bolo prospešné pre konštruktívnejší dialóg.

Aktuálny počet pre niektoré moduly predstavuje pomerne vysokú pracnosť:

  • modul Monetizácia 693 MD,
  • modul Testovanie 1 092 MD,
  • modul Manažment tretích strán 1 449 MD,
  • modul PaaS API 1 239 MD,
  • aktivita Publikovanie služieb/API 1 449 MD,
  • aktivita Integrácie a migrácie 966 MD.

Sme názoru, že v rámci vyššie uvedených modulov a aktivít sú ocenené aj nie potrebné požiadavky. Odporúčame pred vyhlásením VO viesť odbornú diskusiu (napr. prípravné trhové konzultácie) k jednotlivým modulom a tak zefektívniť potrebnú funkcionalitu a jej potrebnú pracnosť. Zároveň odporúčame viesť diskusiu v rámci pracovných skupín k témam ako monetizácia, PaaS, publikovanie API.

CBA v rámci položky prevádzka počíta s finančnými zdrojmi na zmeny, ktoré vyplynú z legislatívnych zmien a požiadaviek na základe reálnej implementácie. Odporúčame tieto finančné prostriedky rozpočtovať a sledovať samostatne.


Participácia na príprave projektu :star::star::star::grey_star:

Veľmi pozitívne oceňujeme, že riešiteľ štúdie poskytol a viedol interaktívny dialóg s tretími stranami.
Nedostatok vidíme, že do dialógu neboli intenzívnejšie a v dostatočnom časovom predstihu zapojené subjekty/útvary, na ktoré má plánovaný projekt priamy dopad:

  • Nases - publikovanie pilotných služieb UPVS a dialóg o komponente/riešení MUK-P. Štúdia počíta budovanie celého projektu práve nad riešením MUK-P.
  • odbor ITMS2014+ - publikovanie pilotných služieb.

Diskusie k projektu na platforme:


:file_folder: Dokumenty


:clock2: Aktivity

V tomto projekte už prebehli nasledovné dôležité aktivity / míľniky:

  • 21.1.2019 Termín na predkladanie pripomienok k štúdii uskutočniteľnosti
  • 21.2.2019 - schválený reformný zámer
  • 21.2.2019 - schválená štúdia uskutočniteľnosti
  • 27.3.2019 - vyhlásená výzva na predkladanie žiadosti o NFP
  • 1.7.2019 - predložená žiadosť o NFP
  • 2.12.2019 - schválená žiadosť o NFP
  • 12.12.2019 - podpísaná zmluva o NFP (https://www.crz.gov.sk/4361412/)
  • 30.3.2020 - začiatok realizácie EŠIF projektu (23 mesiacov, t.j. do 30.1.2022)

Nku potvrdil presne to, čo sme hovorili od začiatku.

1 Like

Zdrojaky za vyse 100M, tak to je sila. Hlavne nerozumiem, ked su v omeskani vyse 30 mesiacov, preco uz davno nie je zrusena zmluva a dodavatel na sude

Že sa gt takto otvorene priznáva k tomu, že muk-p bola príprava na to aby dostali camp, to som teda nečakal. Samozrejme nás vtedy na upvii všetci presviedčali, že samozrejme, že to takto určite nebudem. Normálne sprostí klamári.

A ten bonus, že na open api komponent požívajú otvorené štandardy tak to je akože nejaký bonus? Veď toto im nezozerie ani škôlkar. Samozrejme, že toto bola defacto povinnosť tak urobiť. Máme im poďakovať, že nepoužili na open api nejaký ich proprietarny protokol a nový sktalk? Oni sú úplne z iného vesmíru.

1 Like
1 Like

Väčšiu somarinu som už dávno nečítal. Niektorí ľudia by mali chodiť po kanáloch.

Vieš napísať viac? Z toho článku mi napr to ze to nechceli prebrať ako somarina neprijde. Alebo to je cele úplne inak?

Akosi sa v tej sprave zabudli pochvalit tym, ze tam este bola polozka cca 3M eur za vyvoj komponentu, ktory sa dal normalne kupit a len napojit na UPVS. Tak ako to robia vsetky normalne komercne firmy. Taktiez tam akosi zabudli povedat, ze gro produktu nemal byt nejaky technologicky komponent co preklada SOAP na REST, ale zjednodusenie integracie na statne systemy. Este dnes si pamatam ako architekt GT p. Roland Takacs po vsetkych PS a uradoch svato svate prisluboval, ze toto zjednodusi integracie a nebude treba ziadne papiere. Vysledok je taky, ze nedokazali vypublikovat takto ani sluzby “vlastneho projektu slovensko.sk”. Svedkom tohto bol minimalne @kyselat

Avsak toto neuchopil ani NASES ani UPVII v tom case ako svoju temu. A teda, ze toto mala byt prerekvizita na sluzby statu na mobile, tak to je uz uplna haluz. Toto bol glorifikovany rate limiter a preklapac SOAPu na REST (pricom nebolo ani jasne, ze kto okrem GT toto chce) a nejaky pokus o samoobsluzny developer portal (vsetko dostupne hotove veci). Levi podiel na tomto zalostnom vysledku a stave projektu ma UPVII a NASES v tom case.

Ja sa dnesnemu NASESu absolutne necudujem, ze sa tohto dalsieho vendor-locku s fuzami na dalsie projekty nechcelo ani len dotknut. K tomu ci to mohli alebo nemohli prevziat ked bola podpisana zmluva (minulym vedenim) sa vyjadrovat nechcem, natolko do zmluvy nevidim. Nakolko je tento spor je len predohra k niecomu dalsiemu neviem. Trochu sa k tomu vyjadril Kubina u mna na FB. Redirecting...

Drahý, pomalý, meškajúci a bez zdrojových kódov – modul MUK portálu slovensko.sk - Aktuality - Najvyšší kontrolný úrad Slovenskej republiky?

Zaspominajme si aj tu, 3 roky dozadu.

2 Likes

robil som pripomienky k analýze. už vtedy bolo jasné, že GT netuší, čo treba riešiť, navyše im to bolo evidentne jedno. ale prevalcovali ma manažérske rozhodnutia. bohužiaľ, kým v tomto štáte budú manažovať IT ľudia, ktorí tomu nerozumejú, lepšie to nebude.

1 Like

Ja som presvedceny, ze problem naozaj nebol v tom, ze by tomu nerozumeli. Proste biznis zaujmy boli silnejsie. V klude nech je manazerom aj vystudovany manazer drevorubacov pokial necha odborne rozhodnutia na odbornikov.

2 Likes

v tomto s tebou nesúhlasím. tvoj postoj predpokladá absolútnu dôveru manažérov voči odborníkom a dostatočnú erudovanosť týchto odborníkov. sú aj takí, ale väčšinou to tak nie je.

presvedčiť o niečom manažéra, ktorý veci nerozumie, je oveľa zložitejšie, ako toho, čo veci rozumie.
zvlášť, ak nejde o jednoznačné win-win riešenie, ale častokrát zložitejší, hoci procesne lepší postup.

1 Like

Neviem s cim nesuhlasis, ja viem, ze pokial manazer IT rozumie je to lepsie. Ale aj manazer, ktory IT nerozumie je lepsi ako “manazer”, ktory sa prisiel pozerat vedla a dohadzovat biznis.

3 Likes

áno, jasné. ale s dohadzovačmi ja, našťastie, nepracujem.

Protokol NKÚ z kontroly NASESu:

NKU_Protokol_NASES_KA-029_2021.pdf (1.9 MB)

3 Likes

Možno trochu od veci, ale musím sa opýtať keď Vás tu vidím. (a dokonca pomáhajúceho z FS SR rovno nad Vami)
Tie ostatné utajené zmluvy na FS SR (Beset a Lynx) už nebudete požadovať k zverejneniu? Pretože minimálne pod jednou z nich sa veselo dodávajú služby aj tento rok. Okrem Alexisu ide Imrezcem a Brhelom nastavená mašinéria ďalej.

Ďakujem za protokol NKU. Zarážajú ma niektoré veci:
s. 8: KS (kontrolná skupina?) vyžiadala od NASES stanovisko, či zákaznícky vyvíjané riešenie MÚK-P bolo v období uzatvárania zmluvy v roku 2017ako najhospodárnejšie a najefektívnejšie z dostupných možných riešení. NASES sa vyjadrila listom zo dňa 30.07.2021č. 100-2021/3306-7194, v ktorom uviedla základné porovnanie riešenia API GW zakontrahovaného ako súčasť dodávky riešenia ÚPVS s komerčným produktom CA/Broadcom, ktorý je pomerne rozšírený na slovenskom trhu a ďalej nasleduje popis a porovnanie. Chápem to správne, že sa tam jednostranne prezentuje názor NASESu? Analýzu v konečnom dôsledku nevykonal NKU, ale samotný kontrolovaný NASES? Nemalo by v záujme objektivity analýzu vykonať NKU?

s. 13 Zistenie č. 1 - NKU vytýka že NASES porušila finančnú disciplínu, ale neuvádza v akej sume?

s. 13: Kontrolná skupina (KS) vyžiadaním č. Z-003900/2021/1063/ZFA požiadala subjekt o poskytnutie vyjadrenia ÚHP k projektu. NASES sa odpoveďou z 25.06.2021 vyjadrila, že takéto vyjadrenie „nebolo predmetom posudzovania“. Prečo sa nepýtali priamo ÚHP???

s. 18: Zistenie č. 3 - NKU vytýka porušenie zákona o majetku štátu a v tej istej vete tvrdí že NASES nedisponuje majetkovým právom podľa § 19 ods. 4 Autorského zákona a že sa vedome vzdal
vlastníckych, resp. majetkových práv. Toto mi hlava neberie …

2 Likes

Pre info. Bol som nominovany do riadiaceho vyboru tohto projektu ako clen bez hlasovacieho prava.

Momentalne prebieha pripomienkovanie DNR (detailny navrh riesenia) a kedze dohoda je, ze z RV nevynasam informacie pokym nebudu verejne dostupne v zapisoch a zverejnenych dokumentoch, tak nateraz len napisem, ze som poslal pripomienky.

Nic z toho co som mal moznost sa na RV dozvediet alebo si precitat vsak nepovazujem za tajne, budem teda tlacit na este vacsie otvorenie a participaciu.

2 Likes

parpici…

parciti…

paprici…

patripi…

no taaak…

:smiley:

Asi ste príliš mladý, ale teda ja si pamätám, keď sme sa nemohli zúčastniť ani len pripomienkovania štúdie. Vlastne si pamätám, keď žiadne pripomienkovanie ani neexistovalo. Toto naozaj je niečo veľmi nové a lepšie.

Prečo tieto dokumenty nedávajú von úplne nerozumiem, ale stále je to zásadný posun.