Mikä on avoin API?

6. tammikuuta 2020

Tässä blogissa tuon esille näkökulmia rajapintojen avoimuuteen niiden keskustelujen pohjalta, joita olemme avoimen rajapinnan määritelmää työstävässä OKFI ry:n, COSS ry:m ja Teknologiateollisuus ry:n työryhmässä kevään 2020 aikana pohtineet. Tämä kirjoitus ei edusta työryhmän mielipidettä sellaisenaan. Sen tarkoitus on kuitenkin avata näkökulmia, joista olemme keskustelleet. Tavoitteena on kiteyttää ja jatkaa aiheesta sekä kansallisesti että kansainvälisesti virinnyttä keskustelua.

Näihin loppukeväästä käytyihin keskusteluihin osallistuivat työryhmästä OKFIn edustajana Mika Honkanen, COSSin edustajana Marjukka Niinioja ja työryhmän vapaaehtoisina osallistuneet rajapintojen kanssa paljon työskentelevät Arvi Leino ja Tuukka Hastrup. Myös muut osallistujat ovat vaikuttaneet työryhmän työskentelyyn vahvasti, erityisesti Teknologiateollisuuden edustajana ryhmässä toimiva Antti ”Jogi” Poikola sekä Martin von Willebrand.

On hyvin vaativaa laatia yksiselitteinen määritelmä avoimellelle API:lle. Keskustelu siirtyy nopeasti arvokeskusteluksi ja tavoitteiden asettamiseksi sanakirjamääritelmän sijaan. Englanniksi termillä Open API on ollut hyvin erilainen tausta ja tarkoitus kuin esimerkiksi avoimen datan tai avoimen lähdekoodin käsitteillä.

Sitä saat mitä tilaat. Jos siis haluat mahdollisimman avoimen rajapinnan, jota käyttäisiä laaja hyödyntäjäjoukko ja joka tuottaisi vaikuttavan lopputuloksen, täytyy rajapinnan tarjoamiseen ja hankintaan kiinnittää huomiota. Erityisesti jos tilaat kehitystyötä, valmisohjelmiston tai teknologiaa, joka sisältää rajapintoja. Sopimusehdot ovat siis keskeisessä asemassa rajapintojen avoimuudelle, mutta nykyisissä laajasti käytössä olevissa julkisen ja yksityisen sektorin mallisopimusehdoissa rajapintoja käsitellään varsin suppeasti.

Julkishallinnon, avoimuutta edistävien yhteisöjen ja yritysten näkökulmat saatetaan välillä kokea ristiriitaisiksi (mm. maksullisuus ja maksuttomuus, toimittajalukot vai asiakashankinnan kustannukset). Löysimme kuitenkin etenkin loppukevään keskusteluissa yhteistä säveltä, kun lähdimme työstämään rajapinnan avoimuutta suhteessa siihen, mihin tavoitteisiin avoimuudella pyritään ja mikä silloin on keskeistä avoimuudelle.

Havaitsimme eri esimerkkitapausten avulla, että asiaan liittyi runsaasti eri näkökulmia. Jouduimme yhä uudestaan palaamaan siihen, miksi avoin data, avoin lähdekoodi ja avoin rajapinta ovat toisaalta erittäin samankaltaisia ja toisaalta hyvin erilaisia.

Tässä blogissa on yritetty tavoittaa käytyjen keskustelujen ja rajapintojen avoimuuden monitahoisuus tiiviisti. Lisäksi olen sisällyttänyt mukaan joitakin esimerkkejä ja pohdintoja, joita työstimme Osaangon tiimin toimiessa keväällä 2020 Business Finlandin Keino-hankkeessa, sekä TravelDataHub-hankkeen legal design-kehityksessä asiantuntijana.

Lopussa on avattu joitakin peruskäsitteitä, joita käsitellään laajemmin kirjassa API-talous 101 (Moilanen, Niinioja, Seppänen, Honkanen, 2018, Alma Talent), samoin kuin koko avoimen rajapinnan problematiikaa sekä siihen liittyviä case-tutkimuksia.

Tietoverkkojen (erityisesti internetin) yli käytettävien ohjelmointirajapintojen (Application Programming Interface, API) ja niiden kautta välitettävien resurssien tulee tarjota selkeä hyöty sekä tarjoajalle itselleen että arvolupaus rajapinnan hyödyntäjille.

Miksi valita avoin API?

Yleisesti rajapintojen avoimuudella tavoitellaan

  • kustannustehokkuutta,
  • kehityksen ja muutosten nopeutta,
  • helppoutta ja erityisesti verkostovaikutuksen syntymistä, sekä
  • samoihin tavoitteisiin tähtäävän ekosysteemin muodostumista,
  • markkinaosuuden kasvattamista (yritykset)

Rajapinnan avoimuudella tavoitellaan mahdollisimman laajaa hyödyntäjäjoukkoa

Laajaan käyttöön voidaan päästä useilla tavoilla, mm. standardoimalla rajapinta, joka saattaa olla hidas tie. Toinen vaihtoehto on luoda ns. de facto-standardi, eli huolehtia siitä, että laaja ja kasvava hyödyntäjäjoukko ottaa rajapinnan käyttöönsä.

Vain toteuttamalla riittävän hyvin ja virheettömästi toimiva käyttötarkoitukseen soveltuva rajapinta, sen käytön voidaan olettaa laajenevan. Lisäksi hyödyntäjäjoukon laajuuteen voi vaikuttaa mm. näillä keinoin:

  • avoimella kehittäjäryhmällä,
  • avoimella menettelyllä kehitysideoiden ja puutteiden raportointiin, sekä tukipyyntöihin
  • läpinäkyvällä etenemissuunnitelmalla
  • mahdollisuudella vaikuttaa kehityspäätöksiin
  • riittävällä palvelutasolla ja -lupauksella ja
  • yhteisellä rajapinnan teknisellä toteutuksella
  • julkisesti saatavissa olevalla standardeihin pohjautuvalla rajapintakuvauksella ja muulla dokumentaatiolla, sekä
  • kattavalla markkinoinnilla ja viestinnällä, jotta tieto rajapinnasta tavoittaa potentiaaliset hyödyntäjät
  • Jotta rajapinnan käyttöönotto olisi mahdollismman helppoa tulisi rajapinnan dokumentaation olla julkaistu niin että sen näkeminen tai hyödynnettävyyden arviointi ei vielä sopimusta tai sopimusehtojen hyväksymistä tai käyttöoikeuksien pyytämistä.

Jos kaikilla asianomaisilla kolmansilla osapuolilla on pääsy API:in, käytetään usein termiä julkinen API. Jos vain valitut organisaation ulkopuoliset osapuolet saavat käyttää API:a, käytetään termiä kumppani-API. Näiden lisäksi organisaation eri osat voivat tarjota API:ja itselleen ja toisilleen, jolloin niitä kutsutaan sisäisiksi API:ksi. Monissa lähteissä avoimet API:t määritellään julkisiksi API:ksi. Joitakin lähteitä ovat myös kumppanien API:t. (Moilanen, Niinioja, Seppänen, Honkanen, API economy 101, 2019). Työryhmä keskusteli voidaanko termiä 'avoin API' käyttää kumppani-API:sta.

Avoimuuden lisääminen avoimilla lisensseillä ja standardeilla

Rajapinnan avoimuutta voidaan lisätä sillä, että rajapinnan dokumentaatio kokonaan (ml. ohjeet ja toiminnallisuuden kuvaus) tai ainakin sen sisältämät tietomallit on avoimesti lisensoitu ja perustuvat standardeihin tietomalleihin.

Avointen lisenssien ja standardien toteutusten käyttö on erityisen tärkeää, jos käytön laajeneminen käytännössä edellyttää myös sitä, että eri toimijat kopioivat rajapinnan omien tietojärjestelmiensä ja teknologioiden päälle. On kuitenkin huomattava, että pelkkä rajapinnan kuvauksen tai tietomallin kopioiminen ei riitä takaamaan, että kopioitu rajapinta toimisi samalla tavoin tai pysyisi samassa kehityssyklissä kuin alkuperäinen. Siksi yhteinen tai yhtenäinen tekninen toteutus, sekä avoin kehittäjäryhmä saattava olla tärkeämpiä kuin avoin lisensointi yksinään.

Avoin lisensointi voi edistää kehittäjäryhmän muodostamista ja etua. Jos koko järjestelmän lähdekoodi on lisensoitu avoimella lisenssillä, API:in assosioidut materiaalit voidaan sisällyttää tähän lisenssiin. Jos ohjelmisto tai muu teknologia, joka toteuttaa API on kopioitu, tietojen käyttöehdot voidaan erottaa kokonaan API . Tämä tarkoittaa, että API on jokaisen kuluttajan omassa verkossa, omissa laitteissaan tai pilvessä omassa hallinnassaan. Myös API on vuorovaikutuksessa omien resurssiensa (data, rakennukset, algoritmit jne.) kanssa.

Onko avoin rajapinta aina myös maksuton?

Avoin data ja avoin lähdekoodi mielletään usein maksuttomiksi. Osa määritelmistä mahdollistaa myös kohtuullisen maksun perimisen, jotta datan tai lähdekoodin avaaminen olisi mahdollista. Olennaista on kuitenkin erottaa data ja lähdekoodi itse rajapinnasta. 

Ilmainen tai edullinen API on varmasti suositumpi ja laajemmin käytössä kuin maksullinen API. Katsotaanpa joitain käyttötapauksia.

Rajapintojen maksuttomuus yritysten näkökulmasta

Rajapinnan käyttö voi olla ilmaista ja avoimesti tarjottavissa rajapinnoissa usein näin onkin. Jotta kokonaisuus olisi täysin maksutonta, täytyy huomioida myös rajapinnan kautta välitettävän datan ja datan määrästä ja siirtonopeudesta usein riippuvan tietoliikenneyhteyden kustannukset ja maksullisuus. Lisäksi kokonaisuuteen vaikuttaa rajapinnan tarjoavan teknologian, esimerkiksi älykkään valaisimen tai asiakastietojärjestelmän hankinta- tai käyttömaksut.

Rajapinnan tarjoamisesta aiheutuvat kustannukset voidaan nähdä investointina, markkinointikustannuksena tai esimerkiksi (asiakas)palvelun tarjoamisesta aiheutuvina kustannuksina. Eräässä yrityksessä aikaisemmat räätälöidyt integraatiot veivät vähintään 40 tuntia per integraatio ja niiden ylläpito ja tukeminen oli työlästä ja vaati erikoisosaamista.

Vaikka työ laskutettiin asiakkailta, uusien työntekijöiden perehdyttäminen ja käyttäjien tukeminen veivät niin paljon aikaa, ettei integraatioiden ylläpitoa saatu kannattavaksi tai toteutusten hinnat olisivat kohonneet liian suuriksi asiakkaille.

Integraatiot olivat kuitenkin tärkeä syy siihen, miksi asiakkaat ostivat tältä yritykseltä eivätkä kilpailijoilta. APIt mahdollistivat sen, että integrointityö voitiin antaa asiakkaiden itsensä tehtäväksi. yritys kehitti vain valmistetut standardoidut ohjelmointirajapinnat, joita tarjottiin kaikille asiakkaille. Yrityksen työmäärä väheni 2 tuntiin aiemmasta 40 tunnista integraatiota kohden. Täydelliset integraatiot voitaisiin toteuttaa APIen lisäksi ja tarjota kiinteähintaisina lisäpalveluna.

Yritysten tarjoamat ilmaiset APIt perustuvat usein siihen, että APIn käytöstä ei veloiteta maksua. APIn tarjoaman resurssin käyttö kuitenkin veloitetaan. Näitä resursseja voivat olla lamppu, kodinohjausjärjestelmä, CRM-järjestelmä, paperikone, asiakastiedot tai koneoppimisen kautta datasta käsiteltävät tuotesuositukset. API-liittymien avokkuuteen vaikuttaa siis yrityksen liiketoimintamalli. Ja tämä on asia, jota API-talous voi muuttaa perusteellisesti.

Asiakkaalta voidaan esimerkiksi periä sama maksu riippumatta siitä, käyttääkö hän resurssia käyttöliittymän kautta vai API . Joissakin tapauksissa API kuluttajat ovat täysin eri ryhmä kuin järjestelmän loppukäyttäjät. Ja API voidaan tarjota myös kumppaneille tai markkinointitarkoituksiin ilman asiakkaana olemisen vaatimusta ja siihen liittyviä maksuja. Joskus yritysten on esimerkiksi lain mukaan tarjottava täysin avoimia ohjelmointirajapinnan tarjoamista jopa kilpaileville yrityksille (esim. Suomessa, liikennepalvelulaissa tai avoimessa pankkitoiminnassa).

Rajapintojen maksuttomuus julkishallinnon näkökulmasta

Julkishallinnon tai yleishyödyllisten yhteisöjen tarjoamat rajapinnat saattavat olla maksuttomia tai maksullisia. Esimerkiksi julkisuuslaissa tai erityislainsäädännössä säädetty viranomaistehtävä ja siihen liittyvä rajapinta on perusteltua tarjota maksuttomana.

Maksuttomien rajapintojen kustannukset katetaan budjettivaroin ja sen tarjoamisella pyritään saavuttamaan laajempi kansantaloudellinen hyöty. Kaikkia julkishallinnon palveluita ei kuitenkaan voida tarjota ilmaiseksi, jottei vääristetä markkinoita kilpailemalla yritysten kanssa. Siksi esim. Suomessa on valtionhallinnon tarjoamia palveluita säätelevä Valtion maksuperustelaki, joka määrittelee mistä suoritteista maksua saa ja pitää periä, jollei asiaa muualla lainsäädännössä ole määritelty. Voi siis olla, että jos virasto haluaa tarjota rajapinnan maksuttomasti, joudutaan myös lainsäädäntöä muuttamaan tai ainakin tarkistamaan sen osalta voiko näin tehdä.

Maksuton viranomaisen tarjoama palvelu voi sisältää maksuttoman rajapinnan, mutta se ei silti tarkoita, että rajapinta olisi perusteltua avata kaikille halukkaille tai että sen kuvaus tai välittämä data olisi avoimesti lisensoitua. Maksuttomasti tarjottu rajapinta vaatii myös kannanoton siihen, kuinka suurta käyttömäärää voidaan maksuttomasti tarjota. Usein rajapinnan suosion ja käyttömäärien kasvaessa tietoliikenne- tai palvelinkapasiteetin kasvattaminen aiheuttaa myös enemmän kustannuksia. Jos kapasiteettia ei kasvateta, rajapinnasta tulee käytännössä käyttökelvoton tarkoitukseensa, eikä sen käyttö laajene. Avoimuudella tavoitellut hyödyt eivät toteudu.

Julkishallinnossa usein hankerahoituksella avatut rajapinnat, erityisesti avointa dataa tarjoavat rajapinnat, kohtaavat tämän haasteen. Lisäksi niiden elinkaari jää liian lyhyeksi hankerahojen loppuessa, jotta potentiaaliset hyödyntäjät uskaltaisivat sitoutua niiden jatkuvaan käyttöön puhumattakaan, että käyttäjämäärä laajentuisi.

Onko avoimen rajapinnan tarjoama tai vastaanottama data aina avoimesti lisensoitua?

Ei läheskään aina, mutta mahdollisuuksia siihen olisi useammin kuin ehkä ajatellaan. Esimerkiksi yritysten verohallinnolle rajapintojen kautta ilmoittamat verotustiedot eivät sellaisenaan ole avointa dataa, vaikka rajapinta olisikin avoimesti kaikkien halukkaiden yritysten käytettävissä. Osa datasta voidaan tosin julkaista esimerkiksi julkisuuslain tai muun verotustietoihin liittyvän lainsäädännön perusteella avoimena datana.

Mikä on hyvä syy olla tarjoamatta täysin avointa rajapintaa?

Esimerkki julkisesta palvelusta, jossa API:t ja data eivät ole täysin auki, vaikka niitä olisi tarkoitus käyttää laajasti, on Business Finlandin vuoden 2020 aikana kehittämä TravelDataHub-palvelu. Sen API kuvaus julkistetaan lisenssillä, joka ei salli API:a kopioitavaksi, ainakaan kaupallisiin tarkoituksiin. Palvelun tavoitteena on taata Suomen matkailusta keskitettyä laadukasta tuotedataa valikoiduissa kansainvälisissä matkailukanavissa. Palveluun tallennetut tiedot ovat kunkin matkailuyrityksen omistuksessa. Sitä voidaan käsitellä alueellisissa matkailutoimistoissa, ja siihen voi päästä käsiksi markkinointikanavien kautta, jotka API on määritellyt korkealaatuisksi. Joihinkin kanaviin tietoa julkaistaessa matkayhtiön tuotetiedoista tulee kuitenkin ainakin osittain avointa dataa, sillä kanavan käyttöehdot edellyttävät sitä. Tätä hallinnoi matkailuyritys itse. Näiden kanavien syynä on esimerkiksi se, että ulkoilureittejä nähtävyyksineen on määrä tarjota eri toimijoille, jotka käyttävät karttatietoja laajasti navigointiin. Tällaiset kanavat voivat käyttöehtojensa puitteissa julkaista avoimen lisenssin nojalla saadut tiedot avointen API:en kautta.

Erityisesti julkisin varoin rakennettavien alustatalouden palveluiden osalta on muistettava, että toimittajaloukku voi syntyä alustan ohjelmistokehityksen ja ylläpidon osalta, vaikka alustan käyttöön tarvittavat rajapinnat olisivat avoimia. Saattaa olla perusteltua kehittää jopa avoimen lähdekoodin ratkaisu, jos haluaa varmistaa, että jatkokehityksen ja ylläpidon voi ostaa jatkossa eri toimittajilta tai sitouttaa siihen laajan avoimen kehittäjäyhteisön.

Rajapinnat sisältävä avoimen lähdekoodin ratkaisu ilman yhteistä toteutusta ja hyvin johdettua avointa kehittäjäyhteisöä ei kuitenkaan takaa esimerkiksi kustannustehokkuuden tai kehitysnopeuden toteutumista yksinään, esimerkiksi eri kaupunkien lähtiessä kehittämään samasta avoimen lähdekoodin ratkaisusta täysin omia eriytyneitä toteutuksiaan.

Käyttäjien omia tietoja (omadata) ei myöskään yleensä julkaista avoimella lisenssillä, varsinkaan jos ne sisältävät henkilötietoja. Muita esimerkkejä ovat toimitusvarmuuden, kansallisen turvallisuuden tai yrityssalaisuuksien tiedot.

Mikä on ekosysteemi?

Ekosysteemissä kaikilla toimijoilla on yhteinen tavoite. Muuten se on vain löysempi verkosto. Ekosysteemissä useita käyttäjiä kohdennetaan tiettyihin rajapintoihin ekosysteemin laajempien tavoitteiden saavuttamiseksi. Ekosysteemi voi koostua julkishallinnosta, yrityksistä, voittoa tavoittelemattomista järjestöistä tai kansalaisista/kuluttajista. Kaikki nämä toimijat voivat myös olla läsnä eri rooleissa samassa ekosysteemissä. Operaattorit voivat tarjota yhteisasiakkailleen kattavan palvelutarjonnan ja asiakaspolun, jossa ekosysteemin eri resurssit tarjotaan johdonmukaisesti APIen kautta.

Kuka on API:n kuluttaja?

Rajapinnan hyödyntäjiä ovat kaikki ne tahot, jotka käyttävät (tai voisivat käyttää) kyseistä rajapintaa teknisesti ja toiminnallisesti ja joille kyseisen rajapinnan ja sen tarjoamien resurssien halutaan tuottavan lisäarvoa.

Mitä hyötyä on rajapinnan tarjoamisesta?

Hyödyt tarjoajalle ovat usein innovaatioiden mahdollistuminen, helppo viestiä tarjolla olevat resurssit ja arvolupaus hyödyntäjille, helppo tarjota hyödyntäjille lisäarvoa datan, palveluiden ja tuotteiden avulla Rajapintoja hyödyntävän järjestelmän tai kokonaisratkaisun elinkaari on usein pidempi, jolloin investoinnit kehitykseen ovat kannattavampia. Toisaalta käyttökokemukseen tai toimintamalleihin liittyvät muutokset voidaan toteuttaa nopeammin.

API palveluntarjoajan näkökulmasta, kuluttajien kehittämät innovaatiot API:n kautta ovat usein tapa hankkia ja testata tuotekehitysideoita edullisesti, ilman omaa merkittävää investointia. Palveluntarjoajalla voi myös olla

Joskus tarjoaja joutuu ensin hankkimaan rajapinnan tai rajapinnan tarjoavan tietojärjestelmän tai teknologian valmisohjelmistona tai -tuotteena tai ohjelmisto- tai teknologiakehityksenä. Rajapinnan tarjoamisen mahdollisuuksiin, kustannuksiin ja käyttöoikeuksiin voivat vaikuttaa hankintasopimuksessa määritellyt ehdot sekä käytettäviin teknologioihin liittyvät lisenssit ja patentit (mm. ohjelmointikielet, kuvausstandardit, tietomallit ja tietoliikenneprotokollat).

Rajapinnan tarjoama data saattaa olla tarjoajan omistamaa tai se voi olla rajapinnan hyödyntäjien tallentamaa dataa. Datan käyttöehdot ovatkin oma erillinen selvitettävä kokonaisuutensa.

Mitä arvolupauksia kannattaa tarjota rajapinnan hyödyntäjille?

Tarjoajan antama arvolupaus rajapinnan hyödyntäjille on usein se, että rajapinnan kautta on kustannustehokkaampaa hankkia esimerkiksi toiminnallisuutta, resursseja (tiloja, laitteita, osaamista jne.) tai dataa kuin tekemällä itse vastaavat ratkaisut tai niitä tarjoava kokonainen tietojärjestelmä, laitteisto tai muut resurssit.

Hyödyntäjille tulee tarjota helppo tapa kokeilla (usein käytetään ilmaisua testata, mutta testaaminen voidaan nähdä laajempana laadunvarmistuksena kuin ns. ennen hankintapäätöstä tapahtuva koekäyttö) rajapintaa ennen päätöstä sen ostamisesta, vuokraamisesta tai käyttöönotosta ilmaiseksi. Ennen kaikkea rajapinnan hyödyntäjän tulisi ymmärtää välittömästi, mihin rajapintaa voidaan käyttää. Rajapinnan avulla myös hyödyntäjä pyrkii usein synnyttämään innovaatioita ja mahdollisesti kaupallistamaan niitä tai antamaan niitä oman käyttäjäkuntansa käyttöön.

Mitä muita kysymyksiä tai ajatuksia rajapintojen avoimuudesta heräsi?

Jätä kommentti tai ota meihin yhteyttä - me Osaangolla tarjoamme konsultointia ja koulutusta mm. API- ja alustataloudesta.

Takaisin blogiin

viimeisimmät blogimme

Uutisia, asiakastarinoita, parhaita käytäntöjä ja paljon muuta - katso, mitä me ja asiakkaamme ja kumppanimme olemme tehneet viime aikoina

Miksi APIt kannattaa tuotteistaa?
Mitä hyötyä APIen tuotteistamisesta on? Lue lisää täältä!
16. kesäkuuta 2021
Millainen on hyvä API-tuotepäällikkö?
Kaksi API-gurua, Marjukka Niinioja ja Claire Barrett keskustelevat API-tuotepäällikön roolista ja odotuksista ja jakavat itetämystään menestyksekkäästä API-tuotehallinnasta.
14. kesäkuuta 2021
Osaango & KAVI – innovatiivisia, älykkäitä hankintoja
Kansallinen audiovisuaalinen instituutti KAVI tallentaa vuosittain valtavat määrät dataa, ja vastaa muun muassa kotimaisten elokuvien sekä televisio- ja radio-ohjelmien säilyttämisestä. Kriittisen tärkeässä osassa KAVIn toiminnassa on tekoäly. Osaangon Marjukka Niinioja ja Tessa Viitanen sparrasivat KAVIa heidän mittavassa toiminnan ja tekniikan muutos-casessa tekoälyyn pohjautuvien ratkaisujen, innovatiivisten hankintamenettelyjen, ohjelmistokehitysprosesssien ja arkkitehtuurin osalta.
27. toukokuuta 2021