Poslovanje preko API-jev – od ideje do izvedbe

Podjetja vseh velikosti se bolj in bolj zavedajo, da API-ji postajajo novo področje poslovanja. Če smo pred leti delili kanale predvsem na fizično prodajo (klasično) in digitalno preobrazbo oz. digitalne kanale, ki običajno potekajo preko spletnih ali mobilnih aplikacij, je danes vedno bolj jasno, da se uveljavlja nov kanal – API-ji (aplikacijski programski vmesniki).
Share on facebook
Share on twitter
Share on linkedin
Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on email

Matjaž Jurič

Profesor na Fakulteti za računalništvo v Ljubljani

Anton Zvonko Gazvoda

Raziskovalec

API-ji omogočajo oblikovanje novih vrednostnih verig. To smo slišali že velikokrat, vendar v zadnjem obdobju te nove vrednostne verige postajajo realnost tudi v Sloveniji. Kaj to pravzaprav pomeni? To je odvisno od tega, kje v tej verigi želimo sodelovati. Na eni strani imamo pobudnike novih vrednostnih verig oz. poslovnih modelov, na drugi strani pa podjetja, ki bi želela v teh verigah sodelovati. In za oboje je potrebno vzpostaviti temelje API ekonomije, le da je v drugem primeru, kjer bo neko podjetje v takih verigah le sodelovalo, te precej enostavneje vzpostaviti – še vedno pa ne trivialno. Iz osebnih izkušenj avtorja, ki je sodeloval pri razvoju kar nekaj novih poslovnih modelov oz. vrednostnih verig, lahko povemo, da marsikatero podjetje danes ni sposobno niti sodelovati v API ekonomiji, kaj šele v njej igrati vodilno vlogo. In vse bolj jasno postaja, da razmišljanje managerjev, da bodo pač takrat, ko bodo nastale potrebe po API-jih, zaposlili nekoga, ki bo to na hitro sprogramiral, ne deluje.

Preden se poglobimo v podrobnosti, pa omenimo nekaj praktičnih primerov. Na primer zavarovalnice. Klasično prodajo zavarovalniških produktov vse bolj dopolnjujejo prilagojeni zavarovalniški produkti, ki jih zavarovalnice prodajajo preko API-jev. Primer so nezgodna zavarovanja, ki se prodajajo skupaj z nakupom izdelkov (npr. padal, gorskih koles, ipd.) ali pa storitev (rafting ali kanjoning, ipd.). Prodati nezgodno zavarovanje preko API-ja, kar za končnega kupca pomeni, da nakup opravi kar sočasno z nakupom izdelka ali storitve, je seveda popolnoma druga izkušnja, kot če bi za to bila potrebna še zapletena papirologija in po možnosti »papirnati« dokumenti. Druga ciljna publika so na primer poslovni kupci ali pa marketplace rešitve, preko katerih se prodajajo zavarovalniški produkti. Jih ne poznate? Primer je Revolut, ki poleg bančnih trži tudi zavarovalniške produkte.

Turistične in gostinske storitve, posebej del, namenjen prevozom potnikov ali hrane, so danes nekaj, kar brez API ekonomije ne bi obstajalo. Cenovne agregatorje poznamo že vsi, pripravlja pa se nova generacija rešitev, ki bodo ponujale integrirane rešitve, za katerimi pa bodo stali manjši ponudniki, ki bodo storitve opravljali preko API-jev.

Torej – API ekonomija je veliko več, kot le vzpostaviti API, preko katerega izdajate račune ali sprejemate naročila (za obstoječ poslovni model). API ekonomija vpeljuje nove poslovne modele in prinaša nove priložnosti – za posel, ki je skalabilen.

 

Poslovni vidiki

Za uspešno sodelovanje v API ekonomiji je potrebno najprej razdelati poslovni model. To posebej velja za primer, ko želimo nastopati v vlogi ponudnika nove vrednostne verige. Kdo lahko sodeluje, pod kakšnimi pogoji, kakšen je model monetizacije, kako bo potekal onboarding, kaj bodo imeli od tega partnerji in kaj ponudnik, kako se nivo API modela dopolnjuje z obstoječimi poslovnimi modeli in tako naprej, so vprašanja, na katera je potrebno najti jasne in nedvoumne odgovore.

 

Tehnični vidiki

Naslednji korak pa je tehnični vidik implementacije API ekonomije. Pri tem je potrebno nasloviti vsaj naslednje najpomembnejše korake:

  • Zasnovati in razviti ustrezne API-je na način, da bodo dejansko podpirali transakcijsko delovanje. Na primer, kako na nivoju API-ja zagotoviti, da se bodo transakcije preko API-ja dejansko izvedle natančno enkrat, kako obravnavati napake in odpovedi, kako javljati izredna stanja itd., so pomembna vprašanja, ki jih moramo nasloviti.

Zelo pomemben vidik je tudi vpeljava vseh pomembnih elementov z vidika poslovnega modela. Na primer, če želimo preko API-ja omogočiti nakup vozovnice, kako bomo uredili rezervacijo, kako dolgo bo rezervacija veljala? Kako bomo uredili naknadni preklic kupljene vozovnice ali njeno spremembo?

Kako bomo na nivoju API-ja omogočili, da se poleg rezervacije vozovnice izvedejo še kaki drugi koraki in da uspešnost teh korakov vpliva na to, ali želimo dejansko potrditi nakup vozovnice. Takih in podobnih primerov je še veliko in le dobro načrtovani in implementirani API-ji so nalogi tudi dejansko kos.

  • Testirati API-je in zagotoviti, da delujejo brez napak. Napake v primeru, ko preko API-jev poteka poslovanje, so drage in zahtevne za odpravitev.
  • Zagotoviti ustrezno varnost API-jev. Ta korak je ključnega pomena in zahteva veliko več kot le seznanjanje z OAuth2 in Open ID Connect.
  • Zagotoviti skalabilnost delovanja API-jev. Bodo naši API-ji delovali ustrezno tudi ob povečanem povpraševanju?
  • API-je ustrezno dokumentirati in pripraviti primere uporabe.
  • Vzpostaviti okolje seznanjanja z API-ji in za onboarding uporabnikov. Takemu okolju po navadi pravimo developer portal.
  • Vpeljati orodje in infrastrukturo za celostno upravljanje API-jev.
  • Izpostaviti API-je skozi ustrezna vrata oz. prehod – API gateway.

Seveda zgornji nabor vključuje le najpomembnejše vidike in bi ga lahko dopolnili še v smeri tehnologije (Docker, Kubernetes) in načina razvoja (DevOps, CI/CD) in tako naprej.

Si bomo pa v nadaljevanju pogledali, kako nam pri vpeljavi API ekonomije lahko pomaga platforma Kumuluz, katere sestavni del je orodje za upravljanje API-jev, KumuluzAPI.

 

Kako vzpostaviti API ekonomijo z rešitvijo KumuluzAPI?

 

Rešitev, s katero vzpostavimo API ekonomijo, mora dostaviti funkcionalno podporo za implementacijo procesov znotraj organizacije, kot tudi dotične procese, preko katerih naslovimo potrebe partnerskih organizacij. Poglejmo, kako te procese v neki organizaciji podpremo z rešitvijo KumuluzAPI.

Interni procesi pri API ekonomiji naslavljajo upravljanje API-jev in preoblikovanje le-teh v digitalno sredstvo. Celostno upravljanje API-jev zajema preoblikovanje API-jev v produkte z natančno specifikacijo, dokumentacijo, definiranimi varnostnimi politikami, plani uporabe itd. Interni procesi morajo zagotoviti tudi nadzor dostopa do teh sredstev in njihovo uporabo tako z vidika varnosti, kot z vidika nudenja QoS-a in monetizacije API-jev. Interni procesi API ekonomije naslavljajo tudi optimizacijo razvoja API-jev, saj zagotavljajo pregled nad API-ji, ki v poslovnem okolju že obstajajo in tako zmanjšujejo podvajanja in spodbujajo konsolidacijo samih API-jev in tudi poslovnih funkcionalnosti. Rešitev KumuluzAPI interne procese API ekonomije podpira preko portala za upravljanje in API prehoda.

KumuluzAPI portal za upravljanje nudi funkcionalnosti, preko katerih znotraj organizacije podpremo procese API ekonomije, s katerimi API-je preoblikujemo v sredstva, ki jih lahko uporabimo znotraj organizacije ali pa jih ponudimo zunanjim organizacijam in partnerjem. Portal za upravljanje omogoča centralno upravljanje API-jev, ki zajema centralni katalog API-jev z njihovo specifikacijo, dokumentacijo, varnostnimi politikami za dostop do API-jev, plani uporabe, ki definirajo, kako do API-jev dostopamo itd. KumuluzAPI portal za upravljanje nudi tudi funkcionalnosti za izpostavitev API-jev na portalu za razvijalce in funkcionalnosti, preko katerih razvijalci, tako interni kot zunanji, zaprosijo za dostop do API-jev preko naročnin in onboarding mehanizma. Vsi dostopi do API-jev so zahtevani na portalu za razvijalce, odobreni pa na portalu za upravljanje s strani API upraviteljev.

Dotični procesi API ekonomije zajemajo funkcionalnosti, s katerimi omogočimo dostop do API-jev. Dotični procesi naslavljajo onboarding uporabnikov, naročanje na API-je, centralni dostop do API-jev, peskovnik za interakcijo z API-ji, dostavo dokumentacije in specifikacije API-jev ter dostavo tehničnih informacij za implementacijo integracij z API-ji. Rešitev KumuluzAPI te procese podpira preko komponente portala za razvijalce.

Rešitev KumuluzAPI nudi ločen portal za upravljanje in ločen portal za razvijalce, saj na ta način zagotavlja večjo varnost. Zunanji razvijalci lahko dostopajo le do funkcionalnosti portala za razvijalce, kjer dostopajo do dokumentacije, specifikacije in tehničnih podatkov, potrebnih za dostop do API-jev, kot sta naslov in API ključ. KumuluzAPI portal za razvijalce omogoča enostaven onboarding razvijalcev in enostaven način za dostop do API-jev. Portal za razvijalce nudi samopostrežno specifikacijo in dokumentacijo API-jev in na ta način zmanjšuje nepotrebno interakcijo med razvijalci organizacije in zunanjimi razvijalci.

Glavna komponenta rešitve KumuluzAPI je API prehod. API prehod je lahkotna in skalabilna mikrostoritev, ki skrbi za upravljanje dostopa do API-jev. API prehod je zadolžen za izpostavitev API-jev, zagotavljanje QoS-a, beleženje dostopov, izvajanje varnostnih politik in planov, validacijo API ključev in beleženje zmogljivostnih metrik. KumuluzAPI omogoča postavitev več instanc API prehodov, recimo ločeno instanco za zunanje API-je in ločeno instanco za interne API-je. Na ta način lahko na nivoju omrežja ločimo in izoliramo zunanji promet od notranjega. KumuluzAPI API prehod omogoča enostavno postavitev v visoko-razpoložljivi konfiguraciji in enostavno skaliranje instanc API prehoda. API prehod je neodvisna komponenta KumuluzAPI-ja, ki lahko deluje brez portala za upravljanje in portala za razvijalce (izpad ostalih komponent ne vpliva na delovaje API prehodov).

API prehod beleži vse dostope do API-jev z vidika zmogljivosti kot tudi z vidika monetizacije. Podatke je mogoče pregledovati na portalu za upravljanje, kjer lahko spremljamo zmogljivostne metrike in podatke za monetizacijo (metering uporabe).

Rešitev KumuluzAPI lahko namestimo kot samostojno aplikacijo na VM napravo, v Docker ali Kubernetes.

Primeri uporabe rešitve KumuluzAPI

Vpeljava KumuluzAPI v okolju zavarovalnice:

  • 88 objavljenih API-jev,
  • 613 API naročnin,
  • 62 aktivnih odjemalnih aplikacij,
  • 200k do 500k API klicev na dan,
  • 4 API prehodi,
  • 59 zalednih namestitev API-jev v testnem in produkcijskem okolju.

Cilj digitalizacije poslovanja zavarovalnice je bil dvodelen. Kot prvo, vzpostaviti pregled nad API-ji v poslovnem okolju skupaj s pregledom nad integracijami z internimi aplikacijami. In kot drugo, vzpostavitev ekosistema API-jev za zunanje partnerje. Dva najbolj uporabljena API-ja s strani zunanjih partnerjev sta API za informativni izračun zavarovanj (premoženjsko, zdravstveno) in API za sklenitev zavarovanj. Kot najbolj zanimiv primer je uporaba omenjenih API-jev s strani agregatorja ponudnikov zavarovanj, kjer tuja organizacija uporablja API-je zavarovalnic in omogoča primerjavo zavarovanj med različnimi ponudniki in potem tudi sklenitev zavarovanj pri izbranem ponudniku.

Vzpostavitev rešitve KumuluzAPI v okolju zavarovalnice je doprinesla:

  • 15 % več povpraševanj po zavarovalnih produktih,
  • 5 % povečano število sklenjenih zavarovanj,
  • 2 nova modela partnerske API ekonomije.


Vzpostavitev API integracijske infrastrukture v okolju banke

Digitalno poslovanje banke zahteva vrsto integracij med različnimi aplikacijami in sistemi, tako internimi kot zunanjimi. Z rešitvijo KumuluzAPI smo vpeljali dva integracijska infrastrukturna sklopa – internega in zunanjega. Interna integracijska infrastruktura je namenjena vzpostavitvi integracij med internimi aplikacijami in sistemi z zahtevo po visoki varnosti. Zunanja integracijska infrastruktura je sestavljena iz dveh delov – sklopa za vhodne (ingress) integracije in sklopa za izhodne (egress) integracije.

Ključni del digitalizacije poslovnih okolij z visokim rizikom varnosti je pregled nad vsemi integracijami in možnost upravljanja s posameznimi integracijami. Da dosežemo visok nivo varnosti, moramo zagotoviti tudi enostavno upravljanje varnostne konfiguracije, saj tako zmanjšamo možnosti za človeške napake. To dosežemo z vpeljavo API prehodov, ki predstavljajo enotno vstopno točko v primeru ingress integracij oz. enotno izstopno točko v primeru egress prometa. Na ta način ves promet do internih aplikacij prihaja iz ene vhodne (ingress) točke in ves promet internih aplikacij na zunanje poteka preko ene izhodne (egress) točke.

  • 22 integracijskih API-jev
  • Do 1.1M klicev na dan
  • 35 aktivnih integracij

Preberi tudi

Kadrovske storitve lahko najamete in digitalizirate

Kadrovske službe so pogosto še vedno obravnavane kot tisti interni servis podjetja, ki skrbi za razpise prostih delovnih mest, razgovore, pogodbe in anekse. Morda jim včasih zaupamo še izračun plač in jih povprašamo za nasvet v primeru prekinitve delovnega razmerja. A pravkar naštete naloge niso več bistvo kadrovske funkcije podjetja. Za konkurenčnost na trgu je že danes treba kadrovski servis videti kot eno tistih ključnih strateških služb, ki zagotavlja natanko tiste talente, usposabljanja, nagrajevanje in medsebojne odnose, ki omogočajo optimalen doseg podjetja na trgu. Tradicionalne in nekatere strateške funkcije kadrovske službe se pospešeno digitalizirajo.

PSD2 platforma, ki je odprla banke v svet

SRC je skladno z EU regulativo izdelal rešitev SRC PSD2 API Collection, preko katere se lahko TPP-ji povežejo na bančni vmesnik in uporabniku nudijo vse storitve, ki jih PSD2 direktiva predvideva in zahteva od bank.

Prijavi se na SRC novičke

Novice v svetu IT tehnologije

Vaša računalniška oprema in vaše digitalne storitve so vaša poslovna orodja.

SRC sistemske integracije d.o.o.

Tržaška cesta 116
1001 Ljubljana, Slovenija

T: +386 1 600 7000
F: +386 1 423 4173
E: info@src.si

Vaše mnenje nam je izredno pomembno!

Ste bili s storitvami naših sodelavcev zelo zadovoljni? Mislite, da je še prostor za izboljšave?

small_c_popup.png

Vaše mnenje

Ste bili s storitvami naših sodelavcev zelo zadovoljni?
Mislite, da je še prostor za izboljšave?

Spletno mesto uporablja piškotke zaradi boljše uporabniške izkušnje. Z uporabo naše spletne strani potrjujete, da se z njihovo uporabo strinjate.