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.
HODNOTENIE RED FLAGS
I. Prípravná fáza
Reforma VS 
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)
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.
Postup dosiahnutia cieľov
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
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
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
Š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
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
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
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:
- pomerne veľka diskusia, priebežné pripomienky S.D k tejto štúdii je tu OpenAPI / Otvorené API - plánované a realizované aktivity Slovensko.Digital
Dokumenty
- Reformný zámer
- Štúdia uskutočniteľnosti SU OPII API_GW_v1.10.docx (1.3 MB)
- CBA CBA_OPEN_API_Variant_80-20 - Agendove IS 0.13.xlsx (397.3 KB)
- Link na oznam ohľadne štúdie uskutočniteľnosti OZNAM: Verejné pripomienkovanie štúdie uskutočniteľnosti „Centrálna API Manažment Platforma“ | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
- Link na dokumenty publikované v MetaIS https://metais.finance.gov.sk/studia/detail/ed6146af-477e-0052-d178-cc75c5dd7876?tab=documents
- Zmluva o NFP 1267/2019 | Centrálny register zmlúv
- Osoby zodpovedné za projekt: Pavol Bandura pavol.bandura@vicepremier.gov.sk
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 (1267/2019 | Centrálny register zmlúv)
- 30.3.2020 - začiatok realizácie EŠIF projektu (23 mesiacov, t.j. do 30.1.2022)
