– Perinteisesti palveluarkkitehtuurissa on rakennettu suljettuja kokonaisuuksia; liiketoiminnan edellyttämät muutokset on tehty järjestelmien sisällä. Käytännössä API-johtoisella arkkitehtuurilla haetaan toimintamallia, missä lähtökohtana on järjestelmissä olevien tietojen ja toiminnallisuuksien käytettävyys vakiintuneiden liityntäpintojen kautta niin kokonaisuuden sisällä kuin sen ulkopuoleltakin, kertoo Bonsky Digitalin Solution Architect Kimmo Lankila.

Tavoitteena tukea liiketoimintalähtöistä tekemistä

Mitä enemmän siirrytään API-lähtöiseen kerrostettuun palveluratkaisumalliin, sitä helpommaksi erilaiset siirtymät järjestelmistä toiseen tulevat.
– Muutokset järjestelmien sisälle rakennettuihin ratkaisuihin on pitänyt toteuttaa toimittajan avulla. Tämä on usein hidasta, työlästä ja kallista. Tämän lisäksi järjestelmien välisiä yhteyksiä on usein ratkottu yksittäisiin tarpeisiin liittyen erilaisten integraatiovälineiden avulla, mikä on herkästi tehnyt järjestelmien välisistä suhteista hyvinkin kompleksisia, toteaa Lankila.

API-johtoisessa arkkitehtuurissa on kyse asioiden kerrostamisesta, osasten irrottamista toisistaan. Oikeampi termi olisikin API-johtoinen mikropalveluarkkitehtuuri.
– Mikropalveluarkkitehtuurissa toteutusmallina on synnyttää pienempiä kokonaisuuksia, joita on helpompi kehittää ja hallita itsenäisesti. Tätä mikropalveluiden taustalla olevaa lähtökohtaista ajatusta pienemmistä kokonaisuuksista hyödyntäen saavutetaan kehittymisen kyvykkyyttä, jossa eri liiketoiminnan osa-alueiden tarpeita voidaan viedä digitalisoinnin osalta eteenpäin toisistaan riippumatta, Lankila kertoo.

– Samalla mahdollistetaan uusien kolmansien osapuolien palveluiden ketterä hyödyntäminen. Muun muassa pilvipalvelut tarjoavat jatkuvasti kehittyviä ominaisuuksia ja palveluita, joilla tuoda järjestelmiin uusia ominaisuuksia ja tehostaa kehittämistä, kertoo Vincitin ohjelmistokehittäjä Jukka Rintaluoma.

Aito API-johtoinen kerrostettu palveluarkkitehtuuri rakentaa kustannustehokkuutta ja uudelleenkäytettävyyttä. Näin myös poistetaan turhia tarpeita tehdä erikoisratkaisuja tiedonsiirtämiseksi tulevaisuudessa.

– Haluamme ohjata asiakasta pois yhden järjestelmän loukusta. Tiedon käsittelyn ympärillä olevien prosessien ja järjestelmien tulisi mukautua liiketoiminnan tarpeisiin, eikä toisinpäin siten, että liiketoimintaa joudutaan pyörittämään järjestelmien ehdoilla.

Mistä erotat aidosti itsenäisen ja näennäisen API-johtoisen palveluarkkitehtuurin?

Lähes kaikki alustat tuntuvat myyjien puheiden perusteella olevan API-johtoista palveluarkkitehtuuria parhaimmillaan. Miten sitten erottaa aidosti API-johtoisen, itsenäisen palveluarkkitehtuuritehtailun näennäisesti vendor lockiin pahemmin sysäävästä ratkaisusta?
– Esim. Salesforce ja SAP ovat periaatteessa API-kyvykkäitä alustoja. Mutta näissä tapauksissa API-lähtöisyys on lähtökohtaisesti sidottu alustaan ja sen kyvykkyyksiin. Niiden kehittäminen edellyttää alustan syvempää tuntemista ja mahdollisesti niille erityisesti kehitettyjen välineiden käyttöä. Sitoutumalla lähtökohtaisesti keskittämään ratkaisut tällaisen alustan ympärille menetetään joustavuus etsiä ja hyödyntää parhaiten kuhunkin tarpeeseen soveltuvia ratkaisuja ja ohjaudutaan tilanteeseen missä, jälleen kerran, yhden järjestelmän kyvykkyys rupeaa ohjaamaan liiketoiminnan kehittymismahdollisuuksia, painottaa Lankila.

API-johtoinen palveluarkkitehtuuri pyrkii murtamaan järjestelmien välisiä siiloja, ja mahdollistamaan ensiluokkaisen ja monikanavaisen käyttökokemuksen kerroksellisella ja modulaarisella toteutustavalla.
– Näin luodaan liiketoiminnalle oma pelikenttä kehittää kullekin taholle tarpeellisia kyvykkyyksiä, ja irrottaudutaan samalla yksittäisten järjestelmien ja niiden toimittajien luomista rajoitteista, jatkavat Rintaluoma ja Lankila.

Palveluarkkitehtuurin täytyy pystyä mukautumaan liiketoimintaan

API-johtoisen palveluarkkitehtuurin suurin etu on luoda organisaatioon kyvykkyyttä skaalautua muuttuvissa liiketoiminnan tarpeissa, sekä tuoda liiketoiminnallinen data kaikkien saataville. Käytännössä suurin kilpailuetu tulee tiedon käsittelyyn liittyvän kyvykkyyden kasvattamisesta pitkässä juoksussa. Informaation ja toiminnallisuuksien tulee olla käytössä useampaan eri käyttötarkoitukseen ilman erillisiä toimenpiteitä.
 – Jos asiat toteutetaan eri liiketoiminta-alueiden ohjaamassa sisäisessä kehityksessä API-johtoisesti, on vastaava kyvykkyys helposti muidenkin liiketoiminta-alueiden saatavilla, ja on helppo siirtyä siihen, että kyvykkyyttä tarjotaan myös kumppaneille ja asiakkaille. Samoja rakenteita voidaan siis hyödyntää tuottamaan arvoa niin yrityksen sisällä kuin sen ulkopuolella, kertoo Lankila.

API-kyvykkyyttä voi lähteä rakentamaan ketterästi, kyseessä ei ole Iisakin kirkko.
– API-kyvykkyyden rakentaminen voi lähteä liikkeelle yksittäisestä tarpeesta, vaikka tuotteiden saatavuustietojen toimittamisesta. Jos sisäisesti tuotteiden saatavuustiedon käsittely on luotu API-johtoisesti, tämä kyvykkyys on helppo saattaa myös kumppaneiden ja asiakkaiden käyttöön rajapinnan kautta. Tai jos sisäisesti rikastetaan tuotetietoa, voidaan avata reittejä, joita pitkin yritykset voivat toimittaa tuotetiedot kätevästi rajapinnan kautta. Tätä samaa rajapintaa voidaan käyttää myös muilla liittymäpinnoilla, vaikka jopa kolmansien osapuolten verkkokaupoissa. Myös jälleenmyynnissä voidaan hyödyntää tietoja rajapinnan kautta siltä osin kuin halutaan, esimerkiksi tuoda jälleenmyyjää koskevat hinnat suoraan saataville heidän omiin järjestelmiinsä. Kun näin jatketaan, alkavat vanhat tavat siirtää tietoa eri tahojen välillä olemaan hiljalleen tarpeettomia, kertoo Lankila.

Kun API-johtoista arkkitehtuuria halutaan edistää, on myös hyvä muistaa, että ratkaisuja pitää ylläpitää ja kehittää.
– Koska rajapintojen kautta kulkee tietoa usealle sisäiselle ja mahdollisesti ulkoiselle toimijalle, ollaan myös vastuussa niiden toimivuudesta. Niistä tulee pitää hyvää huolta ja ylläpitää kehitystä. Liittymäpintojen kuvaukset tulee pitää ajan tasalla, ja suunnitellut muutokset tulee toteuttaa siten, ettei pakoteta kaikkia osapuolia reagoimaan niihin välittömästi. Liittymäpintojen vastuullinen kehittäminen ja DevOps-toimintakulttuuri ovat ikään kuin velvollisuuksia, mitkä johtavat alati paranevaan asiakaskokemukseen, tuumaavat Rintaluoma ja Lankila.

Tehdäänkö teillä liiketoimintaa järjestelmien ehdoilla?

Olipa palveluarkkitehtuurimalli mikä tahansa, tärkeintä on, että ratkaisuja suunnitellaan liiketoimintalähtöisesti, ei tekniikan tai järjestelmän ehdoilla.
– Liiketoiminnalla on usein valtavasti ideoita, mutta useinkaan niitä ei voida toteuttaa, koska tarjolla olevat järjestelmät eivät niitä luontaisesti mahdollista. IT toimii tässä kohtaa usein tahtomattaan kehityksen jarruna, koska vastuu ideoiden toteuttamisesta siirtyy heille, ja tarvittavat ratkaisut toisivat heidän toimintaansa lisää kompleksisuutta, toteaa Lankila.

Lankila haluaisi nähdä, että yrityksissä tuettaisiin toimintamallia, missä IT ottaa vastuun määritetyistä järjestelmistä ja infrasta, ja tukisi samalla liiketoimintaa ymmärtämään arkkitehtuurin nykytilaa ja olemassa olevia kyvykkyyksiä. Lisäksi yhteistyössä arvioitaisiin uusien ratkaisujen sovellettavuutta kokonaisarkkitehtuuriin.
– Samalla palveluarkkitehtuurin ylläpitämiseen pitää panostaa. DevOps-toimintakulttuuri on siinä todella tärkeässä asemassa. Kehityksessä tulee alusta alkaen olla kaikki toimet ja asennukset mahdollisimman automatisoituja, ja vikatilanteet hyvin mietittynä, kertoo Rintaluoma.

– Kun organisaatiota rakennetaan kilpailukykyisemmäksi rakentamalla liiketoimintalähtöiseen API-kulttuurin pohjautuvaa arkkitehtuuria, tulee uusien ratkaisuiden kehityksen vastuu olla entistä enemmän liiketoiminnalla. Luomalla IT:lle selkeämmät vastuut, sekä samalla liiketoiminnalle kyvykkyys miettiä suunniteltujen ratkaisujen vaikutuksia kokonaisuuteen, saavutetaan suurin mahdollinen hyöty, tiivistää Lankila.

Miten yritykset pääsevät alkuun, kun haluavat ottaa käyttöön API-johtoista palveluarkkitehtuuria?

Kun haluat varmistaa organisaatiosi kilpailukykyä ja rakentaa proaktiivista liiketoimintaa toimintaympäristöjen muutoksiin, näillä pääset alkuun:

  1. Kartoita ja tunnista millaista digitaalista palvelua ollaan tuottamassa. Lähde ymmärtämään liiketoiminnan tarvetta. Ota selvää mihin tiedot ovat kytköksissä, millaisia kyvykkyyksiä organisaatiollasi on esim. tarvittavien integraatioiden osalta, miltä osin API-johtoinen ratkaisu voidaan toteuttaa nykyisessä vallitsevassa järjestelmäekosysteemissä.
  2. Aloita yksinkertaisesti. Otetaan esimerkiksi tilanne, missä yrityksen kenttätyöntekijöille tarvitaan mobiilisovellus työtehtävien vastaanottamiseen. Lähtökohtaisesti mobiilisovellus kommunikoi taustalla olevan liiketoiminnan järjestelmän tarjoaman liittymäpinnan kanssa. Toteuttamalla tähän erillinen liittymäpinta (systeemi-API) liiketoiminnan järjestelmän yläpuolelle, saavutetaan askel kohti järjestelmäriippumatonta arkkitehtuuria.
  3. Ota DEVOPS-toimintakulttuuri käyttöön heti alusta alkaen. Automatisoi kaikki toiminnot, mitkä voit.
  4. Vie asioita pikkuhiljaa pidemmälle ja kasvavassa määrin riippumattomiksi taustalla olevista yksittäisistä järjestelmistä. Kun esimerkiksi aikaisemmassa vaiheessa kuvattuun mobiilisovellukseen lähdetään lisäämään toiminnallisuuksia, toteuta mahdollisten systeemi-API-kerroksen muutosten lisäksi niiden yläpuolelle seuraavan tason prosessi-API, joka ottaa vastuun liiketoiminnallisista toiminnallisuudesta ja tietojen käsittelystä.
  5. Seuraavassa vaiheessa voidaan toteuttaa kokemustason toiminnallisuuksia liiketoimintalähtöisen prosessi-API-kerroksen päälle. Tarkoituksena on yhdistää prosessi-tason toiminnallisuuksia, ja luoda erityinen käyttökokemus tämän ympärille. Tällä tavalla voidaan mahdollistaa esim. mobiilisovelluksen push-notifikaatiot kuin myös ”julkinen” liittymäpinta esim. kenttätyön toimintojen osalta ulkopuolisille toimijoille. Molemmat toteutukset voivat hyödyntää samoja kyvykkyyksiä.
  6. Pidä iso kuva koko ajan mielessä, mihin arkkitehtuurin halutaan kehittyvän. Kehittämisen tulee olla liiketoimintalähtöistä, ei järjestelmälähtöistä. Iteroimalla ja jalostamalla pieniä hallittavia kokonaisuuksia saavutetaan kyvykkyys mukautua liiketoiminnan tarpeisiin.

Vincit ja Bonsky ovat lyöneet yhteistyössä innovatiiviset päänsä yhteen, jotta voisivat auttaa teollisuusyrityksiä kohtaamaan tulevaisuuden valppaammin ja varmemmin. Vincit on keskittynyt liiketoiminnan murrokseen ja digitalisaatioon, mm.hallitsemaan muutoksia strategian, uusien liiketoimintamallien ja ajatusjohtajuuden avulla. Bonsky Digital on keskittynyt digitaalisen liiketoiminnan ja arkkitehtuurin kehittämiseen asiakkaita osallistavilla ketterillä muotoilun menetelmillä.

Asiantuntijat:

Kimmo Lankila, Solution Architect, Bonsky Digital Oy
Tekniikan alati kehittyvässä maailmassa kulman takana löytyy aina jotain uutta millä voi jalostaa totuttuja ratkaisumalleja.

Jukka Rintaluoma, ohjelmistokehittäjä, Vincit Oyj
Vähemmän koodia, vähemmän virheitä

Haluatko kysyä jotain?

Tatu Könönen, Bonsky Digital Oy, puh. +358 40 520 8477, tatu.kononen@bonsky.com

Olli Laine, Vincit Oyj, puh. + 358 40 455 2610, olli.laine@vincit.fi

Kirjoittaja: Minna Haapsaari, Bonsky Digital Oy