Hyppää sisältöön
fi
En / Globalfisedk
Ota yhteyttä

API-vetoinen arkkitehtuuri pähkinänkuoressa ja miksi sen pitäisi kiinnostaa juuri sinua

API-vetoinen arkkitehtuuri mahdollistaa liiketoimintalähtöisen ja ketterän kehittämisen

Tämän blogisarjan ensimmäisessä osassa kirjoitin integraatioista yleisesti. En kuitenkaan vielä silloin maininnut, että tapoja toteuttaa integraatioita on monenlaisia. Tässä kirjoituksessa puhutaan rajapinnoista (API eli Application Programming Interface – käytän tätä lyhennettä selvyyden ja yksinkertaistamisen vuoksi tästä eteenpäin), joka on keskeinen tapa integroida järjestelmiä välttäen päällekkäisiä, monimutkaisia ja vaikeasti hallittavia ratkaisuita – ja näin ollen myös keino tuottaa lisäarvoa liiketoiminnalle nopeasti.

Mikä on API? Lyhyesti sanottuna se on tapa, jota seuraten ohjelmisto voi jutella toiselle ohjelmistolle. Jotta ohjelmistot voivat kommunikoida keskenään, tulee tavan olla vakioitu tai standardoitu, aivan kuten vaikkapa puhutun kielenkin. Samalla tavalla myös API:t ovat vakioituja eli ne kertovat millä “kielellä” ohjelmistolle tulee kommunikoida.

API:t käytännössä: esimerkkinä asiakashallintajärjestelmä eli CRM

Nykyajan ohjelmistot joutuvat keskustelemaan usean muun ohjelmiston kanssa toimiakseen organisaation liiketoimintaympäristössä.

Ajatellaanpa vaikka asiakashallintajärjestelmää (CRM): se sisältää nimensä mukaisesti tietoa asiakkaista, mutta usein myös käynnissä olevista myyntiaktiviteeteista, suunnitelluista markkinointikampanjoista, yhteydenotoista ja niin edelleen. CRM muodostaa siis API:n (tai itse asiassa: useampia API:ja) omiin tietoihinsa.

Jotta CRM voi toimia tehokkaasti, sen pitää pystyä keskustelemaan toiminnanohjausjärjestelmän (ERP, esimerkiksi asiakastilausten välittäminen), projektinhallintajärjestelmän (PPM, esimerkiksi projektien perustaminen), verkkokaupan (eCommerce, esimerkiksi kohdennettujen tuotenostojen luominen) ja usean muun järjestelmän kanssa. CRM:n pitää siis myös itse käyttää API:ja.

Mikropalveluilla uudelleenkäytettävyyttä ja yksinkertaisuutta

Tämän blogisarjan toisessa osassa puhuin uudelleenkäytettävyydestä ja yksinkertaisuudesta. Ne ovat API-suunnittelun keskeisiä periaatteita, jotka mahdollistavat tehokkuuden, yksinkertaisuuden, ylläpidettävyyden, teknisen velan välttämisen, ketteryyden ja monia muita hyveitä.

Olet ehkä kuullut termin mikropalvelu. Termi on modernin ja uudelleenkäytettävän API-kehittämisen ytimessä. Mikropalveluiden ajatuksena on muodostaa nimensä mukaisesti pieniä, jopa mikroskooppisia palveluita eri tietojärjestelmien käyttöön. Mikropalvelu keskittyy yhteen asiaan, eikä edes pyri täyttämään kaikkia mahdollisia tarpeita. CRM-esimerkkiä jatkaakseni: asiakashallintajärjestelmässä yhden mikropalvelun kautta voidaan hakea esimerkiksi tietyn asiakkaan osoitetiedot. Asiakkaan viimeinen ostos pitää puolestaan hakea toisen, erillisen mikropalvelun kautta – ja niin edelleen.

Mikropalvelumenettelyllä on mahdollista rakentaa pieniä ja helposti ylläpidettäviä API-kokonaisuuksia. Jos API:a pitää joskus muuttaa, sen voi tehdä vain tiettyyn osaseen ilman isoa remonttia. Vastaavasti muutos API:iin vaikuttaa vain kyseistä API:a käyttäviin sovelluksiin eikä koko ympäristöön.

Rakentamalla API:t systemaattisesti ja käyttämällä API:en rakentamisessa mikropalvelumallia, muodostuu organisaatioon API-verkko. API-verkkoa voisi ajatella kuin tietoliikenneverkkoa, jossa jokaiseen osaseen pystytään olemaan yhteydessä tarpeen mukaan. Ihannetilanteessa uuden API:n kytkeminen ja sen käyttäminen on yhtä helppoa kuin vaikka tulostimen ottaminen käyttöön organisaatiossa – ilman monimutkaisia ja kuormittavia integraatioprojekteja.

API-vetoinen arkkitehtuuri ottaa huomioon eri käyttötarkoitukset

API-verkkojen rakentaminen vaatii kuitenkin hiukan enemmän kuin pelkästään edellä kuvatun mikropalvelumallin. API:t ovat nimittäin erilaisia ja erilaiseen käyttöön tarkoitettuja. Osa API:eista on tarkoitettu käytettäväksi liiketoimintasovelluksissa, osa liiketoimintaprosessien orkestrointiin ja osa järjestelmien kanssa keskustelemiseen. Tämän vuoksi on olemassa niin kutsuttu API-vetoinen arkkitehtuuri.

API-vetoinen arkkitehtuuri perustuu kolmeen API-tasoon: järjestelmä-, prosessi- ja kokemustasot. Jokainen API, joka API-verkkoon lisätään, sijoitetaan johonkin näistä tasoista. API:t voikin luokitella järjestelmä-, prosessi- tai experience-API:eksi (system-API, process-API ja experience-API).

  1. Järjestelmä-API:t muodostavat kerroksen liiketoimintajärjestelmiin. Ne pyrkivät yksinkertaistamaan liiketoimintajärjestelmiin yhdistämistä ja vakioimaan datamallin organisaation tai liiketoimintayksikön malliin sopivaksi. Näitä API:ja hyödyntämällä pystytään kytkeytymään haluttuihin järjestelmiin ilman, että järjestelmien omia tietomalleja ja prosesseja tarvitsee ymmärtää syvällisesti. Järjestelmä-API voi olla esimerkiksi asiakastietojen haku CRM-järjestelmästä.
  2. Prosessi-API:t muodostavat nimensä mukaisesti liiketoimintaprosesseja. Tyypillisesti liiketoimintaprosessit liittyvät useampaan järjestelmään tai toisiin prosesseihin, joten prosessi-API:t ovat yhteydessä sekä järjestelmä-API:eihin että toisiin prosessi-API:eihin. Esimerkki prosessi-API:sta voi olla vaikkapa asiakastilauksia varten tehty API, joka hyödyntää toiminnassaan CRM-järjestelmän asiakastietoja ja ERP-järjestelmän tilaustietoja.
  3. Kokemus-API:t kytkevät liiketoimintaprosesseja yhteen sovelluksille, jotka tietoja tarvitsevat. Jotta sovellus voi toimia, sen pitää voida hyödyntää tietoja useista liiketoimintaprosesseista ja syöttää niitä eteenpäin. Eri sovellukset käyttävät tietoja eri tavalla, joten tyypillisesti myös API tulee rakentaa siten, että sen avulla liiketoimintaprosessi sovelluksessa toimii. Esimerkkejä kokemus-API:eista ovat sähköisen kaupan, mobiilisovellusten ja IoT-sovellusten hyödyntävät API:t.

Alla olevassa kuvassa on yksinkertaistettu esimerkki miten näitä eri tason API:ja voidaan organisaatiossa hyödyntää.

Miksi API-vetoinen arkkitehtuuri?

API-vetoinen arkkitehtuuri tuo monia hyötyjä API-kehittämiseen. Kun API:t palastelee mikropalveluiden lisäksi eri API-tasoille, niitä voi järjestellä kuin legopalikoita. Se auttaa ottamaan uudelleenkäyttämisestä kaiken irti ja mahdollistaa API-kehittämisen laajentamisen koko organisaatioon. Palastellun lähestymistavan ansiosta mikään organisaatioyksikkö ei muodostu pullonkaulaksi ja kehittäminen tapahtuu liiketoimintalähtöisesti.

Miten API-vetoisen arkkitehtuurin kehittäminen kannattaa sitten organisoida? Palataan siihen tämän blogisarjan seuraavassa osassa.

Haluatko sukeltaa syvemmälle järjestelmäintegraatioiden maailmaan?
Lue blogisarjan ensimmäinen osa täältä ja toinen osa täältä.

Kirjoittaja

Tämä kirjoitus on kolmas osa järjestelmäintegraatioihin keskittyvää Sofigaten blogisarjaa, joka jakaa tietoa ja asiantuntevia näkemyksiä integraatioista ja niiden modernista hyödyntämisestä osana liiketoiminnan ja organisaation kehittämistä.

Kirjoittaja Jussi Vuokko on auttanut erikokoisia organisaatioita johtamaan palveluita ja automatisoimaan liiketoimintaa moderneja teknologioita hyödyntäen jo yli kahden vuosikymmenen ajan. Jos haluat jutella Jussin kanssa aiheesta, tavoitat hänet sähköpostilla jussi.vuokko@sofigate.com, Twitterissä @jussivuokko tai LinkedInissä linkedin.com/in/jussivuokko.

Jussi Vuokko

Related Insights

Etsi