Epäonnistuitko sinäkin tiedolla johtamisessa? – Organisaatioiden yleisimmät virheet ja miten niistä selvitään

Organisaatioiden toiminta tuottaa dataa, jota pyritään hyödyntämään päätöksenteossa. Halutaan tehostaa toimintaa tai säästää rahaa. Tiedolla johtaminen ei ole kuitenkaan niin helppoa kuin miltä se kuulostaa. Datan keräämiseen ja sen analysointiin voi kulua yllättävän paljon ostettuja tai omia resursseja. Analyysien luvut saattavat heittää tai olla suorastaan virheellisiä! Dataa on, mutta kukaan ei tiedä missä ja miten paljon. Tässä kohtaa tekee mieli heittää hanskat tiskiin. Muotivillityksiä! Hoidetaan tämä niinkuin aina ennenkin.

Eikö kuulostakin tutulta? Lue eteenpäin, sillä tässä blogissa nostetaan esiin viisi hyvin yleistä ja silti keskeistä ongelmien aiheuttajaa sekä ratkaisuehdotuksia niihin.

 

1. Ei tiedetä mitä tietoa kannattaisi kerätä

Yleensä organisaatiossa ei tunnisteta etukäteen mitä tietoa tarvitaan ja milloin. Keräillään varmuuden vuoksi vähän kaikkea. On kenties mallinnettu prosesseja, mutta astuttu “Näin toivoisimme, että asiat olisivat” -ansaan. Ideaalitilanteen kuvaaminen on ajan ja rahan hukkaa.

Ryhtiliike voidaan ottaa seuraamalla mitä työntekijöiden arjessa päivittäin tapahtuu. Tärkeintä on mallintaa todellinen, jopa inhorealistinen, kuva siitä millaisia työvaiheita prosessiin kuuluu ja millaista tietoa vaiheiden välillä liikkuu. Näin päästään kiinni ongelmakohtiin ja aidosti ratkomaan niitä. Mainio menetelmä näiden haasteiden ratkomiseen on arvovirtakartta. Mistä työstä todella syntyy lisäarvoa?

Tueksi kannattaa lisätä myös arvoketjukartta. Se kuvaa organisaation toimintaympäristönsä kontekstissa ja tekee ilmeiseksi miten nykytilasta päästään kohti tulevaa ja luodaan pohjaa strategialle ja investoinneille.

2. Tieto on levällään siellä sun täällä

Turhan tai päällekkäisen tiedon kerääminen aiheuttaa tilanteen, jossa organisaatio hukkaa aikaa, resursseja ja rahaa sirpaleisen ja epätäydellisen tiedon haalimiseen. Samaa dataa voi löytyä useasta eri järjestelmästä. Eri järjestelmien päällekkäiset tiedot eivät täsmää. Tietoa ei voi siirtää eri järjestelmien välillä nopeasti tai ollenkaan. Organisaatiolla on lopulta paljon tietoa, joka ei tuota lisäarvoa tai on täysin kelvotonta analyysien tuottamiseen. Tavoitteena on uskaltaa luopua turhasta ja yhdistää päällekkäisiä toimintoja. Tiedonhallinta saadaan teknisesti hanskaan kokonaisarkkitehtuuri- ja sovellusarkkitehtuurisuunnittelulla. Arvoketju- ja arvovirtakartat toimivat mainiosti myös tietovirtojen mallinnuksessa.

3. Kaikki keräävät samaa irrallista tietoa – monta kertaa ja turhaan

Raportteja varten kerättävää tietoa ei yleisesti saada suoraan päivittäisen työn tuloksena. Tiedon kerääminen ja ylläpitäminen onkin työlästä, hidasta ja kallista. Erillisiin tiedonkeruisiin kuluva aika ja raha eivät pidemmän päälle kannata, vaan ajavat organisaation tiedonhallintaa entistäkin kaoottisempaan tilaan. Laadukkaan tiedon tuottaminen vaatii rohkeutta ja uskallusta luopua hyödyttömän tiedon keräämisestä. Organisaation prosesseja tehostamalla tieto syntyy osana päivittäistä työtä. Prosesseja hiotaan esimerkiksi Toyota Kata ja Lean Change Management -menetelmillä. Ymmärretään mikä on se päätös, joka tiedon pohjalta ollaan tekemässä ja varmistetaan, että käytettävissä on juuri tämä tieto.

4. Prosessikuvaukset ja työohjeet ovat antiikkisia

Ei riitä, että prosessit on piirretty kerran. Organisaatio uudistuu, työntekijät vaihtuvat ja menetelmät muuttuvat. Vähintä mitä voidaan tehdä on aika ajoin päivittää prosessi. Tehokkaampi tapa on pyrkiä ymmärtämään etukäteen toimintaympäristöä, sen toimijoita ja lainalaisuuksia. Suunnitellaan etukenossa seuraavan sukupolven ratkaisuja. Näin voidaan varautua ajoissa tarvittavilla toimenpiteillä, joita vaaditaan myös kerättävän datan ja järjestelmien suhteen. Konkreettisena esimerkkinä siirrytään ihmisten suorittamasta maastomittauksesta ilmakuvaukseen ja tekoälyn suorittamaan hahmontunnistukseen. Ennakoimalla vältetään tilanne, jossa uudenlaista tietoa ei saada tallennettua vanhaan järjestelmään. Ennakoimalla on mahdollista olla kilpailijoita edellä, reagoimalla ei niinkään.

5. Tieto on hapantunut käyttökelvottomaksi

Usein tiedon päivittää ihminen. Ihmiset taas tekevät paljon virheitä, unohtavat tai laiminlyövät päivittämisen ja tulkitsevat asioita eri tavoin. Tiedonhallinnan ylenkatsominen johtaa kaaokseen, jossa tietoa on syötetty niin monella eri tavalla, että siitä ei voida laskea edes yksinkertaisia tilastoja. Tai jos lasketaan, saadaan vääriä tuloksia! Mittajärjestelmän arviointi, MSA(measurement system analysis), on hyvä työkalu, kun arvioidaan kuinka luotettavaa dataa ollaan keräämässä.

Nykyään koneet voivat hoitaa tiedonkeruun ja muita rutiinitöitä. Luotettavin tiedon ylläpito ja päivitys tarvitsee edelleen ihmistä, mutta käytettävät sovellukset pitäisi suunnitella niin, että ne ennaltaehkäisevät virheitä ja luovat mahdollisimman automaattisesti laadukasta tietoa. Lisäksi kaikissa järjestelmissä pitäisi olla modernit rajapinnat, joiden avulla dataa on helppo lukea, ylläpitää ja kirjoittaa.

Kuka päättää siitä mitä ja miten tietoa kerätään?

Aika harva organisaatio saa kiitettävää arvosanaa tiedonhallinnassa. Mieti vastauksia seuraaviin kysymyksiin ja vertaa niitä aiemmin lueteltuihin kipukohtiin. Miten teidän työpaikallanne on järjestetty seuraavat asiat?

  • Kuka päättää millaisia analyysejä ja raportteja organisaatiossa tarvitaan?
  • Millä perusteella päätetään, että raportti on tärkeä?
  • Onko raportointi koordinoitua ja keskitettyä vai tekevätkö kaikki yksiköt ja osastot omia tilastojaan siilomaisesti?
  • Onko raporteille laskusäännöt ja lasketaanko tilastot vuosittain samalla tavalla?
  • Voiko eri vuosien tuloksia vertailla suoraan keskenään?
  • Miten aineisto kerätään? Kerätäänkö aineistoa systemaattisesti joka vuosi vai tarpeen mukaan ad-hoc?
  • Osallistuuko koko organisaatio tiedon keruuseen vai onko se tietyn yksikön tehtävä?
  • Tallennetaanko kerätty aineisto aina johonkin samaan paikkaan?
  • Onko aineiston keräämiselle ohjeet?
  • Onko tiedonkeruu ulkoistettu?
  • Miten eri toimittajia ohjeistetaan tiedonkeruussa?
  • Onko haluttua aineistoa mahdollista edes kerätä?
  • Miten kerättyä tietoa ylläpidetään?
  • Syntyykö tietoa automaattisesti prosesseista?

Laadukas tieto pähkinänkuoressa

  • Laadukkaan päätöksenteon tueksi tarvitaan tuoretta, vakioitua ja virheettömästi ylläpidettyä dataa.
  • Kerätään vain päätöksentekoa ja päivittäistä työtä tukevaa tietoa
  • Yhtä tietolajia kerätään vain yhteen paikkaan
  • Tunnistetaan turha tieto ja uskalletaan luopua siitä
  • Tieto muodostuu osana päivittäisiä työprosesseja
  • Tieto on sidottu aikaan
  • Automatisoidaan keruuprosesseja mahdollisimman paljon
  • Standardoidaan tieto

 

Blogitekstin kirjoituksessa on konsultoitu myös Lean Six Sigma Belt Sensei Miika Kuhaa.

Kato webinaari: Paikkatietoteknologian hyödyntäminen

Millä perusteella teknologia tulisi valita?

Gartnerin malleissa ja menetelmäkäsikirjoissa kaikki menee ihanasti, kun taas käytännön elämässä kehitystiimit ja IT-yksiköt joutuvat tekemään teknologiavalintoja usein puutteellisilla tiedoilla. Erityyppiset hankinnat tulevat eteen niin harvoin, että edellisen kierroksen jälkeen markkina ja sen pelurit ovat ehtineet muuttua täysin. Ostaja on helposti toimittajien mainospuheiden varassa. Vai onko? Ei välttämättä, kun pitää muutaman perusasian valintoja tehdessään mielessä.

 

1 Panosta liiketoimintakriittisyyden mukaan

Ihan ensin hankintaa miettiessä on syytä tunnistaa, minkä verran järjestelmään on perusteltua panostaa. Jos kyseessä on aivan liiketoiminnan keskiössä oleva järjestelmä, jolla etsitään kilpailuetua ja kirkkaampaa tulevaisuutta, sen kehittämiseen voidaan panostaa aivan eri tavalla kuin jos kysymys on toiminnan rutiineista.

Jos tarve kuuluu jälkimmäiseen kategoriaan, hankintaa suunniteltaessa kannattaa saman tien kääntää päälle vaihde, jolla ratkaisut tarpeisiin mietitään vaikka millä ilveellä olemassa olevien valmisratkaisujen ympärille ja kustomointia tehdään minimaalinen määrä.

Seuraavat alaluvut koskevat erityisesti ensimmäisen kategorian teknologioiden valitsemista, niihin kun on todella aihetta keskittyä.

 

2 Varmista käyttäjätarve

Seuraavaksi on ymmärrettävä käyttäjän tarve. Mikä on käyttäjän perusongelma, joka teknologian on syytä ratkaista? Millainen palvelu sen voisi ratkaista, ja miten pystymme varmistamaan että potentiaalisen toimittajan tai meidän itse kehittämämme teknologia oikeasti tekee näin?

Jos mahdollista, ennen investointia on hyvä käyttää viikko-pari sen varmistamiseen, että käyttäjätarve on oikeasti kuultu käyttäjiltä itseltään eikä mielikuviteltu kulmahuoneessa. Ja samalla on hyvä yksinkertaisimmalla mahdollisella prototyypillä myös varmistaa, että löyhästi kaavailemamme ratkaisu oikeasti täyttää tuon käyttäjätarpeen – ennen kuin olemme upottaneet siihen merkittäviä määriä aikaa ja rahaa.

 

3 Analysoi liiketoiminnan tarve

Lähdettäessä toimittamaan käyttäjille sitä mille löytyi toivottavasti huutava tarve, on seuraavaksi selvitettävä liiketoiminnan teknologialle asettamat reunaehdot. Miten asiakkaan toivoma asia aiotaan toimittaa? Onko valintoja, joita on syytä tehdä vaikkapa hinnoittelun tai järjestelmän toimintasyklien suhteen?

 

4 Tutki uudet fiksut työtavat

Käyttäjän ja liiketoiminnan tarpeen lisäksi teknologiaan useimmiten liittyy organisaation työn arkea: teknologialla tehtävää asiakaspalvelutyötä, ylläpitoa tai taustaprosessia. Teknologiaa valitessasi haluat luultavasti varmistaa, että organisaatiosi on hahmottanut työtavan jolla sitä tullaan käyttämään.

Yleensä tässä kohtaa ei haluta menettää sitä mahdollisuutta, että uuden teknologiavalinnan siivin voidaan uudistaa myös työtapa. Kun käytetään hetken aikaa työtavan analysointiin, huomataan, mikä osa tekemisestä oikeastaan tuottaa arvoa asiakkaalle. Arvovirtakartta on tähän hyvä väline. Analyysin jälkeen teknologiavalinnalla voidaan linjata, että työssä saadaan oikeasti keskityttyä asiakkaan saamaan arvoon ja pakolliset rutiinit pystytään hoitamaan mahdollisimman tehokkaasti.

 

5 Kartoita tietojärjestelmäympäristö

Harvoin teknologiaa päästään valitsemaan puhtaalle pöydälle. Yleensä ympärillä on elinkaaren eri vaiheissa olevia tietojärjestelmiä joihin uuden teknologian pitää liittyä, ja palapeli rajoittaa valintoja. Näiden mallintamisen tapaa tärkeämpää on, että ne ja niiden integrointitarpeet tunnistetaan ennen teknologian valintaa. Esimerkiksi: millaisia rajapintatarpeita teknologian pitäisi täyttää?

 

6 Huomaa muut rajoitukset

Edellä mainittujen lisäksi on olemassa yleensä vielä muitakin ulottuvuuksia, jotka rajoittavat teknologiavalintaa. Joskus teknologian käyttöönotolla on aikataulu, joka rajoittaa ratkaisuvaihtoehtoja – kehitykseen panostamiseen ei yksinkertaisesti ole aikaa, vaan pitää rakentaa olemassa olevien ratkaisujen päälle. Joskus toimintaan liittyy lainsäädäntöä, joka asettaa teknologialle rajoituksia, esimerkiksi tietojen sijainnin tai muiden tietoturvatekijöiden muodossa.

 

7 Mieti elinkaaritarpeet

Useimmiten tässä pohdinnan tässä kohtaa vaatimusten yhdistelmä ajaa jo kohti melko harvalukuista joukkoa teknologia- ja toteutustapavaihtoehtoja. Yksi pohdinta on kuitenkin vielä jäljellä: teknologian elinkaari. Useimmiten halutaan välttää joutumista tuoreen teknologian ensimmäisten kokeilijoiden joukkoon.

Kun teknologia on ollut jo jonkin aikaa olemassa, tarjolla on ilmaista etua muiden tekemistä virheistä ja kehittämistä perusasioista eli hienosti sanoen ekosysteemin kypsymisestä. Toisaalta jos kysymys on kriittisestä teknologiasta ja haetaan kilpailuetua, joskus kannattaa myös maksaa oppirahat ja olla eturintamassa.

Joka tapauksessa on hankittava markkinaymmärrystä ja joskus myös meediopalveluita hahmottaakseen myös elinkaaren loppupää: Miten pitkälle tulevaisuuteen teknologialle voi olettaa jatkuvuutta vs. käyttötarpeen mitta? Miltä ekosysteemin kehitys näyttää, vaikuttaako siltä että teknologialle on tarvittaessa löydettävissä ylläpitäjiä myös tulevaisuudessa? Olemmeko investoimassa kisojen voittajahevoseen vai näyttäkö uhkaavasti siltä että kyseessä on häviäjätallin kaakki?

 

Työkaluja:

Tarpeen pikadokumentointiin voit käyttää ohjelmiston visiolakanaa, ks. https://www2.codento.fi/lataa-lean-visiolakana-ohjelmistoprojektiisi/

Lisää prosessien analysoinnista ks. https://www2.codento.fi/2017/08/hyvaa-halvalla-nopeasti/

 

Lataa opas: Uuden verkkopalvelun teknologiavalinnat

Onko blockchain yrityksellesi pelkkä troijan hevonen?

Harvat uudet teknologiat ovat yhtä kiinnostavia ja samalla yhtä vaikeita hyödyntää olemassaoleviin liiketoimintamalleihin kuin lohkoketju, eli blockchain. Lohkoketjun kansikuvajutut bitcoin-kurssikäyrän kera ovat helposti kirjoitettavia, teknologiaan on sijoitettu valtava määrä rahaa ja näyttää siltä, kuin lohkoketjulla olisi todella helppo tienata miljoonia tai miljardeja. Lohkoketju on vieläpä todella hienoa teknologiaa!

Väitän silti voimakkaasti, että useimmille yrityksille lohkoketju on tässä vaiheessa pelkkä kangastus tai troijan hevonen, vaikeasti kaupallistettava superkiinnostava teknologia, joka häiritsee aivan yhtä kiinnostavien mutta nopeasti kaupallistettavien teknologioiden kehitystä.

Blockchain-hypestä tulee Itselle mieleen Ford-autovalmistajan Nucleon -konsepti, kuvankaunis amerikanrauta, jonka moottorina piti olla ydinreaktori. Kun ydinreaktorit olivat kuuminta hottia, niitä ajateltiin asennettavan autoihin, lentokoneisiin, juniin ja jokaiselle asuinalueelle. Todellisuus olikin sitten jotain muuta.

Vähän sama tilanne on lohkoketjun kanssa. Valtavan hienoa teknologiaa, jolla voidaan tehdä uusia palveluita, joita ennen ei olisi voinut kuvitellakaan. Valitettavasti suurin osa nykyisen liiketoimintamallin ja lohkoketjun yhdistelmistä on yhtä banaaleja kuin Fordin ydinreaktorilla käyvä henkilöauto – teoriassa mahdollisia, mutta härveleitä, joiden haitat eivät koskaan vastaa niistä saatua hyötyä.

Mistä sitten kannattaisi aloittaa? Itse ehdotan, että nyt on oikea aika jakaa uusien teknologioiden kehitys kolmelle eri tiimille tai striimille, jos tilanne on samanlainen kuin monilla asiakkaillamme.

  • Tiimi I

Useimmat organisaatiot ovat yllättävän käsityövaltaisia, kun niihin kunnolla tutustuu. Arkisia työvaiheita varten tulostetaan A4:ia, tieto siirretään järjestelmästä toiseen käsin tai eri järjestelmissä olevaa tietoa ei saada yhdistettyä fiksumpaa toimintaa varten.

Yritys, jonka tiedot ovat tällä tavalla hujan hajan ei voi onnistua uudistumisessa, mutta onneksi nykyään yhteisen näkymän luominen on halvempaa ja nopeampaa kuin koskaan aiemmin, eikä tätä varten ole pakko ostaa SAP:pia tai mitään muutakaan monoliittista sovellusta.

  • Tiimi II

Toisena striiminä etsisin kaikki ne kohdat, joissa arkisia päätöksiä tehdään täysin prosessin mukaisesti. Jokainen käsityönä tehty, tarkkaa byrokraattista prosessia noudattava päätös kannattaa automatisoida. Tiedon käsittelyn nopeuttaminen tuo yllättäviä hyötyjä, useimmiten sekä asiakkaalle että myynnille ja markkinoinnille.

  • Tiimi III

On vaikea saada rahoitusta tiimeille I ja II ilman vanhoista malleista poikkeavia liiketoimintasuunnitelmia. Asiat ovat rempallaan, koska loppujen lopuksi vanhassa maailmassa on ollut halvempaa teettää enemmän käsityötä kuin automatisoida prosessit loppuun saakka. Tämä on muuttunut viime vuosina. Automatisointi on jatkossa onnistumisen edellytys, eikä siitä voi tinkiä. Uudet tekoälyyn perustuvat liiketoimintamallit vaativat perustuksekseen hyvää tietoa ja organisaation, joka ei tuhlaa aikaa ja rahaa turhaan käsipelillä tunkkaamiseen.

Tekoäly, tai oikeastaan sen koneoppimiseksi kutsutut toteutustavat, ovat jo arkipäiväisiä. Kaikkien suurten internetyritysten, Googlesta Spotifyhyn, onnistumisen salaisuus on fiksussa koneoppimisen käytössä. Useimmilla toimialoilla tekoälyä fiksusti hyväksikäyttävä yritys tulee seuraavina vuosina pieksemään ne, joiden tekoälytiimi ei ole päässyt vauhtiin.

Kolmostiimi toimii myös loistavana kirittäjänä kahdelle muulle tiimille. Tieto, jonka yhdistäminen on vaikeaa tai johon liittyvät päätökset tehdään vielä käsipelillä, tulee yhdistetyksi ja automatisoiduksi, kun kolmostiimi lupaa sellaista, jota kilpailijalla ei ole – automaattisen asuntolainapäätöksen, juuri sinulle halvalla räätälöidyn puvun valmistuksen tai juuri sinun makuusi viritetyn illallisreseptin.

Me Codentossa autamme teknologiavalinnoissa ja olemme ammattilaisia Tiimien I, II ja III työssä. Etsimme jatkuvasti uusia arkkitehtejä teknologiatiimiimme ja teemme niin suuria kuin pieniä teknologiavalinta toimeksiantoja yksityisellä ja julkisella puolella.

 

Banneri Uuden verkkopalvelun teknologiavalinnat 2018

Etätöissä Japanissa

Kun syys–lokakuussa huomasimme parin kaverini kanssa, että lennot Japaniin olivat pienessä alennuksessa, päätimme tutkia olisiko mahdollista lähteä sinne porukalla. Olen melko uusi työntekijä Codentolla ja erityisesti tuolloin olin vielä upouusi työntekijä. Tiesin että mahdollisuus lähteä Japaniin olisi joko palkaton reissu tai etätyö.

Codentolla kerrottiin jo hakuprosessin alkuaskeleilla, että mahdollisuuksien mukaan etätyöt myös muualla kuin Suomessa onnistuvat. Päätinkin ottaa Japanin-reissun osalta selvää, kuinka sellainen onnistuisi omalla kohdallani. Codenton etähommissa ei tehdä lainkaan firman omia asioita edistäviä töitä, vaan konsultti keskittyy pelkästään asiakasprojektin edistämiseen. Näin tuetaan asiakkaan tavoitteita sekä edesautetaan asiakkaan mahdollisuutta antaa konsultille lupa lähteä pidemmällekin reissulle etätöihin. Lisäksi yrityksenä ja yksittäisinä konsultteina pyrimme siihen, että hommat tulee tehtyä parhaalla mahdollisella tavalla, olipa konsultti sitten tekemässä töitä missä suunnalla palloa tahansa.

Alkuvalmisteluja ennen matkaa

Keskustelin aluksi toimarimme Petrin kanssa, josko voisin tehdä etähommia matkan aikana. Sain Petriltä siunauksen sillä ehdolla, että myös asiakkaalta tulee vihreää valoa. Meillä Codentolla tehdään pääasiassa asiakasprojekteja, siksi hommia tehdään aina asiakkaan aikataulun mukaan. Seuraavaksi juttelin asiakasprojektin vetäjän kanssa mahdollisesta etätyöstä, kerroin myös että saatan tehdä vajaita päiviä etänä. Projektin vetäjä ei edes epäröinyt vaan lupa tuli saman tien kuin apteekin hyllyltä osaksi varmasti siitä syystä, että luottoa minuun löytyy, mutta myös siksi että luottoa Codentoon löytyy.

Etätyöt matkan suunnittelussa keskiössä

Aloimme suunnittelemaan matkaa hyvissä mielin sekä varasimme lennot. Matkasuunnitelmaa muodosteltiin ja hiottiin, korjailtiin ja muutettiin aikataulujen ja muiden asioiden mukaan. Suunnitteluun kuului oleellisena osana myös etätyöt. Hommat ulkomailla saa varmemmin tehtyä, jos se ei estä näkemästä asioita, joita haluan nähdä. Keskustelin myös muiden codentolaisten kanssa etätöistä ulkomailla, ja parhaaksi vaihtoehdoksi muodostui tehdä osa-aikaisia työpäiviä. Lähempänä lähtöpäivää muistuttelin asiakasta sekä projektityökavereitani lähdöstäni ja osa-aikaisesta työpanoksestani. Muistuttelin ihmisiä myös Codentolla, jotta kukaan ei ihmettelisi missä olen. Sovin meidän markkinointivastaavan Eevan kanssa, että kirjoittelisin blogin kokemuksestani, sekä etätyöstä. Lupasin myös hienoja matkakuvia. Juttelin asiakkaan kanssa vielä tarkemmin työtavoista ja olin valmis lähtemään matkoille.

Ja täällä ollaan!

Olen nyt Japanissa, ja teen noin 2–5 tuntia töitä per päivä. Joka päivä olen ollut yhteyksissä asiakasprojektin tiimiin tavalla tai toisella. Töitä on tullut tehtyä junassa, lentokoneessa, rannalla, hotellissa sekä kahvilassa – sopiva paikka on aina löytynyt tosi hyvin. On ollut mukavaa tehdä välillä omissa oloissa töitä. Vaikka yhteydet internettiin ovat välillä olleet mitä ovat, ja joskus projektin tekeminen on ollut hankalaa, niin haasteista huolimatta on projektissa päästy eteenpäin sovitussa aikataulussa.

Kaiken kaikkiaan kokemus on ollut mahtava ja siitä suurin kiitos Japanille. Mahdollisuudesta tehdä matka ja etätöitä iso kiitos niin asiakkaalle kuin Codentollekin!

Katso Codenton avoimet työpaikat

Mikä ihmeen serverless?

Serverless on vuoden 2018 hypesana. Muutaman vuoden takaisen Docker-huuman tapaan monet yritykset tulevat tekemään uusia ja siirtämään nykyisiä palveluitaan serverlessiksi markkinoiduille alustoille. Onkin syytä katsoa mistä asiassa on kyse.

Isompi trendi serverlessin takana on erilaisten liiketoimintojen muuttuminen dataintensiivisiksi. Paradigma IT-puolella tunnetaan nimellä Streaming Platform, joka pohjautuu erilaisten datavirtojen hallintaan. Dataa tulee jatkuvasti lisää, saapuvalla datalla sekä jo aiemmin talletetulla tehdään laskentaa ja sitä säilötään myöhemmin käytettäväksi. Data tallennetaan erilliseen tietovarastoon, ja koska sitä ei jatkuvasti muokata tai käsitellä, on käsittely muuttunut erilliseksi toimeksi.

Yksinkertaisimmillaan data otetaan tietovarastosta, sillä tehdään laskentaa ja tulokset lähetetään käyttäjälle tai talletetaan takaisin tietovarastoon. Samoin saapuva uusi data tai yksittäinen API-pyyntö voidaan haluta käsitellä kertaalleen ilman, että sitä varten on jatkuvasti odottamassa yksi tai useampi palvelin.

Streaming Platform -visualisaatio
Streaming Platform -näkemys Confluent-yrityksen blogista.

Serverlessissä onkin kyse ennen kaikkea ohjelmiston tilattomuudesta. Tilattomuus tarkoittaa, että ohjelmisto saattaa olla PHP-koodin tapaan ajossa vain suorituksensa ajan ja tieto sen tekosista on oltava tallessa jossain sen ulkopuolella, kuten vaikkapa tietokannassa. Hajautettujen järjestelmien yleistyessä on yhä tavallisempaa, että ohjelmistosta on ajossa useampia, jopa satoja, kopioita kerrallaan.

“Serverittömät” palvelut ovat viime vuosina ottaneet sellaisia hyppäyksiä, että termin merkityskin on mennyt matkalla uusiksi. Aikojen alussa eli vielä muutama vuosi takaperin serverless tarkoitti puhtaasti Backend as a Service -tyyppisiä ratkaisuja, joissa pilvitarjoajalta ostettiin tietokantoja tai vaikkapa koneoppimisinfrastruktuuria palveluna. Sittemmin serverless on siirtynyt tarkoittamaan enemmän Function as a Service -tyyppisiä palveluita, joissa yksittäinen pieni tai isompi osa koodia siirretään ajettavaksi palveluntarjoajan suoritusympäristössä. Koska koodi on ajossa vain suorituksen ajan, ei sillä ole erillistä tilaa ja kaikki tilaan liittyvä on haettava erikseen tietokannasta tai esim. AWS:n S3-bucketista. Samanlaiset tilattomat palvelut ovat viime vuosina yleistyneet Docker-konttien ja mikropalveluiden myötä, joten aiemmin luodut tilattomat softat toimivat näppärästi myös serverless-ympäristöissä. Näiltä osin yritys voi luopua myös palvelinylläpidosta, sillä tämä hoituu lähes poikkeuksetta serverless-palveluntarjoajan puolelta.

Kriittisiäkin äänenpainoja on kuultu. Yleisin, hiukan kyyninen näkemys on että kyseessä ei ole mitään uutta. Jo mainittu PHP-ohjelmakoodi on suorituksessa vain ajonaikaisesti ja jo ensimmäisistä webhotelleista löytyi Perlin suorittamiseen tarkoitettu cgi-bin-hakemisto. Serverlessin vahvuus tulee kuitenkin ennen kaikkea ympäristöstä, jossa kaikkea ei tarvitse tehdä enää funktiotasolla. Esimerkiksi AWS:ään pystyy helposti rakentamaan ympäristön, jossa mm. autentikaatio ja osin myös autorisointi on hoidettu ennen pyynnön saapumista serverless-ympäristössä olevalle funktiolle.

Yllä olevaan twiittiin viitaten serverless voi olla hyvä ratkaisu myös keittiön kanssa. Vaikka palveluntarjoajilla on halu esittää asian olevan hyödyllinen ainoastaan heidän ympäristössään, voi serverlessistä olla isojakin hyötyjä myös osana omaa palvelinympäristöä.