Integraatiot murroksessa API-hallinnan aikakaudella

Ohjelmistoalan kuhistessa API-hallinnasta herää kysymys, ovatko integraatiot jäämässä paitsioon? Tosiasiassa integraatiototeutus ja API ovat saman kolikon kaksi puolta tiedon järjestelyssä haluttuun muotoon – ja molemmilla on opittavaa toisistaan.

Ohjelmistoalalla kuhistaan nykyään API-hallinnasta, API-taloudesta ja API edellä kehittämisestä. Se on tämän hetken kuuma peruna, johon suuret ja pienet ohjelmistotoimittajat ovat tarmolla iskeneet kiinni, ja josta kirjoitetaan paljon. Kun ennen puhuttiin integraatiosta, nykyisin puhutaankin API:sta. Onko siis niin, että API on tullut ja korvannut integraatiot? Tarvitaanko enää integraatioita yhdistämään tietojärjestelmiä, käyttäjiä ja asiakkaita?

Mitä integraatio tarkoittaa?

Mitä integraatio sitten oikein tarkoittaa, ja miten se eroaa API:sta? Kun puhutaan perinteisestä integraatiosta kahden järjestelmän välillä, kyse on kahden erilaista tietomallia ja/tai teknologiaa käyttävän järjestelmän välisestä kommunikoinnista, jotka käsittelevät kuitenkin samaa tietoa.

Näillä järjestelmillä on yrityksissä monesti erilainen ja eri vaiheessa oleva elinkaari, eikä niissä välttämättä ole valmiina liitäntöjä toisiinsa. Kun yksi järjestelmä tulee elinkaarensa päähän, korvaava järjestelmä täytyy jotenkin saada toimimaan niiden järjestelmien kanssa, joihin vanhakin on yhteydessä. Integraatiot ovat ketterä ratkaisu, joilla saadaan nämä järjestelmät toimimaan yhdessä nopeasti ilman, että kyseisiä järjestelmiä tarvitsee muuttaa.

Sisäisistä integraatioista ulkoisiksi palveluiksi

Perinteisesti integraatioita on rakennettu erillisen integraatioalustan avulla, jota yleisesti nimitetään ESB:ksi (Enterprise Service Bus). Järjestelmät, joita integraatioalusta yhdistää, ovat usein sisäisiä järjestelmiä, jotka hoitavat tiettyä liiketoiminnalle välttämätöntä osa-aluetta. Ne voivat olla asiakkaan tai liikekumppanin järjestelmiä (B2B) tai kuluttajille suunnattuja liitäntöjä (B2C). Integraatioilla voidaan myös tarjota sisäisiä järjestelmiä ulospäin palveluina, sekä pidentää kalliiden taustajärjestelmien elinkaaria. Yrityksen sisäiset integraatiot ovat usein jatkuvasti pienessä liikkeessä hankintojen ja projektien vuorovaikutuksessa.

Tätä vuorovaikutusta on ohjannut pitkään palvelukeskeinen arkkitehtuuri, eli yleisemmin terminä tuttu SOA. Sisäisten järjestelmien sekä asiakkaiden väliset integraatiot ovat olleet tässä edelläkävijöitä, mutta viime vuosina rajapintoja on täytynyt tarjota enenevässä määrin myös ulkoisille applikaatioille, etenkin mobiiliapplikaatioille. Tästä johtuen integraatioiden täytyykin nykypäivänä palvella huomattavasti isompaa asiakaskuntaa kuin aikaisemmin. Ennen integraatiossa ratkottiin läpäisykykyyn liittyviä ongelmia, mutta nyt haasteena on lisäksi saatavuus. Kun integraatioita tarjotaan ulos palveluina, on luonnollisempaa puhua API-rajapinnoista. Mutta onko API sitten pelkästään integraation rajapinta?

API-hallinta taklaa integraatioiden haasteita

Järeät integraatioalustat ovat nykyisin hieman huonossa maineessa, koska ne koetaan raskaina ja vaikeina hallita sekä oppia käyttämään. Integraatioihin liittyviä standardeja usein sovelletaan ja muokataan, jotta alusta saadaan sidottua kiinteämmin osaksi omaa tuoteperhettä. Kehitykseen tuntuu kuluvan kohtuuttomasti aikaa, eivätkä toteutukset ole helposti testattavia, koska datasta tai järjestelmistä ei ole olemassa täysin tuotantoa vastaavia versiota testaukseen. Tuotannon ongelmien selvityksissä kestää kauan eikä toiminnasta ole olemassa kokonaiskuvaa, koska pystyttämisen jälkeen integraatiot saattavat olla koskemattomia jopa vuosia. Lisäksi integraatioista vastaa yleensä erillinen integraatioyksikkö, joka on yksi ajan tasalla pidettävä toimija lisää sovelluskehityksen aikana, ja joka monesti saattaa jäädä pois kokonaisratkaisun suunnittelusta, vaikka onkin hyvin keskeinen osa toiminnallisuutta.

API:n hallinnalla kyetään ratkaisemaan joitakin näistä ongelmista. Integraatiot saadaan API-tilausportaalin avulla tarjottua yhdenmukaisesti ja turvallisesti käyttäjille. API-hallintatyökaluilla saadaan myös hoidettua monia integraatiossa vaivalloisia toimintoja kuten käyttäjän autentikointi, liikenteen seuranta ja sen rajoittaminen palvelinkapasiteetille oikeaksi. API:t ovat myös paremmin löydettävissä, ja usein niiden dokumentointi voidaan hoitaa osana API-hallintaa. Rajapinnoissa ollaan myös siirrytty mobiiliaikakaudella kevyempiin REST-tyyppisiin rajapintoihin, joissa data liikkuu usein JSON-muodossa XML:n sijaan. Perinteisissä integraatiossa on hyvä huomata että taustajärjestelmät, joiden kanssa integraatiot toimivat ovat usein myös API-rajapintoja, ja voisivat samalla tavalla hyötyä API-hallinnasta ja siten helpottaa integraatiokehitystä.

Kuulostaa siis melko hyvältä, mutta ratkaisuissa täytyy muistaa, että järjestelmäintegraatioissa API:en taustalla on kuitenkin aina myös varsinainen integraation toteutus. Joissakin API-tuotteissa voi olla mahdollisuus kevyen integraation toteuttamiseen sisäisesti, mutta ominaisuudet niissä ovat yleensä rajoitettuja, eikä versiointi välttämättä onnistu.

Integraatioalustat murroksessa

Nykyisin integraatioalustojen vahvuutena ovat lukuisat valmiit adapterit tunnetuimpiin järjestelmiin ja protokolliin, sekä vahvat sisäiset viestimuunnosteknologiat. Vaikka JSON:ia käyttävät REST rajapinnat yleistyvät, viestimuunnokset on monesti yhä helpointa toteuttaa XML muodossa. Integraatioalustat ovat hiljalleen muuttumassa perinteisestä SOA-mallista skaalautuvampaan mikropalveluarkkitehtuuriin (MSA), jossa tarve monoliittisen integraatioväylän asentamiseen pienenee. Mikropalveluissa ei olla myöskään niin riippuvaisia yhdestä teknologiasta, vaan toteutukseen voidaan valita tilanteeseen sopivin. Tällaiset kevyemmät ajoympäristöt mahdollistavat myös pilvipalveluiden tehokkaamman hyödyntämisen.

Myös DevOps-kulttuurin kasvu ja omaksuminen auttaa monessa integraatioita haitanneessa vaivassa. Kehityssyklit saadaan lyhyemmiksi, kun integraation julkaisu palvelimille, testaus, API:n julkaisu, julkaisu tuotantoon sekä dokumentointi saadaan automatisoitua ja ne toimivat synkronoidusti nykyaikaisen versionhallinnan ja pakettivaraston kanssa. On kuitenkin tärkeää muistaa, että yksinkertaiset osaratkaisut ovat yleensä kaikkein toimivimpia. Jos kokonaisratkaisu toimii, mutta alkaa vaikuttaa Rube Goldbergin koneelta, ongelmatilanteiden selvittäminen voi olla hyvin vaikeaa.

“Hajota ja hallitse” on hyvä periaate, jota kannattaa noudattaa integraatioissa, automaatiossa sekä API-rajapinnoissa. Kaikkien sovellus- ja integraatiokehityksessä mukana olevien komponenttien on hyvä olla testattavia ja kehitettäviä myös prosessiketjusta irrotettuina, eikä yhteen komponenttiin ole hyvä liittää liikaa toiminnallisuuksia, jotka eivät sinne helposti sovellu.

Jos tarkastellaan asiaa teknologian ja tuotteiden lävitse, integraatiot ovat pohjimmiltaan tiedon järjestelyä haluttuun muotoon. Tällöin integraatiototeutus ja API ovat kolikon kaksi puolta, jotka kumpikin hoitavat tästä oman puoliskonsa.

API:en määrä kasvaa jatkuvasti, koska toimimme yhä avoimemmassa toisiinsa liittyvien tietojärjestelmien ympäristössä. Data halutaan vapauttaa palvelujen ja rajapintojen kautta, mutta se täytyy tehdä turvallisella tavalla hallitusti. Siinä API-hallinta on työkalu, jota ilman ei pärjää - mutta tavalla tai toisella taustalla on kuitenkin aina integraatio, vaikka se olisi applikaation sisällä.