Pesä puhtaaksi: integraatiot, arkkitehtuuri ja tiedonhallinta

Taas kerran se kuultiin palaverissa: ”Tätä ei kyllä oikein pysty missään järjestelmässä tekemään. Voitaisiinko integraatioon tehdä kantataulu ja päättely ja ylläpitää sitä siellä?” Integraatiokehittäjä narskuttelee hampaitaan, ja yrittää kuumeisesti keksiä miten tällä kertaa selittäisi kuinka huono idea se on. Ja tietää, että lopulta saatetaan silti aivan hyvin päättää tehdä näin.

Käytännössä kaikilla organisaatioilla on käytössään useampia järjestelmiä, ja tiedon on siirryttävä luotettavasti niiden välillä. Ei kuitenkaan ole mitenkään taattua, että eri järjestelmien tietomallit tai tietosisältö ovat aina yhteensopivia. Juuri tähän haasteeseen integraatioalusta vastaa: se varmistaa, että tieto siirtyy järjestelmien välillä, täydentäen puuttuvia tietoja sekä muuntaen rakenteita ja sisältöä tarpeen mukaan.

Välillä tulee kuitenkin vastaan tilanteita, jossa prosessia tai sen vaihetta ei voida suorittaa, koska mistään järjestelmästä ei löydy tarvittua tietoa. Syynä voi olla esim. se, ettei missään ole tietoa, millä perusteilla yhdistellä tietueita järjestelmien välillä. Mitä tehdä, kun palapelin palaset eivät tahdo istua yhteen?

Ongelma voi kuulostaa triviaalilta; sellaiselta, jonka toteuttaa räätälöitynä mihin sattuu – ja liiankin usein siihen suhtaudutaan sellaisena. Mutta, kuten pyrin tällä kirjoituksella osoittamaan, on se kaikkea muuta. Tiedonhallinta ja se, mikä järjestelmä omistaa tiedon, ovat erittäin tärkeitä asioita.

Vastuut pidetään selkeinä

Ongelman nimi on vastuiden sekoittuminen. Hyvässä tietojärjestelmäarkkitehtuurissa jokaisella järjestelmällä on selkeästi määritelty rooli, josta on johdettavissa mihin prosesseihin se osallistuu, mitä tietoa se käsittelee, ja minkä tiedon se omistaa. Kun prosessit ovat selkeästi määritellyt ja vastuut rajatut, on selkeää, missä mikäkin tieto syntyy ja missä sitä ylläpidetään – eli käytännössä, mihin käyttäjän pitää mennä, kun haluaa tiettyä tietoa käsitellä. Mitä kompleksisempi ympäristö, sitä tärkeämpää tämä on.

*Kuvituskuvahahmo ei taaskaan tiedä mistä muutokset dataan tulevat.*

Kun integraatioalustan – tai muun järjestelmän – tontille siirtää vastuita, jotka eivät sille kuulu, hämärtyvät nämä rajat. Vastuut vuotavat järjestelmärajojen yli, ja tiedonhallinnan kokonaiskuva muuttuu epämääräiseksi. Osa tiedosta ei enää asu siellä, missä kuuluisi, eikä sitä ylläpidetä siellä, missä käyttäjät olettaisivat sitä ylläpidettävän. Pahimmillaan tämä johtaa siihen, ettei organisaatiossa ole selkeää käsitystä, mistä jokin tieto tulee ja mikä vaikutus sen muokkaamisella on. Käytännössä kyse voi olla vaikkapa siitä, mihin järjestelmään muuttaa asiakkaan osoite, jotta se päivittyy kaikkialle eikä yliajeta jostain muualta.

Samalla tavalla kuin varastonhallintajärjestelmässä ei ylläpidetä asiakastietoja tai tuotehallintajärjestelmässä yrityksen taloustietoja, ei integraatioalustalla pitäisi ylläpitää muiden järjestelmien tietoja. Usein toistamamme mantra onkin ”integraatio ei omista dataa, se liikkuu sen läpi.” Integraatioalustan tehtävä ei ole synnyttää uutta tietoa, vaan toimia viestiväylänä, jossa tieto siirtyy järjestelmien välillä.

Ongelma on siis ennen kaikkea periaatteellinen, mutta sillä on käytännön merkityksensäkin.

Ylläpidettävän tiedon on oltava ylläpidettävissä

Mitä tarkoittaa, kun sanotaan että tietoa ylläpidetään jossakin järjestelmässä? Se ei tarkoita vain sitä, että kyseinen tieto löytyy sen tietovarastosta, vaan että kyseistä tietoa voi selata, muokata, luoda ja poistaakin. Tieto siirtyy tästä järjestelmästä muualle. Niin käyttäjillä kuin automaatioilla on oltava keinot syöttää tietoa järjestelmään ja/tai hallinnoida prosesseja, jotka synnyttävät ja muokkaavat tietoa.

Juuri tässä on toinen ongelma tiedon ylläpidossa integraatioalustan sisällä. Lähtökohtaisesti se ei tarjoa mitään keinoja muille järjestelmille muokata tietoa tai käynnistää prosesseja. Kaikki pitää räätälöidä. Vielä vähemmän integraatioalusta tarjoaa käyttökelpoisia käyttöliittymiä ja työkaluja käyttäjille tehdä samaa. Muita kuin IT-ammattilaisia ei kehtaa päästää esim. tietokantaeditoria käyttämään.

*Ei-teknisille käyttäjille tarjotaan selkeitä käyttöliittymiä, kehittäjille ja pääkäyttäjille teknisiä näkymiä.*

Integraatioalusta on käytännössä aina automatisoitu järjestelmä, jonka toiminta ei vaadi lainkaan toimia ihmiseltä. Prosessit käynnistyvät automatisoidusti tai muiden järjestelmien kutsumina. Siksi yleensä ei ole tarvetta muille kuin puhtaan teknisille, syväosaamista vaativille käyttöliittymille ja näkymille. Kaikki käyttäjien työkalut tiedon selaamiseen ja muokkaamiseen sekä prosessien käynnistämiseen, ja kaikki vaadittava logiikka säännöstöistä autentikaatioon pitää tehdä räätälöitynä. Apuna voi käyttää PowerBI:n ja Excelin kaltaisia sovelluksia, joissa tietoa voidaan visualisoida ja muokata (esim. Excel-tiedosto organisaation Sharepointissa, josta tietoa luetaan iPaaS-alustalle), mutta nekään eivät ole aivan yksinkertaisia hopealuotiratkaisuja.

Usein päädytään siihen, että ehdotetaan tietoa ylläpidettävän integraatioalustalla, ja aina kun sitä on tarve tarkastella tai muuttaa, pyydetään jotain integraatiokehittäjää toimittamaan tulosteen kannasta ja muuttamaan käsin taulujen sisältöä. Kuvitellaan että tämä on tehokas kompromissi, vaikka se on hidasta, kömpelöä, riskialtista ja vaatii monen ihmisen työpanoksen pahimmillaan yhden kentän arvon muutokseen.

Ongelma on siis lopulta sekä periaatteellinen että käytännöllinen. Järjestelmien vastuiden rajat hämärtyvät, jos integraatioalusta ottaa vastuulleen muualle kuuluvia asioita vain siksi, että ne on näennäisesti helpointa toteuttaa sinne. Se on myös käytännön haaste: joko pitää rakentaa uusia käyttöliittymiä, tai hyväksyä kömpelöt, hitaat ja hintavat manuaaliprosessit.

Mutta, silti…

Kaikki yllä mainitut seikat tiedostaen on todettava, ettei asia silti ole niin yksinkertainen. Niin vain löytyy skenaarioita, joissa nimenomaan integraatioalusta on luontevin paikka säilyttää tietoa ja sälyttää omistajuus tiedosta sille. Tärkeää on ymmärtää, milloin se on järkevää ja perusteltua, ja milloin ei.

Tyypillinen skenaario, jossa joku tieto päätetään sysätä integraatioalustan vastuulle ovat erilaiset vastaavuustaulukot. Vaikkapa maakoodit: Suomi on yhdessä järjestelmässä FI ja toisessa FIN, Ruotsi SE ja SWE, ja niin edelleen. Tai verokoodi 01 on toisessa VK15. Vastaavuustieto on rakenteeltaan tyypillisesti yksinkertainen listaus arvopareja. Kaiken lisäksi moinen tieto on yleensä hyvin staattista: maa- ja verokoodeja ei joudu edes vuosittain päivittämään. Ne syötetään kerran, ja muokataan joskus harvoin.

*Periaatekuva iPaaS:in korrelaatiotaulusta, jossa integraatioalustalla yhdistetään kahden eri järjestelmän ID:t.*

Toinen tyypillinen skenaario on se, että jokin tieto tai objekti luodaan yhdessä järjestelmässä, jossa sille alustetaan järjestelmän sisäinen yksilöivä tunniste. Tämän jälkeen tieto viedään integraatioalustan yli toisiin järjestelmiin, joissa automaattisesti luodaan vastaava objekti. Aina ei ole mahdollista määritellä mitään universaalisti yksilöivää tunnistetta, vaan eri järjestelmien sisäisiä tunnisteita pitää voida yhdistää toisiinsa. Objekti, jonka tunniste on 123 yhdessä järjestelmässä vastaa objektia tunnisteella AZ56GV toisessa. Tämä korrelaatiotieto on luonteeltaan automaattisesti syntyvää, eikä tieto yleensä edes kiinnosta käyttäjiä, kunhan integraatioautomatiikka yhdistää tiedon järjestelmien välillä oikein.

Kummassakaan skenaariossa korrelaatiotieto ei ole sellaista, jolla on merkitystä integraatioalustan ulkopuolella. Sama koskee esim. alustan sisäisiä konfiguraatio- ja ohjausasetuksia. Erikoistapauksen muodostaa myös integraatioalustalla väliaikaisesti tallennettu tieto, jota integraatiot siirtävät kohdejärjestelmiin myöhemmin. Jos tieto on pitkäikäistä, eli sitä tarvitaan vielä viikkojen tai kuukausienkin kuluttua, voi pohtia, kuuluisiko se muualle, esim. johonkin master data -järjestelmään.

Reunaehdot alkavat hahmottua. Jos tieto on rakenteeltaan yksinkertaista, luonteeltaan joko staattista tai automaattisesti syntyvää, jos sillä ei ole merkitystä integraatioalustan ulkopuolella, ja jos tieto ei kiinnosta ei-teknisiä käyttäjiä, voidaan perustella sen sijoittamista integraatioalustalle ja sen omistajuuteen.

Yllätyksiltä ei voi välttyä

Lienee totuus, että jokaisessa laajemmassa IT-projektissa joutuu tekemään myönnytyksiä ja kompromisseja. Ei ole niin hyvää projektisuunnitelmaa ja teknistä määritystä, etteikö yllätyksiä tulisi – tämä koskee tietomalleja ja prosesseja siinä missä mitä tahansa muuta IT-projektin osa-aluetta.

Tärkeää ei olekaan välttää niitä täydellisesti, vaan osata ratkaista ne järkevästi. Liian usein, kun havahdutaan siihen, että on jokin puute kahden järjestelmän välillä, on ensimmäinen ja ainoa ehdotus, että se ratkaistaan integraatioalustalla. Yhtäkkiä alustalla on omistajuutta asiakastiedoissa, tuotetiedoissa, laskutustiedoissa – vähän kaikessa. Ja käyttäjät ihmettelevät, mihin heidän pitää tehdä muutoksia, kun tieto ei vaan löydy sieltä mistä he olettaisivat sen löytyvän.

Ensisijaisen vaihtoehdon pitäisi aina olla räätälöidä tai laajentaa sitä järjestelmää, joka omistaa tiedon. Monesti tämä ei ole mahdollista, jolloin integraatioalustan sijasta pitäisi harkita mahdollisuutta ottaa käyttöön tai luoda räätälöidysti työkalu laajentamaan tiedon omistavan järjestelmän toimintaa. Integraatioalustan pitäisi olla viimeinen vaihtoehto, ja jos siihen päädytään, pitää se tehdä kunnolla – eli mahdollisesti tarjota käyttöliittymiä käyttäjille tiedon ylläpitoon jne.

Joskus ei ole muuta vaihtoehtoa kuin tehdä asiat nopeasti ja rumasti. Usein integraatioalusta on se paikka, jonne on helpointa nopeasti lisätä tietovarasto ja/tai kantataulut, etenkin kun kyse on Azure iPaaS:ista. Se ei ole nättiä, mutta niin se vain joskus on. Jos näin joudutaan menettelemään, on ehdottoman tärkeää, että asia dokumentoidaan perusteellisesti, ja varmistetaan että kaikki ovat tietoisia asiasta. Ja olisi tärkeää, että asia pyrittäisiin korjaamaan, kun siihen on tilaisuus. Liian usein väliaikaisista ratkaisuista tulee pysyviä, ja nopeasti käyttäjät oppivat toteamaan, että ”eihän tämä hyvin toimi, mutta näin me ollaan aina tehty.”

Vastuut mieleen niin ei mene pieleen

Harvemmin teknologiset rajoitukset ovat esteenä sille, etteikö jotain tietoa voisi säilyttää integraatioalustalla ja sysätä omistusvastuuta sille. Esteeksi muodostuvat selkeästi määritellyn omistajuuden ja vastuiden tärkeys. Huomioitavia ovat myös tekniset haasteet tiedon ylläpidossa: käyttöliittymät ja niihin liittyvä auktorisointi- ja validointilogiikka, jotta ei-tekniset käyttäjät voivat käsitellä integraatioalustan omistamaa tietoa.

*High five! Kuvituskuvatyypit iloitsevat kun kerrankin kaikki on tehty kunnolla ja data löytyy sieltä mistä pitäisikin.*

Määritelmällisesti integraatioalustan ei myöskään pitäisi olla paikka, joka synnyttää uutta liiketoiminnallista tietoa. Se voi kyllä luoda uusia objekteja ja tietueita ympäröiviin järjestelmiin, mutta vain sellaisen tiedon perusteella, joka tulee jostain toisesta järjestelmästä.

Joskus on kuitenkin luontevaa antaa omistajuus ja ylläpitovastuu tiedosta integraatioalustalle. Reunaehdot ovat tärkeitä tiedostaa: tieto ei saa olla monimutkaista, sen pitäisi olla sellaista, jolla on merkitystä nimenomaan tiedon siirrossa järjestelmien välillä (esim. korrellaatiotieto), eikä se ihannetilanteessa ole sellaisenaan käyttäjiä kiinnostavaa tietoa. Tiedon pitää myös olla luonnoltaan staattista tai automaattisesti muiden järjestelmien syötteiden perusteella syntyvää.

Tiedon omistajuus on olennaisen tärkeä konsepti modernissa organisaatiossa, jolla on lukuisia keskenään keskustelevia tietojärjestelmiä. Jos omistajuus ja vastuut eivät ole selkeitä, syntyy helposti tilanteita, joissa ei tiedetä missä jonkun tiedon alkuperäisarvo asuu, ja minne tietoa pitää muuttaa, jotta se siirtyy oikein muihin järjestelmiin. Tämä johtaa nopeasti datan laadun heikkenemiseen, ja ennen pitkää sekä vakaviin että noloihin virhetilanteisiin.

Tiedolla on oltava omistaja, ja tiedon on oltava käyttäjien löydettävissä. Liiketoiminnallisen tiedon kohdalla integraatioalusta on väärä loppusijoituspaikka. Kun nämä ohjenuorat pidetään mielessä, on helpompi lähestyä asiaa oikein, ja välttää epäselvän omistajuuden sekä huonosti määriteltyjen vastuiden sudenkuopat.