Integraatiot ja integraatioalustat - lyhyt oppimäärä

Mitä integraatio on?

Integraatio - tai tässä yhteydessä järjestelmäintegraatio - on yhden tai useamman järjestelmän yhdistämistä toisiinsa siirtämällä tietoa yhdestä toiseen tai moneen. Esimerkiksi asiakastietoa voidaan tarvita asiakastietojärjestelmän (CRM) lisäksi markkinointiautomaatiojärjestelmässä ja toiminnanohjausjärjestelmässä (ERP). Tätä asiakastiedon kulkua toiseen järjestelmään kutsutaan tietovirraksi tai joskus yksinkertaisesti vain integraatioksi.

Tämä artikkeli sisältää järjestelmäintegraation perusteet sekä tuoreimpia tuulia integraatioiden saralta.

Hallittu integraatio vai tietovirtojen spagetti?

Kypsyysaste 0: point-to-point -integraatiot, ei integraatioalustaa

Yhdestä yhteen integraatiot (point-to-point integrations) on tapa, jossa integraatiot tehdään kunkin aikakauden "parhaalla" teknologialla ja laitetaan palvelimen nurkkaan tai itse integroitavaan sovelluksen sisälle pyörimään. Seppo Sankarikoodaja IT-osastolta teki näitä ennen php:llä, jonka jälkeen Tauno Tuunaaja jatkoi omilla Python-skripteillään. Molemmat laittoivat ajastuksen rullaamaan Cronilla jonnekin eri palvelinten nurkkiin. Vastaavia ratkaisuja kertyy vuosien mittaan kymmeniä tai satoja. Ajattele yhtä tällaista yksittäisen tietovirran toteuttavaa skriptiä yhtenä spagettinauhana. Näin sankarikoodauksen seuraus on kasaa spagettia muistuttava verkosto, johon muutosten tekeminen aiheuttaa arvaamattomia seurauksia. Lisäksi yhden järjestelmän vaihtaminen onkin yllättävän vaikeaa, sillä vaihdettavan järjestelmän kytkökset hajoavat, eikä kaikkia kytköksiä edes tunneta - Seppo ja Tauno kun eivät tunnetusti olleet niitä ahkerimpia dokumentoijia. Kaikkein tärkeimpänä: keskitetty tietovirtojen valvonta on mahdotonta.

Tietoa on verrattu arvonsa puolesta milloin öljyyn ja milloin veteen. Se on yrityksen arvokkaimpia omaisuuksia sekä kriittinen osa liiketoiminnan sujumisen kannalta. Näiden tietovirtojen keskitetty valvonta ja hallinta ovat yksiä tärkeimmistä tehtävistä modernissa liiketoiminta-ohjatussa IT-organisaatiossa. Nykyaikaisessa IT-ympäristössä valtaosa vian korjaukseen menneestä ajasta käytetään itse asiassa vian etsimiseen. Esimerkiksi CRM-toimittaja sanoo asiakastiedon lähteneen CRM-järjestelmästä ja markkinointiautomaatiota palveluna toimittava yritys väittää, ettei data koskaan saapunutkaan. Keskitettyä monitorointia ja hajautettua suoritusta tukevassa integraatiossa ei ole epäselvää missä vika on ja mikä rajapinta vian aiheutti. Gartnerin mukaan keskitetty integraatio säästää peräti 50% IT-kuluista verrattuna spagettiin. Spagetin ongelma kasvaa järjestelmien määrän kasvaessa. Palveluna myytävien pilviratkaisuiden aikakaudella spagetin keittäminen on helpompaa kuin koskaan.

IT-osaston kovat osaajat, Seppo ja Tauno ovat myös osa ongelmaa - heidän lähdettyään eläkkeelle, kukaan ei tiedä mitä nuo sankarikoodatut skriptit tekevät, missä ne pyörivät ja oikeastaan miksi ne pyörivät.

Point-to-point -integraatiot eivät kuitenkaan ole pelkästään IT:n mörköpeikko - jossain tapauksissa ne ovat perusteltuja ratkaisuja. Tällaisia ovat mm. väliaikaiset integraatiot tai tietovirrat, jossa kahden saman toimittajan järjestelmän eri moduulit puhuvat keskenään, ja toimittaja on vastuussa kokonaisuuden toiminnasta. Muissa tapauksissa seuraavassa kappaleessa kuvattu keskitetty integraatioalusta on oikea valinta.

Miksi keskitetty integraatioalusta?

Kypsyysaste 1: keskitetty integraatioiden valvonta, yhdenmukaistettu toteutustapa.

Nykyaikainen integraatioalusta toimii kaikkien tietovirtojen liikuttajana ja samalla valvojana. Nimensä mukaisesti se on alusta - ei lopullinen ratkaisu. Integraatioalustoja ja niiden toiminallisuusjoukkoja on monenlaisia, ja niiden vertailu onkin vaikeaa. Yksi yhtenäinen ominaisuus integraatioalustoilla kuitenkin on - ne toimivat integraatioiden eli tietovirtojen keskitettynä valvonta- ja hallintapisteenä. Keskitetty integraatio vähentää myös tietovirtojen määrää merkittävästi, sillä integraatiot kulkevat integraatioalustan kautta yhdestä moneen -periaatteella. Tämä keskitetty piste on mitä mainioin kohta valvoa tietovirtoja.

Keskitetyn integraatioalustan tehtävä on siirtää tietoa kahden järjestelmän välillä ja hoitaa samalla tarvittava datamuunnos, jota monesti kutsutaan "datamäppäykseksi". Se tarkoittaa eri rakenteisten sanomien, kuten vaikkapa XML:n tai JSON:n muuttamista vaikkapa edifactiksi. Termillä protokollamuunnos tarkoitetaan sitä, kun esimerkiksi SFTP:llä sisääntullut tiedosto lähetetään eteenpäin REST-kutsuna. Sisältömuunnos taas tarkoittaa sitä, kun saman sanoman sisältö muunnetaan toiseen rakenteelliseen muotoon, esimerkiksi edifactista vastaanottavan järjestelmän määrittelemäksi JSON-rakenteeksi.

Keskitetyllä integraatioalustalla on tyyppillisesti myös kyvykkyys ajastaa siirtoja tai herätä esimerkiksi tiedoston saapumiseen, tietokantamuutokseen tai käynnistyä suoralla REST/JSON -kutsulla. Keskitetyssä integraatiossa tietyn järjestelmän rajapinnat osaavaa moduulia kutsutaan adapteriksi tai konnektoriksi. Samaa nimitystä käytetään usein myös, jos adapteri toteuttaa jonkin standardin, vaikkapa SFTP -tiedostonsiirtoprotokollan.

Keskitetty integraatioalusta tarjoaa myös yhdenmukaisen toteutustavan integraatioille - näin ei tarvitse ylläpitää osaamista monen eri aikakauden teknologioista eikä tämä toiminnan kannalta elintärkeä osaaminen pääse henkilöitymään.

Miten tehdään prosessiautomaatio integraatioalustalla?

Kypsyysaste 2: prosessiautomaatio keskitetyllä integraatioalustalla.

Osa nykyisistä iPaaS-sovelluksista - eli palveluna toimitettavista integraatioalustoista - osaa myös prosessien automatisoinnin. Se tarkoittaa, että prosessit automatisoidaan orkestroimalla niiden tekninen kulku integraatioalustalle ja järjestelmät kytketään toisiinsa osana kokonaista prosessia. Integraatioalusta kykenee automatisoimaan prosesseja monta kertaluokkaa tehokkaammin kuin vaikkapa pelkkä RPA-työkalu, joissa niissäkin on prosessien orkestrointiominaisuuksia. Integraatioalusta on nopeampi automaatiossa, koska se ei simuloi käyttäjän toimia, vaan toimii suoraan rajapitatasolla useinmiten käännettynä koodina. Toisaalta integraatioalustaa ei ole mahdollista käyttää, jos rajapintoja ei ole tai automaatio tapahtuu pelkästään yhden käyttöliittymän sisällä. Uudenaikaiset integraatioalustat sisältävät kyvykkyyden orkestroida prosesseja ja työnkulkuja standardeilla kielillä - esimerkiksi FRENDS -integraatioalusta tukee BPMN (Business Process Model Notation)-esitystapaa, joka löytyy mm. Microsoft Visiosta ja muista mallinnustyökaluista.

Kuvassa FRENDS:n BPMN:llä on kuvattu prosessi, joka yhdistää RPA-robotin ajon osaksi integraatioprosessin työnkulkua. RPA:ta ja prosessiautomaatiota, jota usein kutsutaan liiketoimintaprosessien automaatioksi (Business Process Automation, BPA).

Hyperautomaatio

Kun liiketoimintaprosessien automaatio (BPA) yhdistetään ohjelmistorobotiikkaan ja lisätään joukkoon ripaus tekoälyä, puhutaan hyperautomaatiosta. Se on teknologiatrendi, jonka Gartner ennustaa olevan numero 1 vuonna 2020. Hyperautomaatio eroaa aiemmin mainitusta prosessiautomaatiosta siten, että se pystyy tekemään loogisten dataan perustuvien loogisten päätösten lisäksi koneopittuja päätöksiä. Esimerkiksi, kulutusluoton koon hyväksyminen tai ehdottamihnen asiakkaalle verkkopankissa perustuu usein koneopittuun, jatkuvasti päivittyvään riskiprofiiliin asiakkaasta. Polttonesteitä myyvien huoltoasemien hintoja päivitetään jatkuvasti kilpailihintojen ja huoltoaseman kokonaiskatteen mukaan. Vain mielikuvitus on rajana prosessien älyllistämisessä.

Perinteiseen nauhoitushenkiseen RPA:han hyperautomaatio on lyömätön vaihtoehto. RPA:lle vaikeat ehdolliset päätösket (if-then-else), datan esikäsittely, datamappaus ja konnektorit hoituvat integraatioalustalla paljon paremmin. Yhdistämällä prosessiautomaatiokyvykäs integraatioalusta ja RPA-alusta, voidaan puolittaa suoraan robottien määrä ja vähentää kompleksisia ja vikaherkkiä nauhoituksia siirtämälle ne osuudet integraatioalustalle ja ajamalla nauhoituksia vain niihin järjestelmiin, mihin ei ole rajapintoja tai muista syistä järkevää integroitua.

Mikä on palveluväylän tehtävä?

Kypsyysaste 3: Palveluväyläpohjaiset integraatiot ja sisäiset rajapinnat

Palveluväylää kutsutaan usein sen englanninkielisellä lyhenteellä ESB (Enterprise Service Bus). Palveluväylän sisältävät integraatiot alustat pystyvät erilaisiin viestin välitystapoihin. Väylä sisältää yleensä jonojärjestelmän, johon sanomat voidaan laittaa persistoidusti. Tämä tarkoittaa, että lähettäjä voi luottaa, että sanoma - vaikkapa verkkosivulta tullut sähköinen tilaus tai hakemus - on talletettu pysyvästi jonojärjestelmään, vaikka se ei ole vielä saavuttanut sitä järjestelmää, mihin se on lopulta menossa. Tämän ominaisuuden voi hankkia myös erillisenä jonojärjestelmänä ilman integraatioalustaa. Esimerkiksi FRENDS-integraatioalusta sisältää jonojärjestelmän itsessään, ja toisaalta se pystyy käyttämään muita jonojärjestelmiä, koska se tukee jonokommunikaatioon tarkoitettua AMQP-standardia.

Vaikka jonojärjestelmillä erikseen tai osana integraatioalustaa on edelleen käyttötapauksensa, on maailma menossa koko ajan enemmän tapahtumapohjaiseen tiedonvälitykseen. Se tarkoittaa, että sanomia - esimerkiksi myyntisanomia kassalta keskusjärjestelmään - ei laiteta enää jonoon, vaan ne voidaan lähettää suoraan integraatioalustan REST/JSON-rajapintoihin, jotka parhaimillaan synkronoivat ne suoraan vastaanottaviin järjestelmiin. Jos tulee kuormapiikki - esimerkiksi myyntisanomia tulisi joulumyynnin aikana satakertainen määrä - skaalaavat niin integraatioalusta kuin vastaanottava keskusjärjestelmäkin pilvessä esimerkiksi konttiteknologialla. Jos taas vastaanottava järjestelmä on monoliitti, voi integraatioalusta puskuroida viestejä tai jonottaa niitä perinteiseen malliin. Tuki konttiteknologiaan ei ole vakiintunut ominaisuus integraatioalustoissa, ja tarvetta sille kannattaa harkita integraatioalustan valintaa tehdessä.

Jonotuksen lisäksi palveluväylä osaa myös publish-subscribe-viestivälityksen. Siinä tietoa ja sanomia itselleen haluavat järjestelmät ilmoitetaan kuuntelijoiksi eri aiheisille viesteille (topic) tai sisällöille (content). Palveluväylä osaa reitittää kuuntelijoille juuri oikean aiheen sanomat tai ne sisällöt, joita vastaanottaja kaipaa. Esimerkiksi asiakkuudenhallintajärjestelmä (CRM) voidaan ilmoittaa kuuntelemaan kaikkia asiakasmuutoksen sisältäviä sanomia, ja niitä voi tulla useammasta lähteestä. Tai ostotilaussanomia voidaan kuunnella useammassa järjestelmässä, jonne väylä ne reitittää ja muuntaa niin protokollan kuin sanomarakenteenkin vastaanottajille sopivaksi.

Palveluväylä kokonaisuudessaan ei kuitenkaan ole välttämätön osa integraatioratkaisua, vaan se on usein käytössä suurempien organisaatioiden järjestelmäintegraatiossa.

Integraatioalusta on rajapintatalouden moottori

Kypsyysaste 4: sisäiset ja julkiset rajapinnat sekä OpenAPI

Integraatioalustat, kuten FRENDS eiPaaS, pystyvät toimimaan niin sisäisten kuin julkistenkin API-rajapintojen suoritusmoottoreina ja toteutusalustoina. Integraatioalustan konnektoreilla tai adaptereilla kytkeydytään perinteisiin järjestelmiin, kuten konesalin ERP-järjestelmään, tai pilvijärjestelmiin, kuten SalesForce CRM. Näistä järjestelmistä ja näiden järjestelmien yhdistellyistä tiedoista voidaan julkaista liiketoimintafunktioita tai tiedonjakopalveluita monella eri teknologialla ja tavalla. Nykypäivänä näistä yleisin ja suositeltavin on OpenAPI -standardin määrittelemät tavat ja teknologiat. Julkaistut APIt voivat olla vaikkapa edellisen kappaleen sanomien sisääntulokanava. Yhtälailla integraatioalustan päälle toteutettu julkinen rajapinta voi olla synkronisesti yhteydessä ilman väylää taustajärjestelmiin.

OpenAPI on siis standardi ja esimerkkinä sen toteutuksesta on esimerkiksi Swagger: joukko työkaluja tämän standardin toteutukseen, joita tässä artikkelissa mainittu FRENDS -integraatioalustakin hyödyntää. OpenAPI varmistaa, että API on aina kuvattu ja dokumentoitu samalla tavalla ja että se on helposti testattavissa. OpenAPIiin viitatataan usein termillä "Public API". Suomen kielessä tulee olla tarkkana: jos puhutaan julkisesta APIsta, tarkoitetaanko OpenAPI-standardin toteuttavaa APIa, julkiseen internetiin julkaistua APIa vai julkisesti saatavilla olevaa APIa. Jälkimmäisten ei tarkkaan ottaen tarvitse toteuttaa OpenAPI-standardia ollakseen julkinen eli julkisesti saatavilla.

Sisäiset APIt

Alla olevassa kuvassa taksiyhtiön asiakkaan hakupalvelut tai tilauksenmuokkauspalvelut - APIt - voivat olla toteutettu integraatioalustalla vaikkapa REST/JSON -rajapintoina. Ennen REST/JSON-aikaa kyseisiä rajapintoja toteutettiin SOAP/XML-yhdistelmällä. Vaikka kuvassa olevat rajapinnat toteuttaisivat OpenAPI-standardin, ei niitä voi kutsua julkisiksi rajapinnoiksi. Ne vasta toteuttavat standardin, joka tekee niiden käytöstä helpompaa, mutta niitä ei ole julkaistu palomuurien toisella puolella avoimessa internetissä. Sisäisiä rajapintoja voivat kutsua eri aikana toteutetut järjestelmät, ja niitä otetaan käyttöön kunkin järjestelmän - vaikkapa uuden ERP:n - käyttöönottoprojektissa. Niistä on jo selvää hyötyä: alla olevan järjelmän, esimerkiksi sen ERP:n, voi vaihtaa siten, että kutsuvat järjestelmät eivät huomaa muutosta. Toisaalta hakupalvelut ovat uudelleenkäytettäviä: samaa integraatiotyötä ei tarvitse tehdä kahdesti. Tällaista syntyvää palvelukerrastoa kutsutaan palvelukeskeiseksi arkkitehtuuriksi (SOA).

Ulkoiset APIt

Otetaan API-taloudesta esimerkiksi taksipalveluyritys. Se päättävää hankkia uuden mobiiliapplikaation, sillä yhä enemmän taksitilauksia tehdään applikaatioilla puhelinkeskusten sijaan. Tieto vapaista autoista, kuskeista ja sijainneista löytyvät eri ikäisistä legacy-järjestelmistä, kuten Fleet Management (kaluston ja autojen hallinta ja niiden varaukset) sekä HRM, josta löytyy kuskien tiedot.

Tällaisen taksiapplikaation voi rakentaa suoraan nykyaikaisen integraatioalustan päälle. Lukijalle voi olla uutta, että applikaation voi rakentaa suoraan integraatioalustan varaan ilman erillistä kallista taustapalvelua, sillä osa alustoista osaa julkaista matalan latenssin tilallisia palveluita. Tämä tarkoittaa, että integraatioalustan nopeus ja skaalautuvuus ovat sellaisia, että itse alusta ei tuo kuin millisekunnin lisää vasteaikaa. Palvelun suorituksen aika on oikeasti se aika, mikä kuluu taustajärjestelmien sisällä esimerkiksi kyselyjä tehdessä. Tilallisuudella tarkoitetaan sitä, että integraatioalustan päälle rakennetut palvelut osaavat sisäänrakennetusti sessionhallinnan. Eli kun avatessasi mobiiliapplikaation kirjaudut palveluun ja tovin päästä painat "Tilaa taksi" -nappia, ymmärtää alla oleva integraatioalusta näiden tulevan samasta käyttäjäsessiosta. Käyttäjäsessiota kutsutaan myös usein suomenkielillä vähemmän tunnetulla termilla käyttäjän istunto.

Tällaisessa tapauksessa integraatioalustaan luodaan apeja, jotka toimivat liiketoimintafunktioina, kuten "haeVapaaAuto", "tilaaTaksi" tai "arvosteleKuljettaja". Ne päivittävät eri taustajärjestelmiin tarvittavat tiedot tai hakevat niitä sitä mukaa, kun kuluttaja taksiappiaan käyttää.

OpenAPI-standardia hyödyntäen voi samaa mobiiliapplikaatiota varten tehtyä palvelua julkaista julkiseen verkkoon. Esimerkiksi sama API "tilaaTaksi" voi olla kutsun kohteena, kun painat toimistokompleksin aulassa fyysistä taksintilausnappia. Näin samasta APIsta syntyykin kokonaan uusi myyntikanava. Joku kolmannen osapuolen erilaisia tilaisuuksia järjestävän yrityksen kehittäjä voi löytää APIn googlesta ja lisätä APIn omaan, tilaisuuksista tietoa jakavan applikaationsa osaksi. Näin myyntikanavan käyttö laajenee, kun APIa tarjotaan holistisesti kaikille. Tällaiset julkiset APIt muodostavat jo nyt kokonaan uuden myyntikanavan perinteisten kivijalkakauppojen ja verkkokauppojen rinnalle.

API Management eli APIen hallinta

Kun rajapintoja - apeja - tehdään integraatioalustalla tai rakennetaan suoraan alustapalvelun kuten AWS:n päälle, niiden hallinta muodostuu seuraavaksi haasteeksi Miten saan muut löytämään julkisen APIni? Miten varmistan, että se on turvallisesti saatavissa julkisessa verkossa? Tätä varten on oma alueensa, jota kutsutan APIen hallinnaksi. APIen hallintaa varten voi hankkia pelkästään näitä toimintoja varten tehdyn alustan, kuten esimerkiksi RedHat 3Scale. Silloin APIn sisuskalut eli toteutus ja itse APien hallinta ovat erillään. Toisaalta nykyaikaiset integraatioalustat pitävät sisällään APIen hallintaominaisuuksia hyvinkin kattavasti. Esimerkiksi FRENDS-integraatioalustassa on API management -ominaisuudet niin FRENDS:llä itsellään tehdyille kuin muissakin ympäristöissä toteutetuille API-rajapinnoille.

APIen hallintaa jaetaan usein kahteen pääosaan: portaaliin (API portal) ja välityspalveluun (API gateway). Nämä osiot eivät pidä sisällään itse APIn toteutusta, vaan ovat APIen hallinta- ja julkaisukerros. Portaalista kolmannen osapuolen koodajat voivat löytää julkaistun APIn vaikkapa Google-haulla ja ohjelmoida sovelluksensa käyttämään sitä (kuvassa application).

Nykyaikaiset integratioalustat pystyvät toimimaan niin APIen suoritus- ja luontialustoina kuin APIen välityspalveluina ja portaaleina.

Mitä ovat SOA, mikropalvelut ja minipalvelut?

SOA (Service Oriented Architecture) on 1990-luvun lopulla syntynyt kehitystapa, jossa luotiin uudelleen käytettäviä palveluita. Yllä olevan esimerkin kaltainen "tilaaTaksi" on myös SOA-ajattelun mukainen yleiskäyttöinen palvelu. Alkuajan SOA-ajattelun mukaisia palveluita vaivasi usein raskaus: ne määriteltiin raekooltaan kaiken kattaviksi funktiokokonaisuuksi. Niiden kehitys saattoi usein olla niin hidasta, että liiketoiminta ei voinut odottaa, ja tarpeet vanhenivat ennen kuin raskas kokonaisuus saatiin valmiiksi.

Ongelmaa ratkaistiin ajattelemalla palvelut uudelleen pienemmiksi, selkeiksi liiketoimintafunktioiksi (yleiskäyttöiset APIt), jotka ovat täysin riippumattomia muista järjestelmistä (uncoupled). Näin syntyi SOA:n perillinen mikropalveluarkkitehtuuri. Mikropalvelu on myös kehitin- ja teknologiariippumaton. Usein ajatellaan, että mikropalveluita pitää tehdä alustoilla kuten Azure tai AWS, mutta yhtälailla niitä voi toteuttaa integraatioalustalla, joka kykenee täyttämään mikropalvelun määritelmän. Monet organisaatiot, kuten vaikka Zalando, ovat rakentaneet liiketoimintafunktionsa mikropalveluiksi - se onkin yksi sovelluskehityksen muoto, ei integraatiotapa. Useat organisaatiot ovat tehneet yhtälailla verkkokauppansa tai muut asiointipalvelunsa mikropalveluiden varaan, mutta unohtaneet, miksi valmissoftatuotteet olivatkaan alkuaan tehty: mikroilijat joutuvat rakentamaan hyvin paljon sellaista, mikä tulee valmissoftan mukana, kuten operoinnin tuen, monitoroinnin jne. Kaiken koodaminen tarkoittaa myös valtavaa määrää ylläpidettävää koodia, eikä silloin ole mahdollista rakentaa esimerkiksi integraatioalustasta saatavaa visuaalista audit-trailia, monitorointia, hiljaisuuden valvontaa tai muita pitkälle kehittyneitä ominaisuuksia.

Mikropalvelussa palvelu on täysin skaalautuva eikä sillä saa olla riippuvaisuuksia. Se ei saa hakea tietoa esimerkiksi ERP:stä vaan sillä on oltava oma "sisäinen" yhtä skaalautuva tietovarastonsa. Tätä tarkoitetaan termillä "uncoupled" ja sillä varmistetaan täydellinen skaalautuvuus. Mikropalvelua voi skaalata, esimerkiksi seuraavassa kappaleessa kuvatulla kontituksella, lähes loputtomasti. Tällaisen palvelun tekeminen on kuitenkin kertaluokkaa isompi kustannus kuin minipalvelun. Minipalvelu on käytännössä samanlainen liiketoimintafunktio, mutta se on ns "loosely-coupled" eli sallitan kytkökset vaikkapa ERP-alustaan. Skaalautuvuus kärsii, koska vaikka minipalvelun toteuttava frends skaalautuisi edelleen, ERP ei skaalaudu. Ei ainakaan yhtä pitkälle kuin esimerkiksi kontitettu

Frends -integraatioalustalla voi toteuttaa molempia - mini- tai mikropalveluita, sekä valvoa ja ylläpitää niitä keskitetysti.

Mitä on kontitus?

Kontituksella tarkoitetaan sovellusten tai palveluiden virtualisointia pieniksi, eheiksi ja itsenäisiksi järjestelmiksi. Tällaiseen konttiin laitetaan kaikki sovelluksen tarvitsemat tiedostot ja ohjelman osat sekä valmis konfiguraatio. Yksi kontti voi sisältää aiemman taksiesimerkin yhden palvelun "tilaaTaksi" tai joukon palveluita yhdessä suoritusmoottorissa. Kontit pyörivät erillisessä kontitusympäristössä kuten hyvin vakiintuneessa Docker-ympäristössä tai suosiotaan kasvattavassa RedHat OpenShift -ympäristössä.

Kontituksesta on seuraavia hyötyjä:

• Sovelluksen kaatuessa kontitusympäristö osaa replikoida ehjän kontin kaatuneen tilalle ns. "tehdasasetuksilla".

• Kontitus mahdollistaa konttien skaalautumisen tarpeen mukaan. Esimerkiksi pikkujouluaikana "tilaaTaksi"-palvelu voisi skaalautua konteissa moneksi lisääntyneen kutsumäärän myötä. Kontitusympäristö, esimerkiksi aiemmin mainittu Docker, osaa jakaa kuorman konteille tasaisesti. Itse taksiautoja kontitus ei ikävä kyllä skaalaa.

• Kontitus nopeuttaa palveluiden julkaisua sekä jakelua ja vähentää näin aikaa, jolla palvelu saadaan haluttuun käyttöön (time-to-market)

Siinä, missä virtuaalikone on yhden palvelinympäristön raudan virtualisointi, kontti virtualisoi yhden sovelluksen tai palvelun.

Jotkin uusista integraatioalustoista, kuten tässä artikkelissa mainittu FRENDS-integraatioalusta, tukevat kontitusta. Kontituksen ajatuksessa, että palvelut ovat itsenäisiä, sopivan pieniä skaalautuvia kokonaisuuksia, on hyvin paljon samaa kuin mikropalveluissa.

Digitaalinen integraatiohubi

2021 Gartner lanseerasi termin Digital Integration Hub (DIH). DIH tarkoittaa alustaa, joka julkaisee liiketoimintafunktioita, kuten aiemmin mainitut mini- tai mikropalvelut. Sen sijaan, että DIH olisi kytketty suoraan taustajärjestelmiin (coupled), se kytketään välikantaan. Välikannan tehtävä on erottaa hitaat taustajärjestelmät ja julkistaa suurellekin kuormalle altistuvat API vaarantamatta taustajärjestelmiä.

Frends -alustalla APIt ovat konteissa ja suoritusskaalautuu elastisesti pilvessä - aamu ruuhkassa on 6 API-agenttia ja ruuhkan jälkeen vain yksi. Luku- ja kirjoitusoperaatiot tehdään välikantaan, joka voi olla esimerkiksi muistin varainen (in-memory) tietokanta. Erilliset datapumput, jotka nekin ovat frends prosesseja, pumppaavat dataa pääjärjestelmiin ja takaisin. Frendsin orkestrointikyvyt auttavat ratkomaan datan takaisin viennin loogisissa haasteisa kun sama data on päivittynyt esimerkiksi kahdesta eri lähteestä - APIsta ja pääkäyttäjän toimesta.

Korvaako pilvialustat Azure ja AWS integraatioalustat?

Erilaiset pilvialustat, kuten AWS ja Azure, sisältävät tässäkin artikkelissa mainittuja integraatiotoiminnallisuuksia omina kokonaisuuksinaan. Esimerkiksi Azuren integraatiopalvelut jakautuvat yli kuuteen erilliseen komponenttiin. Samat ominaisuudet saa uusilla iPaaS-alustoilla yhdestä koherentista käyttöliittymästä. Molemmilla - pilvialustan integraatiotoiminnallisuuksilla tai integraatioalustalla pilvessä - voi tehdä integraatiot aina tiedostonsiirroista APIen hallintaan ja mikropalveluihin. Missä erot sitten syntyvät?

• Alustakehitys vaatii aina monipuolisen koodaajan - se on välttämättömyys. Samat toiminnot saadaan integraatioalustalla aikaan ilman koodajataustaa - eritoten, jos alusta on no-code- tai low-code-tyyppinen, mistä puhutaan seuraavassa kappaleessa.

• Alustakehitys on laajempi konsepti ja sisältää integraatioiden lisäksi myös liiketoimintasovellusten räätälikehityksen, missä se onkin parhaimmillaan.

• Integraatioalustojen monitorointikyvykkyys on tyypillisesti paljon parempi

• Visuaalisten integraatioalustojen ilmaisuvoima on kertaluokkaa vahvempi: esimerkiksi tässä artikkelissa esiintyvä FRENDS vs. Azure Logic Apps

• Pilvialustat sisältävät usein koneoppimiseen ja tiedonvarastointiin (Data Lake) liittyviä ominaisuuksia.

• Pilvialustat ovat myös integraatioalustan palveluiden jakelukanava, jos integraatioalusta kontitusta tukee.

• Hybridi-integraatioalustat sisältävät hajautetun arkkitehtuurin, missä integraation tai APIn suoristus voi tapahtua pilvessä tai vaikkapa asiakkaan omassa konesalissa - silti kaikkea kehitetään, operoidaan ja valvotaan yhden käyttöliittymän kautta.

Integraatioalustatkin pyörivät käytännössä näissä samoissa pilvialustoissa tarjoten koherentimman käyttökokemuksen ja ylläpidon helppouden pelkkään pilvialustaan nähden. Esimerkkinä monet FRENDS-asiakkaat ylläpitävät ja tekevät integraatioratkaisujaan ilman erillistä toimittajaa tai omaa koodaajakatrasta.

Vastaus otsikon kysymykseen onkin: eivät korvaa, vaan integraatioalustat ja pilvialustat toimivat symbioosissa, missä integraatioalusta tarjoaa koherentin kehityksen ja valvonnan integraatiohin, ja pilvialustat tarjoavat komponentteja integraatioon ja paljon muuhunkin, kuten koneoppimiseen ja tiedon varastointiin.

No-code, low-code vai full-code?

Integratioalustat ovat hyvin erilaisia. Kuten aiemmin mainitsin, niiden toiminnallisuudet ja kyvykkyydet vaihtelevat merkittävästi. Myös kehitystapa vaihtelee erilaisten alustojen välillä. Osa integraatioalustoista perustuu puhtaaseen koodaamisen, osa prosessien visuaaliseen mallinnukseen ja teknologia- tai järjestelmäadaptereihin. Puhtaan koodaamisen integraatioalustoja kutsutaan full-code-alustoiksi, vähän protokolla- ja standardiosaamista vaativia alustoja kutsutaan low-codeksi ja täysin valmiisiin, sovelluksen rajapinnat suoraan osaavia järjestelmiä kutsutaan no-code-alustoiksi.

No-code muuttuukin helposti ja ennalta arvaamattomasti full-codeksi, kun integroitavaa järjestelmää onkin käytetty tavalla, jota valmisadapteri ei ymmärrä. Kuinka moni toiminnanohjausjärjestelmä on otettu käyttöön räätälöimättä tai käyttämällä sen tietokenttiä juuri alkuperäisessä tarkoituksessa ja samalla tavalla eri yrityksissä? Se, mikä tarkoitettiin toimivaksi 80%:ssa ratkaisuja, toimiikin vain 20%:ssa. Tästä syystä no-code-alustat toimivat usein hyvin demoissa, mutta käytännössä ne ovat työläitä toteuttaa, jos ja kun adapteri ei toimikaan niin kuin olisi tarvittu. Full-code-alustoissa ongelma on osaamisen hallinta: ne tarvitset mittavan määrän alustan tuntevia koodaajia. Usein esimerkiksi ylläpito muodostuu kalliiksi, kun jokaista ysköstä kaivamaan tarvitaan se kallis toimittajan koodaaja.

Näistä paras vaihtoehto nykypäivänä on low-code, sillä se on oikea yhdistelmä ilmaisuvoimaa ja operoinnin helppoutta. Alla esimerkkinä FRENDS-integraatioalustan BPMN-esitystapa. Kuvassa olevalla tietovuolla tehdään kaikki kehitys ja operointi. Itse asiassa kuvassa on yhden prosessin suorituksen instanssi: operaattori pääsee käsiksi kaikkiin tiedon murusiin, mitä instanssin läpi on kulkenut - oli se sitten sisältöä tai vaikkapa tiedonsiirtoprotokollan sisäistä lokia.

On hyvä muistaa, että integraation kustannus muodostuu hyvin nopeasti olemassa olevien integraatioiden ylläpidosta, ei uuden tekemisestä. Tästä syystä operoitavuus ja monitoroitavuus ovat avainasemassa nykyaikaista integraatioalustaa valittaessa.

Millainen on nykyaikainen integraatioalusta?

Gartnerin pääintegraatioanalyytikko Massimo Pezzini puhuu usein termillä "pervasive integration platform". Tällä hän tarkoittaa integraatioalustaa, jossa on laaja joukko tai jopa kaikki tässä artikkelissa mainituista toiminnoista. FRENDS-integraatioalustassa olemme ajatelleet ominaisuusjoukkoa vieläkin laajemmin ja yhdistäneet prosessiautomaation (RPA:n) samaan integraatiotoiminnallisuuksien joukkoon.

Tässä summattuna nykyaikaisen integraatioalustan toiminnallisuuksia:

• Keskitetty monitorointi ja valvonta kaikelle - niin prosessiautomaatiolle kuin vaikkapa APIn suoritushistorialle

• API-hallinta / API Management

• API-suoritus / API hosting

• Prosessien automaatio visuaalisesti (esim. BPMN-esitystavalla)

• Kyky orkestroida prosesseja koneopitun (machine learning) perusteella

• Kyky orkestroida prosesseja siten, että osassa prosessia voidaan simuloida ihmistä nauhoituksin (RPA).

• APIen luonti visuaalisella notaatiolla

• Tuki uusille ja vanhoille sanoma- tai rakennestandardeille konnektorien kautta (esim. REST/JSON, SOAP/XML, oAuth2, edifact jne.)

• Tuki suurimmille järjestelmille valmisadapterien kautta (esim. SAP)

• Kyky toteuttaa ja julkaista mini- tai mikropalveluita, jotka voivat olla yllä mainittuja sisäisiä tai ulkoisia apeja

• Perinteiset ajastukset - kaikki ei ole vielä tapahtumapohjaista. Esimerkiksi palkanmaksuprosessin pitää käynnistyä joka kuun 25. päivänä tai sitä edeltävänä ensimmäisenä pankkipäivänä, jos 25. ei ole pankkipäivä = monimutkaisemmat ajastukset

• Skaalautuminen konttiteknologialla pilvessä

• Kyky toimia aidosti hybridinä = yksi käyttöliittymä, mutta suoritus voi olla omassa konesalissa tai pilvessä

Lisää luettavaa / lähteet

• Mikropalvelut, Martin Fowler https://martinfowler.com/articles/microservices.html

• Palveluiden granulariteetti, Christian Verstaete Cooking breakfast and Microservice granularity

• RPA ja integraatioalustat, Antti Toivanen RPA done Right

• HiQ:n integraatiopalvelut

• Digital Integration Hub, Gartner

Jos kiinnostuit aiheesta tai haluat kuulla lisää integraatiosta, ota yhteyttä alta löytyvällä lomakkeella.