Tilanteessa, jossa organisaatiossa kaikki API-talouteen hyppäämisen esteet on jo ennakkoon ratkottu, muodostuu haasteeksi lähinnä itselle parhaiden toimintatapojen hahmottaminen. Vaikeus API-talouteen lähtemisessä piilee lähinnä siitä, ettei toimintatapaan ole yhtä oikeaa valmista mallia.
API-talous puhuttaa tällä hetkellä varsin laajasti ihmisiä aikaansa seuraavissa organisaatioissa. API:t ovat luonnollinen keskustelun aihe teknisen IT-väen keskuudessa. Niissä ei ole mitään uutta ja ihmeellistä. Ainoastaan tekniset API-hallintaratkaisut ovat uudempi tulokas aihepiiriin, sillä niille on noussut tarve, kun API-kehityksen mittakaava on kasvanut ja hommaa halutaan tehdä silti hallitusti ja tehokkaasti. Kehitysmenetelmät ja API-hallintaratkaisut ovat kehittyneet käytettäviksi ja laadullisesti kypsiksi. Teknisestä näkökulmasta API:t ovat varsin ”Business as Usual”.
API-talouden työkalut
Liiketoiminnan näkökulmasta API-talous ymmärretään käsitteenä hyvin. Alustatalouden API-vetoiset esimerkit ovat kaikille tuttuja. Esimerkiksi lentoliput on pitkään varattu edullisimmat hinnat yhteen koostavista palveluista ja Amazonin rantautumista synkkään Pohjolaan spekuloidaan valtamedioita myöden.
Oman organisaation liiketoimintalähtöiseen API-kehittämiseen on menetelmäpuolella tarjolla toimivia työkaluja.
Esimerkiksi laajasti hyödynnetystä liiketoiminnan Business Model Canvas -työkalusta on muokattu API-tuotteiden liiketoimintanäkökulman jäsentämiseen oma API Model Canvas. Liiketoiminnan suunnalta ei kokemukseni mukaan nähdä mitään estettä täysimittaiseen API-talouteen mukaan hyppäämisessä.
API:en omistajuus aiheuttaa päänvaivaa
Missä sitten suurimmat haasteet tulevat vastaan? Viime aikaisissa keskusteluissa asiakkaiden kanssa on toistunut yksi ja sama teema, kun API:en laajaa hyödyntämistä aletaan suunnittelemaan: API-kehittämisen hallintamalli. Valitettavasti vanha kunnon governance nostaa vahvasti päätään myös hyvin nahkansa luoneella API-aikakaudella.
Kaikista konkreettisimmaksi haasteeksi tunnutaan koettavan API:en omistajuus. Tilanne on lopulta varsin ymmärrettävä. Samalla API:lla voi olla käyttäjiä sekä organisaation sisältä että ulkoa. Sisälle API voi näyttäytyä hyvin teknisenä tuotteena, kun taas ulospäin puhtaasti asiakkaille tarjottavana liiketoimintapalveluna.
On selvää, että API:en omistajuus ei putoa luontevasti suoraan mihinkään olemassa olevaan rooliin – API:en omistajuus on selvästi uusi rooli.
Aiheesta on kirjoiteltu ehkä eniten otsikolla API Product Manager. Itselleni roolia on ollut luontevampi hahmottaa agile-metodologioista johdetulla termillä API PO eli API Product Owner.
Minkään ihmeellisen asian äärellä tässä ei olla, mutta selkeästi vaaditaan vähintään uudelleenorganisoitumista ja uuden oppimista. Omistajuuden rooli edellyttää liiketoiminnan tuntemista ja ennen kaikkea tiivistä yhteistyötä sekä liiketoimintakehityksen että IT:n vetämän API-kehityksen suuntaan. Tästä syystä roolia ei ole myöskään helppo ostaa ulkoa, tai ainakin siinä tuottavasti alkuun pääseminen ottaa enemmän aikaa kuin joissakin suppeammin rajautuvissa rooleissa.
API-käsikirjan laatiminen linjaa toimintaa
Toinen paljon puhuttanut aihe on teknisen kehittämisen tueksi tarvittava ohjaus. Teknisen API-hallintaratkaisun hyödyntämiselle on hyvin selkeä tarve, kun API-kehittämisen mittakaava kasvaa vähänkään. Työkalu ohjaa tiettyyn systemaattisuuteen, mutta mitä muuta ohjausta vaaditaan, jotta ei siirryttäisi kuitenkaan jarrumiehen rooliin?
Missä menee raja, kun toisaalta halutaan mahdollistaa API:en kehittäminen ketterästi monipuolisilla teknologioilla, mutta tarjota samalla yhtenäinen käyttökokemus API-asiakkaan suuntaan?
Tähän ongelmaan olen suositellut yleensä niin sanotun API-käsikirjan laatimista. Käsikirja linjaa API:en suunnitteluun, kehittämiseen ja hallinnointiin liittyvät asiat sillä tasolla, että ne toimivat konkreettisina ohjeina kehittäjälle ja varmistavat API-asiakkaalle yhtenäisen käyttökokemuksen, olipa API-endpoint sitten Pythonilla tehty serverless-funktio tai on-premise -integraatioalustalta tarjottu API.
Käsikirjassa tulisi käsitellä ainakin linjauksia seuraaviin asioihin: nimeämiskäytännöt, URL-rakenteet, HTTP-verbien käyttö, API:en hieno-/karkeajakoisuus, vastausten HTTP-statuskoodit, haku-, suodatus-, järjestämis- ja sivutusratkaisuiden käytännöt ja versiointimalli. Lisäksi tulisi linjata API-hallintaratkaisun hyödyntämisen käytännöt esimerkiksi tunnistamiseen ja käytönhallintaan liittyen.
Tässäkään ei olla minkään organisaation uniikin asian äärellä, joten käsikirjan pohjaksi kannattaa harkita asiaa pidempään miettineen tahon julkaisemaa ohjeistusta. Google on esimerkiksi julkaissut omassa API-kehityksessään soveltamansa käsikirjan.
Kun organisaatiossa kaikki API-talouteen hyppäämisen esteet on jo ennakkoon ratkottu, tulee kyse lähinnä itselle parhaiden toimintatapojen hahmottamisesta. Vaikeus tuleekin lähinnä siitä, ettei toimintatapaan ole yhtä oikeaa valmista mallia, eikä sitä voi ratkaista yhtä helposti kuin teknisiä tarpeita sopivien teknologioiden käyttöönotolla, vaan aina jää jäljelle myös muutoksen vieminen käytäntöön.
Kiinnostuitko? Lue lisää asiasta verkkosivuiltamme ja tutustu asiantuntijoidemme ajatuksiin blogit-sivullamme.