Miten mitata alustan, kaupungin, maan tai yrityksen API-potentiaalia?

Updated: Jun 4, 2018

Mittaaminen on olennaista liiketoiminnan ja tuotteiden kehityksessä. Jos ei mittaa, ei tiedä mitä tapahtuu. Toisaalta yhtä tärkeää on mitata oikeita asioita. Helpommin sanottu kuin tehty. Tästä kumminkin lähti ajatus alustojen API-potentiaalin mittaamisesta. Lopulta sovelluskenttä laajeni yksittäisen yrityksen, kaupungin tai muun ohjelmointirajapintoja laajasti tuottavan organisaation tai yhteisön API-kyvykkyyden mittaamiseen.


Samalla kyllä tuli mieleen että sanan API voisi korvata toisella, jotta ei sortuisi teknokraattisen kielen käyttöön heti matriisin nimessä. Voisi hyvin käyttää vaikkapa datan hyödyntämis- ja jakelupotentiaalista. Jatkossa kuitenkin käytän tässä artikkelissa API -matriisi nimeä, koska keskityn vain rajapintojoihin. Datan hyödyntämis- ja jakelupotentiaalia arvioitaessa tulisi analyysi laajentaa sisältämään myös muutakin kuin vain ohjelmointirajapinnat.


Kenties matriisista yhteistyössä toisten asiantuntijoiden kanssa saisi mallin, joka olisi suoraan sellaisenaan sovellettavissa yritysten liiketoimintaa suunnitellessa. Matriisia ei vielä ole empiirisesti testattu. Korostan että matriisin luvut ovat suoraan stetsonista eivätkä kuvasta minkään yrityksen, alustan tai kaupungin API-potentiaalia.


Motivaatio matriisin tekemiselle


Alussa toin esille jo mittaamisen merkityksen toiminnan kehittämiselle. Kuitenkin matriisimallin tekeminen oli enemmän aivojumppaa ja ajatusten tuulettamista suurempaa oivallus odottaessa. Kirjoitin kaksi artikkelia ja siitä syntyi ajatus API-matriisista, jolle voi hyvinkin pienen kehittelyn jälkeen löytyä käyttökohteita, joista muutaman mieleeni tulleen esittelen alla. Jotta voit ymmärtää matriisin nyansseja, on hyödyllistä lukea edelliset kaksi artikkelia:

  1. APIen moninaiset kasvot (3)ja

  2. Datarajapintojen jälkeen koittaa toiminnallisten-APIen aikakausi (4)

API -matriisi tiiviisti


API -matriisissa on kaksi akselia. Pystyakselilla on ohjelmointirajapintojen lajityypit kuten ne laajassa tutkimuskirjallisuudessa ymmärretään. Kyseiset lajityypit on käsitelty yksityiskohtaisesti esimerkkien valossa elokuussa 2018 ilmestyvässä API-talous 101 -kirjassa. (5) Sitä ennen voit perehtyä tiiviiseen kirjoitukseen APItalisti -blogissa.


Vaaka-akselilla on puolestaan APIen jaoettelu niiden toimintalogiikan mukaan. Data API tarjoilee nimensä mukaisesti dataa ulos ja sisältää toisinaan myös datan käsittelyyn tarvittavat metodit (CRUD). Kaksi muuta API-tyyppiä on tapahtumapohjaiset- ja toimintorajapinnat. Tiivistetysti voidaan todeta heräte/tapahtumapohjaisen olevan enemmän toimintamalli verrattuna esim perinteiseen REST toteutukseen, jossa asiakas (sovellus) on aktiivinen prosessin aloittava osapuoli. Tapahtumapohjaisessa rajapintapalvelussa asiakassovellus on passiivinen ja tietoa “työnnetään” (push) asiakassovellukselle.


Toiminnalliset APIt rakennetaan usein datan päälle ja niillä tuotetaan lisäarvoa asiakkaille algoritmien ja joskus jopa tekoälyn avulla tehdystä analyysista, jonka alkusyötteen asiakas saattaa antaa. Tarkempi kuvaus vaaka-akselin rajapinnoista löytyy omasta jo aiemmin mainitusta artikkelista (4). Kun nämä kaksi näkökulmaa rajapintoihin yhdistetään toisiinsa saadaan alla olevan kuvan mukainen API-matriisi.



Geneerisesti API-kyvykkyysmatriisia voi käyttää kohteen kuin kohteen APIen tuoman potentiaalin ja kypsyyden mittaamiseen sekä hahmottamiseen. Jos matriisiin vielä

  • APIen lukumäärän tai prosenttiosuuden lisäksi laitettaisiin

  • kuukausittaiset hyödyntäjämäärät ja

  • niiden kautta saadun liikevaihdon

mallin käyttökelpoisuus nousisi huomattavasti. Lisäksi mainittujen mittareiden avulla voitaisiin kohteesta tehdä parempi analyysi liiketoiminnan suhteen. Kysymys joka saattaa nousta mieleen on että miksi sisäistä käyttöä myös pitäisi monitoroida tai analysoida? Jos yritys tai organisaatio ei käytä omia rajapintojaan mitenkään, on aika todennäköistä että "eat your own dogfood" (6) on unohtunut ja APIt ovat vain kakunkoriste.


Rajapinnasta saadun hyödyn mittaaminen


Äkkiseltään voisi kuvitella että lisääntynyt myynti olisi ainut mittari, mutta näin ei ole. Tuoreehkon vuodelta 2017 olevan tutkimuksen (1) mukaan käytännössä suurimmat hyödyt ovatkin kustannusten laskeminen. Toki yrityksen kokonaismyyntikin saattaa nousta, mutta kustannusten lasku on useammin suurempi hyöty. Toisaalta tämä on myös linjassaan sen asian kanssa, että sisäiset ja yksityiset APIt ovat yleisimpiä ja juuri niiden avulla tyypillisesti tehostetaan omaa toimintaa.


Hyöty jota ei välttämättä tule ajatelleeksi on uusien palveluiden kehittämiseksi vaadittujen resurssien (aika, kehittäjien määrä) vähäisempi määrä. Rajapintojen tuottamisella on myös mahdollisesti sekin vaikutus että sijoittajat pitävät yritystä houkuttelevampana, koska APIen uskotaan luovan kyvykkyyksiä reagoida tulevaan entistä nopeammin ja tehokkaammin.


Sanomattakin on selvää että API joka on tuotteistettu, vaatii mittarointia. APIn tuottamiseen ja ylläpitämiseen kuluu resursseja, joten jotain hyötyä siitä tulee olla ja hyöty pitää olla jotenkin mitattavissa. Mitä mitata riippuu APIn tarkoituksesta. Otetaan pari esimerkkiä.

APIsta saatu hyöty on helposti mitattavissa silloin kun kyseessä on esimerkiksi julkinen kaupallisestettu API. Tällöin saatu rahallinen hyöty on mittari ja se voidaan suhteuttaa käytettyihin resursseihin. Lisäksi voidaan tällöin mitata kustannusta ja saatua tuloa / API kutsu.


Kumppani-APIn kohdalla tilanne on usein monimutkaisempi. Useinkaan kumppani-APIn käytöstä ei peritä maksua ja saadut hyödyt näkyvät lisääntyneenä omien tuotteiden myyntiä. Ongelmaksi muodostuu miten mitata varmasti, että API on ollut osallinen lisääntyneeseen myyntiin. APIn tuottama hyöty lisääntyneinä tuloina voi olla epäsuoraa ja lisätä esimerkiksi sitä hyödyntävän sovelluksen myyntiä, mutta jälleen APIn aikaansaama vaikutus on vaikea mitata.


Toisinaan kumppani-APIn tuomaa hyötyä voi mitata hyvinkin suoraan erilaisten teknisten avainten avulla kuten esimerkiksi sisääntulevan liikenteen määrä, josta tietty osa päättyy asiakkuuteen. Näin ollen hyöty on laskettavissa kohtuullisen helposti. Samoin myös jos kumppanien kanssa on tehty tulonjakomalli eikä kumppanin kanssa ole juuri muuta yhteistoimintaa. Tällöin kumppani-APIn tuotto on karkeasti ottaen kumppanilta saatu osuus myyntitulosta

.

Sisäisten ja yksityisten rajapintojen kohdalla hyötyä voi olla vaikeampi mitata, mutta uusien tuotteiden kehittämisnopeus voi olla yksi mittari (1). Toisin sanoen tulevien tuotteiden koodaaminen helpottuu. Tällöin mitataan kehittäjien tuottavuutta. Tämä ei koske vain yrityksen sisäisiä kehittäjiä vaan myös toimeksiantoja eli alihankkijoita jotka kehittävät yritykselle ratkaisuja hyötyntäen rajapintoja. Oletuksena silloin tietysti on että APIen dokumentaatio on kunnossa ja niiden käyttö helppoa sekä suoraviivaista. APIen tuottamisesta (etenkin sisäiset) saatu hyöty lisääntyneessä myynnissä tulee viiveellä, koska lisäarvo realisoituu vasta kun rajapinnat on otettu käyttöön osana palvelua ja palvelutuotantoa.


Mikäli kyseessä on alusta, on alustassa toimivien sovelluskehittäjien määrä yksi mitattava asia. Näin siitä syystä että kehittäjien suuri määrä nähdään yhtenä menestystä edistävänä tekijänä (2). Sovelluskehittäjien yhteismäärä ja API-kohtaiset määrät saa yleensä alustasta irti, joten siinä mielessä ne sisällytetään API-matriisiin yhtenä mittarina. Kuitenkin kehittäjäyhteisön tarkempi mittaaminen rajataan ulos, koska se on oman “matriisin” tai ainakin oman artikkelin laajuinen asia.


Avoimien (Open API) rajapintojen suhde muihin rajapintoihin on olennainen tieto etenkin silloin jos tavoite on lisätä sovellustuotantoa ilman, että omaa R&D:tä kasvatetaan. Avoimuudella on todettu Android ja iOS ekosysteemien vertailussa avoimuuden johtavan pienempään alustan nettotuottoon, mutta suurempaan sovellusmäärään(2). Tämä tarkoitti kyseisten alustojen välillä sitä, että Androidin sovellusmäärä ohitti iOS:n 2014 vaikka Android lähti kisaan myöhemmin.


Mihin sitten API-matriisia voisi hyödyntää?


Edellä hahmottelin muutamia mittareita API-matriisin sisään ja niiden tarkennusta on jatkettava vielä, jotta voi sanoa jokaisen lokeron sisään tulevan mittareina toimivan muuttujajoukon. Tässä vaiheessa voidaan listata muuttujiksi:

  • APIen määrä + prosenttimäärä yhteenlasketusta kokonaismäärästä

  • APIen käyttäjämäärä kuussa - sisäiset ja ulkoiset käyttäjät erikseen

  • Saatu myyntitulo

  • Suorat ja epäsuorat kustannukset (7)


Tämän lisäksi on kysymys, että missä tilanteissa ja mihin tarkoituksiin API-matriisia voi hyödyntää. Alla muutama esimerkki, joiden lisäksi löytyy varmasti vielä useita lisää.


Työkalu bisneskumppanin valintaan tai kilpailijan analysointiin

API-kyvykkyysmatriisin yksi käyttötarkoitus voisi olla kumppanien valinta, olettaen että tiedot kumppaneista on saatavilla. Lisäksi matriisia voisi käyttää yritysostoissa yhtenä arviointityökaluna. Tällöin voidaan tarkastella miten hyvin kumppanin APIt sopivat omiin tarpeisiin ja millaista lisätyötä niiden käyttöönotto tarkoittaa. Yrityksen tarve voi olla tapahtumapohjainen asioiden tilan muutoksen seuranta APIn avulla mutta potentiaalinen kumppani tarjoaa vain datarajapintoja. Tällöin APIn käyttö tarkoittaisi muutoksia omiin suunnitelmiin APIn kautta saatavan tiedon hyödyntämisessä ja arkkitehtuurissa.


APIen alkutaipaleella olevan yrityksen tunnistaminen

Esimerkiksi jos kyseessä on yritys, jonka rajapinnoista lukumääräisesti suurin osa on sisäisiä ja kyseessä on datarajapinnat, voi hyvinkin kyseessä olla APIen alkutaipaleella oleva yritys. APIt on olemassa sisäisen tehokkuuden parantamiseksi.


Analysoinnilla liiketoimintaa tekevän yrityksen tunnistaminen

Jos taas yrityksellä on paljon julkisia rajapintoja (toiminto-API luokassa) ja datan käsittelyyn tarkoitettuja kumppanirajapintoja, voi yritys olla toisten dataa analysoiva ja siitä lisäarvoa toisille tuottava. Julkiset rajapinnat ovat tarjolla muillekin kuin vain kumppaneille, joten niistä voidaan saada liikevaihtoa.


Julkisen sektorin organisaatioiden tilanteen hahmottamiseen

Julkisen sektorin organisaatioista suurin osa tulisi todennäköisesti API -matriisissa painottumaan datarajapinta tasolle ja sielläkin matriisin vasempaan yläreunaan. Kieltämättä väittämä on puhdasta mutua eikä tukena ole mitään faktaa. Tarvittavaa dataa ei ole saatavilla hypoteesin testaamiseksi ilman täysipäiväistä työtä jo datan keräämiseksi. Toki eri organisaatiot sijoittuvat varmastikin matriisissa eri paikkoihin ja osa hajautetusti eri puolille matriisia.


Julkisen sektorin organisaation kumppani-APIt ovat suomi.fi -palveluväylässä olevia rajapintoja. Avointa dataa tarjoavia rajapintoja ei vielä ole Suomessa paljon, mutta varmaankin enemmän kuin julkisia (kaupallisia) rajapintoja. Tästä en ole mitään tutkimusta löytänyt, joten vaikea sanoa mikä on organisaatioiden tai kansallisen tason jakauma tai määrä. Väylän osalta luku kyllä saadaan selville mikäli lähtökohdaksi otetaan että API pitää olla liityntäkatalogissa ja käytetään sen APIen lukumäärän summaa. Julkinen sektori istuu tietovarantojen päällä ja vasta aloittaa polkuaan REST APIen maailmaan. Tapahtumapohjaiset ja toiminto-rajapinnat ovat enimmäkseen liikennesektorilla, mutta niiden lukumäärä on vain muutamia (oletus ja tuntuma).


Toimialojen vertailu

API-matriisia voisi käyttää myös toimialojen vertailuun kansallisesti tai kansainvälisesti. Voisi olla silmiäavaavaa nähdä vierekkäin API-matriisit eri sektoreista kuten esimerkiksi koulutus, liikenne ja terveys.


API-katalogien vertailu

Vastaavasti työkalua voisi käyttää API-katalogien vertailuun. Mitä jos paljastuu että yhdessä katalogissa on yrityksen kannalta toimialan keskeiset toiminnalliset API:t? Sovelluskehittäjät löytävät APIn paremmin muiden samankaltaisten joukosta, vaikkakin kilpailu siellä on kovempaa. Joskus päinvastainen liike voi olla myös kannattavaa.


API-matriisin käyttökohtee ja haasteet tiiviisti

Kuten alusssa mainitsin, matriisin käyttökohde voisi olla esimerkiksi alustan API-kyvykkyyksien tai potentiaalin hahmottaminen, kilpailijoiden analysointi, potentiaalisten kumppanien API-kyvykkyyksien hahmottaminen. Haasteena on kuten usein että mistä saa datan matriisin täyttämiseen? Mielellään matriisia testaisi, mutta datan kerääminen tuntuu aika työläältä. Ehkä tässä voisi tehdä yhteistyötä ylipistojen ja muiden alasta kiinnostuneiden kanssa.


Lähteet:

  1. Benzell, Seth, Guillermo Lagarda, and Marshall W. Van Alstyne. "The Impact of APIs in Firm Performance." (2017).

  2. Parker, Geoffrey, Marshall Van Alstyne, and Xiaoyue Jiang. "Platform ecosystems: How developers invert the firm." (2016).

  3. https://www.apitalisti.fi/blog/ohjelmointirajapinnan-api-moninaiset-kasvot

  4. https://www.apitalisti.fi/blog/datarajapintojen-j%C3%A4lkeen-koittaa-toiminnallisten-apien-aikakausi

  5. https://apitalous101.fi/

  6. https://www.programmableweb.com/news/why-api-providers-should-dog-food-their-own-apis/analysis/2015/09/10

  7. https://www.businessnewsdaily.com/5498-direct-costs-indirect-costs.html

0 views

©2018 by apitalisti
 

Yhteystiedot

Brändit

Apitalist is registered trademark of APInf Ltd

APIOps is registered trademark of Osaango Ltd and APInf Ltd

Tilaa kirja

API -talous 101 -kirja Alma Talent kaupassa!

Podcast

"Opi tuntemaan API -asiakkaasi" podcast -sarja

Lue lisää!