Monipilvi-hybrid on integraatioiden tulevaisuus – kuinka sinne mennään?

Tietojärjestelmät siirtyvät vauhdilla pilveen, mutta osa tiedosta täytyy jatkossakin säilyttää omassa konesalissa. Miten integraatiot tällöin hoidetaan? Jonas Källström kertoo, miten siirryt hallitusti monipilvi-integraatioihin.

Jo integraatioiden alkuhämärissä huomattiin, että aina uusien point-to-point-integraatioiden tekeminen heterogeenisten järjestelmien välille johtaa vyyhteen, jota on hyvin hankala hallita. Nopeasti keksittiin laittaa keskelle palikka, jota myös kutsuttiin EAI-/ESB-/jne.-integraatioalustaksi. Tämä joidenkin rakastama ja joidenkin vihaama palikka toimii siinä hyvin, että se pakotti omien järjestelmien väliset integraatiot toimimaan vakioidulla teknisellä tavalla. Näin saavutettiin hallittu integraatioympäristö rajapintojen teknisellä vakioinnilla. Tämä malli toimi oikein hyvin niin kauan kuin järjestelmät olivat siellä omassa konesalissa ja oman hallinnan piirissä.

Nyt ollaan kuitenkin maailmassa, jossa monoliittijärjestelmien sijaan nähdään paljon heterogeenisempiä ratkaisuja. Osia ajetaan vieläkin omassa konesalissa, mutta osa ratkaisusta saattaa on SaaS-palveluna ostettavaa ja osa kenties serverlessinä ajettavina pieninä koodinpätkinä. Näiden kytkeminen oman konesalin perinteiseen integraatioväylään tuntuu lähtökohtaisesti järjettömältä. Järjestelmät siirtyvät vauhdilla pilveen, mutta vielä on tietoa, joka vaatii säilyttämistä omissa konesaleissa.

Eikä se pilvikään ole ihan yksiselitteinen paikka. Pikkaisenkin isommassa IT-ympäristöstä löytyy erilaisia pilvipalveluita pilvin pimein. Kun aiemmin integraatioprojektissa mietittiin, miten liitetään oman konesalin mainframe-ratkaisu uuteen saman konesalin ERP-järjestelmään, saattaa moderni integraatioratkaisu edellyttää Azure Event Gridissä liikkuvan tiedon vientiä AWS RedShiftiin, jossa sitä yhdistetään konesalin SAPista saatuun dataan. Integraatioiden on siis pystyttävä toimimaan useiden eri pilvipalveluiden sekä konesalin välillä.

Hallittuun monipilvi-integraatioon uusissa arkkitehtuureissa

Mutta kuinka tällaiseen multi-cloud-integraatiomaailmaan päästään hallitusti? Ainakin kolme asiaa pitää ottaa huomioon:

1. Yhteinen integraatiostrategia

2. Oikeat välineet

3. Läheinen yhteistyö kehitystiimien kanssa

Yhteinen integraatiostrategia

Integraatiostrategia kertoo, millä periaatteella integraatioita ympäristössä kehitetään ja ylläpidetään. Strategian pitäisi olla muotoiltu siten, että se kestää teknologiamuutoksiakin. On esimerkiksi todennäköistä, että eri SaaS-palveluiden integraatioihin kehittyy valmiita täsmäpalveluita. Voidaanko tällaisia käyttää ja millä edellytyksillä? Entä jos palvelu sijaitsee USA:ssa? Pitääkö varautua siihen, ettei ko. palvelua enää vuoden päästä ole olemassakaan? Näihin on syytä miettiä etukäteen suuntaa-antavia linjauksia ja käydä niitä eri sidosryhmien kanssa läpi. Näin on sitten projektikiireessä helpompi päätyä perusteltuun ja kaikkien hyväksymään tekniseen ratkaisuun.

Integraatiostrategiassa tulisi myös huomioida, että kaikki integraatiot eivät ole tasa-arvoisia. Niiden tärkeysjärjestyksen tulisi määräytyä sen mukaan, mikä on vaikutus liiketoiminnalle, jos kyseinen integraatio menee rikki. Tämän liiketoiminnan vakaan ytimen rinnalla tarvitaan joustavuutta nopeisiin kokeiluihin esimerkiksi uusien palveluiden kehittämisessä. Tällöin integraatioiden on oltava kevyitä ja helposti muutettavia.

Integraatiostrategissa olisikin syytä kuvata vähintäänkin:   

• Hallinnan minimivaatimukset (esim. lokitukset, dokumentointi, omistajuus, jne.) 
• Tietoturvavaatimukset (miten dataa saa siirtää eri verkoissa, salausratkaisut, palveluiden maantieteelliset sijaintivaatimukset, jne.) 
• Integraatiovälineet (milloin on syytä käyttää olemassa olevia välineitä, milloin voidaan rakentaa suoria yhteyksiä, milloin/miten voidaan käyttää ulkoisia integraatiopalveluita (esim. iPaaSit) jne.) 
• Uudelleenkäyttötavoitteet (varsinkin API-pohjaisissa ratkaisuissa) 
• Kustannus- ja vastuujako 
• Sidosryhmien väliset yhteistyömallit  

Oikeat välineet

Moderneja integraatiovälineitä voidaan pitää eräänlaisina työkalupakkeina, joista löytyy eri tilanteisiin kehitystä nopeuttavia komponentteja, kuten sovellus- ja pilvipalvelu-connectoreita. Näppärä koodaaja voi toki itsekin rakentaa integraatiot koodipohjaisesti esim. pilvifunktioina. Joskus tämä saattaakin olla ihan hyvä malli. Toisaalta saattaa kuitenkin perusasioiden kimpussa, kuten autentikointiratkaisujen kanssa, kulua yllättävänkin kauan. Nämä ovat niitä asioita mitä integraatiovälineen connectorit hoitavat siellä konepellin alla. Pilvi-integraatiovälinerintamalla näkee myös nopeaa kehitystä, joten multi-cloud integraatioratkaisujen kehittämisestä tulee ajan myötä yhä helpompaa. Välineissä on kuitenkin suuriakin eroja, joten evaluoinnit kannattaa tehdä huolella.

On myös todennäköistä, että vähänkin isompi IT-ympäristö tarvitsee useamman integraatiovälineen hoitamaan erityyppisiä integraatioratkaisuja. Näiden roolitusta kannattaa kuitenkin miettiä siten, ettei synny sitä kuuluisaa sillisalaattia. Samaan aikaan on hyvä myös muistaa, että se tekninen ratkaisu, joka tänään oli paras ei välttämättä enää ole sitä vuoden kuluttua kun välineet kehittyvät. Integraatioiden tukijalkana kannattaakin kuvata integraatiostrategiaan ne muuttumattomammat periaatteet, joita vasten ratkaisuja sitten aina voidaan sparrata ennen toteutusta.

Yhteistyö kehitystiimien kanssa

Integraatioita tehdään myös entistä enemmän itsenäisesti kehitystiimeissä. Tärkeää on, että yhteinen integraatiostrategia ohjaa tätäkin tekemistä yhtenäisesti, ja että tehdyt ratkaisut on keskusteltu yhdessä auki ennen ratkaisun valintaa. Kehitystiimien ydinosaaminen on usein muualla kuin integraatioratkaisuissa, joten joskus näkee vähintäänkin mielenkiintoisia ratkaisuja, jos niihin on päädytty vain projektin lähtökohdista.

Integraatiotoiminnon tärkeäksi tehtäväksi muodostuukin tällöin hallittujen hybridi-integraatioiden mahdollistaminen, vaikka integraatioiden toteutus voi vaihdella eri yksiköillä ja kehitystiimeillä ratkaisuista ja välineistä riippuen. Jotta ympäristö pysyy järkevänä, pitää kuitenkin tiimien tukemiseen ja auttamiseen olla kyvykkyyttä. Perinteinen integraation asiantuntijakeskus (ICC) toimii tässä hyvänä runkona, mutta sen pitää pystyä kehittymään enemmän hankkeita tukevaksi mahdollistajafunktioksi. Ja tärkeintä tässä on se saumaton päivittäinen yhteistyö hankkeiden kanssa. Yhdessä ne parhaat ratkaisut tehdään.