Avainsana-arkisto: palveluväylä

Kuinka kansallinen palveluväylä tulisi tehdä

Kansallinen palveluväylä on ehkä merkittävin IT-projekti tällä hetkellä Suomessa, Apottiakin tärkeämpi. Se on luonteeltaan ristiriitainen: toisaalta siinä pyritään uudistamaan koko se tapa, jolla julkisia tietojärjestelmiä Suomessa tehdään. Toisaalta siinä saatetaan vain kaataa 120 miljoonaa sille jolla on syvimmät taskut. Ratkaisut hankkeen ja ehkä koko suomalaisen IT-palvelualan suunnasta tehdään lähikuukausina.

Kun olen seuraillut projektia vuoden verran melko läheltä, koen että minun täytyy kertoa mistä siinä nähdäkseni on kyse, ja mitä sille pitäisi tehdä.

Optimistin tarina

Tekniikkana palveluväylä on itse asiassa suhteellisen yksinkertaista: sovittu toimintatapa ja sovitut rajapinnat siihen, miten toisiin järjestelmiin otetaan yhteyttä. Yhteinen tapa tunnistaa käyttäjät ja tapa selvittää järjestelmien osoitteet. Useimmilla isoilla yrityksillä on jonkinlainen palveluväylä, mutta se on vain osalla pakollista perusinfraa, vähän kuin serverihallit tai nettikaapelointi. Se ei sinänsä ole mitään kauhean ihmeellistä, vaikka toki tarpeellista.

Kansallinen palveluväylä ei ratkaise järjestelmien yhteentoimintaa eikä sinänsä tuo kovin dramaattisia säästöjä. Suurin osa palveluväylään kohdistetuista odotuksista onkin täysin ylimitoitettuja, jos ajatellaan pelkkää väylää.

Mutta kyse on enemmästä kuin vain tietojärjestelmästä. Palveluväylähankkeen – tai kansallinen palveluarkkitehtuurin, kuten sitä nyttemmin kutsutaan – tavoitteena on mullistaa tapa, jolla suomalaisia tietojärjestelmiä tehdään. Hallituksen rakennepoliittisessa ohjelmassa marraskuussa kirjattiin:

”Toteutetaan viipymättä kansallinen sähköinen palveluväylä ja sähköinen tunnistautuminen kustannustehokkaasti sekä Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen.”

Kremlologian parhaiden perinteiden mukaisesti ”viipymättä” ja ”kustannustehokkaasti” tarkoittavat tässä, että hanke tehdään ketterästi eikä perinteisenä julkishallinnon mammuttiprojektina. ”Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen” taas tarkoittaa avointa lähdekoodia. Voisihan sen sanoa paljon selvemminkin, mutta ei ole ollut tapana.

Rakennepaketin perustelumuistiossa (s. 71) asiaa selitetään lisää.

”Palveluväylä mahdollistaa tiedon välityksen organisaatioiden välillä yhdenmukaisesti sovituilla tavoilla (yhtenäiset tiedon kuvaukset, rajapintakuvaukset ja standardit) perustuen avoimiin rajapintoihin ja keskeisten osien osalta avoimeen lähdekoodiin. […]

Yhteentoimivuuden lisäksi Palveluarkkitehtuuri luo aiempaa paremmat liiketoimintaedellytykset yrityksille ja erityisesti PK-sektorille, sillä uusi toimintamalli ja avoimet rajapinnat parantavat niiden edellytyksiä osallistua julkisiin ICT-hankintoihin sekä mahdollisuuksia luoda uusia innovatiivisia palveluja julkista tietoa hyödyntäen.”

Tarkoitus on siis toteuttaa suuri julkinen softahanke kevyesti ja nopeasti ja siirtyä integraatioissa käytäntöön, jossa ne tehdään helposti ja toimivat sen sijaan, että niitä jarrutellaan ja rahastetaan niiden avulla toimittajaloukkua. Samalla avataan kaikki mahdollinen data ja rajapinnat ja siirrytään malliin, jossa strategiset julkiset tietojärjestelmät ovat avointa koodia, jotta niitä voidaan hyödyntää tehokkaammin.

Ja tämä toimivien tietojärjestelmien kulttuuri on tietenkin tarkoitus laajentaa koskemaan julkista sektoria yleisestikin – kuten on tehty Virossa. Rakennepaketissa ennakoidaan tästä saatavan kansantalouden tasolla puolen miljardin vuotuiset hyödyt. Siis 500 000 000 euroa joka vuosi.

Tässä vaiheessa varmaan ymmärrätte, miksi olen innoissani hankkeesta. Tässä yritetään tehdä monia niistä asioista, joista olen puhunut viime vuosina. Toisaalta tämä ei ole ainoa totuus hankkeesta, sillä on myös synkempi puoli.

Viron palveluväylän (X-Road) yleisarkkitehtuuri. Keskellä on väylä, joka yhdistää tietojärjestelmiä. Tämän tarkkuuden kaaviosta ei tietenkään näe, mitä oikeasti tehdään.

Viron palveluarkkitehtuurin yleisarkkitehtuuri. Keskellä on väylä (X-Road), joka yhdistää tietojärjestelmiä. Tämän tarkkuuden kaaviosta ei tietenkään näe, mitä oikeasti tehdään.

Pessimistin tarina

Taloussanomat kertoi tammikuussa, kuinka palveluarkkitehtuurihanke on ”120 miljoonan euron ontto kuori” ja rahojen käytölle ei ole olemassa suunnitelmaa. IT-hankkeiden tunnettu kriitikko, Professori Tomi Voutilainen taas epäilee, että siitä on tulossa teknologiavetoinen uudistus, jossa unohdetaan loppukäyttäjien tarpeet. Valitun teknologiankin järkevyyttä kyseenalaistetaan, eikä luvattujen puolen miljardin hyötyjen toteutumisesta ole vielä mitään näyttöä.

Vastaavia tietojärjestelmien yhteentoimivuuteen tähtääviä hankkeitahan on tehty Suomessa ennenkin, ks esim. Julkishallinnon perustietovarantojen rajapinnat (PERA)  tai Valtion yhteinen integraatiopalvelu (VIA). Molemmissa on varmasti tehty paljon sinänsä tarpeellista työtä, mutta kumpikaan ei ole ratkaissut yhteentoimivuuden ongelmia, vaan integraatio on edelleen ihan yhtä jähmeää.

Epäilyksille on siis perusteita. Isoissa julkisissa IT-hankkeissa yleensä päädytään tekemään raskas mammutti, myöhässä ja yli budjetin, tuottaen samalla toimittajaloukku, joka hidastaa kehitystä ja maksaa jatkossakin. Pitäisi olla vahvat perustelut, miksi tällä kertaa kävisi eri tavalla.

Koodin avoimuus hankkeessa on myös hiukan epäselvää. Sitran Mirjami Laitinen sanoi Sitran Real Time Economy-seminaarissa että palveluväylä ei ole avointa koodia, eikä jaettavissa muille. Että se on väärinkäsitys. Sittemmin tosin olen kuullut, että Laitisen esittämä käsitys olisi väärinkäsitys.

Internet-huhun mukaan koodi olisi avointa vain osittain, eikä kaikkea lähdekoodia saataisi. Vahvistusta ei ole, mutta näiden huhujen uskottavuutta lisää se, että Suomen ja Viron välisessä sopimuksessa ei mainita avoimuudesta tai ylipäänsä lähdekoodista mitään.

Kaiken tämän kruunaa, että hankkeessa on nyt onnistuttu käyttämään ensimmäinen vuosi saamatta aikaan paljoakaan. On toki kirjoitettu kokonaisarkkitehtuuri ja pidetty seminaareja. Kumpikaan ei varsinainen ketterän hankkeen avauspaukku. Kehitysympäristökin on tiettävästi pystytetty, mutta kenellekään ei anneta pääsyä siihen.

Palveluväylä näyttääkin tällä hetkellä avoimen koodin hankkeelta, jonka koodiin ei pääse käsiksi; ketterältä hankkeelta, jossa tehdään kaikkea paitsi koodataan ja kehittäjäyhteisönrakentamishankkeelta, jossa kehitysympäristöihin ei pääse kukaan käsiksi. Ja 120 miljoonaa olisi tarkoitus käyttää toistaiseksi tuntemattomaan kohteeseen.

mahdollisuudet-ja-uhat

Kumpi kuvaus tilanteesta sitten on totta? Molemmat, ja vain aika näyttää, kumpi perii voiton.

Todellisuudella on vielä tällä hetkellä edellytykset kummankin toteutumiselle. Palveluväylästä voi tulla se käännekohta, jossa jälkikäteen huomataan julkiset IT-hankkeiden kurssin kääntyneen kohti toimivaa ja järjellistä. Tai siitä voi tulla yksi pahimpia esimerkkejä siitä, miten IT:n varjolla vedetään rahat yksityiseen taskuun saamatta mitään toimivaa aikaiseksi. Lähikuukaudet ratkaisevat, kummasta tarinasta tulee totuus.

Tässä siis hahmotelma, mitä nähdäkseni pitää tehdä, jotta optimistin tarina voittaa.

Suuntaviivoja hankkeelle

Hankkeelle tarvitaan täsmälliset tavoitteet. Abstrakteista visioista pitää päästä yksi askel alaspäin konkreettisesti mitattavalle tasolle. Tällaisia täsmällisiä suuria tavoitteita näen hankkeella kolme:

  1. Jokainen tieto on yhdessä ja vain yhdessä paikassa (master data). Muut tiedon tarvitsijat hakevat sen tästä tunnetusta paikasta, mahdollisesti käyttäen välikopioita, mutta säilyttämättä koskaan omaa rekisteriä.
  2. Kansalaisille tarjotaan mahdollisuus nähdä omat tietonsa ja tarkistaa kuka niitä on katsellut. Tämä toteutetaan kaikelle väylään kytkettävälle tiedolle.
  3. Projektissa ei luoda uusia toimittajaloukkuja. Olemassa olevat toimittajaloukut tunnistetaan ja joko rajataan vaikutuksiltaan tai puretaan.

Ensimmäinen tavoite on se mitä julkishallinto saa: selkeämmän ja toimivamman arkkitehtuurin kaikelle tiedolle ja siten toiminnalleen. Ministerienkin visioiman reaaliaikaisen verotuksen tai kuntien tuottavuusharppauksen.

Toinen tavoite on se mitä kansalaiset saavat: vahvemman hallinnan omaan dataansa, ensimmäisen askeleen kohti digitaalista kansalaisuutta eikä vain kuluttajuutta.

Kolmas tavoite taas on se mitä alan yritykset saavat: uudenlaisen lähtökohdan siihen, miten tietojärjestelmiä ostetaan, askeleita kohti toimivaa ja tehokasta markkinataloutta.

Nämä tavoitteet on oikeastaan kirjattu muodossa tai toisessa hankkeen asiakirjoihin, tiivistin ne vaan konkreettisemmiksi. Nämä tavoitteet on syytä pitää kirkkaana mielessä kaikessa toiminnassa, sillä kaiken toiminnan tulee niitä edistää. Eikä ole poissuljettua, että tavoitteita voisi olla muutama lisääkin, nämä olivat vain ne mitä minä näen.

Konkreettisesti projekti on syytä rakentaa mahdollisimman ketteräksi ja avoimeksi.

Ketteryys tarkoittaa tässä etenkin nopeita konkreettisia käyttöönottoja ja pieniä osaprojekteja. Ei vuoden mittaista suunnitteluhanketta, vaan pieniä kokeiluhankkeita, ja niiden pohjalta seuraavia pienehköjä hankkeita.

Avoimuus taas tarkoittaa mukaan ottamista. Palveluväylään on tarkoitus integroida aluksi kymmeniä, sitten satoja tietojärjestelmiä ja myös sitä käyttäviä järjestelmiä on potentiaalisesti vähintään satoja. Kaiken tämän tekeminen keskusjohdetusti ja erilaisilla kahdenvälisillä sopimuksilla veisi vuoskymmenen. Siksi pitää tehdä kaikki mahdollinen, jotta kukin virasto, kunta tai yritys voi toteuttaa omia integraatioitaan mahdollisimman itsenäisesti ja helposti.

Sitä varten tarvitaan avoimet testi- ja kehitysjärjestelmät, joilla integraatioita voi kokeilla, vapaasti käytettäviä esimerkkikoodeja, ohjeita, jne. Vielä enemmän tarvitaan väylä käyttävien ja kehittävien ihmisten yhteydenpitoa.

Palveluväylän kehittämiselle ja käytön tueksi pitää rakentaa avoimia keskustelun ja yhteistyön alustoja. Siis esimerkiksi ottaa käyttöön Github, pitää säännöllisiä avoimia seminaareja, tehdä metadatan standardointi avoimesti ja julkisesti, kutsuen kaikki kiinnostuneet mukaan jne. Petri Aukia luonnostelee joitakin hyviä käytäntöjä blogauksessaan.

Kaikki palveluväylän koodi ja mahdollisimman suuri osa integrointikoodista on syytä julkaista netissä avoimella lähdekoodilla. Ei niinkään mistään periaatteellisesta syystä, vaan koska se helpottaa uusien tahojen mukaantuloa ja nopeuttaa uusia integrointeja, kun jo tehdystä työstä voi oppia. Ei ole ollut kerta eikä kaksi, kun avoimen koodin bugi on korjattu sitä käsittelevän palaverin aikana, tai sen myöhästyessä. Avoimuus myös estää palveluväylä-integraatiota muodostumasta taas uudeksi toimittajaloukuksi.

Ja koska rahaa on jonkin verran käytettävissä, projekti voi kannustaa sillä virastoja mukaan toimintaan – ja toimintatapoihin.

Yhteistyösopimus, joka Suomessa salattiin ja Virossa laitettiin nettiin. Tässä toimintatapojen maahantuonnissa on vielä vähän työtä tehtävänä...

Yhteistyösopimus, joka Suomessa salattiin ja Virossa laitettiin nettiin.
Tässä toimintatapojen maahantuonnissa on vielä vähän työtä tehtävänä.

Yllä kuvaamani tavoitteet ja toimintatavat tarkoittavat vallankumousta siinä, miten tietojärjestelmähankkeita Suomessa tehdään. Ne ovat totta kai paras tapa saada palveluväylä nopeasti toimintaan ja käyttöön. Mutta softa on tässä viime kädessä sivuroolissa, tärkeintä onnistumisen kannalta on muuttaa toimintatapoja ja ajattelutapoja.

Ja siksi tärkein yksittäinen ratkaisu on, millaisia ihmisiä hanketta vetämään palkataan. Sellaisen tuloksen saa, millaiset tekijät palkkaa.

Ensinnäkin, pitää palkata osaavia.

Pätevyyttä on monenlaista, ja montaa erilaista osaamista tässä tarvitaankin: poliitista, teknistä, byrokratiaa, muutosjohtamista… Ei tule olemaan helppo homma. Mutta on helppoa keksiä yksi minimiehto, jonka onnistuminen edellyttää: hankkeeseen tarvitaan ihmisiä, jotka ymmärtävät miten ohjelmistoja tehdään.

Vielä konkreettisemmin: jotta hanke voisi onnistua pitää palkata ihmisiä, jotka ovat joskus tehneet työkseen ohjelmointia, mieluiten vielä muualla kuin julkisen sektorin hovihankkijoilla. Kaikkien ei tarvitse vanhoja koodereita, mutta puolet porukasta olisi syytä olla.

Hankkeessa on tarkoitus levittää toimintatapoja, joilla softaprojektit voivat onnistua (sen sijaan että muuttuvat tahmeiksi mammuteiksi). Ja näiden tapojen levittämisessä auttaa paljon, jos oikeasti ymmärtää miten ja miksi ne toimivat.

Toisekseen, pitää palkata muutosta haluavia.

Tehtäessä muutoshanketta avain on totuttujen toimintatapojen muuttamisessa. Tarkoitus on tehdä asiat eri tavalla kuin ennen, ja siksi olisi hyvä palkata ihmisiä, jotka haluavat tehdä asiat paremmin kuin ennen. Haluavat sitä niin paljon, että ovat valmiita näkemään vähän vaivaakin, jotta hanke onnistuisi. Jos näin ei tehdä, hanke tuskin voi onnistua.

Kolmannekseen, pitää palkata ihmisiä, jotka uskaltavat rikkoa totuttuja toimintatapoja.

Kun tarkoitus on muuttaa toimintatavat, halun lisäksi tarvitaan valmiutta rikkoa vakiintuneet käytännöt. Vallankumousta ei tehdä pelkästään kabineteissa pullaa syömällä.

Näillä eväin lähtisin itse liikkeelle.

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


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ä? 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.

Vanhanaikaisia sovelluksia, kukin omassa siilossaan

Vanhanaikaisia sovelluksia, kukin omassa siilossaan

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ä.

10