”Tässä on meidän 2000-sivuinen määrittelydokumentaatio järjestelmälle, jota toteutamme seuraavat kymmenen vuotta 1,5 miljardilla eurolla.” – Ai ei houkuttele vai? Voi olla, ettei järjestelmässä päästä alkua pidemmälle ennen kuin määrittelyt ovat jo vanhentuneet.
Ohjelmistoalan eri trendeissä viimeisen kymmenen vuoden ajalta voi havaita korkeamman tason megatrendin.
Ketterä ja iteratiivinen ohjelmistokehitys, lean-tuotantomalli ohjelmistoissa, pilvipalveluiden ostaminen käyttöperustaisesti, kehittämisen ja ylläpidon DevOps-yhteennivoutuminen ja beta-testaaminen loppukäyttäjillä.
Kaikissa näissä ilmiöissä varaudutaan muuttuviin odotuksiin ja tavalla tai toisella pyritään lyhentämään läpimenoaikaa päätöksestä valmiiseen tuotteeseen. Palvelujen tarjoajilla ei ole enää varaa olla hitaita. Koko yhteiskunnassa tarpeet muuttuvat sellaisella tahdilla, ettei ohjelmistoalan turbulenttisessa ilmastossa kannata enää vetää läpi valtavia ja riskialttiita vesiputousmallisia projekteja. Lisää spiidiä siis tarvitaan.
Suomessa tähän on herätty tutkimusmaailmassa tänä vuonna käynnistyneellä Digilen Need For Speed -tutkimushankkeella. Harras toiveeni on, että myös julkishallinnon tietojärjestelmäprojekteissa herättäisiin tähän vahvemmin. Ketteryys tekee kyllä vähitellen tietään, mutta aina se ei yllä projektien kaikille tasoille. Ohjelmistokehitys saattaa rullata ketterästi, kunnes tarvitaan uusi palvelin käyttöpalvelutoimittajalta. Pyyntö toteutuu kahdessa kuukaudessa, jonka aikana kehitetään hampaat irvessä palvelun muita osia.
Vanha klisee ketjun heikoimmasta lenkistä kirkastuu silmissä, kun yhdenkin kumppanin ketteryys on kuin ketjuun kahlittua. Uusien ominaisuuksien kehityssykli pyörii kuitenkin sulavasti, jos infrastruktuurin hallinnasta saadaan yhtä ketterää kuin itse ohjelmistokehittämisestä.
Amatsonien pilvilinnoja
Kävin alkukesästä Amazon Web Services Summitissa Tukholmassa toteamassa Amazonin olevan edelleen pilvi-infrastruktuurin markkinajohtaja. Myös Gartnerin tutkimuksen mukaan AWS porskuttaa tarjontansa laajuudella ja syvyydellä kaukana muista kilpailijoista, vaikkakin Google ja Microsoft kirivät.
Kaikki näistä ovat ponnistaneet pilvipalvelunsa alun perin omista sisäisistä tarpeistaan ylläpitää monimutkaisia palvelinkokonaisuuksia. Konesalitoiminta, jos mikä, on volyymibisnestä, ja pilvipalveluiden yhteydessä puhutaan usein suuruuden ekonomiasta (economies of scale). Mitä enemmän palvelimia on sitä pienemmiksi ylläpitokustannukset kuten sähkö, jäähdytys ja ohjelmistoylläpito saadaan puristettua per palvelin.
Keskittäminen siis kannattaa. Suuria toimijoita paremmin ja kustannustehokkaammin hommaa on todella vaikea hoitaa. Jos konesalien pyörittäminen ei ole oman organisaation ydintoimintaa, ei omien palvelimien omistaminen ole kannattavaa. Uudet markkinoille pyrkivät pilvipalveluiden tarjoajatkin joutuvat etsimään muita kilpailuvaltteja.
Koska pilvipalveluissa maksetaan käytössä olevista resursseista ja käytännössä kaikille asiakkaille on tarjolla samat palvelut, niiden on monesti sanottu demokratisoivan infrastruktuurin hankkimista.
Kokeilemisen taito
Niin pienen startupin kuin uuden ketterän ohjelmistoprojektinkin arjessa on paljon epävarmuustekijöitä. Eteenpäin pitäisi päästä ja rohkeasti kokeillen etsiä toimivia asioita. Monet asiat kirkastuvat vasta, kun niitä pääsee kokeilemaan ja näkemään, ja suunta vääjäämättä muuttuu projektin aikana. Rohkeimmat ideat jäävät helposti tutkimatta, jos niiden kokeileminen vaikuttaa riskialttiilta. MIT:n Media Labin johtaja Joi Ito kiteytti ajatuksen hyvin:
”If you want to increase innovation, you need to lower the cost of failure.”
Jos idea todetaan toimimattomasti, kului lähinnä työaikaa. Tärkeintä on kuitenkin pelkän jatkuvan koodin tuotantoon viemisen (continuous deployment) sijasta jatkuva oppiminen. Rohkeimmat pilvipalveluita hyödyntävät toimijat lähtevät jopa liikkeelle siitä, että tuotantoympäristö on ainoa paikka, jossa sovellusta voi täysin aidosti testata ja analysoida. Esimerkiksi Google ja Facebook tekevät jatkuvasti pieniä muutoksia palveluihinsa ja A/B-testauksella vertailevat muutoksia loppukäyttäjien käyttäytymisessä.
Ohjelmistot ovat muuttuneet fyysisesti jaelluista korpuista ja rompuista internetissä tarjottaviin palveluihin, mikä on sumentanut perinteisten kehitys- ja ylläpitovaiheiden välisen rajan. Sen sijaan että palveluihin tehtäisiin isoja, kaiken mullistavia versiopäivityksiä, on entistä enemmän yleistynyt malli, jossa pieniä parannuksia viedään nopealla syklillä jatkuvasti tuotantoon. Laadusta riippuen käyttäjä voi kokea olevansa jatkuvasti paranevan palvelun käyttäjä tai ikuinen beta-testaaja.
Vaikka palvelu siirtyisikin selkeästi passiivisempaan ylläpitovaiheeseen, saattaa vielä tällöinkin asiakkaalta ponnahtaa yllättävä tarve uudelle toiminnolle. Tällöinkin onnistuminen voi riippua siitä, kuinka nopeasti muutos saadaan toteutettua.
Propellipäiden kahlekuningas
Kuinka sitten päästää propellipäät irti kahleista? Se vaatii hieman Lean Startup -henkeä, jota voi luoda isommissakin organisaatioissa itsenäisen projektitiimin tasolla. Kun ylin johto antaa hyväksyntänsä projektille ja tuoteomistajalle, voi tiimi itsenäisesti edetä rivakastikin kehityksessä. Pilvipalveluiden ketteryysetua ei saa kehitysvaiheessa lunastettua, jos päätösprosessit edustavat vanhaa maailmaa, jossa jokaista pientä päätöstä edeltää viikon sähköpostirumba.
Pilvipalveluita käyttöönottaessa tulee kartoittaa omat tarpeet ja sitoutua palveluun sen mukaisesti. Mitä tiukemmin sitoo oman tuotteensa alustan uniikkeihin ominaisuuksiin sitä enemmän lukittautuu kyseiseen palveluntarjoajaan. Toisaalta tällöin saa suurimmat hyödytkin ja valmiiden toteutusten hyödyntäminen on juuri se, millä pääsee nopeasti eteenpäin.
Kyse on aina tasapainoilusta, jossa pitää muistaa, ettei pilvipalveluiden käyttö ole kaikki-tai-ei-mitään. Palveluista voi hakea kokemuksia ottamalla niitä käyttöön tietyissä projektin vaiheissa (esim. vain kehityksessä tai testaamisessa) tai järjestelmän osassa (esim. varmuuskopiot, data-analyysit).
Oleellista olisi kuitenkin lähteä liikkeelle nyt, tulevaisuudessa ollaan jo myöhässä.
