APIttaminen on liiketoimintapäätös

Sovelluskehittäjiä on aina kiinnostanut jakaa vastuita osiin, paketoida ja hajauttaa tehtäviään. Rynnätäkseen kehityksessä eteenpäin he käyttävät mielellään hyväkseen jonkun toisen ratkaisuja. Miten niin sanottu APIttaminen tähän liittyy ja miksi siihen kannattaa panostaa?

Moderni järjestelmäkehitys on suurelta osin valmiiden palikoiden ja tietolähteiden koostamista yhteen. Tehtävien ja vastuiden paketointi, ns. komponentisointi, tuo mukanaan käsitteen ohjelmointirajapinta (API).

APIttaminen on toimintojen ja tietojen tarjoamista palveluna järjestelmien käytettäväksi. API piilottaa taakseen varsinaisen toteutuksen ja paljastaa käyttäjälleen vain yksinkertaistetun vuorovaikutusmallin.

Karkeasti yleistettynä APIttamisen taustalla on kaksi mallia: proaktiivinen ja reaktiivinen. Proaktiivisesti tarjottavan rajapinnan avulla arvaillaan kohdeyleisön tarpeita ja kalastellaan uusia käyttäjiä omille ratkaisuille tai tiedoille. Siis luodaan aktiivisesti uutta kysyntää. Reaktiivisessa mallissa taas aloite ja tarve tulevat ulkoa. Toiset osapuolet ovat jo havainneet toiminnon tai tiedon arvon omassa liiketoiminnassaan ja haluavat hyödyntää sitä.

Molemmissa kyse on lopulta liiketoimintapäätöksestä, joka tiivistyy kysymykseen: “Onko kyvykkyyden tai tiedon tarjoamisesta muille palveluna enemmän hyötyä kuin siitä koituu vastuita, ylläpitokuluja ja työtä?”.

Yksittäiset kehittäjät tekevät APIttamispäätöksiä päivittäin koodin tasolla, helpottaakseen omaa tai kaverin työtä. Järjestelmän tai tuotteen omistajat miettivät asiaa hieman isommissa kokonaisuuksissa ja tuovat mukaan ehkä ansaintalogiikan. Päätös panostaa avoimeen rajapintaan  voi olla strateginen, yksittäisen organisaation johtoryhmän tai organisaatioiden ryhmittymien tekemä. Se voi olla myös poliittinen, yhteiskunnan säätelyn mekanismi.

APIttamisen hyödyt

Miksi APIttaminen sitten kannattaa? Seuraavassa muutamia konkreettisia hyötyjä lyhyine perusteluineen.

  1. Toteuta integraatiot itsepalveluna

Tarkoitus on pyrkiä siihen, että jos vaikkapa verkkokauppa haluaa näyttää käyttäjälle tilauksen toimituksen tilan, ei verkkokaupan kehittäjien tarvitse kuin etsiä kehittäjäportaalista oikea API ja ottaa se käyttöön omassa ratkaisussaan. Muita osapuolia ei käyttöönotossa tarvita. Tähän päästään laatimalla hyvä tietoarkkitehtuuri ja vaatimalla järjestelmiltä tuotteistettuja rajapintoja.

  1. Nosta sovelluskehittäjät keskiöön

Meidän on vaadittava järjestelmiltä ihmisymmärrettäviä, hyvin määriteltyjä ja helposti käyttöönotettavia rajapintoja. APIn tuottajan on tuettava muita kehittäjiä hyvällä dokumentaatiolla, toimivilla koodiesimerkeillä, vertaisyhteisöllä ja jopa toimittava sovelluskehitystukena. Itsestään selvää on, että virhetilanteet ja niistä toipuminen on oltava hyvin suunniteltu ja automatisoitavissa.

Kun oikein rakennetulla tiimillä on valtuudet sekä palvelun sisällöstä että sen toteuttamiseen liittyvistä asioista, motivaatio tehdä laadukkaita ratkaisuja kasvaa. Rajapinnat tuotteistetaan, jolloin niiden käytön itsepalveluaste kohoaa.

  1. Yksinkertaista ja vähennä yllätyksiä

Teknologiakirjo kasvaa ja kasvaa, joten APIttamisella on yhä oleellisempaa luoda liiketoimintaa tukevia mahdollisimman yksinkertaisia ratkaisuja. Etenkin niin sanottujen Web APIen hallintaan kehittäjät saavat nykyään yksilöivän avaimen, jolla voi seurata käyttöä ja asettaa erilaisia rajoituksia, sekä muutostilanteessa viestiä kehittäjien kanssa etukäteen ja vähentää yllätyksiä.

  1. Tehosta innovaatiosykliä

Rajapintakuvaus edellä voidaan rynnätä mittaamaan kiinnostusta jotain ideaa kohtaan, jopa ennen kuin investointipäätös varsinaiseen palveluun on edes tehty. Kun järjestelmien toiminnallisuuksia ja tietoja avataan hallitusti laajemmalle joukolle, ideoiden määrä lisääntyy. Joukosta saattaa löytyä ennalta arvaamattoman suosittuja ja raikkaita yhdistelmiä sekä näkökulmia.

  1. Lisää suojaa operatiivisille järjestelmille

Varsinkin tietokyselyrajapintojen osalta on turhaa kuluttaa yrityksen operatiivisten järjestelmien, monesti kalliisti lisensoitua, laskentakapasiteettia. Transaktion tai entiteetin tilan muutos voidaan julkaista myös ulos. Pilvipalveluiden tai avoimen lähdekoodin teknologian varaan rakennetut tietopalvelut voivat ottaa muutoksen vastaan ja tarjota eteenpäin kyselyrajapinnat, jotka skaalautuvat itsenäisesti ja halvasti kyselyjen määrän mukaan.

--

Konkreettisia hyötyjä tulee tietenkin aina miettiä oman yrityksen kontekstissa ja luoda API-strategia tekemisen tueksi. Oleellista on ymmärtää, että arkkitehtuuri, kehitysnopeus, laatu ja organisaatio heijastelevat toisiaan.

Panostamalla mikropalveluarkkitehtuuriin, autonomisiin toimitustiimeihin ja kehittäjäystävällisiin rajapintoihin voit tehostaa palvelujen kehittämistä sekä skaalautumista. Toteutuksiin tulee lisää tärkeää tuotelähtöisen liiketoiminnan ajattelua.

Marko Pitkänen

Marko Pitkänen

Työskentelen Solteqissa pääarkkitehtina. Erikoisosaamiseni on järjestelmäintegraation alalta. Tällä hetkellä yritän ymmärtää miten modernisoida järjestelmäkehityksen ja arvon tuotannon menetelmiä. Vapaa-ajallani olen innokas ulkoliikunnan harrastaja ja vienkin usein perhettäni esimerkiksi suunnistuskilpailumatkoille.
Lue kaikki kirjoittajan artikkelit