Integraation haasteet

Kahden järjestelmän liittäminen toisiinsa on suoraviivaista, mikäli molempien järjestelmien käsitys siirrettävästä tiedosta on samanlainen. Otetaan esimerkki:

• Järjestelmä A käsittelee maalaismaisemassa maa-alueiden rajaamiseen käytettyjä puisista elementeistä valmistettuja yhtenäisiä esterakennelmia
• Järjestelmä B käsittelee riukuaitoja.

Kuten nähdään, terminologia järjestelmien välillä on erilainen, mutta järjestelmien käsittelemä asia on täysin sama.

Haastavammaksi tilanne muuttuu, jos eri järjestelmät tarkastelevatkin samaa asiaa hieman eri näkökulmista:

• Järjestelmä X kuvaa säännöllisiä seiväsaitoja esittämällä jokaiselle aidalla tarkan paikan ja kertomalla, kuinka monta seivästä kyseisessä aidassa on.
• Järjestelmä Y käsittelee seipäitä, joilla jokaisella on tarkka paikka ja joista jokainen kuuluu johonkin aitaan.

Vaikka tietoa käsitellään eri näkökulmista ja eri tavoin, molemmista järjestelmistä on mahdollista saada tieto siitä, missä tarkalleen sijaitsee tietyn aidan pohjoispäästä katsoen kolmas seiväs.

Ensimmäisessä tapauksessa riittää, että tiedon terminologia käännetään toiseksi, mutta jälkimmäisen tapauksen kohdalla järjestelmien käsitemallien välille täytyy luoda yhteys. Suurissakaan käsitteellisissä poikkeavuuksissa tämä ei tietenkään ole mahdotonta, mutta joskus hyvin työlästä ja manuaalista asiantuntijatyötä.

Perinteisin tapa toteuttaa kahden järjestelmän keskinäinen integraatio on liittämällä järjestelmät suoraan toisiinsa yhteisen rajapinnan kautta. Tämä rajapinta saattaa olla toisen järjestelmän jo valmiiksi tarjoama tai kyseiseen tarpeeseen erikseen suunniteltu ja toteutettu. Yksisuuntaisen tiedonvaihdon tapauksessa, datan tuottaja käytännössä määrittää missä muodossa sitä tarjotaan eli millainen rajapinta on, minkä seurauksena vastaanottava järjestelmä on vastuussa käsitemalliin mukautumisesta ja siis myös työstä. Mikäli taas järjestelmät vaihtavat tietoa molempiin suuntiin, eikä kummallakaan järjestelmällä ole valmiina tarpeeseen soveltuvaa rajapintaa, tilanne on monitahoisempi. Rajapinnalla ei näissä tilanteissa välttämättä ole yksiselitteistä omistajaa, vaan molemmat osapuolet ovat siihen tasavertaisesti sitoutuneita.

Useampien järjestelmien muodostaman kokonaisuuden kohdalla myös alkuperäinen integraatio on monisyisempi prosessi. Useinkaan kaikki järjestelmät eivät yleensä liity kaikkiin muihin järjestelmiin, ja tiedonvaihto järjestelmien välillä on vaihtelevasti yksi- tai kaksisuuntainen. Edellä kuvatut järjestelmien väliset tiedon käsitteellisten erojen tuomat haasteet pätevät myös tällöin vähintäänkin samassa mittakaavassa, ja järjestelmäkokonaisuuden tiedon vaihdon mallista riippuen mahdollisesti vielä korostetummin.

Eri tavoin toteutettujen järjestelmäkokonaisuuksien kustannukset eivät juurikaan eroa toisistaan. Näin ollen järjestelmäkokonaisuuden hankintavaiheessa ei useinkaan asiakkaan kannalta vaikuta olevan juuri mitään väliä millä tavoin kokonaisintegraatio toteutuu, jolloin edellä kuvatut järjestelmästä-järjestelmään rajapinnat tuntuvat parhaalta vaihtoehdolta. Valinnan todelliset haasteet ja kustannukset tulevat ilmi kuitenkin vasta myöhemmin järjestelmien elinkaaren aikana, kun muutoksen tarve astuu esiin.

Muutos on vääjäämätön

Jokainen järjestelmäkokonaisuus ja -ympäristö on myös muuttuva ympäristö, elleivät kaikki toisiinsa yhteydessä olevat järjestelmät oteta ja poisteta käytöstä täysin yhdenaikaisesti. Mikäli järjestelmien toiminta on jatkuvaa, näin kuitenkaan harvoin tapahtuu. Toimintaympäristöstä riippuen järjestelmäkokonaisuuteen saattaa myöhemmin ilmentyä tarve integroida uusia järjestelmiä, korvata niitä toisilla tai kokonaan poistaa jokin järjestelmä. Integroitavan kokonaisuuden muutoksiin voidaan rajapintojen ja yhteyksien osalta varautua etukäteen aina tiettyyn pisteeseen asti. Ennakoimattomuus astuu kuitenkin mukaan jo yhdenkin järjestelmän elinkaaren venyessä suunniteltua pidemmäksi.

Lisäksi jo jokainen käytössä oleva järjestelmä itse muuttuu vääjäämättä: vain käytöstä poistettu järjestelmä ei enää päivity ja jalostu. Jo ohjelmistotekniikan kehitys uusine ja poistuvine teknologioineen usein pakottaa järjestelmän kehittäjän ”juoksemaan pysyäkseen paikalla”. Tämän ohella kannattaa huomioida, että niin pitkään kuin järjestelmää käyttävän toimijan oma toiminta kehittyy ja muuttuu, myös järjestelmän olisi kyettävä heijastelemaan samaa kehitystä. Kun kyse on järjestelmäkokonaisuudesta, toimintatapojen ja prosessien muutokset heijastuvat luonnollisesti vielä laajemmalta käyttäjäryhmältä ja toiminta-alueelta.

Järjestelmien ja välisten liitosten muuttuessa luontaisen kehityksensä mukaan, harmillisen usein syntyy tarve myös rajapintojen muuttamiseen. Tämä tarve ei toki ole vääjäämätön, mutta johtuu usein siitä, että rajapinta on alun perin suunniteltu enemmän järjestelmän kuin itse datan ehdoilla. Mikäli järjestelmää ei tietoisesti muuteta tekemään asioita, joihin sitä ei alun perin ole suunniteltu, järjestelmän tuottaman datan luonne säilyy järjestelmän koko elinkaaren varsin samana, vaikka järjestelmän sisäinen tiedon käsittelytapa muuttuisi ja jalostuisi merkittävästikin. Integraatioiden päivittämisen tarve voitaisiin siis suurelta osin välttää sillä, että järjestelmien väliset rajapinnat olisi alun perin suunniteltu datakeskeisesti.

• Palataksemme aikaisempaan esimerkkijärjestelmään A, olisi täysin mahdollista, että maalaismaisemien lisäksi järjestelmä voisi laajentua käsittelemään myös kaupunkiympäristöjä, ja lisäksi yksittäisten puisten elementtien sijaan käsittelytarkkuus voisi tarkentua koskemaan myös jokaista naulaa ja muuta kiinnitystarviketta. Näin ollen käsiteltävä abstraktio olisi venynyt useampaankin eri suuntaan alkuperäisestä, mutta hyvin suunnitellun rajapinnan avulla edelleen olisi mahdollista saada tieto siitä missä tarkalleen sijaitsee tietyn aidan pohjoispäästä katsoen kolmas seiväs.

Mikäli järjestelmien rajapintoja joudutaan muuttamaan, lisäämään tai poistamaan muutosten myötä, aiemmin toteutettu, järjestelmät suoraan yhdistävä rajapinta, osoittautuu yllättäen hintavaksi vaihtoehdoksi. Tässä vaiheessa asiakkaalla ja järjestelmän käyttäjällä ei käytännössä ole muuta vaihtoehtoa kuin teettää tarvittava muutostyö suoraan järjestelmään. Mikäli asiaa ei ole tarpeeksi ajoissa eli yleensä järjestelmää hankittaessa suunniteltu ja sovittu, järjestelmävalmistaja hyödyntää kysynnän ja tarjonnan lakien mukaista valtaansa veloittaa muutoksista juuri niin paljon kuin itse parhaaksi näkee.

Järjestelmänvalmistajien suurimmat voitot eivät yleensä tulekaan itse järjestelmän rakentamisesta, vaan heti sen jälkeen tai myöhemmin tehtävistä muutoksista. Mikäli eri tavoin toisiinsa liittyviä järjestelmiä on useampia, nousevat asiakkaan kustannukset entisestään rajapintamuutosten määrän kasvaessa eksponentiaalisesti suhteessa järjestelmien määrään. Riippumatta siitä ovatko perinteisesti toisiinsa suoraan liitettyjen järjestelmien rajapinnat vain toisen tai molempien järjestelmien vastuulla, asiakkaan näkökulmasta päädytään joka tapauksessa samaan lopputulokseen: hintavia muutoksia on pakko tehdä.

Kalliiden muutostöiden ohella lisää arvaamattomuutta järjestelmäintegraatioihin tuo mukaan hankalasti ennakoitavat lisätarpeet, joista keskustelemme artikkelisarjan seuraavassa osassa.

Combitech on kotimainen kumppani tietojärjestelmiin liittyvissä neuvotteluissa ja määrittelyssä ja on toiminut rajapintojen määrittelijänä useissa usean toimijan integrointiprojektissa.