Suomeen on päätetty rakentaa kansallinen palveluväylä Viron X-Road-esimerkin ja lähdekoodin pohjalta. Aiheesta on puhuttu paljon, mutta paljon on jäänyt myös avoimia kysymyksiä.

Mikä ihmeen palveluväylä?

Mikä oikein on kansallinen palveluväylä? Onko kyseessä verkko, laite, sovellus vai jotain muuta? Kansallinen palveluväylä on joukko yhteisiä protokollamäärityksiä, joiden ansiosta palvelujen liittäminen toisiinsa on helpompaa. Palveluväylässä on sama idea kuin sähköpostissa: posti menee suoraan lähettäjältä vastaanottajalle, ilman keskitettyä palvelinta. Kaikki järjestelmät käyttävät yhteisiä teknologioita sähköpostin lähettämiseen ja vastaanottamiseen.

Palveluväylä ei siis ole joukko palvelimia, joiden kautta kyselyt kulkevat, erillinen tietoliikenneverkko tai edes käyttäjille näkyvä joukko palveluita, vaan yhteenliittymisen toteuttamista helpottava toimintatapa ja siihen liittyvä ohjelmisto. Palveluväylä on tapa luoda palveluja verkkoon ja käyttää niitä.

Miksi palveluväylä?

Palveluväylä ei itsellän ratkaise valtion IT-ongelmia. Jokainen vanha ohjelmisto on liitettävä palveluväylään erikseen. Kunkin ohjelmiston osalta pitää löytää, mitä sen tiedosta voi jakaa muille ja mitä muiden jakamaa tietoa kannattaisi käyttää ohjelmistossa hyväksi. Määrittely-, suunnittelu- ja toteutustyön hinta voi olla varsin kallis.

Useimmat valtion virastot ja muut julkishallinnon toimijat keskittyvät hankinnoissaan uushankintahintaan. IT-hankkeille ominaiset lisätyön kustannukset ja oikeudet hankkeessa tehtävään ohjelmistokoodiin eivät ole olleet kriittisen huomion kohteena. Näin toimien on jätetty jatkokehitystyön monopoli sopimuksellisellisesti sovelluksen alun perin myyneelle taholle. Osa toimittajista hinnoittelee sovellustensa palveluväylään liittämisen erittäin kalliiksi.

Palveluväylän suurimmat hyödyt muodostuvat niistä sovelluksista, joiden tekeminen on nykyisin käytännössä mahdotonta. Vuosikymmenien aikana kukin siilovirasto on jo luonut tärkeimmät niistä sovelluksista, jotka voi tehdä riippumatta  toisen viraston siilossa tuotetusta tiedosta. Tästä johtuen käyttäjä joutuu kertomaan kullekin virastolle osoitteensa ja muut tietonsa. Kun ei luoteta muihin, joudutaan samat tiedot kysymään yhä uudestaan.

Tietomassat, jotka on liitetty palveluväylään, on helppo liittää uusiin sovelluksiin. Jos Viron esimerkit toteutuvat myös Suomessa, on lopputuloksena tästä tilanne, jossa tietoja ei tarvitse enää syöttää erilaisiin julkishallinnon moolokin kitoihin. Sovellukset selvittävät toisiltaan lisätiedot, kunhan vain perustiedot on oikein syötetty.

Jos oikein hyvin käy, palveluväylän ansiosta osaan virastoista muodostuu modulaarisempi arkkitehtuuri, jossa viraston eri tehtävät ovat erillisissä, toistensa kanssa hyvin kommunikoivissa sovelluksissa.

Entä jo olemassaolevat sovellukset?

Ei tarvitse olla kovin kaksinen ennustaja arvatakseen, että suuri osa olemassaolevista sovelluksista ei helpolla taivu palveluväylään. Tähän on monia syitä:

1. Sovellus tekee jo sen mitä siltä odotettiin. Monilta sovelluksilta ei odotetakaan laajempaa toiminnalisuutta, eikä niiden liittämistä väylään edes harkita.
2. Sovellus on muutenkin vanhentunut. Ei kannata laajentaa jo korvauslistalla olevia sovelluksia juuri ennen kuin niistä päästään eroon.
3. Sovelluksen päivittäminen olisi liian kallista. Sovellukselle on löytynyt mielekäs liittymä palveluväylän kautta, mutta sovelluksen tehnyt toimittaja pyytää liian kovaa hintaa päivityksen suunnittelusta ja toteutuksesta.
4. Muna – kana -ongelma. Ne sovellukset, joihin olisi mukava liittyä eivät ole vielä valmiita, joten palveluväylähanke haudataan toistaiseksi, eikä siten tulla jakaneeksi omiakaan tietoja väylään.

Onko hanke siis turha? Kannattaako moista edes harkita? 

Yrityspuolen esimerkit palveluväylistä ovat kannustavia. Suuret yritykset, jotka saavat omat sovelluksensa liitettyä toisiinsa, ovat löytäneet yllättäviä etuja siilojen rikkomisesta. Toisissa yrityksissä talouden kokonaiskuva on osoittautunut aivan erilaiseksi kuin eräajona tehtävien vuosikoosteiden perusteella oltiin luultu. Amazonin ja Netflixin kaltaiset verkkopalvelut eivät olisi mahdollisia ilman satojen sovellusten saumatonta liimaamista toisiinsa.

Eikä pidä unohtaa, mitä kaikkea Viro on saanut kustannustehokkaasti aikaiseksi oman palveluväylänsä päälle.

Miten palveluväylästä tehdään menestys?

Palveluväylään avatun tiedon lähestyttävyys on kaiken a ja o. Pitää jakaa tietoa, jota muut tarvitsevat, muodossa, joka on luonteva. Esimerkiksi kansallinen tilasto hevosten määrästä voi olla tiedon jakajalle luonteva, mutta palvelun käyttäjä oli ehkä ajatellut kaupallisten hevostallien näyttämistä kartalla. Jos tarjolla on vain hyvin koostettua tietoa, ei sen päälle saa rakennettua palveluita.

Toinen selvä kokemus on, että rajapintoja tulee käytettyä paljon enemmän silloin, kun käyttö on riskitöntä ja onnistuu keneltä tahansa. Sen sijaan vaikeasti käytettävät rajapinnat jäävät helposti kuolleeksi kirjaimeksi.

Onneksi kansallinen palveluväylä ei ole ainutlaatuinen hanke. Programmable web -verkkopalvelun Six Ways to Make Your Developer Portal More Intuitive -artikkeli on erinomainen suositus niin Valtiovarainministeriölle kuin muillekin palveluväylään tietoja avaaville tahoille siitä, kuinka palveluväylästä ja siihen liitetystä palvelusta tehdään menestys.

Ohjeet lähelle tietoa

Kansallisen palveluväylän kehittäjätiedot on syytä kerätä helposti löytyviin paikkoihin. Joskus 90-luvulla luonteva tapa olisi ollut käyttää paljon työaikaa kansallisten portaalin ylläpitoon, nykyaikaisempaa olisi sopia kaikkien palveluväylän asiakkaiden käyttämä yhteinen nimeämiskäytäntö. Itse kannattaisin /api -tyyppisen hakemiston käyttöä kussakin tietoa jakavassa virastossa. Eli esimerkiksi vero.fi/api, vm.fi/api.

Tee kokeilu helpoksi

Hyvällä rajapinnalla on oltava selkeä dokumentaatio verkossa. Parhailla palveluilla on oma verkkosivunsa, jolla palvelua voi itse saman tien kokeilla. ”Onko Y-tunnuksessa väliviiva tämän kutsun kautta kutsuttuna?” ”Mikä on oikea formaatti osoitteelle?” Helppoja kysymyksiä, jos niitä voi kokeilla saman tien verkkopalvelun kautta.

Hyvät esimerkit rajapinnan käytöstä ovat todella tärkeitä. Esimerkki on sitä parempi, mitä lähempänä se on käyttäjän tarvetta. YTJ-järjestelmälle se voisi olla vaikkapa Y-tunnuksen haku yrityksen nimen perusteella.

Verkkoesimerkin lisäksi tarvitaan ohjelmanpätkiä, joilla näytetään kädestä pitäen, miten palvelua käytetään. Esimerkkikoodia tarvitaan monella eri ohjelmointikielellä. Parhaat kehittäjät osaavat lukea esimerkkejä yhdellä kielellä ja päätellä mitä toisessa ympäristössä tarvitaan, mutta muille tuo on turha kivi kengässä.

Kunnon kirjastot valmiiksi

Kaikilla kehittäjillä on samantyyppisiä tarpeita palveluväylän käytössä. Kirjastoksi kutsutaan ohjelmoinnissa valmista koodia, joka voidaan lliittää toiseen sovellukseen ja joka tarjoaa korkeamman abstraktion sitä kutsuvalle ohjelmalle.

Valtiovarainministeriön kannattaisi varmistaa, että yleisesti käytetyille ohjelmointikielille olisi vahva kirjasto, joiden kehitys on VM:n näpeissä – yksi kirjasto, jonka kautta kutsutaan kaikkia palveluväylän kautta saavutettavia palveuita.

Jos jokaiselle palveluväylän takaa saatavalle palvelulle tulee oma kirjastonsa, ei hankkeella ole saatu vähennettyä monimutkaisuutta nykyiseen verrattuna.

Monilla organisaatioilla on kiusaus kirjoittaa kirjasto vain heille tärkeimmälle ohjelmointikielelle. Kansallisesti kriittisessä hankkeessa tämä olisi vaarallista. Useimmille kielille muodostuisi omat harrastelijoiden kehittämät kirjastonsa, jotka voivat muodostua yhteensopivuus-, päivitettävyys-, lisensointi- tai jopa tietoturvariskeiksi laajalti käytettyinä.

Käytä tuttuja toteutustapoja

Parhaita rajapintoja ovat ne, jotka ovat täysin itsestäänselviä. Niissä on käytetty alan yleisiä käytäntöjä tutuilla tavoilla, ja niiden käyttöä ei tarvitse erikseen oppia. Luovuudelle ei ole tässä tilaa.

Neuvosta voi ottaa vaarin sekä kansallisen palveluväylän suunnittelutiimi Valtiovarainministeriössä että kunkin rajapinnan kehittäjät. Vaikka palvelu olisi helpompi tehdä käyttäen tavallisesta poikkeavia kirjasimia, kutsuja tai autentikointeja, palveluväylästä tulee suositumpi, kun kaikki pitäytyvät tutuissa tavoissa toteuttaa palvelut.

Mitä tutummalta palveluväylä tuntuu, sen parempi se on käytössä.