Integraatioarkkitehtuurin tulee kestää muutoksia

Integraatioarkkitehtuurin ja erilaisten rajapintojen merkitys korostuu tiedon lisääntyessä ja järjestelmien monimutkaistuessa. Rajapintojen monikäyttöisyys ja integraatioiden muokattavuus on kuitenkin syytä pitää mielessä, jotta toteutus pysyy mukana myös tulevaisuuden kehityskaaressa.

Integraatioista puhuttaessa kohtaa yllättävän paljon ennakkoluuloja. Ne koetaan usein haastaviksi, niiden toimintaa ei hahmoteta, tai ne koetaan turhan järeiksi ja kalliiksi. Tuskastumisen taustalta paljastuukin usein vanhoja, sekalaisilla ajastetuilla scripteillä toteutettuja integraatioita, joiden tekijä ei ole enää talossa, eivätkä vanhentuneet integraatiomenetelmät enää vastaa monimuotoistuvan liiketoiminnan vaatimuksiin.

Myös integraatioteknologiat ja -arkkitehtuurit kehittyvät, ja SOA:n ja ESB:n tilalle onkin monin paikoin tullut kehittäjäystävällisemmät ja modernimmat REST-tyyliset APIt (Application Programming Interface). Jo pelkästään eri tiedostomuodot, kuten XML ja JSON, ovat aiheuttaneet omat debattinsa. Molemmissa on toki puolensa, mutta väärällä työkalulla käytettynä kumpi tahansa voi vaikuttaa erityisen huonolta.

Yksisuuntaisen vanhan sanomaliikenteen sijaan modernit integraatiot ovatkin hyvin vuorovaikutteisia ja rajapintojen kautta integraatiot pystyvät tekemään hyvinkin täsmällisiä toimenpiteitä.

Integraation orkestrointi ja API

Julkisten pilvipalveluiden ja teknologiayhtiöiden tarjoamien avointen rajapintapalveluiden myötä erilaisten pienten integraatioiden määrä on kasvanut, ja niistä on tullut luonteva osa ohjelmistokehitys ja -käyttöönottoprojekteja. Integraatioiden kehitys onkin arkipäiväistynyt hyvässä mielessä ja yhä useampi meistä kohtaa erilaisia järjestelmäintegraatioita ja niiden puutteita työssään.

Integraatioiden vuorovaikutuksellisuuden kasvaessa liikkuvaa tietoa voidaan ehdollistaa, jolloin kyse ei olekaan enää yksisuuntaisesta datan siirrosta. Integraation orkestroinnissa prosessi kutsuu suorituksen aikana toista prosessia, ensimmäiseltä saadun vastauksen perusteella.

Myös integraatiotekniikat kehittyvät jatkuvasti, ja tällä hetkellä yksi yleisimmistä tavoista lähestyä integraatiototeutuksia on API-arkkitehtuuri. APIn perusajatuksena on, että integraatioprosessin tarvitsemat toiminnot pilkotaan omiksi erillisiksi toiminnoikseen, joita voidaan kutsua useimmiten REST-tyylisen APIn kautta. Kaikille integroitaville järjestelmille luodaan aina omat tarvittavat APIt, joiden kautta järjestelmän tarjoamia toimintoja ja dataa voidaan hyödyntää. Useimmissa järjestelmissä onkin nykyisin tarvittavat APIt jo valmiina, mikä osaltaan helpottaa järjestelmien käyttöönottoa.

Onkin tärkeää ajatella myös nykyisen käyttötarpeen ulkopuolelta, jotta toteutettavasta APIsta tulee jo lähtökohtaisesti riittävän monikäyttöinen.

Uutta APIa suunniteltaessa onkin tärkeää ajatella myös nykyisen käyttötarpeen ulkopuolelta, jotta toteutettavasta APIsta tulee jo lähtökohtaisesti riittävän monikäyttöinen. Kun jo olemassa olevaa APIa hyödynnetään yhdessä muiden APIen kanssa uuteen käyttötarkoitukseen, tämä tekee arkkitehtuurista kustannustehokkaan ja nopean tavan toteuttaa uusia prosesseja ja palveluita.

API-arkkitehtuuri soveltuu yksinään parhaiten esimerkiksi verkkopalvelun tai mobiilisovelluksen taustalle. Koska APIt eivät itsestään tee mitään, vaan odottavat ulkoisen järjestelmän tai sovelluksen kutsua, tarvitaan APIn lisäksi aina myös ulkoinen käskynlähde.

Tapahtumapohjainen integraatioarkkitehtuuri

Yksinkertaisimmillaan käskyjako voidaan toteuttaa toistuvasti ajastettuina kutsuina APIin, joka orkestroi taustalla kokonaisen integraatioprosessin. Mikäli liikuteltava data kuitenkin muuttuu hyvin epäsäännöllisesti, järjestelmiin aiheutuu paljon turhia kyselyitä. Ratkaisuna tähän on tapahtumapohjainen integraatioarkkitehtuuri, missä kukin dataa sisältävä järjestelmä ilmoittaa, kun jokin tieto järjestelmässä on muuttunut. Kun ilmoitus muutoksesta tehdään kutsumalla siihen tarkoitettua APIa, voi se edelleen kutsua varsinaista integraatioprosessia toteuttavaa APIa, kuten ajastetussa vaihtoehdossa. Tällöin integraatioprosessi suoritetaan vain tarpeesta, ja tapahtuman ilmoittaneesta järjestelmästä riippuen integraatio on lähes reaaliaikainen.

Esimerkki tapahtumapohjaisen API-arkkitehtuurin käyttötapauksesta on vaikkapa asiakastietojen integraatio CRM:stä ERPiin. CRM-järjestelmässä on API, jonka avulla saadaan luettua yksittäisen asiakkaan tiedot. ERPissä vastaavasti on API, jonka avulla voidaan tallentaa yksittäisen asiakkaan tiedot. Kun käyttäjä muokkaa asiakkaan tietoja CRM:ssä, CRM kutsuu tapahtuma-APIa seuraavilla parametreillä: lähde=CRM, tieto=asiakas, id=X. Tapahtuma-API taas välittää kutsun toiselle APIlle, joka taustalla kutsuu CRM:n asiakastieto-APIa, tekee sinne tarvittavat muutokset, ja kutsuu lopuksi ERPin asiakastieto-APIa tallentaakseen muuttuneet tiedot.

Voidaan puhua jo kokonaisten prosessien automatisoinnista, mikä taas tarkoittaa toiminnan tehostumista, manuaalisen työn vähentymistä ja siten kustannussäästöjä pidemmällä aikatähtäimellä.

Yhdistelemällä erilaisia APIen tarjoamia toiminnallisuuksia tapahtumapohjaisuuteen, voidaan puhua jo kokonaisten prosessien automatisoinnista, mikä taas tarkoittaa toiminnan tehostumista, manuaalisen työn vähentymistä ja siten kustannussäästöjä pidemmällä aikatähtäimellä.

API-arkkitehtuurin toteutukseen on tietysti useita vaihtoehtoja. Azure ja AWS tarjoavat molemmat omat palvelunsa API-arkkitehtuurin perustaksi, niin toiminnallisuuden, kuin API-hallinnan osalta. Näiden lisäksi myös erityisesti integraatioihin tarkoitetut integraatioalustat, kuten Dell Boomi ja Mulesoft Anypoint platform, tarjoavat tehokkaita työkaluja itse prosessien toteutukseen.

Mitä laajemmasta kokonaisuudesta integraatioiden osalta puhutaan, sitä todennäköisempää on, että tarpeet ja vaatimukset muuttuvat projektin aikana. Vaikka tuskin on olemassa integraatioiden hopealuotia, joka yksin sopii kaikkeen, sopivimmat teknologiat ja työkalut yhdistelemällä integraatiot saadaan toteutettua ketterästi ja joustavasti tarpeiden muuttuessa.