Lean ajattelu ohjelmistoprojektin valmistelussa

Lean ajattelu ohjelmistoprojektin valmistelussa lähtee kahdesta peruskysymyksestä:

  • Miten voimme tuottaa ohjelmistolla asiakkaallemme – välillä myös asiakkaan asiakkaalle – eniten arvoa (ja sitä kautta myös omalle liiketoiminnallemme)?
  • Miten saisimme tehtyä ohjelmiston tehokkaimmin, vähimmällä mahdollisella ylimääräisellä työllä? Entä kun mietimme ohjelmiston käyttöä ja ylläpitoa: onko prosesseja joissa voisi oikaista tai jopa työtä jonka voisi jättää kokonaan tekemättä?

Tietenkin ohjelmistoprojektiin valmistautuminen, myös ketterä projekti, vaatii lisäksi paljon tarkempaa ja syvällisempää suunnittelua. Tässä kirjoituksessa käydään läpi tärkeimmät visiotasolla suunniteltavat asiat.  Voit ladata maksuttoman lean-visiolakanan, jota voit käyttää visiotyöpajassa ohjausryhmän kanssa, ehkä jopa pitää näkyvissä projektihuoneen seinällä projektin ajan. Lakana on ladattavissa täällä.

Lean-visiolakana kiteyttää oleellisimman ohjelmistosta

Suunnittelutyön ongelmana on usein, että yksityiskohtia yritetään kuvitella ja kiinnittää paljon pidemmälle kuin on oikeastaan pakko. Samalla lukitaan ratkaisuja turhan aikaisin, ja kehitystyön aikana syntyvää ymmärrystä voi jäädä hyödyntämättä. Ihannetapauksessa nimittäin voitaisiin projektin aikana käyttäjäpalautteen avulla huomata esimerkiksi, että jotakin ominaisuutta ei tarvitse rakentaa ollenkaan.

Hyvä visioajattelu pitää kysymykset niin yleisellä tasolla, että päätöksentekijätkin jaksavat osallistua keskusteluun, ja toisaalta vaikkapa uusi projektiin tuleva henkilö saa tärkeimmistä asioista kirkkaan yleiskäsityksen ennen kuin hän ryhtyy syventymään projektiin tarkemmin. Hyvässä visioajattelussa päästään tietojärjestelmän ohella kiinni liiketoiminnan perimmäisiin kysymyksiin: Mikä on se epäreilu kilpailuetu, joka saa asiakkaat tulemaan meille eikä menemään naapuriin? Ja mikä toisaalta on meille koko homman tarkoitus, se minkä takia jaksamme aamulla nousta ylös sängystä?

Visio koostuu seuraavista asioista:

Käyttäjien ongelma

Projektin riskitasoa laskee heti kättelyssä, jos ongelma validoidaan eikä se perustu arvaukseen. Esim. käyttäjähaastattelut ovat hyvä keino tähän. Jos sitten huomataan että käyttäjäongelma oli väärä arvaus, suunnittelua voidaan jatkaa toiseen suuntaan ilman kummoisiakaan uponneita henkisiä tai konkreettisia kustannuksia.

Onnistunut järjestelmä ratkaisee käyttäjille jonkin tärkeän ongelman. Kuluttajabisneksessä kyse voi olla vaikka opiskelijoista jotka kaipaavat lukupiiriseuraa ja parempaa kontaktia opiskelutovereihinsa, organisaation sisäisissä järjestelmissä kyse voi olla vaivattomammasta ja varmemmasta kuittien käsittelystä kirjanpitoa varten. Useimmiten ongelmia voi luetella monia, mutta kirkkaan konseptin kannalta on hyvä, jos tärkeimmäksi saadaan nostettua yksi.

Järjestelmän tarjoama ratkaisu

Seuraavaksi on mietittävä, miten järjestelmämme ratkaisee edellä tunnistetun käyttäjän ongelman. Lukupiiriesimerkissä vastaus voi olla Tinder-tyylinen kohtauttamistyökalu, jossa hakija kertoo opintoaiheen johon kaipaa opiskeluseuraa ja työkalu ehdottaa kanssaopiskelijoita sopivalta paikkakunnalta ja oppilaitoksesta. Kuittiesimerkki voi ratketa vaikkapa kännykän appillä jolla voi kuvata kuitit lennossa.

Myös ratkaisu on syytä validoida. Se onnistuu esim. yksinkertaisen prototyypin ja siihen yhdistetyn käyttäjätutkimuksen avulla. Jos käy ilmi, että oletettu ratkaisu ei itse asiassa autakaan käyttäjän ongelmaan, voidaan lähteä hakemaan toista ratkaisua eivätkä tappiot vieläkään ole suuria.

Ainutlaatuinen arvo

Useimmiten järjestelmillä on tavalla tai toisella kilpailijoita, jos ei muita niin se, että käyttäjä jättääkin asian kokonaan tekemättä. Ainutlaatuinen arvo on ohjelmistossa se ominaisuus, joka saa käyttäjän käyttämään juuri meidän järjestelmäämme ja ihastumaan siihen. Lukupiiri-Tinder-esimerkissä tämä voi olla mahtava sosiaalisuuden tuntu, kuittikamerassa taas se että kuva kuitista hoituu yhdellä painalluksella laskujärjestelmään asti.

Ainutlaatuista arvoa voi lisäksi syntyä siitä, että uuden järjestelmän myötä saadaan helpotettua järjestelmää tarjoavan yrityksen omia prosesseja. Viekö jokin asia tiskin takana nykyään paljon aikaa? Onko jotakin minkä voisi jättää tekemättä kokonaan?

Molemmantyyppiset ainutlaatuiset arvot on edelleen tärkeää validoida. Jo prototyypissä voi kokeilla haetun hurmausefektin tehokkuutta, ja uusien työtapojen säästövaikutuksia voi mitata vaikka kokeilemalla ilmaistyökaluilla ennen kuin uusi järjestelmä on edes kehitysvaiheessa.

Avainresurssit toteuttamisessa ja päätöksenteossa

Jokaisessa ohjelmistoprojektissa on resursseja, joiden jääminen löytymättä tai menettäminen on iso riski projektin onnistumiselle. Tällainen voi olla taitava tuoteomistaja, sponsori ylimmässä johdossa tai ohjelmiston tekninen velho, mutta yhtä hyvin korvaamaton lanseerauskanava, datalähde tai lähiprojekti.

Kehitystiimiltä kaivataan yleensä paitsi tiettyä todistettua teknologiaosaamista, myös hyviä yhteistyötaitoja toistensa ja asiakkaan edustajan kanssa. Ja mitä erikoisempi teknologia tai vaatimusyhdistelmä on kyseessä, sitä kriittisempää juuri tiettyjen resurssien saamisesta yleensä tulee. Resursoinnissa kannattaa myös miettiä läpi jatkokehitysvaihe.

Resursointia miettiessä yksi avainkysymys on, onko tärkeimmissä resursoitavissa jotain mikä voitaisiin itse asiassa saada valmiina verkostojen kautta tai ostettuna. Voisiko siitä silloin tulla jopa parempi, ja softantekijät ja tilaaja pääsisivät keskittymään siihen minkä tekevät parhaiten?

Kenelle järjestelmää tehdään

Kohderyhmiä miettiessä mopo usein karkaa käsistä, ja erilaisia käyttäjätyyppejä päädytään luetteloimaan esim. 12 kappaletta. Lean-ajattelun hengessä kuitenkin hyödyllisintä olisi pyrkiä erottamaan yksi tärkein käyttäjäpersoona. Minkä käyttäjäryhmän varassa liiketoiminnan tuleva kasvu on? Kuka viettää järjestelmässä eniten aikaa? Mikä käyttäjäryhmä voisi tuoda muut mukanaan? Olisiko käyttäjäryhmää edustavia ihmisiä saatavilla pilottikäyttäjiksi kehitystyötä varten?

Käyttäjäpalaute ja mitä sitten

Käyttäjäpalautteen keräämisellä ja analysoinnilla varmistetaan, että palvelu kehittyy jatkuvasti paremmaksi. Tämä on edelleen tärkeää, kun järjestelmää kehitetään eteenpäin vaikkapa kymmenettä vuotta.

Tilauskannan kehittyminen on hyvä käyttäjäpalautteen mittari, mutta myös laadullisempaa dataa tarvitaan. Apuun tulee esim. prototyypeistä kerättävä palaute, järjestelmän käyttöanalytiikka, käyttäjille tehtävät kyselyt, muutosten A/B-testaus tai klassinen käytettävyystestaus.

Tärkein asia käyttäjäpalautteessa kuitenkin on, että sitä käytetään päätöksenteon pohjana yhtä hyvin projektin päivittäisessä elämässä kuin isommissakin linjoissa esim. ohjausryhmän kanssa. Muuten kerääminen on jokseenkin hyödytöntä.

Rajoitukset projektille

Jokaisella ohjelmistoprojektilla on rajoituksia. Tyypillisimpiä ovat liiketoiminnan sykli tai aikataulu, johon on osuttava täyden hyödyn saamiseksi investoinnista. Esim. Lukupiiri-Tinderin tapauksessa lukukauden alku on tärkeä, koska opiskelijat järjestelevät elämäänsä ja ovat avoimia uusille vaikutteille.

Myös budjetti on usein rajallinen, ja suunnittelua tarvitaan. Maksavatko lisenssit, tarvitaanko laitteita ja tiloja kehitykseen, hankitaanko ohjelmistokehittäjät rekrytoinneilla vai ostamalla?

Harva järjestelmä tuottaa arvoa ilman, että käyttäjät tietävät siitä. Paljonko lanseeraukseen olisi syytä varata työtä tai rahaa?

Miten palvelun ylläpitovaihe eli hosting ja mahdollinen jatkokehitys aiotaan resursoida? Halutaanko järjestelmä taas uudistaa joidenkin vuosien päästä isosti, vai kehitetäänkö sitä mieluummin jatkuvasti pienellä panoksella?

Tekninen visio

Teknisessä visiossa ohjelmiston ostaja hyötyy eniten toimittajasta, ja suunnittelu onkin syytä tehdä yhdessä. Toisaalta seassa on kysymyksiä, joissa leanit ratkaisut eivät välttämättä kulje käsi kädessä toimittajan maksimikatteen kanssa. Omaakin visiota on siis hyvä hankkia vaikka sitten riippumatonta näkemystä ostamalla.

Millä teknologioilla ohjelmisto aiotaan toteuttaa? Onko vaihtoehtoja? Mikä tekniselle onnistumiselle on ensiarvoista, haetaanko vaikkapa monistettavuutta tulevaisuutta varten vai riittääkö kertatoteutus? Suositaanko avointa lähdekoodia?

Miten projektissa voitaisiin tehdä mahdollisimman vähän ohjelmistokehitystä? Onko olemassa valmiita tuotteita, joilla osa tarpeista voitaisiin kattaa vaikkapa muovaamalla vaatimuksia hiukan? Onko käytettävän teknologian sisällä valmismoduuleita joita voitaisiin käyttää, tai jopa olemassa olevia toteutuksia joihin voitaisiin pohjata? Jos käytetään avointa lähdekoodia, hyödynnetäänhän kehittäjäyhteisön valmiit ratkaisuaihiot?

Yksi järjestelmän lisäarvon ulottuvuuksista syntyy siitä, mitä sillä voidaan korvata. Sitä kautta voidaan esim. saada säästöä lisenssikustannuksissa.

Edelleen on mietittävä, mihin järjestelmä linkittyy – tästä syntyy teknisiä rajoitteita. Pitääkö sen viedä tai tuoda dataa, ja jos niin mihin kaikkiin järjestelmiin? Mitkä ovat turvallisuustarpeiden ja lain tai säännösten aiheuttamat rajoitukset?

Ja viimeisenä: mihin järjestelmän jatkokehitettävyys perustuu? Ollaanko valittu teknologia, jolla on pitkä elinkaari, vai lähdetäänkö suoraan siitä, että homma on menossa uusiksi muutaman vuoden päästä? Tämä vaikuttaa teknologiavision kunnianhimotasoon. Jos ketterä projekti etenee iteratiivisesti mutta aikajänne on pitkä, miten myöhemmin aiotaan kuroa umpeen teknistä velkaa, jota alun nopeissa voitoissa on mahdollisesti syntynyt? Löydetäänkö valituille teknologioille osaajia myös tulevaisuudessa?

Liiketoimintamittarit

Lean ajattelu ohjelmiston visiossa päätyy tuottonäkökulmaan. Kun visio on muodostettu ja validoitu, kehitys etenee suunnitellusti ja asiakkaalle alkaa syntyä uutta arvoa, kehitysinvestointi alkaa näkyä viivan alla. Vaikutuksen toteamiseen tarvitaan kuitenkin mittareita.

Visiossa on hyvä tunnistaa, onko järjestelmän tarkoitus tuoda liiketoimintaan kenties kokonaan uusi alue tai käänne, vai tähdätäänkö laadun parantamiseen esim. asiakaskokemuksessa tai lopputuloksissa? Vai haetaanko ennemminkin toiminnan tehostamista?

Molemmissa tapauksissa tarvitaan sekä välittömiä että epäsuoria mittareita. Lukupiiri-Tinderin tapauksessa välitön mittari voi olla esimerkiksi opiskelijoiden kokema tyytyväisyys ja tenteistä saadut arvosanat, ajan mittaan tulokset näkyvät toivottavasti nopeutuneina valmistumisaikoina ja vähentyneinä mielenterveysongelmina.

Lean-visiolakana käyttöösi

Oman ohjelmistovisiosi vastaukset edellä listattuihin ydinkysymyksiin voit kirjata joko täytettävään PDF:ään tai tilata samalla lomakkeella maksutta työpajaasi A1-kokoisen visiojulisteen.

Visiolakanan lisäksi projekti tietenkin tarvitsee paljon muita ohjausvälineitä, kuten tarkemman konsepti-idean ja mahdollisesti sitä testaavan proton, käyttäjätutkimuksen ja siltä pohjalta muodostetut käyttäjäpersoonat, kehitysjonon ja jonkin välineen sen käsittelyyn, konkreettiset menestysmittarit ja niiden tulosseurannan, resurssi- ja budjettisuunnittelun, taustajärjestelmäselvitykset sekä välineet käyttäjäpalautteen keräämiseen. Visiolakana kiteyttää projektin sielun ja kokoaa edellä mainitut yhteen.

Lataa lean-visiolakana maksutta

Voit ladata visiolakanan täällä.

PyCon Finland 2015

Yksi Pyconin mielenkiintoisimpia oppeja oli se, miten Pythonin avulla voi taistella haittaohjelmia vastaan.

PyCon Finland 2015 on Python-kielestä kiinnostuneille suunnattu konferenssi, jonka järjestää Python Suomi ry. Tässä blogauksessa esittelen mielenkiintoisimmat huomiot ja oivallukset niin puheista kuin tapahtuman toimivuudestakin.

Kuin rasvattu käärme

Pycon lähti osaltani käyntiin hieman kankeasti, kun bussini jumiutui ruuhkaan ja missasin vaihtoratikan. Puhujana minun olisi syytä olla ajoissa. Pamahdinkin paikalle kirjaimellisesti viime hetkellä.

Nimikylttiä ei näkynyt rekisteröinnissä! Sainkin sen suoraan järjestäjältä, minkä jälkeen konferenssi sujui kuin rasvattu salami, tai käärme. Taukoja oli sopivasti ja tekniikkakin toimi paremmin kuin yleensä tällaisissa tapahtumissa. Hektisen aamun jälkeen oli mukavaa viettää päivä kitkattomasti soljuvassa tapahtumassa.

Nähtävissä netissä

Mainitsemisen arvoista on etenkin se, että PyCon kuvattiin ensimmäistä kertaa ammattilaisten voimin, ja kaikki talkit tulevat myöhemmin nähtäväksi YouTubeen. Konferenssissa oli kaksi erillistä trackiä, joten kaikkia puheita ei ehtinyt näkemään livenä, vaikka olisi miten halunnut. Onneksi ne voi nyt tsekata jälkikäteen netistä. Kaikki näkemäni puheet olivat hyviä, mutta tässä kohokohdat.

Kafka – jonojärjestely täydellisellä logituksella

Keynotesta on tietysti pakko sanoa pari sanaa. Spotifyn Jyrki Pulliainen esitteli puheessaan Solid data structures in Python with logs Kafkaa, joka on LinkedInin kehittämä viestijonojärjestelmä täydellisellä logituksella, jota pystyy myös hajauttamaan. Homman juju on siinä, että viestijonon voi palauttaa aiempaan tilaan ja kelata eteenpäin haluamaansa pisteeseen. Ehkä mielenkiintoisin käyttökohde tälle olisi tietokantamuutos, jossa luodaan uusi tietokanta päivitetyllä schemalla ja ajetaan vanhan tietokannan transaktiot Kafkasta sisään. Se ei tosin sovellu hyvin töihin, joissa täytyy yrittää uudelleen epäonnistunutta tehtävää, koska jokainen tehtävä on uusi transaktio.

Hakukone, johon asianajajat rakastuvat

Priidu Kull on entinen asianajaja, nykyinen koodari. Hän kertoi puheessaan Building a Product for Legal Professional projektistaan, jossa hän pyrkii luomaan hakukoneen lakidokumenteille. Hakukoneen päämääränä on olla sellainen, että juristit käyttävät sitä mielellään. Hakukone rakentuu asianajajien workflow’n ympärille. Tästä talkista teki erityisen mielenkiintoisen se, että puheen lopuksi Kull keskusteli yleisönsä kanssa projektinsa sisällöstä ja kysyi heidän näkemystään sen ongelmakohdista. Keskustelua syntyi etenkin siitä, miten haut olisi parasta toteuttaa – tekstien hakeminen kun ei ole ihan helppoa. On hienoa nähdä koodaaja avoimena ja vielä hienompaa, kun hän on harvinaisesti sekä asianajaja että koodaaja. Tämän lisäksi opin, että virolainen oikeusjärjestelmä ei ole aivan samanlainen kuin suomalainen.

Python vs. haittaohjelma

F-Securen Matteo Cafasso kertoi ja näytti livenä talkissaan Hunting malware with Python kuinka haittaohjelmia ajetaan. Puheen aikana pääsi näkemään myös F-Securen vakavaa suhtautumista tietoturvaan. Cafasso kertoi, että läppäriä, jolla ajetaan malwarea millään tavalla, kutsutaan punaiseksi läppäriksi. Tämä tarkoittaa, että jos koneelle on mitenkään saatettu malwarea, edes virtuaalisesti sillä ajettavaan ympäristöön, ei konetta saa kytkeä mihinkään paitsi videotykkiin – eikä etenkään laittaa siihen muistitikkua. Hän näytti kolme erilaista haittaohjelmaa ja kertoi niiden toiminnasta.

Ohjelmistovirheitä voi ennustaa

Tommi Penttisen puheessa Bug forecasting by visualizing code evolution  käsiteltiin sitä, miten ohjelmistovirheitä voi ennustaa visuaalisin menetelmin. Hän viittasi paljon Adam Thornhillin kirjaan Your Code as a Crime Scene sekä käytti samaisen Code Maat -ohjelmistoa versiohallinnan kuvaamiseen. Sillä voi nähdä paitsi koodimoduulien omistajuutta, myös paljonko muutoksia koodi on vaatinut. Tästä voidaan päätellä riskikkäitä alueita ja mahdollisia puutteita testauksessa. Jos tällaiset haasteet havaitaan ajoissa, voi niihin myös puuttua ennen kuin nk. tekninen velka kasaantuu holtittoman suureksi ja korjaaminen tulee kalliimmaksi kuin heti hyvin tekeminen.

Lightning talkit

Lightning talkeja oli vain muutama. Niiden lisäksi PyConin sponsorit pitivät omat puheenvuoronsa. Suurin osa niistä oli odotesti rekry-puheita, paitsi Local Bitcoinsin, joka keskittyi Bitcoin-maailman tapahtumiin ja Bitcoinia muistuttaviin muihin blockchain –teknologioihin. Oli virkistävää, että kerrankin sponsori ei ollut vain rekrytoimassa, vaan esitteli uusia näkemyksiä.

Pluginit Pythonissa

Oma talkkini oli nimeltään Plug in with Python. Kerroin sen aikana, mitä pluginit ovat ja miten niitä voi koodata sovelluksiin. Itseäni kiehtoo ohjelmien eräänlainen väärinkäyttö, eli toiminnallisuuden muokkaaminen. Kävin läpi hieman erilaisten ohjelmistojen plugin-arkkitehtuureja ja omaa aiempaa koodia. Valmisteluksi olin tehnyt yksinkertaisen tekstinmuokkaajan PyQt5-käyttöliittymäkirjastolla. Lopuksi tein myös hieman livekoodausta, joissa näytin yleisölle, miten hommat hoituvat käytännössä.

Mitäs Dockerille kuuluu?

PyConin lopuksi oli perinteinen illallinen, jossa päästiin jatkamaan tauoilla lupaavasti alkanutta verkostoitumista. Yksi konferenssien parhaita puolia on se, kun pääsee näkemään tuttuja, joita ei niiden ulkopuolella juuri kohtaa. Lisäksi tietenkin pääsee tapaamaan aivan uusia ihmisiä. Jatkoilla juttelimme paljon Dockerista ja siitä, kärsiikö se samoista ongelmista kuin vuosi sitten. Vuosi sitten oli paljon keskustelua esimerkiksi virheviestien logituksen vaikeudesta ja parhaiden käytäntöjen puuttumisesta. Parhaat käytännöt ovat ilmeisesti kehittyneet hyvin viime vuoden aikana, ja logitukseen on jonkinlaista ratkaisua. Pienten terävien kulmien takia minusta ei tullut suoraan Docker-fania; se ratkoo kyllä ongelmia, mutta ongelmiin on muitakin päteviä ratkaisuja. Siitä huolimatta heräsi halu päästä perehtymään siihen tarkemmin. Päivä päättyi rennosti oluttuopilla One Pintissa.

 //Kuva: Tambako the Jaguar, Flickr

Pilvipalvelut vuonna 2020

Viiden vuoden kuluttua pilvipalveluja otetaan käyttöön myös siksi, että se on tietoturvallisin valinta.

Senja Larsen kirjoitti Kauppalehdessä pilvipalveluiden voittokulusta ja vanhojen, aikansa eläneiden IT-käytäntöjen hautajaissaatosta. Hän toivoi erityisesti, että Suomessa tajuttaisiin hylätä kyseinen saattoseurue, kääntää katseet nykyaikaan ja ymmärtää, että pilviarkkitehdit ovat uuden ajan IT:n avainosaajia. Innostuin Larsenin artikkelin pohjalta pohtimaan pilvipalveluiden tulevaisuutta. Julkaisin luonnoksen tästä blogauksesta alunperin Facebook-tililläni.

Tärkeimmät muutokset pilvipalveluissa viimeisen viiden vuoden aikana

Vaikuttavimmat muutokset pilvipalveluiden käytössä viimeisten viiden vuoden aikana ovat johtuneet siitä, että palvelujen käytöstä on saatu käytännön kokemusta. Etukäteen ei ollut selvää, että:

  1. Amazonin pisimmät katkot ovat olleet lyhyitä ja parhaat sovellusarkkitehdit ovat luoneet pilvijärjestelmiä, joilla ei ole ollut käyttökatkoja koko ajanjaksona.
  2. Hinnat todella jatkuvasti laskevat ja että tähän järkyttävään hinnan laskuun voi luottaa omassa budjetoinnissaan.
  3. Tietoturva on ollut kunnossa: mitään sellaisia vakavia haavereita ei ole nähty, joilta olisi vältytty omilla konesaleilla.

Ennuste: pilvipalvelut 2020

Oma ennusteeni on, että seuraavan viiden vuoden aikana:

  • Amazonin kaltaiset pilvipalvelut muuttuvat kaikissa tapauksissa halvemmaksi, kuin omien servereiden ostaminen ja käyttäminen.
  • Sovellusten kehittämisestä tulee niin paljon helpompaa, ettei uusi sukupolvi kehittäjiä enää edes osaa asentaa palveluita muualle kuin pilveen.
  • Amazonin ja sen kaltaisten palveluiden tietoturva paranee niin paljon, että palvelut siirretään niihin tietoturvasyistä.
  • Uuden sukupolven ylläpitäjät kieltäytyvät vanhojen palvelimien tekohengityksestä. He pitävät pilven ylläpitotyökaluja itsestäänselvyyksinä.
  • Amazon tekee oman integraatioalustan, joka vetää sovellustoimittajia magneetin tavoin – ei vain pilveen, vaan juuri heidän pilveensä.

En ihmettelisi, vaikka samalla Amazonin kaltaisten yritysten kyky investoida siihen, että käyttö menee juuri heidän pilveensä lisääntyisi. Applen tavoin he voivat ostaa uusien komponenttien koko vuoden tuotannon tai luoda App Storen kaltaisia markkinapaikkoja, jotka ratkovat ohjelmistoyritysten myynnin ja markkinoinnin ongelmia.

Entä tietoturvavaatimukset?

Näyttäisi siltä, että suurimpien toimittajien pilvipalvelut ovat turvallisempia, kuin käyttäjien omat konesalit. Niiden tietoturvassa akilleenkantapäänä on ulkopuolisten tahojen vaatimusten toteutuminen. Monet viranomaiset ovat asettaneet pikkutarkkoja teknisiä tietoturvavaatimuksia ja muut tavat toteuttaa yhtä tehokasta turvaa eivät heille kelpaa.

Miten siis käy vaatimuksenmukaisuudelle vuoteen 2020 mennessä?

Vaatimuksenmukaisuutta tai tietoturvaa kaipaavat palvelut jakautuvat yhä tiukemmin kolmeen kategoriaan:

  1. Palvelut jäävät Suomeen niiden osalta, joissa vaatimukset ovat kotimaisia. Tämä palvelujen joukko saattaa jopa kasvaa, mutta tuskin yhtä nopeasti kuin kansainväliset pilvipalvelut. Näiden hinnat tulevat myös jäämään korkeammalle kuin kansainvälisille markkinoille tarkoitetuilla palveluilla.
  2. Ne palvelut, joiden vaatimukset ovat globaaleja, esimerkiksi luottokorttitiedon PCI-DSS, tulevat siirtymään yhä useammin globaaleihin pilviin. Vaatimuksenmukaisuuden toteuttaminen miljoonalle serverille maksaa vain vähän enemmän kuin oman konesalin kahden palvelimen tarkastaminen.
  3. Palvelut, joiden pitää olla mahdollisimman turvallisia, mutta joiden turvatasosta ei ole ulkopuolisia teknisiä vaatimuksia, jäävät joksikin aikaa vielä tuttuihin konesaleihin, mutta pilvien turvaominaisuuksien parantuessa, ne siirretään nopeasti turvallisempiin holveihin.

Omien konesalien käyttäjille käy kuten Cobol-kehittäijille. Huomaamattaan valtavirta muuttuu tehottomaksi poikkeukseksi, jonka käyttäjiä salaa säälitään heidän selkänsä takana.

 

// Credit for Hubble image: NASA, ESA, N. Smith (University of California, Berkeley), and The Hubble Heritage Team (STScI/AURA) Credit for CTIO Image: N. Smith (University of California, Berkeley) and NOAO/AURA/NSF

Alhainen latenssi luo laatua myös palveluissa

Latenssin mittaus ei ole vain kauniita palloja, se on vakavaa tiedettä. Kuva: Kyle Hailey

Vanha vitsi sanoo, että ensimmäisessä työpaikassa vaikuttaa fiksummalta kun onkaan, kun vain kysyy, miten voisimme lyhentää prosessin läpimenoaikaa. Mutta vitsi ei olisi hauska, jos siinä ei olisi ripausta totta.

Latenssi käännetään yleensä vasteajaksi, ja se on oleellinen käsite kun puhutaan siitä, miltä ohjelmisto tuntuu käyttäjälle.  Jokainen meistä on kokenut esimerkiksi hitaan verkkosivun: jos verkkosivu latautuu hitaasti, käyttäjä tuskastuu ja poistuu, ja yritys on juuri menettänyt potentiaalisen asiakkaan. Googlen suositusten mukaan verkkosivun olisi latauduttava kahdessa sekunnissa, ja Amazonin tutkimus vuodelta 2008 kertoo, että jokainen 100ms:n – siis sekunnin kymmenesosan – lisäys verkkosivun latautumiseen pudotti kävijämäärää 1%:lla. Aika on rahaa, mutta Amazonilla millisekunnit ovat miljoonia.

Eritoten mobiiliverkkosivuilla vasteajan optimointi korostuu, koska tyypillinen mobiiliverkko lisää kymmeniä, ellei satoja millisekunteja ylimääräistä jokaiseen uuteen selaimen tekemään verkkoyhteyteen.  Yksi iso syy mobiiliapplikaatioiden suosioon onkin se, että käyttäjän kokemus on helpompi optimoida, kun kaikki hitaasti latautuvat elementit (esim. kuvat ja muut mediatiedostot) on jo asennettu puhelimeen, ja varsinainen verkkoyhteys voidaan suorittaa taustalla. Lopputulos sekä tuntuu nopeammalta, että näyttää paremmalta.

Ennen vanhaan palvelimen hajoaminen tarkoitti uuden fyysisen palvelimen tilaamista, ja pahimmassa tapauksessa viikkojen – parhaimmassakin tapauksessa tuntien odottelua, että uusi palvelin saatiin tilattua, asennettua ja konfiguroitua tuottavaan työhön. Eräs tärkeä syy siihen, että pilvipalvelut ovat ottaneet niin vahvasti tuulta alleen on se, että nyt palvelimen vaihtaminen kestää minuutteja – ja jos hitaan ihmisen ottaa välistä kirjoittamasta komentoja, ehkä vain joitain kymmeniä sekunteja.  Kuten ekonomi sanoisi, prosessin läpimenoaika on optimoitu.

Mutta tämähän on vain koodausta?

Kun puhutaan ohjelmistoarkkitehtuurin suorituskyvystä, tarkoitetaan kahta asiaa: kuinka monta toimintoa järjestelmä pystyy suorittamaan sekunnissa, ja kuinka kauan yksittäinen toiminto kestää.  Nämä eivät ole täysin toisistaan riippumattomia – jos verkkopalvelussa pystytään palvelemaan yksi pyyntö sadassa millisekunnissa, jolloin yksi CPU pystyy vastaamaan 10 pyyntöön sekunnissa. Jos latenssi puolitetaan 50 ms:iin, yksi CPU pystyy vastaamaan 20 pyyntöön sekunnissa, jolloin palvelu tarvitsee vain puolet keskusyksiköiden määrästä, mikä puolestaan on suoraa rahansäästöä.

Vaikka on siis tärkeää rakentaa skaalautuvaksi tarkoitettu järjestelmä sellaiseksi, että siihen voi tarvittaessa vain lisätä uusia koneita, käyttäjälle näkyvä suorituskyky on usein kiinni puhtaasti järjestelmän latensseista.  Näitä syntyy järjestelmässä monissa kohtaa, ja vaikka alla olisi kuinka modernit teknologiat, huonoa arkkitehtuuria voi olla silti vaikea skaalata. Latenssia voi olla missä tahansa kohtaa järjestelmässä DNS-kyselyistä tietokantakoneen levyaccessiin asti, ja satunnaisiin paikkoihin välimuistien lisääminen voi jopa huonontaa tilannetta. Periaatteessa hyvässäkin arkkitehtuurissa voi syntyä pullonkauloja yllättäviin paikkoihin, sillä tuotantoliikenne ei yleensä ole aivan sellaista, mitä on suunniteltu. Siksi esim. profilointi ja oikeanlainen logittaminen ovat ensiarvoisia työkaluja myös tuotantojärjestelmissä.

(Sivuhuomiona sanottakoon, että IT-arkkitehdin työ on yksi niitä maailman harvoja töitä, jossa valon nopeus on todella työtä rajoittava asia: bitti ei yksinkertaisesti voi liikkua Singaporesta Suomeen nopeammin kuin 31 millisekunnissa, ellei joku keksi keinoa suihkuttaa neutriinoja suoraan pallon läpi.)

Latenssi asuu rosessissa

Yksi syy siihen, miksi ketterät menetelmät (engl. agile) on otettu nykyään käyttöön on se, että se parantaa tiimin kykyä reagoida muutoksiin – siis pienentää tiimin latenssia. Liiketoimintaympäristön tai spesifikaation muuttuessa ei ole varaa palata takaisin piirustuspöydälle rakentamaan kaikkea alusta, vaan lyhyillä iteraatioilla pyritään pitämään tiimin kyky ohjata itseään oikeaan suuntaan mahdollisimman nopeana.

Ketterien menetelmien tavoite on lyhentää tämän kierron kestoa.
Ketterien menetelmien tavoite on lyhentää tämän kierron kestoa.

Perinteinen tapa kuvata asiaa on kuvassa oleva prosessipyörä. Näitä pyöriä on monenlaisia, mutta ketterien menetelmien perusperiaate on se, että yhtä ympyrän kierrosta – siis läpimenoaikaa – yritetään nopeuttaa mahdollisimman paljon.  Toimiva, ketterä tiimi pystyy viemään tuotantoon uusia ohjelmistoversioita 15-20 kertaa vuorokaudessa kuitenkaan riskeeraamatta järjestelmän toimintaa.  Tämä tarkoittaa sitä, että esimerkiksi ohjelmistovirheisiin voidaan reagoida erittäin nopeasti, jolloin tuottava työaika kohdistuu varsinaiseen tekemiseen, eikä niinkään odotteluun.

Koskee kaikkia koko firmassa

Olisi kuitenkin tyhmää ajatella vasteaikaa vain designerien ja nörttien valtakuntaan kuuluvana asiana. Asiakkaalle kaikenlainen yhteistyö yrityksesi kanssa koostuu latenssista: Palvelusi on oltava helppo ja nopea löytää (harrasta hakukoneoptimointia), verkkosivujen on latauduttava nopeasti (se nörttiosuus), niiden on selkeästi ja välittömästi kerrottava, miksi juuri täältä pitäisi ostaa ja mitä sieltä saa (se designer-osuus), kysymyksiä pitää olla helppo esittää ja niihin pitää saada nopeasti vastaus, oston ja tuotteen käytönoton pitää olla nopeaa ja sujuvaa – ja jopa tuotteen käytön lopettamisen pitää olla helppoa.

Asiakkaallasi on parempaakin tekemistä kuin ihmetellä. Peliteollisuus on ymmärtänyt tämän: käyttäjä on saatava koukkuun ensi hetkestä alkaen, koska verkkokaupasta saa miljoona muutakin peliä, jos tämä peli ei heti aukene. Jos jotain pelimaailmasta tulisi siirtää B2B tai B2C-puolelle, niin tämä.

Piilaaksossa on kirjoittamaton sääntö, jonka mukaan jokaiseen sähköpostiin tai muuhun yhteydenottoon on vastattava alle 24 tunnissa. Useimmat vastaavat sitä nopeammin, myös viikonloppuisin.  Harva asia tekee asiakkaan olon yhtä ei-toivotuksi kuin hidas vasteaika, ja nopea vastaaja usein saa myös asiakkuuden.  Tässä olisi monella firmalla parannettavaa.

Asiakkaan kannalta pieni latenssi on laatua.

Lisätietoa verkkosivujen optimoinnista

Steve Souders: High Performance Websites

Tämän artikkelin on kirjoittanut Janne Jalkanen  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.