Mitä yhteistä on verkkosivulla ja junalipulla?

22.04.2015

Viime päivinä on taas keskusteltu VR:n järjestelmäuudistuksista. Liiketoiminnan kannalta täysin keskeisten ohjelmistojärjestelmien rakentaminen ja etenkin pitäminen ajantasaisena eivät ole ihan helppoja juttuja. Osaamisen lisäksi ne vaativat määrätietoista näkemystä ja pitkäaikaista päätöksentekoa. Poutapilvi toimii alalla, jossa käytännössä kaikki liiketoiminta pohjautuu johonkin ohjelmistojärjestelmään. Lisäksi alalla on hyvin tavanomaista se, että projekteissa käytetään jotain ulkopuolisen järjestelmätoimittajan tuotetta. Markkinasta, verkkosivuston tilaajan liiketoiminnasta ja etenkin sen koosta riippuen monen sivuston taustalla on myös avoimen lähdekoodin järjestelmä. Miksi Poutapilvi tekee asioita omilla järjestelmillään ja mitä VR:n seikkailuista voidaan oppia?

Ihan oma

Perimmäinen kysymys on tietenkin lankojen pitäminen omissa käsissä. Mielestäni tämä epämääräinen ilmaisu voidaan jakaa kahteen konkreettiseen ongelmaan, jotka halutaan ratkoa.

Ensimmäinen ratkaisu muodostuu järjestelmän toimintatarpeista. Mihin järjestelmää halutaan käyttää? Monet verkkopalveluiden toteuttamiseen tehdyt järjestelmät kohdistuvat seuraavaan tarpeeseen: Toteutetaan työn alla oleva verkkopalvelu mahdollisimman helposti juuri nyt. Meidän tarpeemme on lähempänä seuraavaa: Pyöritetään satoja verkkopalveluita yllättävän hyvin seuraavat kymmenen vuotta. Jos toteutusprojektia katsotaan sen hektisimmän kolmen viikon osalta, ei järjestelmissä yleisesti ottaen aina tunnu olevan suuria eroja. En ala tässä myöskään nyt erotella näitä tarpeita tämän teknisemmin. Todettakoon kuitenkin, että nämä kaksi tarvetta poikkeavat toisistaan melkein yhtä paljon kuin kumpikin niistä verrattuna tarpeeseen myydä kansalle junalippuja.

Perimmäinen kysymys on tietenkin lankojen pitäminen omissa käsissä.

Ratkaisutarpeista jälkimmäinen koskee tulevaisuutta. Jokainen joka on joskus päivittänyt tietokoneen, puhelimen tai tabletin käyttöjärjestelmän uudempaan versioon tuntee sen innostuksen ja kauhun sekoituksen, jota koetaan laitteen käynnistyessä uudelleen päivityksen jälkeen. Kun ei vielä tiedetä onnistuuko se miten on toimittu aiemmin, onko sitä ärsyttävintä toimintoa korjattu paremmaksi ja ennen kaikkea - toimiiko kaikki mikä eilen vielä toimi. Mikä organisaatio voisi katsoa tulevaisuuteen niin, ettei tiedä vastauksia näihin kysymyksiin etukäteen? Monille tahoille verkkoviestintä on vain osa, vaikkakin yhä tärkeämpi, laajempaa kokonaisuutta. Poutapilvelle se on toiminnan kulmakivi. Ellemme pysty menemään tulevaisuuteen niin, että voimme taata itsellemme mahdollisuuden tehdä kaikkea sitä mitä verkossa vain voi, miten voimme kehittää toimintaamme markkinoiden vaatimalla tehokkuudella?

Avoimen lähdekoodin ilot ja surut

Avoimen lähdekoodin historia suomessa on pitkä. Se on vanhempi kuin internet. Silloin kun surisevat modeemit olivat aikansa tapa yhdistyä jonkun koulun atk-luokan nurkassa hyrräävään kaikille (jotka osasivat sen löytää) avoimeen viestipalveluun, tuon ajan teinit (joihin minullakin oli ilo kuulua) kaivoivat ohjelmointiosaamista juuri tuolta mistä sitä oli mahdollista saada ja rakensivat Suomen nykyistä uusmediaosaamista. Tuosta ajasta eteenpäin olen ollut vakaasti sitä mieltä, että avoin lähdekoodi on se paras tapa saada käyttöönsä uusinta ja toimintavarminta softaa. Tuolloin tosin sitä ei kutsuttu sillä nimellä. Pidettiin selvänä, että tässä nyt selitetään yhden osatoiminnallisuuden paras toimintamalli, ja palikoita kutsuttiin kirjastoiksi. Yksi kirjasto sisälsi toiminteita näppäimistön painallusten seuraamiseen, toinen liikkuvien kuvien piirtämiseen ruudulle.

Uudet ja hyvät toiminnallisuudet ovat tärkeä asia, mutta toinen ikiaikainen peruste näissä oli se, että kun jotain julkaistiin kaikkien saataville, löytyi heti joku joka osoitti siinä olevat virheet. Tuolloin ei tietoturvasyistä, vaan siksi että pystyi osoittamaan olevansa kovempi koodari. Nykyään ilmiö on laajentunut siihen, että avoimen lähdekoodien projekteissa laatu muodostuu useampien valvovien silmäparien lisäksi siitä, että avointa koodia julkaiseva kokee ylpeyttä ja onnellisuutta siitä, että pyrkii seuraamaan hyviä ohjelmointikäytäntöjä. Ei tarvita selityksiä, kun suoraan koodista voi lukea miten homman kuuluu toimia. Kuulostaa uskomattomalta monelle asiaan vihkiytymättömälle, mutta on täysin totta.

Kuulostaa hyvältä, mutta... Aina on joku mutta, mikä tässä siis?

Avoimella lähdekoodilla ja hyvällä perustutkimuksella on todella paljon yhteistä. Jotta päästään tavoitteisiin, pitää kaivaa syvälle ja keskittyä johonkin joskus uskomattoman suppeaan erikoisalueeseen. Kokonaiskuva hämärtyy. Silloin kun kaikki tehdään oikein, sillä ei ole väliä. Tarkoituskin on vain tuottaa työkaluja sille asiantuntijalle, jolla on jostain asiaan liittyvästä selvä kokonaiskuva ja tarve edetä näkemyksensä kanssa. Tämä asiantuntija ei ikinä pääse eteenpäin, jos hän joutuu tekemään kaiken itse. Menestyäkseen hän poimii rutiininomaisesti oikealta ja vasemmalta perusosaamista, työkaluja ja parhaat kirjastot.

Suppealla fokuksella toimivissa projekteissa kokonaiskuvaa on vaikea hallita. Jos siihen pyritään, joudutaan tekemään monenlaisia kannanottoja, jotka vaativat lisäkompromisseja toteutuspuolella. Kokonaisuus kärsii kunnes laatua menetetään niin paljon, että ratkaisu ei enää pärjää vertailussa muiden vaihtoehtojen kanssa. Joskus kokonaisuus saattaa pysyä kilpailukykyisenä, mutta erinomaisuus menetetään kun kuukaudet muuttuvat vuosiksi ja tulevaisuuden ennakointi ei toimikaan enää kaikille yhtä hyvin.

Parhaat päältä

Avoimeen lähdekoodiin perustuvat ratkaisut ovat parhaimmillaan silloin, kun niitä käytetään kirjastoina. Ne ovat rakennuspalikoita, joiden käyttö estää saman pyörän rakentamisen yhä uudelleen. Rakennuksen perustus koostuu omaan tarkoitukseensa huolellisesti rakennetuista ja arvioiduista itsenäisistä kokonaisuuksista. Mutta kirjoitukseni alkupuolella mainitut tulevaisuuden hallintaan liittyvät osaset pitää tavallisesti pitää omissa käsissä. Nämä ovat tavallisesti myös ne osat, joilla tuotetaan kokonaisuuden kannalta eniten uutta lisäarvoa.

Insinöörillehän tämä on selvää. Ensin varmistetaan, että kaikki laskelmat ovat kunnossa, mutta mitään ei synny ilman kunnon piirrustuksia. Tärkeää se on myös arkkitehdille, jolla tulee olla luottamus siihen, että voi visioida omia mullistavia ajatuksiaan turvallisesti ilman huolta tosielämän katastrofista.

Avoimeen lähdekoodiin perustuvat ratkaisut ovat parhaimmillaan rakennuspalikoina, joiden käyttö estää saman pyörän rakentamisen yhä uudelleen.

Miten tämä nyt sitten liittyy VR:ään? Vain kyseisen projektin asianomaiset sen voivat tarkkaan tietää, mutta arvioita voi esittää. Ensinnäkin, uskon että myös tässä miljoonaprojektissa avoimet kirjastot on jätetty sivurooliin ja yritetty rakentaa kaikki alusta. Tuhannet ja kymmenet tuhannet työtunnit tehdään uudelleen huonommin. Toiseksi, kaiken tämän kokonaisuuden hallinta, joka on jo valmiiksi hankalaa, hankaloituu vielä moninkertaisesti jouduttaessa hallitsemaan kokonaiskuvan lisäksi jokaista pientä juonnetta. Kolmanneksi, se timantti, joka syntyy vain rakennettaessa jotain oikeasti hienoa hyvän perustuksen päälle ei ikinä pääse esiin, koska perustuksen rakentaminenkin epäonnistuu väistämättä jollain tasolla.

Lopuksi: Tämähän on vain webbisivu

Miksi Poutapilvi siis käyttää paljon aikaa ja energiaa omien järjestelmien toteuttamiseen? Meille ei ole tärkeää vain se, että saamme toteutettua jonkinlaisen verkkopalvelun, vaan se, että saamme toteutettua kaikenlaiset verkkopalvelut. Meille ei ole tärkeää se, että saamme toteutettua palvelun siinä aikataulussa missä asiakas sen toivoo, vaan myös parhaassa mahdollisessa kokonaisaikataulussa oman toimintamme tehostamiseksi. Meille ei ole tärkeää se, että järjestelmä kelpaa mahdollisimman suurelle määrälle asiakkaita, vaan se, että järjestelmä palvelee asiakkaita mahdollisimman hyvin.

Meille kyseessä ei ole yksikään webbisivu, vaan ne kaikki. Voimme toteuttaa valmisjärjestelmillä sitä mitä kaikki odottavat, mutta omassa ohjauksessamme olevalla tuotteella voimme tavoitella asioita, jotka ovat tärkeitä huomenna. Emme siis reagoi vaan ohjaamme. Ei VR:nkään ongelma ole se, ettei lippuja saada myytyä, vaan se, että niiden ostaminen ei vastaa asiakkaan toiveita palvelun tasosta.