API-arkkitehtuuri organisaation integraatioarkkitehtuurina

Mitä API tarkoittaa?

API tarkoittaa ohjelmointirajapintaa, ja se on lyhenne sanoista Application Programming Interface. Joskus apeista puhuttaessa termistö saattaa mennä hieman sekaisin, joten kerrataanpa oleellisimmat:

• OpenAPI: standardi, joka määrittelee, kuinka rajapinnan tulee olla kuvattu ja dokumentoitu

• Julkinen API (public API): mikä tahansa rajapinta, joka on julkaistu avoimeen internetiin ja julkisesti saatavilla. Rajapinnan ei tarvitse toteuttaa mitään standardeja ollakseen julkinen

• Kumppani-API (Partner API): rajapinta, joka on julkaistu avoimessa verkossa rajatulle joukolle kuluttajia, jotka on jotenkin hyväksytty API:n käyttäjiksi ja joiden kanssa on luotu jonkinlainen sopimus

• Sisäinen API (Private API): Sisäisessä verkossa organisaation muiden palveluiden tai järjestelmien käytettäväksi julkaistu rajapinta. Voi olla toteutettu OpenAPI-standardin mukaisesti

OpenAPI-standardin mukaisia rajapintoja voi julkaista myös omassa sisäverkossa omien järjestelmien kulutettavaksi. Usein OpenAPI:sta ja API-katalogeista puhutaan vain digitalisaation ja uusien myyntikanavien mahdollistajana, mutta API:t ovat joskus myös hyvä ratkaisu organisaation sisäisen integraatioarkkitehtuurin toteuttamiseen - eli moderni SOA (Service Oriented Architecture).

API-arkkitehtuuri ja mikropalvelut

Mikropalveluita kutsutaan usein SOA:n manttelinperijöiksi. Ne ovat API-rajapintoja, jotka sisältävät kokonaisen liiketoimintafunktion eivätkä ole pelkkiä integraatioita muihin järjestelmiin. Mikropalveluiden idea on skaalautua pilvialustalla elastisesti, kun riippuvuuksia muihin järjestelmiin ei ole (uncoupled). Mikropalveluiden teko on siis käytännössä sovelluskehitystä. Jos organisaatiolla on jo käytössä ERP tai CRM, joiden eteen API:t rakennetaan, eivät mikropalvelut ole järkevä ratkaisu.

Minipalvelut ovat muuten sama asia kuin mikropalvelut, mutta ne saavat olla kytköksissä muihin järjestelmiin (loosely coupled). Tällöin elastinen skaalautuvuus jää saavuttamatta, mutta ERPin tai CRM:n osia ei tarvitse rakentaa tyhjästä.

Mikropalvelut sopivat tuotekehitysmalliksi organisaatiolle, joka ei voi käyttää mitään valmissoftaa, koska sellaista ei ole. Minipalvelut taas ovat oikea valinta organisaatiolle, joka haluaa yleiskäyttöisen API-arkkitehtuurin olemassa olevan järjestelmäkentän päälle ja tueksi.

Koska kannattaa valita API-arkkitehtuuri?

Organisaation sisäistä API-arkkitehtuuria kannattaa harkita, jos palveluita kuluttavat osapuolet pystyvät kutsumaan rajapintoja, eikä niitä tarvitse triggeröidä käyntiin. Jos integraatioalustan pitää toimia prosessien käynnistäjänä, saattavat perinteiset integraatiot ja eräajot olla parempi valinta.

API on hyvä keino piilottaa vanhat järjestelmät taustalle. Jokaisella organisaatiolla on eri ikäisiä järjestelmiä, joissa on erilaisia rajapintaratkaisuja. Tarjottavat palvelut voi harmonisoida piilottamalla vanhemmat teknologiat API-rajapintojen taakse: tällöin API toimii ikään kuin fasadina kuluttavien osapuolten ja taustajärjestelmän välillä. Ja kun taustajärjestelmä tulee käyttöikänsä päähän, voidaan se vaihtaa huomaamattomasti uudempaan järjestelmään (tai vaikka useampaan!) ilman, että API-rajapintoja kuluttavat osapuolet joutuvat tekemään muutoksia. API-rajapinta tuo taustajärjestelmälle lisävuosia ja lyhentää palvelujen käyttöön ottamisen aikaa, koska palvelut on tehty yleisten käytäntöjen mukaan ohjelmointikieli- ja laiteriippumattomiksi.

API-rajapinta on hyvä valinta, jos tavoitteena on luoda palveluita, jotka keräävät dataa useammasta lähteestä. Lähteet voivat olla taustajärjestelmiä, tietokantatauluja tai muita lähteitä.

Yleiskäyttöisiä palveluita

API-arkkitehtuurin ideana on tarjota palveluita, joita kuluttaa useampi taho. Huonosti suunniteltuna apeillakin voi onnistua tekemään point-to-point-integraatioita, jos jokainen rajapinta räätälöidään yhdelle sitä käyttävälle taholle. API-arkkitehtuurissa avainsanoja ovat yleiskäyttöisyys ja skaalautuvuus. Siksi apeja suunnitellessa on tärkeää tunnistaa, mitä dataa ollaan jakamassa ja kenelle. Kuten integraatioissa aina, API-arkkitehtuurissakin päädytään lopuksi olennaisen äärelle: mikä on organisaatiosi liiketoiminnan tarve tälle palvelulle?

Palveluiden julkaisemisesta ei ole juurikaan iloa, jos kukaan organisaatiossa ei saa tietää palveluiden olemassaolosta. Sisäverkossa ei voi harrastaa hakukoneoptimointia, joten palveluita julkaistessa on tärkeää hoitaa organisaation sisäinen tiedonjako niin, että tietoa tarvitsevat ja kuluttavat tahot saavat tietää julkaistuista rajapinnoista. API managementia voi toteuttaa myös organisaation sisällä. Jos organisaatiolla on myös julkisia rajapintoja, voidaan ulkoiset ja sisäiset rajapinnat jakaa API management -työkalulla eri osioihin. Näin kaikkia apeja voidaan hallinnoida samalla alustalla, mutta käyttäjät näkevät kulloinkin rajapintakuvauksista vain osan riippuen, ovatko he sisäverkossa vai julkisessa verkossa.