Britanniassa on määritelty tarkat ohjeet, joita kaikkien valtion nettipalveluhankkeiden tulee noudattaa. Ajatus on, että kun kansalaisille tehdään palveluita, heillä on oikeus odottaa jotain perustason toimivuutta ja viranomaisilla velvollisuus se tarjota. Myös USA:ssa on käytössä vastaavat ohjeet.
Suomessa sen sijaan ei toistaiseksi ole kattavia ohjeistuksia julkisten digitaalisten palveluiden suunnitteluun. Koska ainakin Helsingissä sellaisia suunnitellaan, tässä lähtökohdaksi suomennos brittien ohjeistuksesta.
Digital by Default
Tunne käyttäjäsi. Selvitä keitä palvelun käyttäjät ovat ja perehdy heidän tarpeisiinsa. Selvitä, miten tämän pitäisi näkyä digitaalisten palveluiden suunnittelussa.
Perusta pysyvä, monialainen ryhmä, joka vastaa palvelun suunnittelusta, rakentamisesta ja käytöstä. Ryhmän johtajalla tulee olla riittävä asiantuntemus sekä valtuudet päättää palvelun toimintatavasta.
Selvitä, mitä käyttäjien tietoja palvelu tallentaa tai käsittelee ja mitä turvallisuusvaatimuksia tai muita juridisia vaatimuksia ja riskejä tähän liittyy, esim. henkilörekisterisäädöksistä johtuen. Konsultoi tarvittaessa asiantuntijoita.
Arvioi riskit yksityisyydelle ja varmista että henkilötietojen käsittelyä koskevat vaatimukset täyttyvät.
Arvioi, mitä työkaluja ja järjestelmiä tarvitaan palvelun kehittämiseen, ylläpitoon sekä toiminnan mittaamiseen, ja kuinka nämä työkalut ja järjestelmät kannattaa hankkia.
Rakenna palvelu käyttäen ketteriä, iteratiivisia ja käyttäjäkeskeisiä menetelmiä.
Laadi palvelulle laatukriteerit ja -mittarit (kohdat 21–24), joiden mukaan sen toimivuutta arvioidaan.
Analysoi prototyyppipalvelun menestystä. Suunnittele uudet ominaisuudet ja muu jatkokehitys käyttäjiltä saadun palautteen perusteella.
Luo palvelu, joka on niin yksinkertainen ja intuitiivinen, ettei ensikertalainenkaan tarvitse apua sen käyttämisessä.
Tarjoa avustettua sähköistä tukea niille, jotka tarvitsevat apua voidakseen käyttää palvelua
Integroi digitaalinen palvelu ja mahdolliset ei-digitaaliset osat yhdeksi yhtenäiseksi palvelukokemukseksi.
Tee palvelun käyttäjäkokemuksesta, -tyylistä ja ohjeistuksesta yhteensopivia muun julkisen palvelutarjonnan kanssa.
Varmista että sinulla on riittävä kapasiteetti ja tekniset edellytykset palvelun jatkuvaan päivittämiseen ja parantamiseen.
Tee kaikki syntyvä lähdekoodi mahdollisimman uudelleenkäytettäväksi ja julkaise se avoimella lisenssillä (tai perustele vakuuttavasti, miksi jotakin osaa koodista ei voida julkaista).
Käytä avoimia standardeja ja valtion yhteisiä palveluja silloin kun niitä on saatavilla.
Testaa palvelua ympäristössä, joka on identtinen lopullisen käyttöympäristön kanssa. Testaa sitä kaikilla yleisillä selaimilla ja laitteilla. Käytä testitunnuksia ja edustavaa otosta käyttäjistä.
Käytä analytiikkatyökaluja palvelun toiminnan seuraamiseen.
Rakenna palvelua jatkuvasti iteroiden, ja varmista että koko organisaatiolla on siihen tarvittavat edellytykset.
Luo suunnitelma myös käyttöönoton jälkeen jatkuvalle käyttäjätutkimukselle ja käytettävyystestaukselle ja kannusta käyttäjiä antamaan palautetta.
Aseta käyttäjätyytyväisyyden tavoitetaso kaikille palvelun osille erikseen ja seuraa tuloksia systemaattisesti.
Aseta tavoitetaso tehtävien onnistumisasteelle ja seuraa tuloksia systemaattisesti.
Tee (faktojen tukema) suunnitelma saavuttaaksesi matalat yksikkökustannukset ja seuraa tuloksia systemaattisesti.
Tee (faktojen tukema) suunnitelma, jotta mahdollisimman suuri osa kohderyhmästä ottaisi palvelun käyttöön, ja seuraa tuloksia systemaattisesti.
Tee suunnitelmat sen varalle, että palvelu otetaan väliaikaisesti pois käytöstä. Kuinka käyttäjiä palvellaan?
Testaa palvelua kokonaisuudessaan siitä vastaavan ministerin kanssa.
Ohjeet ovat lyhyitä ja selkeitä. Ne eivät määrittele täsmälleen mitä pitää tehdä, mutta ammattitaitoinen verkkopalvelun suunnittelija osaa soveltaa niitä hetken mietittyään googlattuaan omaan tilanteeseensa. Ne ovat sitä, mistä nykyään käytetään sanaa lean.
Helsingin kaupunginhallitus hyväksyi juuri uuden tietotekniikkaohjelman, jossa linjataan avoimen koodin käyttö:
”Kaupungin toimeksiannosta kehitettävä uusi ohjelmistokoodi julkaistaan avoimen lähdekoodin lisenssillä, ellei ole perusteltua syytä muuhun.”
Tämä tarkoittaa, että jatkossa kun kaupunki hankkii uuden tietojärjestelmän, eikä valmiita tuotteita ole ostettavissa, projektissa tehtävä koodi julkaistaan avoimella lisenssillä. Ei enää toimittajaloukkua, vaan sen sijaan järjestelmien laatu parantunee ja hinta laskee pikkuhiljaa. Kyse ei ole ideologisesta periaatteesta, vaan käytännöllisestä tietojärjestelmien hallinnasta. Päätös olikin yksimielinen sekä kaupunginhallituksessa että sen IT-jaostossa.
Tämä ei tarkoita, että kaupunki siirtyisi Linuxiin tai Open Officeen. Valmiita tuotteita hankittaessa valitaan ensi sijassa parasta, ja se voi olla myös Windows tai Office365.
Samassa paperissa linjataan myös, että ennen hankintaa on valittava ja perusteltava hankinnassa käytettävä strategia: ollaanko hankkimassa valmista tuotetta vai teettämässä uutta järjestelmää. Ja kaupunki aloittaa myös koulutusprojektin, jossa IT-hankintoja tekevät virkamiehet koulutetaan siihen, miten hankinnat saadaan onnistumaan.
Ensimmäisenä merkkinä uudesta toimintatavasta, tarjouskilpailu avoimen kehityksen puitesopimukseen on jo käynnissä.
Avoimen koodin kirjaus ei ole ohjelmassa sattumalta, vaan se on vuosien työn tulos.
Tammikuussa 2012 ehdotin edelliseen tietotekniikkaohjelmaan lisäystä:
”Avoin lähdekoodi. Kaupungin tilaama ohjelmistokehitys julkaistaan EU:n avoimen lähdekoodin lisenssillä (EUPL), ellei tästä ole erityisistä syistä tarpeen poiketa”
Silloin ei ollut oikein mitään tapaa käydä poliittista keskustelua aiheesta, eikä virkakunnassa myöskään oikein ymmärretty, mitä edes tarkoitin. Itselläni ei myöskään ollut mitään asemaa, joka pakottaisi minua kuuntelemaan. Olin vain yhden lautakunnan jäsen.
Nyt kolme vuotta myöhemmin molemmat ovat osa uutta ohjelmaa (tosin lisenssiä ei määritellä). Sillä tavoin politiikka toimi. Ensin ehdotetaan, sitten keskustellaan. Usein se vie aikaa, ja joskus se vaatii uusien keskustelukerhojen perustamista. Kun vaan jaksaa keskustella ja perustella asiat, kysyä kysymyksiä ja antaa vastauksia, niin lopulta voi käydä niin, että ehdottamasi muutos hyväksytään yksimielisesti.
Matkalla oli aika monta askelta. Käytiin kuntavaalit 2012 joissa tulin valituksi. Strategianeuvotteluissa olin vihreiden neuvottelijana ja esitimme IT-jaoston perustamista. Syksyllä 2013 se perustettiin, ja minusta tuli sen puheenjohtaja.
Jaosto käsitteli ohjelman valmistelua moneen kertaan, ja vaatimuksestamme se oli myös kahdesti kommentoitavana julkisesti. Kommentoinnit tosin osuivat juhannukseen ja uuteen vuoteen, mutta jostain se on avoimuuskin aloitettava. Ensi kerralle voisimme ehkä ottaa oppia Espoosta.
Helsinki on nyt ottanut merkittävän askeleen kohti toimivampia tietojärjestelmiä. Seuraavaksi sama periaate pitää ottaa käyttöön koko maassa. Intia ehti jo meitä ennen, samaten Britannia ja USA.
Piraattinuorten puheenjohtaja Ahto Apajalahti haukkuu blogissaan tekijänoikeuslain viimeisintä muutosta ja yrittää sälyttää sen Vihreiden syyksi. Kyse on lähinnä mustamaalaamisesta vaalien alla, ns. FUD-taktiikasta (fear, uncertainty and doubts). Mutta juuri siksi kirjoitukseen onkin syytä vastata.
Olen koettanut perehtyä kyseiseen lakimuutokseen ja sen syntyhistoriaan. Tässä on selvinnyt seuraavat asiat
Lakimuutos on huono
Se ei ole ollenkaan niin merkittävä kuin Apajalahti antaa ymmärtää
Se meni kaikilta netin vapaudesta kiinnostuneilta vähän ohi silmien
Juuri siksi eduskuntaan tarvitaan ihmisiä, joita netin vapaus kiinnostaa
1) lakimuutos on tältä osin huono
Tekijänoikeuslain muutoksessa eduskunnassa eniten huomiota kiinnitettiin alkuperäisten tekijöiden ja teosten välittäjien välisiin kohtuuttomiin sopimusehtoihin. Tältä osin lakimuutos on hyvä, ja myös Vihreät on tukenut tätä muutosta. Effikin lausunnossaan kiitti sitä.
Huonoja sen sijaan ovat estomääräystä koskeva muutos (tekijänoikeslaki 60c-60f) ja nettitallennuspalveluita koskeva muutos (tekijänoikeuslaki 25-26) . Keskityn tässä ensinmainittuun.
Tekijänoikeuslain 60-pykälien muutoksen merkittävin kohta on uusi estomääräys (60e), jolla voidaan kieltää operaattoreita välittämästä liikennettä osoitteeseen, josta levitetään tekijänoikeuksia rikkovaa materiaalia, vaikka osoitteen haltija ja siis vastuullinen taho on tuntematon. Tähän Apajalahtikin osoittaa kritiikkinsä kärjen.
Muutos on ongelmallinen sananvapauden kannalta, koska se mahdollistaa jostain tietystä osoitteesta tulevan liikenteen sulkemisen kategorisesti ja ilman osoitettua rikosta. Hallituksen esityksessä pohditaan sananvapauden ja oikeuksienloukkauksen suhdetta asiassa:
”Perustelujen mukaan pääsyn estoa tai vaikeuttamista koskevat ankarat edellytykset. Kyseessä tulee olla verkkosivu, joka sisältää laajassa mitassa aineistoa, joka ilmiselvästi loukkaa tekijänoikeuksia. Tuomioistuimen on lisäksi tehtävä laaja arviointi eri intressien välillä. Määräys voidaan antaa vain, jos sitä tukevat näkökohdat painavat enemmän kuin sitä vastaan puhuvat näkökohdat. Tuomioistuimen tulee erityisesti kiinnittää huomiota sananvapauteen ja informaation suojaan.”
Itse olisin halunnut perustuslakivaliokunnan käsittelevän lakimuutoksen, joka tällä tavoin lippaa selvästi sananvapauden rajoja. Eduskunta kuitenkin katsoi toisin, ja vain sivistysvaliokunta sekä lakivaliokunta käsittelivät asian. Tästä lisää kohdassa 4.
2) muutos ei ole niin suuri
Käytännössä estomääräys ei ole kovin suuri muutos nykytilaan. Jo 2011 käräjäoikeus määräsi Elisan estämään pääsyn Piratebayn palvelimille nykyään voimassa olevan lain 60c pykälän perusteella. Hovioikeus piti päätöksen voimassa ja korkein oikeus ei antanut valituslupaa Elisalle. Tuomioistuimet ovat siis voineet määrätä sulkemaan liikenteen tuntemattoman tahon hallitsemalle sivulle tähänkin asti. Uudessa laissa esto on vain vuodeksi kerrallaan, kun tähän asti se on määrätty käytännössä ikuiseksi. Samalla blokattavaksi haettavat IP-osoitteet on yksilöitävä jo hakemuksessa, eikä vasta käsittelyssä.
Toisin kun Apajalahti väittää, estomääräystä ei voisi antaa vain tekijänoikeusjärjestön näkemyksen perusteella, vaan se vaatii tuomioistuimen perusteellista harkintaa ja painavat syyt. Hallituksen esityksen perusteluissa sanotaan:
”On myös tärkeää huomata, että tuomioistuin antaisi määräyksen muulle kuin vaatimuksen vastapuolelle, eli välittäjälle tilanteessa, jossa ei vielä varmuudella tiedetä, että loukkaus on tapahtunut. Tämän vuoksi näyttökynnys määräyksen saamiseksi olisi tavanomaista korkeammalla. Kun kanne väitettyä loukkaajaa vastaan on nostettu, ratkaistaan asia lopullisesti varsinaisessa oikeudenkäynnissä. Tuntematonta loukkaajaa vastaan annettavan määräyksen osalta kynnys olisi vieläkin korkeammalla.”
Menettely ei myöskään ole olennaisesti kevyempi kuin tähänastinen menettely, vaan aivan vastaava oikeuskäsittely. Ja hallituksen esityksen mukaan siis vaatii vielä painavammat perusteet. Jos väitetty oikeuksien loukkaaja on tunnistettavissa ja haastettavissa oikeuteen, uusi laki myös edellyttää näin toimimaan. Estomääräys voidaan antaa vain, jos loukkaaja ei ole tunnistettavissa.
Toistan vielä, että tämä laki on mielestäni sananvapauden kannalta ongelmallinen. Ongelmallinen se oli kuitenkin jo ennen tätä lakimuutosta, eikä muutos ole kovin suuri. Apajalahden esittämä kuva laista ja sen muutoksesta ei vastaa todellisuutta.
3) Asia meni vähän kaikilta ohi, niin myös minulta
Tekijänoikeuslakia käsiteltiin eduskunnassa samassa hässäkässä kymmenien muiden viime hetken lakiesitysten kanssa, joista osa oli erittäin merkittäviä ja sai paljon huomiota, mm. Sote-uudistus, metropolilaki, opintoaikojen rajaus… Ei ole hyvää lainsäädäntötyötä käsitellä lakiesityksiä kiireessä, mutta niin luopuva eduskunta nyt joka tapauksessa teki. Kansanedustajien oli käytännössä pakko keskittyä asioihin, joiden kanssa erityisesti tekevät työtä tai joista heihin otetaan yhteyttä.
Vihreissä internetin säätelykysymyksiä on tällä kaudella pitänyt esillä erityisesti Oras Tynkkynen. Asian käsittelyn aikana häneen oli asiasta ottanut yhteyttä yhteensä 0 kansalaista.
Minäkin olisin voinut sanoa tästä Orakselle, tai Ville Niinistölle joka istui sivistysvaliokunnassa. Mutta en sanonut, koska en huomannut koko asiaa. Effi toimitti lakivaliokunnalle hyvän lausunnon ja vpj Tapani tarvainen puhui myös sivistysvaliokunnalle. Lausunnon työstön Effin aktivistilistalla osallistui kaksi ihmistä. Asia meni varmaan ohi silmien aika monelta muultakin.
Tähän lienee kaksi syytä: 1) asiaa käsiteltiin juuri Ville Oksasen äkillisen menehtymisen jälkeen, mikä ymmärrettävästi vähensi Effin mahdollisuuksia käsitellä asiaa ja 2) muutos ei ollut tärkeimpiä esillä olevia asioita. Huomattavasti suurempaa huomiota saivat muun muassa esitykset verkkovalvonnasta ja rahankeräyslain uudistus. Ne ovat minustakin selvästi merkittävämpiä periaatteellisia kysymyksiä kuin tämä muutos.
Eduskunnassa muutos hyväksyttiin yksimielisesti. Suurin osa kansanedustajista varmasti kannatti kohtuullisuuspykälien muutosta, ja nämä kaksi lähinnä lakia selkiyttävinä nähtyä muutosta menivät siinä sivussa. Tämä yksimielisyys asettaa myös hieman erikoiseen valoon Apajalahden vihjailut kuinka juuri Vihreät olisivat päätöksestä vastuussa
4) Eduskuntaan tarvitaan ihmisiä, joita netin vapaus kiinnostaa
Kaikki kansanedustajat eivät voi olla kaikkien asioiden asiantuntijoita. Käytännössä puolueiden kannat muotoutuvat sitä kautta, että kussakin puolueessa juuri tietystä asiasta kiinnostuneet ovat sen suhteen aktiivisia. Siksi jokaiseen puolueeseen pitäisi saada ihmisiä, jotka ymmärtävät netin toimintaa ja ovat kiinnostuneita siitä miten nettiä säädellään (esim. net neutrality, estolistat, verkkourkinta jne).
Tällä hetkelle eduskunnassa tämä osaaminen on todella ohutta.
2011 eduskuntavaaleissa ilkeästi sanottiin Piraattien suurimmaksi saavutukseksi tiputtaa Jyrki Kasvi. En aivan jaa tätä käsitystä, mutta Vihreitä mustamaalattiin silloin paljon, ja merkittävältä osin aiheetta. Apajalahden blogikirjoitus näyttäisi olevan samaa jatkumoa, jossa puolitotuuksia ja vihjeitä viljelemällä yritetään saada Vihreät näyttämään internettiä vihaavilta idiooteilta.
Vaalien alla toki poliittinen viestintä kiihtyy, mutta on silti valitettavaa, jos Piraatit keskittyvät estämään teknisesti sivistyneempien ehdokkaiden läpimenoa muissa puolueissa. Toivottavasti näin ei ole yleisemmin käymässä.
Jyrki Kasvi on jälleen ehdolla Uudellamaalla. Minä olen ehdolla Helsingissä. Muita hyviä ehdokkaita löytyy muun muassa Tieteen ja teknologian vihreiden vaalilehdestä.
Tieteen ja teknologian vihreät julkaisi vaalilehden – viitenumeron. Suosittelen tutustumaan. Tässä maistiaisiksi pääkirjoitus jonka lehteen kirjoitin, koko lehti löytyy Issuusta.
Viitenumero 2015
Politiikan pitäisi perustua tutkittuun tietoon. Tutkimus ei sanele poliittisia päätöksiä, mutta se kertoo, millaisia vaikutuksia erilaisilla ratkaisuilla luultavasti on. Tämä tieto pitää huomioida päätöksenteossa.
Käsissäsi on Viitenumero, Tieteen ja teknologian vihreiden vaalilehti. Esittelemme 33 ehdokasta, joilla on kykyä ja halua muuttaa Suomea paremmaksi. Kirjoittajina on ehdokkaiden lisäksi eri alojen asiantuntijoita, jotka haluavat antaa panoksensa parempien argumenttien tuomiseksi poliittiseen keskusteluun.
Poliittinen päätöksenteko koskee aina tulevaisuutta. Sitä, miten maailman halutaan jatkossa toimivan. Politiikassa tarvitaan laajaa ymmärrystä nykyisyydestä ja historiasta, mutta myös kykyä kuvitella, mitä on edessäpäin. Siksi Viitenumerossa kirjoitetaan älykkäästä sähköverkosta, robottiautoista, energiantuotannosta ja tietoyhteiskunnasta – unohtamatta myöskään ydinvoimateknologian uusimpia näkymiä ja geenimuuntelun turvallisuuskysymyksiä.
Tiede ei ole vain laboratorioita ja isoja koneita. Erityisesti sosiaalipolitiikka tarvitsee tuekseen tutkimusta yhteiskunnasta ja sen toimintamekanismeista. Siksi Viitenumerossa käsitellään myös köyhyyden vaikutuksia, työttömyyttä ja ihmisen ikääntymistä.
Jotta politiikkaa voidaan tehdä tutkittuun tietoon perustuen, tieteeltä tarvitaan avoimuutta. Datat ja analyysit pitää julkaista. Politiikassa tulkitaan todellisuutta aina eri tavoin, ja tulkintojen erot ovat politiikan ydintä. Siksi tieteellisen tiedon pitää olla avointa tulkittavaksi jokaisen puolueen näkökulmasta.
Emme tarvitse yhtäkään kansanedustajaa, jolla on varmaa tietoa siitä, miten asiat pitää hoitaa, ja joka pitää loppuun saakka kiinni jokaisesta mielipiteestään. Tarvitsemme poliitikkoja, jotka osaavat ottaa uuden tiedon huomioon maailman muuttuessa. Ihmisiä, jotka osaavat toimia samojen perusarvojen pohjalta myös tilanteissa, joita emme vielä osaa kuvitellakaan.
Helpottaaksemme valintaa tarjoamme teille 33 sellaista ehdokasta. Suosittelen tutustumaan.
Otso Kivekäs
Tieteen ja teknologian vihreiden puheenjohtaja
Kansanedustajaehdokas, Helsinki
Tietojärjestelmähankinnat menevät Suomessa yleensä pieleen. Etenkin julkisella sektorilla. Koska olen vuosien varrella useaankertaankertonut miten tietojärjestelmiä ei pidä ostaa ja millaisia virheitä hankinnassa on tehty, koen velvollisuudekseni myös kertoa, miten niitä sitten pitää hankkia.
Tietojärjestelmiä voi julkisella sektorilla ostaa onnistuneesti kolmella tavalla:
Ostamalla palveluna (pilvestä)
Ostamalla valmiin standardituotteen
Teettämällä järjestelmän avoimena
Jos julkiset järjestelmät hankittaisiin näillä tavoin, ongelmia olisi paljon vähemmän.
Perinteisesti tietojärjestelmiä on ostettu niin, että tilaava organisaatio määrittelee (konsultin avulla) mitä tarvitsee, lähettää tästä tarjouspyynnön tarjoajille ja valitsee parhaalta kuulostavan järjestelmän halvimmalla hinnalla. Sen jälkeen seuraa pitkä ja hyvin kallis projekti, jonka myöhästyneen toimituksen jälkeen asiakkaalla on huono järjestelmä, jonka korjailusta ja jatkokehittelystä maksetaan seuraavat kymmenen vuotta, kunnes se päätetään heittää romukoppaan ja palataan toistamaan sama virhe. Useimmat julkiset tietojärjestelmähankinnat on tehty näin.
Se ei ole toimiva tapa. Mutta sen mukaisesti toimitaan, ellei nimenomaisesti pidetä huolta että toimitaan toisin.
Se siitä, takaisin niihin toimiviin tapoihin.
1. Osta palveluna
Ensinnäkin, et oikeasti halua ohjelmistoa. Haluat palvelun, jonka ohjelmisto sinulle tuottaa. Se ohjelmisto on vain tapa tehdä se.
Haluatko extranetin? Ota vaikka Basecamp. Tarvitsetko CRM:ää? Miten olisi SugarCRM? Dokumentinhallintaa? Riittäisikö Google Drive?
Pilvipalvelut eli valmiit online-ratkaisut eivät yleensä ole täsmälleen sitä, mitä sinulla oli mielessä. Mutta vaiva ja kustannus on ehkä tuhannesosa täsmälleen oikeanlaisen järjestelmän hankkimisesta. Kannattaa selvittää, onko sopivia online-tuotteita tarjolla, ja vakavasti miettiä, voitaisiinko toiminta sovittaa toimimaan niillä. Digitalisaation [6] suuret hyödyt tulevat töissä, joissa se yli satakertaistaa tehokkuuden, ja niitä kannattaa hiukan etsiäkin.
Pilvipalvelut sopivat käytettäviksi etenkin tukitoimissa, joissa 1) muillakin lienee suunnilleen samanlaisia tarpeita, ja 2) täsmälleen oikeanlainen toimintatapa ei ole keskeiwtä, vaan voidaan sopeutua siihen mitä palvelu tarjoaa. Koska muuttaahan palvelua ei voi.
Siis esimerkiksi tavanomaisen taloushallinnan tai varastoseurannan ohjelman voi yleensä hankkia palveluna, koska aika lailla samanlaisia tarpeita on muillakin. Laissa tarkkaan määrätyn palvelun toteutusta sen sijaan yleensä ei voi.
Pilvipalveluunkin voi jäädä jonkinlaiseen toimittajaloukkuun. Jos rakennat prosessisi toimimaan nimenomaan vaikkapa Google Driven kanssa, siirtymä siitä toiseen tarjoajaan on ylimääräinen vaiva. Tai palvelu saatetaan lopettaa lyhyelläkin varoitusajalla. Mutta koska kyse oli toiminnoista, joissa asiakkaalla on joustovaraa prosesseissa, tämä ei ole yleensä kovin suuri ongelma.
2. Osta standardituote
Jos jotain ratkaisua ei saa palveluna netistä, sen saattaa silti saada valmiina tuotteena. Tai jos lainsäädäntö ei mahdollista nettipalvelun käyttöä, niin tietojärjestelmän voisi ehkä kuitenkin hankkia valmiina omiin tiloihin.
Tämä on noin kymmenen kertaa työläämpää kuin nettipalvelu, ja ehkä kymmenen tai sata kertaa kalliimpaa. Mutta muutoin kyse on samasta asiasta, ja se siis joskus kannattaa.
Valmis tuote on sellainen, joka on olemassa ja käyttöön otettavissa sinä päivänä kun ostat sen. ”Tuote”, josta näet powerpointin ja toimitus luvataan ensi vuonna, ei ole valmis tuote, vaan myyntipuhe, jonka jäljiltä olet toimittajaloukussa. Se on se perinteinen tapa, jota piti välttää. Jos tuote ei sovi sellaisenaan käyttöön, et ole ostamassa tuotetta. Tai ainakaan pelkästään tuotetta, katso seuraava kohta.
MS Sharepoint on valmis tuote ja Photoshop on valmis tuote. Yksikään Suomessa myyty potilastietojärjestelmä ei ole valmis tuote.
3. Teetä avointa
Jos markkinoilta ei kerta kaikkiaan löydy sellaista järjestelmää jota tarvitset, on se sitten jonkun pakko koodata. Tähän liittyy aina suurin toimittajaloukun riski.
Kun järjestelmä kehitetään yhtä asiakasta varten, asiakkaan siis täytyy maksaa sen kehityskulut. Ja kaikkea koodia täytyy jatkokehittää, mikään järjestelmä ei koskaan ole lopullisesti valmis. Sen jatkokehityksenkin maksaa sama asiakas (sinä), ja siinä vaiheessa jos olet loukussa, sinulla on vain yksi tarjoaja, ja maksat mitä pyydetään.
Toimittajaloukku vältetään sillä, että kaikki koodi on avointa. Tämä on perusperiaate, josta on hyvin harvoin syytä poiketa. Ja yleensä poikettaessa tehdään virhe. Kun koodi on avointa, toimittajaa voidaan vaihtaa tarvittaessa, eikä toimittajaloukkua synny, tai ainakin siitä pääsee pois helpommin.
Koodin avoimuus on lähes välttämätön, mutta ei riittävä ehto kehityshankkeen onnistumiselle. Tässä muutama muu periaate, joita yleensä on syytä noudattaa
Ketterä kehitys, esim Scrum-mallilla.
Kaikki koodi heti avoimena julkiseen repositoryyn (esim: Github, Bitbucket). Siis joka päivä sitä tahtia kun se syntyy
Hyvin dokumentoidut julkiset rajapinnat (usein REST)
Standardien käyttö
Modernit kehitystyökalut
Valmiiden komponenttien käyttö
Prototyypit ja käyttöliittymä edellä työskentely
Vaiheittainen julkaisu ja pilotointi koko ajan käyttäjien kanssa
Modulaarinen arkkitehtuuri ja hankinta osakokonaisuuksina
Kilpailutuksessa arvioidaan osaamista ja toteutustapaa, ei tuotetta
Nämä eri käytännöt tukevat toisiaan, ja ovat tavallaan yhtenäinen paketti modernin ohjelmistokehityksen menetelmiä. Lisää ohjeita käytännön hankintaan muun muassa tässä ja tässä.
Jos järjestelmää pitääkin koodata, se ei missään tapauksessa tarkoita, että kaikkea pitäisi koodata tyhjästä. Päin vastoin, suurin osa siitä mitä tarvitaan, voi löytyä valmiina, ja koodataan vain se mitä ei löydy.
Projektin pohjana toimiva alusta voi olla avointa koodia tai suljettu tuote. Yleensä sen kannattaa olla avointa koodia, koska suljetun tuotteen kanssa on helpompi mokata ja päätyä taas toimittajaloukkuun.
Jos halutaan ostaa valmis järjestelmä ja kehittää sen päälle, siihen on syytä suhtautua kahtena eri hankintana: 1) hankitaan perusjärjestelmä, 2) kilpailutetaan erikseen sen päälle uuden laajennoksen kehitys. Perusjärjestelmän pitää siis tarjota riittävät avoimet rajapinnat, että muutkin kuin sen perusjärjestelmän tekijä tai kumppanit voivat aidosti kilpailla kehitysprojektista. Itse asiassa perusjärjestelmän tekijätaho olisi syytä sulkea ulos toisen projektin tarjoajien joukosta. Samaan tapaan ylläpito ja käyttötuki pitää pystyä kilpailuttamaan erikseen.
Jos järjestelmä ei tähän taivu, sen varaan ei voi jatkokehittää mitään jäämättä toimittajaloukkuun. Täytyy valita jokin muu perusjärjestelmä. Avoimen perusjärjestelmän kanssa tällaisia riskejä ei ole, siksi niitä yleensä kannattaa suosia.
Näillä samoilla periaatteilla järjestelmän voi kasata myös omana työnä, jos palkkalistoilla on siihen pystyviä ihmisiä. Työn määrä ei välttämättä ole kovinkaan suuri, mikäli lähes kaikki tarvittava löytyy valmiina avoimen lähdekoodin ratkaisuina. Jos tarve kehittää tietojärjestelmiä omaan käyttöön on jatkuva, ei välttämättä ole huono idea rakentaa jonkinlainen kyvykkyys siihen omaan organisaatioon.
Suuri osa avoimen koodin kehityksen hyödyistä saavutetaan periaatteessa silläkin, että asiakkaalla on omistusoikeus koodiin. Käytännössä se ei kuitenkaan riitä. Avoimeen koodiin kilpailevat yritykset voivat aidosti tehdä tarjouksia jatkokehityksestä, kun taas koodiin, jonka ne periaatteessa saavat, mutta jota ne eivät näe, on vaikea tarjota. Lisäksi toteuttajayritys pystyy sumuttamaan piilossa olevan koodin kanssa paljon paremmin, miten asiat tehdään. Ja olen nähnyt enemmän kuin yhden hankkeen, jossa asiakas ei lopulta ole ihan varma, mitä oikeuksia koodiin itse asiassa onkaan. Selkeän avoimuuden kanssa näitä ongelmia ei tule
Pakko valita
Hankintatapa on strateginen valinta, joka on pakko tehdä heti hankinnan alussa, ennen kun tarjouspyyntöjä lähdetään edes luonnostelemaan. Epävarmempi ostaja saattaa ajatella, että eikö kannattaisi antaa tarjoajien ratkaista? Että tehdään väljä tarjouspyyntö ja katsotaan millainen ratkaisu voittaa. Valitettavasti se on kuitenkin mahdotonta.
Tämä liittyy ennen kaikkea hankintalakiin, joka vaatii määrittelemään tarkasti hankinnan kohteen ja valintakriteerit. Jokainen hankintatapa vaatii oman, erilaisen tarjouspyyntönsä. Kilpailuun, jonka voi voittaa pilvipalvelulla, ei ole järkeä tarjota koodausprojektia, ja koodausprojektia pyydettäessä pilvipalvelu ei täytä ehtoja.
Jos tarjouksen kriteerit määritellään niin väljiksi, että mikä vaan tapa käy, silloin käy myös tapa, jossa ostaja sidotaan toimittajaloukkuun ja se jää tarjoajan vangiksi. Ja silloin tämä tapa tulee myös valituksi. Toimittaja hyötyy aina asiakkaan sitomisesta toimittajaloukkuun, siitä kannattaa jopa maksaa alihintaisen tarjouksen muodossa. Siksi toimittaja, jonka aie on lypsää asiakasta myöhemmin, voi aina tehdä halvimman tarjouksen. Tarjouspyynnön täytyy nimenomaisesti estää toimittajaloukku.
Julkisessa tietojärjestelmähankinnassa yksi tärkeimpiä tehtäviä on välttää joutuminen toimittajaloukkuun, ainakaan yhtään pahemmin kuin on pakko. Nämä kolme strategiaa ovat suhteellisen tunnettuja keinoja minimoida toimittajaloukku. Ne eivät ole omaa keksintöäni, vaan valtaamassa alaa Suomenkin julkisella sektorilla.
Avoimen ja suljetun lähdekoodin eroja IT-projektissa
Jälkikirjoitus luotetuista kumppaneista
Yksityisillä yrityksillä on käytössään vielä neljäskin hyvä vaihtoehto: kumppanuus luotetun toimittajan kanssa, jonka tuotetta käytetään.
Jos yrityksen oma toimiala ei ole koodaaminen, sen ei yleensä kannata lähteä teettämään koodia itselleen, vaan antaa pätevämpien hoitaa kehitys. Ja vaikka itsekin koodattaisiiin, erikoispalikat tekee tehokkaammin joku joka on niihin erikoistunut.
Kumppanuus toimii niin, että etsitään johonkin tiettyyn asiaan keskittyneistä firmoista se, jonka tyypit tuntuvat luotettavimmilta ja joiden kanssa tulee hyvin juttuun (ja joilla on näyttöä että osaavat työnsä). Jatkossa sitten ostetaan heidän tuotteensa ja pysytään siinä. Ja usein annetaan myyjän kertoa, että mitä oikeastaan kannattaisi ostaa, koska hehän alan parhaiten tuntevat. Ja jos ei yhteistyö suju tai jos alkaa tuntua että myyjä vedättää, lempataan myyjä niskaperseotteella pihalle ja haetaan seuraavaksi paras kilpailija tilalle. Luottamusta joko on tai ei ole.
Julkisella sektorilla tätä ei pidä tehdä. Se menee yleensä pieleen. Jos sidot itsesi yhteen tuotteeseen, sidot itsesi loukkuun.
Hankintalaki kieltää suosimasta yhtä toimittajaa. Julkinen toimija ei siis voi laillisesti luvata luottotoimittajalle, että he saavat jatkossakin projektit. Eikä valita luottotoimittajaansa, jos joku muu onkin tarjouskilpailun kriteereillä parempi.
Tätä voi tietenkin kiertää, ja hyvin yleisesti kierretäänkin. Ehkä kolmannes julkisista softahankinnoista on viritetty tietyn toimittajan voitettaviksi rakentamalla ehtoja, jotka ovat yhdelle toimittajalle mahdollisia ja muille vaikeita tai jopa mahdottomia. Se on tietenkin laitonta, mutta yleistä.
Jos kumppania onnistuukin suosimaan, se ei kuitenkaan riitä. Kun kumppani muuttuu hyvästä rengistä huonoksi vedättäjäksi, siitä pitäisi vielä päästä eroon. Luotettavan kumppanin pitää luotettavana se, että kumppani tietää tulevan bisneksen olevan kiinni luottamuksesta. Jos luottokumppani alkaa vedättää, se on entinen luottokumppani, ja menettää tämän asiakkaan lisäksi muitakin, joille sana leviää.
Hankintalaki kieltää tämänkin. Tarjoajia pitää kohdella tasapuolisesti, eikä huono maine tai yleinen epäluotettavuus ole pätevä peruste syrjinnälle (ja aiemman kokemuksenkin pohjalta se on vaikeaa). Tässä kohti lain kiertäminen on vaikeampaa. Talossa pitkään toiminut ja asiat tunteva kumppani, jonka tuote on tähän asti ollut paras, osaa kyllä tarvittavat asiat, ja tuntee tarpeeksi sisältöä viedäkseen markkinaoikeuteen selvästi itseään syrjivät tarjouskilpailut.
Julkisessa hankinnassa voi siis vähän laittomasti valita itselleen hovitoimittajan, jolta ostaa jatkossakin. Mutta mitään tapaa saada hovitoimittaja toimittamaan laatua jatkossakin ei ole. Tarjoavat yritykset tietenkin yrittävät rakentaa tällaisen ”luottamussuhteen”, mutta siihen suhteeseen ei valitettavasti voi luottaa.
Se, ettei tätä sääntöä ymmärretä, on suurimpia syitä siihen miksi julkiset tietojärjestelmät ovat niin huonoja.
Helsingin kaupungin tietotekniikkaohjelman luonnos on kommentoitavana Otakantaa.fi:ssä tänään viimeistä päivää. Tämä näkökulma ei näy siinä vielä riittävästi.
”Kuinka tietoyhteiskunta korjataan” on kirja siitä, mikä on tietoyhteiskunnassamme vialla, ja mitä sille pitäisi tehdä.
Kirjaprojektini on nyt rahoitettavissa Mesenaatti.me:ssä.Palvelusta voi ostaa etukäteen kirjan ja paljon muutakin. Rahat käytetään kirjan painamiseen, tai jos jää yli, vaalikampanjointiin.
Ensimmäisen 2 vuorokauden aikana se on kerännyt jo 1500 euroa, mikä tekee siitä menestyneimmän vaaliprojektin palvelun historiassa.Kiitos kaikille tähän mennessä osallistuneille 46 ihmiselle! Mukaan kuitenkin mahtuu vielä hyvin. Painokulut maksavat selvästi enemmän, vaalikampanjasta puhumattakaan.
90-luvulla Suomi oli tietotekniikan edelläkävijä, jossa oli eniten kännyköitä ja nettiliittymiä ja palveluita digitalisoitiin ensimmäisenä maailmassa. Tätä ihmettä tultiin ihastelemaan eri puolilta maailmaa.
2010-luvun Suomi on tietoyhteiskuntana parhaimmillaankin keskisarjaa. Tahtoa vielä on, mutta infrastruktuuri on rikki, ja hajoaa yhä lisää.
Blogissani olen etsinyt syitä taantumaan ja korjausratkaisuja jo vuosien ajan. Mutta koska maailmaa ei muuteta vain Internettiin kirjoittamalla, olen asettunut ehdolle eduskuntavaaleissa, ja julkaisen blogini pohjalta pamfletin “Kuinka tietoyhteiskunta korjataan”.
150 sivuun aion mahduttaa tietojärjestelmähankkeet, niiden ongelmat ja ratkaisut, tietotekniikan opetuksen, tekijänoikeuden tulevaisuus ja nettiajan maailmanpolitiikan muutokset.
Nämä ovat teemoja, joilla on yhä suurempi vaikutus Suomen politiikkaan, mutta joita ymmärretään eduskunnassa vielä valitettavan vähän. Haluan parantaa tilannetta paitsi pyrkimällä itse eduskuntaan, myös lisäämällä tietoisuutta tietoyhteiskunnan kysymyksistä poliitikkojen ja äänestäjien parissa. Loppujen lopuksi saamme sellaisen eduskunnan kuin ansaitsemme.
Tähän projektiin toivon tukeasi. Tilaa Mesenaatin kautta kirja ennakkoon paperilla tai sähköisenä, ja tilaa samalla lippu julkaisubileisiin, kirjan esittely tai vaikka luento sen aihepiiristä. Tarjolla on myös Jyrki Kasvin tulossa oleva kirja “Sensuurin vieno viettelys” samaan pakettiin. Kirja ilmestyy osana vaalikampanjaani ja kaikki kirjan rahoitus on samalla siis myös vaalikampanjani rahoitusta.
Helsingissä 4.1.2014
Otso Kivekäs
Kirja sisältää osiot:
– Tietojärjestelmät ja niiden hankinta
– Avoin data, avoin koodi ja avoin hallinto
– Koulut ja tietotekniikka
– Internetin maailmanpolitikka
– Immateriaaliset omistusoikeudet
Helsingin kaupunki teki nettisivu-uudistuksen kesällä. Ensimmäiset osat päivitettiin toukokuussa, viimeiset syyskuussa. Uudet sivut sinänsä ovat paremmat kuin aiemmat, mutta samalla rikottiin kaikki vanhat linkit ja sabotoitiin googlen toiminta. Seurauksena kaupungin sivuilta ei löytänyt enää googlella yhtään mitään.
Tämä on aika iso ongelma, koska perinteisesti google on ollut ainoa tapa löytää kaupungin sivuilta yhtään mitään. Navigaation kautta useimpia asioita ei voi löytää kuin ehkä ammattilainen: sivut ovat siihen ihan liian isot.
Kaupungin uudet sivut ovat oikeasti hyvät. Nätin näköiset ja navigaatio on aiempaa parempi. Mutta se ei paljon auta, jos mitään ei löydä ja linkit ovat rikki.
20.8., kun kesäloman jälkeen aloin taas tarvita kaupungin sivuja enemmän, hermostuin siihen että googlella ei edelleenkään löytänyt mitään. Selvästikään kyse ei ollut vain sivujen muutoksen hetkellisestä häiriöstä. Debuggasin wiresharkilla miksi goole ei toimi ja lähetin kaupungille palautetta:
”Hei,
Google-haut kaupungin sivuilta ovat olleet rikki sivu-uudistuksesta alkaen. Ongelma ei ole Googlen, vaan kaupungin sivujen, ja se olisi syytä korjata pikimmiten. Google tarjoaa rikkinäisiä linkkejä, koska kaupungin sivut vastaavat myös vääriin linkkeihin 200 OK, eikä 404 Not Found kuten kuuluisi. Jos tämä korjataan, google siivoaa virheelliset linkit muutamassa päivässä.
Google-haku on käytännössä toimivin tapa hakea mitään kaupungin sivuilta. Navigaatio pitkin hierarkiaa on vaikeaa, eikä juuri kukaan tee sitä. Tällä hetkellä kaupungin sivujen tärkein käyttötapa on siis rikki, ollut jo kuukausia.”
Virhe on melko lailla käsittämätön, eikä sitä olisi pitänyt ikinä sattua. 200 OK palauttaminen virhetilanteessa on HTTP-standardin vastaista, eikä siihen ole mitään järkevää perustelua. Sivu-uudistusta tekevien olisi pitänyt ymmärtää sen olevan ongelma, tai vähintäänkin minkäänlaista vastuuta tuntevan toteuttajatahon olisi tullut selittää asiakkaalle, että noin ei pidä toimia.
Ylipäänsä vanhoja linkkejä ei suositusten mukaan pitäisi rikkoa koskaan, jos sama sisältö vaan edelleen on jossain olemassa. Mutta ainakaan google-hakuja ei pitäisi tarkoituksella sabotoida.
Muutamien mailien vaihdon jälkeen 22.9. sain viestin:
Olemme muuttaneet käytäntöämme siten, että jatkossa ohjaamme kävijät viraston vanhoilta sivuilta uusien sivujen etusivulle noin kuukauden ajan. Tämän jälkeen vanhojen sivujen osoitteet palauttavat virhekoodin 404, jolloin Google karsii sivut hakutuloksistaan. Pääsivun osalta tästä ohjauksesta on jo luovuttu.
Sivujen uusiminen on kaupungin kannalta suurin viestinnällinen hanke vuosiin. Teemme koko sivuston uusiksi ulkoasun, teknisen toteutuksen ja rakenteen osalta, koska tämä on ainoa keino saada sivut palvelulähtöiseksi ja responsiivisiksi. Tässä yhteydessä on valitettavasti mahdotonta säilyttää vanhoja linkkejä muuttumattomina, koska osa sivuista katoaa kokonaan rakennemuutoksessa.
Nyt lokakuussa google jo toimiikin kaupungin sivuilta hakiessa. Vajaat viisi kuukautta rikkoutumisen jälkeen ja kaksi kuukautta sen jälkeen kun selitin, miten ongelma korjataan.
Vanhat pöytäkirjalinkit sen sijaan eivät toimi edelleenkään. Sekin on iso periaatteellinen ongelma.
Vielä taannoin pöytäkirjoja pidettiin verkossa vain pari vuotta, koska kuntaliiton ohje suosittaa, ettei henkilötietoja pidetä esillä. Se oli todella hankalaa, kun esimerkiksi katusuunnitelmaa hyväksyttäessä liikennesuunnitelma johon se perustui oli jo piilotettu (ei, liikennesuunnitelmissa ei ole kaupunkilaisten henkilötietoja, mutta poistettiin silti).
Sitten kaupunki teetti kalliilla systeemin tägätä henkilötiedot niin, että netissä voidaan pitää versioita ilman niitä, ja vuodesta 2011 alkaen vanhat pöytäkirjat pysyvät verkossa. Paitsi nyt niitä ei sitten löydä, kun kaikki vanhat linkit on rikottu. Kuten jo todettu, linkkejä ei kuuluisi sivu-uudistuksissa rikkoa. Eikä varsinkaan silloin, kun kyse on demokraattisen päätöksenteon julkisuudesta. Esimerkiksi luottamushenkilöidenblogit linkittävät yleensä pöytäkirjoihin, joista päätöksistä kiinnostunut lukija löytä yksityiskohdat. Samaten myös kaupungin projektiblogit.
Tämäkin ongelma on sangen helppo korjata. State of the art -ratkaisu olisi laittaa koko sivuston eteen Nginx-proxy, joka tekee tarvittavat URL-muutokset. Kaupungin omistamalla Lasipalatsin mediakeskuksella esimerkiksi lienee kykyä tehdä tuo parin päivän varotusajalla.
Esimerkiksi yleisten töiden lautakunnan osalta ohjaussääntö näyttäisi nginxissä suunnilleen tältä:
Näitä sääntöjä tarvitaan yksi per lautakunta, eli parikymmentä samanlaista. Tekisin tuon itse varmaan parissa tunnissa, koska en ole ikinä konffannut WTE:tä. Ammattilaisen pitäisi selvitä nopeammin.
Käytännössä kommunikaatioon pitää varata lisäaikaa, koska sivut on jaettu parinkymmenen eri viraston vastuulle, ja niillä lienee parikymmentä eri vastaavaa. Jonkun pitää siis ensin kirjoittaa ohje, ja välittää se joka paikkaan. Vaikea siihen silti on kovin montaa työpäivää käyttää.
Maanantaina tietotekniikkajaoston kokouksessa esitinkin aiheesta kysymyksen:
”Pyydän kaupunginjohtajaa selvittämään, miten pääsi käymään niin, että kaupungin nettisivujen uudistushanke esti kaupungin sivujen toimivuuden googlella pitkäksi aikaa ja hukkasi kaikki vanhat päätökset sekä mitä ollaan tekemässä, jotta linkit tehtyihin päätöksiin saadaan taas toimimaan.”
Odotan tähän vastausta joulukuun ensimmäisen päivän kokouksessa. Toivottavasti vastaus on, että ongelma on korjattu.
Kirjoittaja on kaupunginhallituksen tietotekniikkajaoston puheenjohtaja eikä ole koskaan tehnyt nettisivuja työkseen. Kaikki tekstissä esitelty konffaus on opeteltu tätä tekstiä varten.
Peruskoulussa kuulin olevani nörtti. En kerran, enkä kaksi, vaan aika monta kertaa. Ja sitähän minä olin. Koodasin Commondore 64:llä, hahmottelin 3d-mallinnuksen algoritmeja, suunnittelin parin kaverin kanssa omia roolipelejä ja yhteiskuntajärjestelmiä.
Vaikka koulu oli ehkä suvaitsevammasta päästä mitä löytyy, niin eihän sitä ihan normaalina pidetty. En ollut mitenkään kovin suosittu ja minulla oli vain pari varsinaista kaveria – toisia samankaltaisia.
Lukion kävin koulussa, jossa melkein kaikki olivat tavalla tai toisella nörttejä. Pääsin tottumaan siihen, että se on ihan normaalia. Ja yliopistolla sama jatkui tietojenkäsittelytieteessä. Töihin menin nörttifirmaan, joissa kaikilla oli aina läppärit mukana ja niissä Linux. Ja juodaan kolaa; kyllähän te nyt tiedätte, sellaista mitä nörtit tekevät.
Teinhän minä muutakin kuin nörttäilin. Muun muassa organisoin kansainvälisiä mielenosoituksia Prahassa 2000. Mutta sielläkin olin se, joka hommaa paikallisen nettiliittymän ja istuu puun alla lähettämässä kuvia ja raportteja mielenosoituksista ja mellakoista Suomeen nopeammin kuin STT. Siis porukan nörtti.
Kaiken aikaa vietin aikani seurassa, jossa yllättävät kiinnostuksenkohteet, sosiaaliset omituisuudet ja sekava pukeutuminen olivat ihan ok ja kaikkien hyväksymää. Kaikki olivat nörttejä, tai vähintäänkin tottuneet nörttien seuraan.
Kuva kaupunkisuunnittelunörttien Tukholman matkalta.
Ja sillä aikaa maailma muuttui. Asiat joita olin aina tehnyt, muuttuivatkin normaaliksi. Siitä, mikä kävi joskus haukkumasanasta, tuli lähes kehu.
Joskus oli harvinaista viettää päivänsä tietokoneella. Nykyään ammatit, jotka eivät koostu tietokoneella istumisesta alkavat olla poikkeus. Virkamies istuu koneella, lääkäri naputtaa näppäimistöä ja maanviljelijä naksuttaa padiaan. Ja töiden jälkeen jokainen heistä jatkaa samaa kotonaan.
Telkkarissa nörtit olivat aikoinaan koomisia sivuosahahmoja, mutta nykyään jo pääosassa. [a2] Ja parhaassa tapauksessa jopa realistisesti kuvattuja.
Maaseudulla ei vielä ole koodikerhoja lapsille, mutta Helsingissä niitä on jo useita. Ja kohta lapsille opetettaneen koodausta koulussa (juu niin minun aikanakin – nörteille, jotka osasivat sitä paremmin kuin matikanopettaja).
Viimeksi minua kutsuttiin päin naamaa nörtiksi keskiviikkona. Eikä se todellakaan ollut haukkumasana.
Mitä tästä tarinastani voidaan oppia? Auttavatko tällaiset kuvat ja tarinat jotenkin kiusattuja, vähentävätkö ne kiusaamista? No tuskin. Mutta on niillä myös yksi tärkeä viesti: asiat muuttuvat paremmiksi.
Minä olen pysynyt nörttinä kaikki nämä vuodet, ja minua saa sellaiseksi kutsua. Mutta maailma on muuttunut paremmaksi. Ja muuttuu yhä vielä vaan, kun sen eteen teemme töitä.
Julkisissa järjestelmähankinnoissa on herätty vaatimaan avoimia rajapintoja, mikä on erittäin hyvä. Avoimet rajapinnat ovat modulaarisen arkkitehtuurin perusasioita, ja yksi keskeinen keino toimittajaloukun välttämisessä.
Mutta aika usein jää epäselväksi, mitä avoimilla rajapinnoilla tarkalleen ottaen tarkoitetaan. Ja siksi niiden hyödytkin saattavat jäädä saamatta. Siksi luonnostelimme Poikolan Antin kanssa määritelmää avoimelle rajapinnalle. Määritelmä on kommentoitavissa tässä, ja keskustelua aiheesta myös täällä ja jatkokehitetty ehdotus täällä. Tarkoitus on tämän pohjalta rakentaa virallinen määritelmä, jota esim Open Knowledge Finland ja Avointen tietojärjestelmien keskus COSS voisivat käyttää. Ja useammassakin kunnassa on myös moista määritelmää kaivattu.
Joten, tässä siis ehdotus kommentoitavaksi.
Spiidnesuolun saari kokonaisheijastuu veden ja ilman välisestä rajapinnasta Bugoynesin edustalla. Kuvan rajapinta ei liity asiaan. Kuva Hannu Oskala
Mikä on avoin rajapinta?
Tämän dokumentin tavoitteena on määritellä selkeästi, mikä on avoin rajapinta. Täsmällistä määrittelyä tarvitaan esimerkiksi julkisissa järjestelmähankinnoissa, joissa usein vaaditaan avoimia rajapintoja. Ilman määritelmää järjestelmätoimittaja saattaa väittää, että järjestelmässä on avoin rajapinta, mutta käytännössä rajapinnan dokumentaation saa vain maksamalla tai se on saatavilla vain muutamille valituille alihankkijoille.
Perusajatuksena rajapinta on avoin, jos kuka vain voi kehittää sitä käyttävän (uuden) sovelluksen. Tähän ei riitä pelkkä dokumentaatio, vaan itse rajapintaan pitää päästä käsiksi, ja sitä vasten pitää pystyä testaamaan sovellustaan. Kehittäminen pitää voida tehdä kysymättä lupaa rajapinnan tekijältä tai haltijalta ja kertomatta etukäteen mitä on tekemässä.
Monilla julkishallinnon organisaatioilla on vahva intressi saada kaikkiin tuleviin tietojärjestelmiin kattavat rajapinnat, joilla tieto saadaan liikkumaan järjestelmien välillä nykyistä joustavammin. Rajapintojen käyttö ei sinänällään ota kantaa siihen, mikä osa tiedoista on julkisia ja mikä osa sisäisiä, mutta niiden avulla tieto on halutessa vaivattomasti saatavissa ulos järjestelmästä.
Rajapinta
Rajapinta (Application programming interface, API) on määritelmä, jonka mukaan eri ohjelmat voivat tehdä pyyntöjä ja vaihtaa tietoja eli keskustella keskenään. Käytännössä tämän dokumentin kannalta mielenkiintoiset rajapinnat ovat usein Internetin yli käytettäviä Web Service-rajapintoja. Samat periaatteet pätevät kuitenkin muunkinlaisiin toteutuksiin.
Rajapinta voi olla pelkkä datarajapinta (esim. kansalaisaloite.fi:n rajapinta) tai toiminnallinen rajapinta (esim. Helsingin Palauteytimen Open311-rajapinta, jonka kautta voi tehdä vikailmoituksia). Jos järjestelmässä on erikseen datarajapinta ja toiminnallinen rajapinta, on syytä täsmentää, minkä kaiken on tarkoitus olla avointa.
Avoin rajapinta
Jotta rajapinnan voi sanoa olevan avoin, sen täytyy täyttä seuraavat ehdot:
1. Dokumentoitu: Rajapinta on määritelty ja sen dokumentaatio on verkon kautta avoimesti saatavilla. Järjestelmän sisältämät tiedot, niiden rakenne ja rajapinnat tulee dokumentoida riittävällä tarkkuudella, jotta rajapinnan käyttöönotto ja hyödyntäminen on vaivatonta.
2. Käyttöönotettava: Avoin rajapinta on mahdollista ottaa käyttöön ilman ylläpitäjän tai järjestelmätoimittajan toimia (myös virka-ajan ulkopuolella). Mahdolliset rekisteröitymiset ym ovat automaattisia.
3. Testattava: Rajapintaa voi koekäyttää, eli tarjolla on vähintään testiaineisto.
Testattavuuden ehto voi täyttyä jollain seuraavista tavoista:
avoin pääsy tuotantojärjestelmään, jota käyttäen palveluun voi integroitua, tai
avoin pääsy testijärjestelmään, jossa on realistista esimerkkidataa, tai
testijärjestelmä on ladattavissa vapaasti omaan käyttöön
Avoimen rajapinnan kautta saatava data on usein avointa, mutta sen ei tarvitse olla avointa dataa. Esimerkiksi potilastietojärjestelmä voi sisältää avoimen rajapinnan, mutta potilastiedot eivät ole avoimia.
Jos järjestelmä tarjoaa avoimen rajapinnan, se ei tarkoita, että tuotantojärjestelmään tai sen sisältämään tietoon pääsisi kuka vain käsiksi. Rajapinta voi olla avoin, vaikka tuotantojärjestelmä olisi kokonaan irti internetistä ja pääsy siihen vain hyvin rajatulla joukolla. Tällöin tarjolla pitää kuitenkin olla jonkinlainen testiympäristö.
Esimerkkejä
Palveluun A on rajapinta tarjolla, ja palvelun toimittaja on sitoutunut tarjoamaan sen asiakkaidensa osoittamille kolmansille osapuolille -> SULJETTU
Palvelun B datarajapintaan pääsee vapaasti käsiksi, mutta toiminnalliseen rajapintaan ei. Rajapinta on julkisesti netissä, ja esimerkkikoodia löytyy googlella -> AVOIN, mutta vain datarajapinnan osalta
Palveluun C on olemassa toiminnallinen rajapinta. Päästäkseen siihen käsiksi täytyy pyytää käyttöavain palvelun tarjoajalta, koska palvelu ei kestäisi vapaan käytön kuormitusta. Käytännössä lupa myönnetään aina. -> SULJETTU Jos palvelusta tarjottaisiin testiversio vapaasti käytettäväksi, se olisi avoin
Palveluun D on rajapinta, jonka määrittelyt ja dokumentaatio ovat vapaasti saatavilla. Itse palveluun ei pääse vapaasti käsiksi, koska se sisältää ihmisten henkilötietoja. Palveluntarjoaja pitää kuitenkin yllä testipalvelinta, jossa on esimerkkidataa, ja testipalvelimeen pääsee käsiksi luomalla itselleen tunnuksen palveluntarjoajan järjestelmään. -> AVOIN
Tilaajan hallitsema rajapinta
Toisinaan avoimella rajapinnalla tarkoitetaan rajapintaa, jota järjestelmän tilaajalla on oikeus käyttää ja levittää haluamallaan tavalla, mutta joka ei välttämättä ole avoimesti kenenkään muun saatavilla. Tällöin kyse ei ole avoimesta rajapinnasta, vaan olisi syytä puhua ennemmin tilaajan hallitsemasta rajapinnasta.
Tilaajan hallitsema rajapinta tarkoittaa siis rajapintaa, jonka järjestelmän tilaaja voi halutessaan avata ilman, että tähän tarvitaan järjestelmän toimittajan lupaa.
Tilaajan hallitsemalla rajapinnalla saavutetaan joitakin avoimen rajapinnan hyödyistä (erityisesti toimittajaloukun välttämäinen), mutta ei niitä kaikkia.
Huomiota ja hyviä käytäntöjä
Sopimusehdot: Tekeillä olevat JIT ehdot määrittelevät, että ostajalla pitää olla mahdollisuus halutessaan avata rajapinta (laittaa dokumentaatio ja testiaineisto verkkoon yms.) ilman, että toimittaja puuttuu siihen. JIT-ehdot eivät kuitenkaan vaadi, että kaikissa julkishallinnon ostamissa ohjelmistoissa rajapinnat olisi pakko avata, vaan tämä jää ostajan harkintaan. Käytännössä ehtoihin siis kirjataan, että rajapinta on tilaajan hallinnassa.
Standardointi: Rajapintojen toteutuksessa kannattaa suosia yleisesti käytettyjä standardeja, protokollia sekä formaatteja. Käytännössä rajapinta voidaan toteuttaa esimerkiksi REST-arkkitehtuurin mukaisesti siten, että sen kautta järjestelmän tiedot saadaan koneluettavana XML-muodossa sekä selainpohjaisia sovelluksia varten JSON-muodossa. Tässä kiteytyksessä ei oteta kantaa harmonisointiin. Harmonisointi on kuitenkin looginen kehityskulku, jotta kaikki avoimet rajapinnat eivät olisi keskenään erilaisia, vaan syntyisi ainakin toimialakohtaisesti yhteisiä käytänteitä. Open311.org on hyvä esimerkki avoimien rajapintojen standardoinnista.
Rajapinnan käyttö ilman rekisteröitymistä: Rajapinnan avoimuus ei velvoita tarjoamaan pääsyä tuotantojärjestelmään tai tuotantodataan vapaasti, vaan sen osalta voidaan vaatia esim. SLA. Jos itse tuotantojärjestelmään ei pääsyä, täytyy tarjota testijärjestelmä avoimesti kehittämistä varten.
Kuormitusrajoitukset: Avoin rajapinta kannattaa toteuttaa siten, että sitä kuormittamalla ei voi (ainakaan vahingossa) aiheuttaa uhkaa tai haittaa tietojärjestelmän muulle käytölle. Eli esimerkiksi rajapinnassa teknisesti rajattu kutsujen määrää per aikayksikkö. Tämä saattaa aiheuttaa tarpeita kahdentaa osia tietojärjestelmästä (vrt. Reittiopas).
Helsinkiin suunnitellaan 100 000 neliömetrin uutta datakeskusta.
Satatuhatta kerrosneliöä on paljon. Noin 2/3 Itäkeskuksesta, tai 2500 ihmisen asunnot. Mutta konesaliksi se on vielä paljon enemmän. Suomen suurin konesalisuunnitelma on Venäläisen Yandexin rakenteilla oleva sali Mäntsälässä, joka tulee valmiina olemaan 36 000 neliöä. Googlen sali Haminassa on seuraavana ja siitä noin puolet. Ne molemmat palvelevat ennen kaikkea Venäjän asiakkaita.
Suurin kotimaiseen käyttöön tehty konesali on Tiedolla, ilmeisesti alle kymmenesosa Roihupellon suunnitelmasta. Tyypilliset Suomalaisten palveluntarjoajien konesalit ovat 1000 neliön luokkaa. Academican kuluisa sali Uspendskin katedraalin alla on 200 neliöä, 0,2% Roihupellon suunnitelmasta ja saman yhtiön suurempi mutta vähemmän kuuluisa sali Suvilahdessa 2000 neliöä.
Satatuhatta kerrosneliöä lienee enemmän kuin Suomen koko tämänhetkinen konesalikapasiteetti. Yhdysvalloissa konesaleja arvioidaan olevan yhteensä 10 miljoonaa neliöä. Suunnitelma on prosentin siitä, ja siis maailmanmittakaavassa merkittävä konesali-investointi.
Tässä ei todellakaan puhuta nyt paikallisesta pikkubisneksistä, vaan siitä miten ja missä tulevaisuudessa koneita Euroopassa pyöritetään. Kyse on tiedon valtatien geopolitiikasta.
Google on jo Suomessa, palvelemassa lähinnä venäjän asiakkaitaan. Samaten on Yandex, ”Venäjän Google”. Venäjällä on paljon kysyntää erilaisille nettipalveluille, mutta niiden tarjoamisessa maan rajojen sisällä on riskejä. Ja osa asiakkaista haluaa nimenomaan palvelua, jossa heidän hallituksensa ei pääse lukemaan viestien ja kovalevyjen sisältöä.
Kyse ei kuitenkaan ole vain Venäjästä. Suomen hallitus päätti myös 10 terabitin valokaapelin rakentamisesta Itämeren pohjaa pitkin Saksaan. Vielä nykyään Suomen käytännössä ainoa yhteys Keski-Eurooppaan ja oikeastaan koko muuhun maailmaan kulkee Ruotsin ja Juutinrauman sillan kautta. Yksinäinen linkki on aina haavoittuva, ja Ruotsin sotilastietopalvelu FRA myös salakuuntelee liikennettä. Saksan kaapeli on oikeastaan välttämätön edellytys sille, että Suomesta käsin voidaan palvella Euroopan markkinoita datapalveluilla.
Suunnitteilla on myös toinen merikaapeli. Koillisväylän kaapeli kulkisi Lontoosta Murmanskin kautta Siperian pohjoispuolitse Japaniin ja Kiinaan. Pituutta kaapelille tulisi yhteensä 14 000 km. Kun Rovaniemeltä rakennettaisiin vielä kaapeli Murmanskiin, Helsinki olisi yhtäkkiä Euroopan pääkaupungeista lähimpänä Tokioa.
Matka Helsingistä Tokioon olisi noin 12 000 km, eli valonnopeutena 40 millisekuntia, realistisesti ehkä 100-150ms. Nykyinen etäisyys esimerkiksi Lontoosta Tokioon on 24 000km ja 230 millisekuntia, ja kehitettäessä nettipalveluita, millisekunneilla on väliä, koska ne nopeasti kertautuvat sekunneiksi, jotka tekevät palvelusta käyttökelvottoman. Käytännössä Koillisväylän kaapeli saattaisi tehdä monet sellaiset palveluratkaisut mahdollisiksi, jotka eivät sitä tänään ole.
Tämän päivän geopolitiikka on ennen kaikkea yhteyksiä, ei niinkään rajoja
Suomi on tässä uudessa maantieteessä onnekkaassa asemassa. Ainoa Venäjän rajanaapuri, jolla on hyvä tietoliikenne- ja sähköinfra. Lisäksi kohta riittävän hyvät yhteydet Keski-Eurooppaan ja sitten vielä Euroopan nopeimmat yhteydet Japaniin ja Kiinaan. Ja toimiva infrastruktuuri sekä vakaa demokratia.
Luonnonolojen päälle, myös menestyksen edellyttämä infra on hoidettu. Mutta politiikassa on kyse muustakin kuin edellytysten tarjoamista. Politiikassa on kyse myös siitä, ettei sössitä kaikkea.
Datapalveluille on vielä yksi kriittinen ehto: luotettavuus, ja ettei tietoliikennettä vakoilla. Valitettavasti juuri se on uhattuna. Puolustusministeriö kaavailee USA:n urkintalainsäädännön kopioimista Suomeen, millä olisi tuhoisa vaikutus pyrkimyksille toimia luotettavien datapalvelujen kärkimaana.
Järjettömät lakihankkeet eivät ole luonnonlaki, ne ovat poliittisia valintoja. Niin Suomessa kuin Euroopassakin. Tästäkin on eurovaaleissa kyse.
Kirjoittaja on ehdolla eurovaaleissa numerolla 164
