Kansallinen palveluväylä rakennetaan seuraavan 10 vuoden aikana. Se tulee olemaan Valtionvarainministeriötä (VM) lainaten
Tiedonvälityskonsepti, jossa eri toimintaympäristöjen palveluiden tarvitsema tieto on saatavilla avoimien rajapintojen yli kaikille tietoa tarvitseville palveluille. Kukin palveluväylään liitetty järjestelmä hallitsee omia tietojaan sekä vastaa siitä, että muiden tarvitsemat tiedot ovat saatavissa välitysalustan kautta ottaen huomioon tietojen käyttöön liittyvät mahdolliset rajoitukset. (VM)
Käyttöönotto ensimmäiselle neljälle vuodelle (2014-2017) on rahoitettu 120 miljoonalla eurolla. Laskelmia projektin kokonaiskustannuksista ei vielä ole.
Palveluväylää on havainnollistettu VM:n asiakirjajulkaisussa alla olevan kuvan avulla. Siinä palveluväylä kuvataan pilvenä, jonka avulla tietovarannot ja palvelut yhdistyvät.
Toimiessaan palveluväylä on jokaisen it-ihmisen ”dream come true” ja siten ehdottomasti myös tavoittelemisen arvoinen. Moni on kuitenkin skeptinen: eihän näistä valtion it-projekteista mitään tule, budjetit paukkuvat ja aikataulut pettävät eikä loppukäyttäjiä kuunnella. Onneksi historian ei tarvitse toistaa itseään! Tässä 7 huomionarvoisia näkökulmaa ja vinkkejä palveluväylähankkeen toteuttajille:
Ensimmäinen ja ehkäpä samalla myös tärkein kysymys on mielestäni tämä: Mitä palveluväylä ja sen ympärille kiedottu hanke lopulta sisältävät? Olisi mainiota saada tästä lisätietoa. Strateginen ohjaus-yksikön päällikkö Riku Jylhäkangas Valtiovarainministeriöstä kertoi Tietoviikossa 21.12.2013 palveluväylän olevan 85-prosenttisesti käytössä ensi vuosikymmennellä. Mitä se tarkoittaa? Mitä palveluita palveluväylä minimissään kattaa? Mitä jää pois? Blogissaan Karri Lehtinen Solita Oy:stä rinnastaa palveluväylän käsitteenä integraatioalustaan. Onko tästä lopulta kyse? Tiedän, että hankkeesta löytyy esittelymateriaalia yllä olevan määrityksen ja kuvan tapaan, mutta ne eivät valitettavasti puhuttele suurinta osaa hankkeen sponsoreista eli veronmaksajista. Itse kuvaisin palvelut laatikoiden ja viivojen sijaan prosessien kautta. Hyvin toteutetulla viestinnällä voi saada paljon positiivista julkisuutta aikaan! Olisimmeko vieläpä niin hulluja, että osallistaisimme kansalaiset mukaan palveluiden ideointiin?
Palveluväylän yhteydessä puhutaan poliitikkoja myöten arkkitehtuurista. Jos kyse on kokonaisarkkitehtuurista, niin kuin mielestäni tässä yhteydessä olisi tarpeen, puhutaan siitä kuinka organisaation elementit – organisaatioyksiköt, ihmiset, toimintaprosessit, tiedot ja tietojärjestelmät – liittyvät toisiinsa ja toimivat kokonaisuutena (Tietohallintomalli). Kakku on siis iso ja siinä on monta kerrosta. Lisäksi on hyvä muistaa, että arkkitehtuuri muuttuu ja kehittyy koko ajan. Tietyt periaatteet voidaan määrittää tietysti kertaluontoisesti, mutta mikään yksittäinen projekti arkkitehtuurityö ei ole.
VM:n yllä olevassa kuvauksessa lukee: ”Kukin palveluväylään liitetty järjestelmä hallitsee omia tietojaan”. Mitä on oma tieto? Tässä tullaan master data managementin eli perustiedon hallinnan ytimeen. Perustietoa voidaan kaikessa yksinkertaisuudessaan ajatella olevan kaikki se tieto, joka on organisaatiossa suhteellisen pysyvää sekä käytössä monessa eri palvelussa. Esimerkiksi Suomen kansalaisten perustiedot (nimet, sotut jne.) olisivat tällä määritelmällä ehdottomasti perustietoon kuuluvien listalla. Kun jokainen palveluväylään liitetty järjestelmä hallitsee omia tietojaan, on perustiedon osalta muistettava määrittää, minkä järjestelmän ”omaa” kukin tieto on. Eikä tämäkään vielä riitä; tarvitaan myös työvälineet määritystyön jatkamiseksi. Kenen vastuulla on päättää tietojen omistajuuskysymyksistä, kun niitä väistämättä tulee? Palvelut kehittyvät ja niin myös niissä käytettävä tieto. Tiedon omistusasiat kuntoon siis!
Palveluväylän rakenteita luodessa tulee pohtia myös avoimuuden kysymyksiä: Mikä tieto on kaikkien vapaasti käytettävissä, mikä ei? Onko tiedon avoimuudella joissakin tapauksissa aikaikkuna (yksi taho saa tiedon tänään, toiselle tieto voidaan julkaista vasta ensi viikolla)? Millaiseksi käyttäjähallinta ja tietoturva rakentuvat? Onko Suomessa jokin keskitetty taho, joka ottaisi palveluväylässä liikkuvan tiedon osalta kantaa?
Kun palveluväylä on speksattu, voidaan uusia palveluja rakentaa sen päälle niin kuin Virossa ilmeisen menestyksekkäästi tehtiin. Mutta miten saamme Suomen vanhat palvelut mukaan? Asian on nostanut esille myös pitkän uran julkishallinnon it-hankkeiden parissa tehnyt, nykyinen Itä-Suomen yliopiston informaatio- ja tietoteknologiaoikeuden professori Tomi Voutilainen (Talouselämä, 30.11.2013). Kärjistäen voisi sanoa, että mitä vanhempi järjestelmä, sitä vanhempi logiikka ja sitä vähemmän vaihtoehtoja siirtää tietoa sisään tai ulos. Tulee äkkiä tilanne, jossa tekninen kaveri toteaa: ”Ei onnistu”. Mitkä ovat palvelut, jotka pitäisi palveluväylään minimissään saada ja onko näiden joukossa edellä mainittuja, hankalia tapauksia?
Lisäksi tulee jossakin vaiheessa varmasti ajankohtaiseksi keskustella datan migraatiosta. Suomeksi se käytännössä tarkoittaa sitä, että ennen kuin tietoja aletaan siirtää yhteiseen käyttöön, varmistetaan lähdejärjestelmissä tiedon laatu ja yhteensopivuus kyseisiä tietoja sillä hetkellä käyttävien kohteiden kanssa. Tämä on usein paljon työläämpi vaihe kuin mitä aluksi kuvitellaan. Lisäksi erittäin vähälle huomiolle jää monesti järjestelmissä käytettävän tiedon ”todellisen sisällön” selvittäminen. Kaksi järjestelmää voivat käyttää jollekin tiedolle samaa termiä, vaikka todellinen sisältö ja sitä myötä käyttötarkoituskin on aivan toinen. Ja toisin päin, sisällöltään sama asia voi saada eri nimeämismuotoja eri järjestelmissä. Jotta samaa tietoa voidaan yhteisesti käyttää, ei tällaisia terminologiaväärinymmärryksiä saisi ihan hirveästi olla. Erojen selvittämiseen tarvitaan henkilö, jolla on kokonaisvaltainen näkemys tai huomattava halu oppia organisaation (tässä tapauksessa Suomen!) toiminnasta. Olen itse ollut tässä roolissa ja voin vakuuttaa, että se on vaativaa jo paljon pienemmässäkin mittakaavassa.
Palveluväylän toteutuksessa on suunniteltava tiedonsiirtojen aikataulu sekä varauduttava niissä tai muissa asioissa esiintyviin vika- ja muutostilanteisiin. Mitä jos siirto ei onnistukaan, kuka saa siitä tiedon? Kuka korjaa tilanteen? Mitä jos joku järjestelmä muuttaa palveluväylään tarjolle antamiaan tietojaan? Miten muutoksesta tiedotetaan ja miten se vaikuttaa muihin järjestelmiin? Mitä jos kapasiteetin kanssa tulee ongelmia ja palveluiden käyttö hidastuu tai mitä jos palvelu peräti kaatuu? Vikatilanteiden selvittely varsinkin tiedonsiirtoon ja kapasiteettiin liittyvissä asioissa vaatii helposti usean eri tahon konsultointia. Kyseisissä tilanteissa on myös yleensä se huono puoli, että vian lähdettä ei heti tunnisteta, jolloin vian selvittämiseen menee aikaa myös niiltä tahoilta, joilla ei ole mitään tekemistä vian kanssa. Tässäkin asiassa auttaa, jos vastuut ja toimintaperiaatteet on sovittu etukäteen ”just in case”.
Viimeisimpänä mutta ei vähäisimpänä on toteamus roolien ja vastuiden tärkeydestä. Jo pelkästään tämän kirjoituksen sisällä on paljon vastuunjakoon liittyviä kysymyksiä. Kun ajatellaan palveluväylää ja sen arkkitehtuurin toteutumista, käyttäjähallintaa, tiedon omistajuuskysymyksia sekä päivittäistä ylläpitoa ja toisaalta kaikkia niitä tahoja, jotka palveluita voivat käyttää tai tarjota, on paletissa monta liikkuvaa osaa. Miten roolien ja vastuiden jako toteutetaan ilman että valtiolle tyypillinen byrokratia käy sietämättömäksi?
Palveluväylän toteuttaminen tulee olemaan mielenkiintoista, mutta samalla myös erittäin vaativaa. Toivon, että edellä mainitut esimerkit avaavat hieman tätä alussa mainitun havainnekuvan ”taikapilveä”, jonka kautta tieto kauniisti kulkee palvelulta toiselle. Onnistuakseen kansallinen palveluväylä vaatii todella paljon työtä ja oikeat ihmiset sitä tekemään. Seuraan innolla tuloksia!
Eeva Melama
Kirjoittaja on IT-projektipäällikkö yrityksessä Sofigate ja ite wiki oy:n co-founder.
Haluatko tietää lisää Bisnesteknologiamallista ja sen soveltamisesta käytännössä? Ota yhteyttä.