Sisällys

2

Sisällys 2Johdatus aiheeseen 3API eli ohjelmointirajapinta 5API-työkalut 7API Management 9API:n hyödyt IT:lle ja liiketoiminnalle 11

Helppo ylläpito ja jatkokehitys 11Toimittajariippumattomuus 12API-strategia osana IT-arkkitehtuuria 12Tuotteena tarjoaminen 13

Integraatiot ja API 14Haluatko lisätietoja? 16Alfame lyhyesti 17

Johdatusaiheeseen

Laatutietoisuus työssä käytettävien tietojärjestelmien

ominaisuuksista ja hyödykkeistä on kasvanut runsaasti

viimeisten vuosien aikana. Enää ei tyydytä hyvään, vaan

vaaditaan parasta. Joskus hankintoja tehdään jopa IT-strategian

vastaisesti, sillä erilaisia sovelluksia ja järjestelmiä on niin helppo

ostaa pilvestä.

Tietoturva ja järjestelmien yhteentoimivuus jäävätkin usein

jälkijättöisesti IT-hallinnon päänvaivaksi – esimerkiksi miten

asiakastiedot saadaan siirtymään ajantasaisesti CRM-

järjestelmästä muihin järjestelmiin tai tuntikirjaukset

laskutuksen järjestelmiin.

Palvelulaadun ja ketteryyden takaamiseksi IT-hallinnot

joutuvatkin panostamaan integraatiotyökaluihin entistä

enemmän. Vakiintunut ratkaisumalli on ESB (Enterprise Service

Bus), jonka avulla saadaan rakennettua keskitetty palveluväylä ja

löyhemmät riippuvuudet (Loose Coupling) tietojärjestelmien

välille. Tiukat riippuvuudet (Tight Coupling) ovat yleensä suurin

hidaste kehitykselle, sillä muutokset heijastuvat useisiin eri

järjestelmiin.

3

Tietojärjestelmien integrointi toisiinsa ei silti itsessään täytä

kaikkia nykyisiä ketteryysvaatimuksia. Tietojärjestelmien sijaan

halutaankin tyypillisesti tarjota palveluja, jotka on mahdollista

integroida sellaisenaan niitä tarvitseviin sovelluksiin tai toisiin

palveluihin.

Perinteisillä ESB-työkaluilla tai monoliittisillä applikaatioilla

tällaiset räätälöinnit vaativat laajoja käyttöönottoprojekteja

useidenkin toimittajien välillä. “Tätä on siis syytä vältellä” tulee

helposti ensimmäisenä mieleen – vaikka todellisten vaatimusten

täyttämiseksi vaaditaankin räätälöintiä. Palvelutuotantoon

tarvitaan siis uudenlainen lähestymistapa: API (Application

Programming Interface) ja tuottamiseen sopivat API:n

hallintatyökalut (API Management).

Tämän materiaalin tarkoituksena on jakaa tietoutta rajapinnoista

ja niiden mahdollisuuksista ketterään IT-strategiaan eli API-

strategiaan. Jos mieleesi herää kysymyksiä tai haluat tietää

aiheesta lisää, otathan yhteyttä!

Mukavia lukuhetkiä oppaan parissa toivottaa,

Alfamen väki

4

5

API eli Application Programming Interface onohjelmointirajapinta, joka kuvaa vuorovaikutuksen tarjottujenpalveluiden kanssa. Se rajaa riippuvuudet varsinaisentoteutuksen ja asiakkaan välillä minimiin eli on eräänlainenmenettely löyhään sidontaan. API:a käyttämällä saadaan siisliiketoimintaan teknologia- ja toimittajariippumattomuutta, mikätaas lisää jatkokehitysmahdollisuuksia ja taloudellisia etuja.

Ilman rajapintamäärityksiä sovelluksista tulee monoliittisia, jossakaikki tarjotut toiminnot on sidottu kiinteästi yhteen. Silloinyksikin muutos voi heijastua koko toteutukseen ja aiheuttaaennalta tuntemattomia ongelmia. Sen vuoksi sovelluksillemääritetään komponenttiarkkitehtuureja ja lisätään rajapintojakomponenttien vuorovaikutuskohtiin, jotta osia olisi mahdollistakehittää tai korvata riskittömämmin.

Web-teknologioiden kehittymisen myötä API:t ovat siirtyneetvahvemmin sovellusten julkaisemiksi palveluiksi sisäisentoteutuksen selkiyttämisen lisäksi. Web Service API:n asiakkuus eienää sido toteutusteknologiaan tai ajoympäristöön, jotentoimittajayhteistyö ja komponenttikohtainen uudelleenjakelu onmahdollista.

Kehitystyö painottuu nykyään API:n määrittämiseen,toteuttamiseen ja hyödyntämiseen. Kehitystä tehdään siis niinsanotusti API edellä (API first). Kehityksen tehokkuutta ohjaakehityksessä hyödynnettävien API-työkalujen laatu. API-työkaluista voit lukea lisää myöhemmin tässä oppaassa.

Rajapintatuotannon kehittyessä API:n julkaisukanava nouseetärkeään rooliin. API:t tulee versioida, jotta asiakkailla onmahdollisuus varautua muutoksiin ja migroitua itsevalitsemanaan hetkenä uuteen versioon. Tällöin ikäviä ja etenkinmonitoimijaympäristössä työllistäviä palvelukatkoja ei myöskäänenää synny.

API:n pääsynhallinta tulee voida konfiguroida hyvinkindynaamisesti, sillä niiden toteutuksissa ei ole voitu, eikä yleensäkannatakaan, ottaa kantaa jatkuvasti muuttuviinpääsynhallintavaatimuksiin: uusia asiakkaita tulee voida palvellailman käyttöönottohankkeita.

Lisäksi palveluiden performointia tulee pystyä seuraamaan jamukauttamaan, jotta ne vastaavat kulloistakin palvelukutsujenmäärää. Julkaisukanava voidaan rakentaa API:n hallintatyökaluilla(API management).

Myös API-palveluiden tuotteistaminen ja myyminen (SaaS) onmahdollista. API:n julkaisukanaviin tehtävä panostus avaasamalla mahdollisuuden tarjota palveluita ulkoisille asiakkaille jarahastaa niistä. Mikäli olet kiinnostunut API-ratkaisujentuotteistamisesta, otathan yhteyttä!

6

API:n määritykseen käytettävät teknologiat ovat kaikkien API-työkalujen lähtökohta. Esimerkkeinä teknologioista:

• WSDL• RAML• Swagger

Nämä teknologiat mahdollistavat API:n vuorovaikutuksenkuvaamisen sekä dokumentoinnin sitomatta asiakas- taipalvelutoteutusta mihinkään tiettyyn toteutusteknologiaan. Niitätulkitsemalla on siis mahdollista oppia, miten API:a tulisi käyttääja kuinka toteutus on rakennettava.

Koska kuvaukseen käytettävät teknologiat ovat vakiintuneita,niiden pohjalta on mahdollista myös automaattisesti rakentaatoteutuksia: toteutusteknologiakohtainen ratkaisun runko syntyygeneroimalla kuvaimesta koodi, olipa kyseessä asiakas- taipalvelutoteutus.

Esimerkkeinä:• Wsdl2Java• Mulesoft ApiKit• Postman

7

API:n tarjoaman löyhän sidonnan johdosta se tarjoaa myösluonnollisen paikan testiautomaatiolle ja väliaikaistoteutuksille.Testaamisen yleisin ongelma on, miten testattava kohdeirrotetaan ajoympäristöön niin, että säilytetään riittävä tarkkuustestaamiseen. Koska API-kuvaimista pystytään generoimaankoodirunkoja, siitä voidaan myös helposti generoida väliaikainenpalvelutoteutus, jota käytetään testin aikana (Mock tai Stub). Itsetestaaminen voidaan tehdä asiakastoteutuksen roolissa eli juurisiten kuin tuotannossakin.

Esimerkkejä testaustyökaluista:• QUnit• Robot Framework• SOAP UI

8

API Management on laaja kokonaisuus, jonka pääpainona ontehdä rajapintojen suunnittelusta, käyttöönotosta ja hallinnastahelpompaa. API Management pitää sisällään tietoja, kutenmillaisia rajapintoja on käytössä, ketkä niitä käyttävät sekä mitäja missä niitä tarjotaan. API:n toteuttavien taustajärjestelmien eitarvitse ottaa kantaa lopullisesta asiakasympäristöstä, vaanniissä voidaan keskittyä tehokkaaseen rajapinta- japalvelutuotantoon.

API Managementilla helpotetaan API:n käyttöönottoa tarjoamallajulkaisualusta API-kuvaimille. API:t ja niiden tarjolla olevat versiotlöytää selaamalla katalogia, josta ne on mahdollista ottaakäyttöön kuvainten tai koodiesimerkkien avulla. Julkaisualustamyös dokumentoi vallitsevaa nykytilaa ja helpottaa sitenhallintaa.

Esimerkkejä toteutuksista:• Azure API Management• Mulesoft API Manager• Kong• WSO2

9

API Managementille ei ole olemassa standardeja, mikä toisaaltamuodostaa haasteen sopivan työkalun valintaan.Ideaalitilanteessa API Management sisältäisi seuraaviaominaisuuksia:

Dokumentaatio ja API-kuvaimetAPI:t julkaistaan kuvaimen ja palvelun identifioivan polun eliURL:n avulla. Tyypillisesti API:t versioidaan, jolloin API:sta onmahdollista tarjota useampaa yhdenaikaista versiota, kunnesvanhat versiot pystytään lopulta poistamaan käytöstä. API-kuvaimesta generoidaan yleensä Web-sivu, jossa esitetäändokumentaatio sekä käytön kokeilua sallivat toiminnot.Käyttöönoton helpottamiseksi tarjolla voi olla myös valmiitaasiakastoteutuksia tai työkalut niiden rakentamiseen.

MarkkinapaikatJulkaistujen API:en etsintä, hankinta ja rahastus tehdään yleensäverkkoportaalin kautta. Maksullisiin palveluihin myönnetääntyypillisesti API-avain (API-key), joka sallii käyttöoikeudenhankittuihin palveluihin.

Analytiikka ja tilastotPalveluiden käytöstä on tärkeä kerätä dataa, jotta palveluavoidaan tarvittaessa skaalata tarpeen mukaan. Kerätty datatoimii myös palautteena palvelulaadusta, joka on pohjana uusilletarvekartoituksille ja kehityshankkeille.

SuorituskykyMikäli palvelun resurssit eivät ole kerätyn datan perusteellariittäviä, on niitä mahdollista skaalata eli toteuttaa ”rate limitting”tai ”load balansointi” uusille rinnakkaisjärjestelmille. Myös tiedonpuskurointi on mahdollista, mikäli samaa tietoa noudatetaantoistuvasti lyhyen ajan sisään.

Turvallisuus ja hallintaKaikki käyttäjät on syytä tunnistaa käyttöoikeuksienvahvistamiseksi, mutta myös mahdollisten väärinkäyttöjenestämiseksi. Lisäksi rahastus on mahdollista kohdentaa tarkastiyksittäisten käyttöoikeuksien perusteella.

10

API tarjoaa mitattavia hyötyjä niin IT:lle kuin kokoorganisaatiollekin. IT:n näkökulmasta API:n hyödyt kanavoituvatsen tuottavuuteen, kun taas liiketoiminnalliset hyödyt syntyvätlisääntyvän kilpailukyvyn ja myynnin kautta. Seuraavaksikerromme tarkemmin hyödyistä, jotka API mielestämme tuottaa:

Helppo ylläpito ja jatkokehitys

Julkaistut API:t mahdollistavat jatkokehityksen myös omanorganisaation ulkopuolella. Omien palveluiden arvoa onmahdollista kehittää rakentamalla ekosysteemejä kumppaneidenja asiakkaiden avulla. Esimerkiksi KONE on viime vuosinarakentanut itselleen täysin uuden kehittäjäverkoston, jokapohjautuu API-ratkaisuihin.

Palveluiden tuotteistaminen tukee myös sisäistä kehitystä: APImanagement -alustan julkaisu- ja hallintaominaisuudetpalvelevat myös sisäisiä kohderyhmiä. Mitä useamman API:njulkaisuun saadaan jalkautettua sama alusta, sitä tehokkaampaaniiden kehitys, julkaisu ja käyttöönotto on.

11

Toimittajariippumattomuus

Toimittajariippumattomuus takaa, että rajapinta ja sitähyödyntävät palvelut eivät kärsi, vaikka palvelujauudistettaisiinkin. Esimerkiksi CRM-järjestelmän vaihtaminen eivaikuta API:n ansioista muihin yrityksen järjestelmiin taipalveluihin, vaan ne säilyvät ennallaan.

Mikäli käytössä olevaan rajapintaan ei ole enää saatavillatoteutusta, se voidaan esim. tarjota ESB-alustalla toteuttamallavanha rajapinta uudelleen ja mappaamalla kutsut nykyiseenpalveluun. Tällöin uuden palvelun käyttöönotto on ketterää,koska uusiin rajapintoihin voidaan migroitua vaiheittain.

API-strategia osana IT-arkkitehtuuria

IT-ratkaisut ovat tyypillisesti olleet laajoja teknologia- jatoimittajasidonnaisia palvelukokonaisuuksia, mutta API-strategiaan keskittymällä tiukoista sidoksista pääseeirrottautumaan. API management –työkalujen ja ketterienvirtualisointi-/konttiteknologioiden ansiosta palveluista onmahdollista rakentaa itsenäisiä (Microservices).

Perinteinen ja harmaita hiuksia aiheuttava tilanneorganisaatioissa onkin, että IT on jumissa vanhojen sovellusten jataustajärjestelmien kanssa, joihin ei uskalleta tehdä muutoksia.Toimittajat eivät osaa ylläpitää tai kehittää vanhoja järjestelmiä.Koko liiketoiminnan pelätään jopa kaatuvan käsiin, jos niihintehdään muutoksia. API Managementin ansiosta ei tarvitsepelätä järjestelmien hajoamista, vaan rajapinnat mahdollistavatesimerkiksi vaiheittaisen käyttöönoton, ketterän testaamisen jaselkeän palveluiden dokumentoinnin.

12

API-strategiassa monoliittiset sovellukset pyritään korvaamaantäysin selainsovelluksilla. Tällöin tuotettuja API-palveluja onmahdollista integroida suoraan loppukäyttäjien selaimissa. Silloinvoidaan pala kerrallaan tuottaa uusia palveluja julkaisemallauusia API-versioita hyödyntämällä rakennettua API-julkaisukanavaa.

Kuvassa vasemmalla vanhan maailman ratkaisut ja oikealla API-kerroksella varustettu toivetila:

13

Tuotteena tarjoaminen

API:n tuotteistaminen voi jopa olla lähtökohtana API:ntoteuttamiselle. Näin ei kuitenkaan aina ole, vaan yritys saattaaensin tuottaa palvelua itselleen, kunnes saadaan idea, miksi eitarjottaisi palvelua myös muille.

API management -alustalla tuotteen julkaisu on helppoa: samaamenettelyä on harjoitettu jo sisäisesti, nyt vain lisätääntuotteesta rahastus ja markkinointi. Yritykselle aukeaakin uusikanava liiketoiminnan laajentamiseen. Tuotettuja palveluja voimyös markkinoida ulkoisissa API-portaaleissa, kutenAPI:Suomessa.

Integraatiot ovat pitkään olleet kiinteä osa IT-arkkitehtuuria. Neovat yleensä erittäin liiketoimintakriittisiä ja vaativat jatkuvaaseurantaa. Siksi integraatioratkaisut pyritään keskittämään esim.ESB-alustalle, joka on tarkasti seurattavissa ja auditoitavissa.

Toiminnallisesta näkökulmasta integraatioita on karkeasti kolmeaeri tyyppiä:

• API-palveluiden yhteen liittäminen ja tarjoaminen• Olemassa olevien applikaatioiden ja datan yhteen liittäminen• Monimutkainen prosessiautomaatio ja ohjelmistorobotiikka

Julkaistu palvelu on ideaalitilanteessa sellainen, joka onmahdollista ottaa käyttöön ja integroida saumattomasti. WebService/SOAP-teknologioilla toteutetut palvelut vaativatkohtuullisen monimutkaisen asiakasohjelmiston ja siksi ne ovattyypillisesti piilotettuja loppukäyttäjiltä osaksi applikaatioita taiintegraatioita. Siten jokainen uusi loppukäyttäjälle kehitettypalvelu heijastuu helposti myös IT:lle. Siitä seuraa uusienintegraatioiden kehitys- ja käyttöönottohankkeita, jotta tuotetutpalvelut saadaan vastaamaan nykyisiä tarpeita.

14

Palveluiden integraatioista tulisikin saada mahdollisimmanlähellä loppukäyttäjää toteutettavia. REST-teknologioillatoteutetut API:t on helppo käyttöönottaa kevyemmissäkinlaitteissa, sillä asiakasohjelmistoksi riittää HTTP-asiakasohjelmisto. Sen vuoksi REST API on mahdollista ottaakäyttöön suoraan käyttäjän selaimessa, eivätkä kaikkiuudistukset enää heijastu integraatiomuutoksina IT:lle.

Mitä useampi palvelu saadaan julkaistua REST API:na, sitäenemmän niitä on mahdollista integroida API-kerroksenulkopuolella. Yhä useampi palvelu kehitetäänkin suoraan RESTAPI –palveluksi, joita voidaan jakaa versioituina ketterin DevOps-menetelmin API management –alustan avulla. ESB:n tehtävätAPI-palveluiden yhteen liittämisessä ovat sen vuoksivähenemässä ja API-palveluiden seuranta siirtymässä APImanagement –alustan tehtäväksi.

ESB-alustan rooli on jatkossa yhä vahvemmin monimutkaisenprosessiautomaation ja ohjelmistorobotisaation työkaluna.Toimenpiteet, joita tehdään ilman ihmistä, vaativat edelleenjatkuvaa seurantaa ja auditointia. Kehitys painottuuliiketoimintaprosessien (BPMN, BPEL jne.) ja –sääntöjenmäärittämiseen (DMN, Drools jne.) sekä API-palveluidentuottamiseen, jotta ihmiset voivat osallistua osana tekoälyä.

15

API:t ovat taloudellinen investointi, joiden käyttöönottoa on hyvä miettiä huolella. Ne eivät ole pelkästään teknisiä päätöksiä, vaan

APIen avulla ohjataan koko liiketoimintaa. Mikäli haluat tietää lisää tai sinulla heräsi kysymyksiä aiheesta, otathan rohkeasti

yhteyttä.

Tutustu myös blogiimme ja maksuttomaan tietopankkiimme!

Janne Tirkkonen Toimitusjohtaja044 906 2216

janne.tirkkonen@alfame.com

Jaana AngléRatkaisumyyjä050 465 8668

jaana.angle@alfame.com

Jari SaariRatkaisumyyjä050 470 0958

jari.saari@alfame.com

16

Haluatkolisätietoja?

1

7

Alfame lyhyesti

Olemme vuonna 2004 perustettu riippumatontietojärjestelmätoimittaja ja ohjelmistokehittäjä. Autamme

asiakkaitamme digitalisoimaan ydinprosesseja, tehostamaan kommunikaatiota ja kasvattamaan kilpailukykyä.

Palvelemme kasvavaa yritys- ja julkishallinnonasiakaskuntaamme valtakunnallisesti – tunnustetulla hyvällä

asenteellamme ja korkealla osaamisellamme. Olemme teknologiariippumaton yritys. Toteutamme ratkaisuja sekä

Microsoftin että avoimen lähdekoodin teknologioilla.

Haluamme erottua markkinoilla toimintamallillamme, joka perustuu luotettavuuteen, läpinäkyvyyteen ja 100 prosenttiseen

tyytyväisyystakuuseen.

http://www.alfame.com