Centrálna API manažment platforma (API GateWay)

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

7,5M Eur (investície) + 5,6M Eur (prevádzka 10 rokov) s DPH

Garant

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

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.

Aktuálny stav projektu

Príprava projektu

Čo sa práve deje

  • 21.2.2019 Schvaľovanie štúdie v rámci Riadiaceho výboru OPII

Hodnotenie


Posledná aktualizácia: 29.03.2019

I. Prípravná fáza

Reforma VS

Merateľné ciele (KPI)

Postup dosiahnutia cieľov

Súlad s KRIS

Biznis prínos

Príspevok v informatizácii

Štúdia uskutočniteľnosti

Alternatívy

Kalkulácia efektívnosti

Participácia na príprave projektu

II. Obstarávanie / nákup

Stratégia obstarávania

Prípravné trhové konzultácie

Druh postupu

Predmet zákazky

Podmienky účasti

Kritériá hodnotenia

Vendor Lock-in a Autorské práva

Lehoty

Obchodné podmienky

Hospodárska súťaž

Subdodávatelia

Rozdelenie na časti

Vyhodnotenie obstarávania

Cena

Detailné hodnotenie projektu

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