Elääkö organisaatiossasi API-drontti?

Evoluution voima

Vuoden 1690 paikkeilla Mauritiuksella metsästettiin sukupuuttoon mauritiuksendodo eli drontti. Laji päästiin nuijimaan sukupuuttoon, koska sen ympäristö muuttui ihmisen ilmaantumisen johdosta niin nopeasti, ettei tämä sympaattinen ja kookas mutta lentokyvytön lintu kyennyt siihen mukautumaan. Kuten Leon C. Megginson mukailee Charles Darwinia: ”luonnossa eivät selviä vahvimmat tai älykkäimmät lajit, vaan ne jotka sopeutuvat herkimmin muutokseen”[1] . Tyypillisesti tällä viitataan yrityksen liiketoimintaympäristössä tapahtuviin muutoksiin, joihin sen pitää pystyä mukautumaan. Mutta yhtälailla muutokset IT-teknologioissa heittävät jo tehdyt tietotekniset ratkaisut evoluution kirjopesuun – eivätkä API:en hallinnan ratkaisut ole tästä poikkeus.

Epäonnistumisten syyt

Yleisimmät syyt miksi API:en hallinnan pilottihanke on ajautunut hiekalle ovat, että projektia lähdetään tekemään IT-vetoisesti ilman liiketoiminnan osallistamista. Lisää ongelmia tuo se, että organisaatio tekee tätä ensimmäistä kertaa eikä välttämättä osaa miehittää avainrooleja oikein, ei ymmärrä palveluiden ja API-rajapintojen eroja tai toiminnallisia vaatimuksia joita julkiset rajapinnat tuovat ympäristöön. Yhtä usein unohtuu osallistaa mahdolliset rajapintojen käyttäjät jo osaksi suunnitteluprosessia, määrittää mittarit projektin onnistumiselle ja mahdollisesti vielä markkinoida niitä rajapintoja potentiaalisille käyttäjille. Kun tähän soppaan vielä lisätään Gartnerin paperissa ’Predicts 2019: Democratization of IT Requires Different Strategies for Integration’ [2] esittämä ennustus, että vuoteen 2021 mennessä 25% organisaatioista joilla on julkisia API-rajapintoja joutuvat lopettamaan tai uudelleenkäynnistämään API-ohjelmansa puutteellisen tietoturvan vuoksi, ollaan pian tilanteessa jossa sitä palveluväylän ja mikrogatewayn ristytyksestä syntynyttä API:en hallinnan dodo-sorsaa ollaan nuijimassa hengiltä useammastakin suunnasta.

Lääkkeet

Lääkkeeksi epäonnistumisia vastaan Gartner suosittelee API-tuotepäällikön roolin perustamista. Hänen johdollaan on tärkeää huolehtia, että koko API:n elinkaari on katettu – mukaanlukien suunnitteluvaihe – ja sisällyttää tietoturva osaksi sitä. Näissä suurena apuna ovat koko elinkaaren kattavat kaupalliset API:en hallinnan alustat, jotka sisältävät tuen API-tuotepäällikön roolille sekä laajalle tietoturvalle. Ja muista, ettei API:en onnistumista mitata liikenteen määrällä, eikä edes käyttäjien määrällä, vaan sillä miten hyvin ne ovat linjassa liiketoimintatavoitteiden kanssa!

Arkkitehtuurin muutos

Myös hyvin suunnitellut ja pystytetyt API-hallinnan ympäristöt joutuvat mukautumaan ympäröivän arkkitehtuurin muuttuessa yhä kiihtyvällä tahdilla. Kun ensimmäiset ratkaisut on suunniteltu loogiseksi kerroskakuksi palveluväylän päälle, pitääkin tämän ratkaisun yhtäkkiä luoda sulkansa siten, että se pystyy tukemaan myös pilvinatiivien ja mikropalveluista rakennettujen hajautettujen arkkitehtuurien tarpeita, vieläpä monipilviympäristöissä. Lisäksi organisaatio muuttuu perinteisistä kehitystiimeistä ketterien mallien heimoiksi, killoiksi, osastoiksi, ryhmiksi jne. Nimenomaan tästä muutoksesta olen mukana puhumassa yhdessä kesän kiinnostavimmista tapahtumista: kesäkuussa Koskenrannassa järjestettävässä APIDays Finland -tapahtumassa. Monipuolisten ja innostavien puheenvuorojen lisäksi tapahtumasta tekee mielenkiintoisen sen historiallinen miljöö: drontit vielä tallustelivat Madagaskarilla kun kuningas Kustaa Vaasa perusti vuonna 1550 Helsingin näille main. Mikäli organisaatiossasi elää API-drontti, tai epäilet sellaisen olevan muotoutumassa, tule kuuntelemaan viimeisimmät vinkit API-evoluution saralla.

1. 1. Megginson, ‘Lessons from Europe for American Business’, Southwestern Social Science Quarterly (1963) 44(1): 3-13, at p. 4.
2. 2. Gartner, ’Predicts 2019: Democratization of IT Requires Different Strategies for Integration’ , (2019): https://www.gartner.com/en/documents/3898763

Tutustu ilman kustannuksia: IBM API Connect