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öä.

Slack – miten se vaikuttaa Codento-kulttuuriin?

Inspiroituneena Miikan mainiosta flow-blogauksesta päätin pohtia, miten Codentossa käyttämämme Slack vaikuttaa codentolaisten flow-tilan saavuttamiseen. Slack on pilvipalveluun pohjautuva, tiimien yhteistyötä helpottava viesti- ja arkistointiohjelma, johon pääsee liittymään tiimin ylläpitäjän kutsulla.

Mitä hyötyä me codentolaiset saamme Slackistä? Kysyin asiaa kollegoiltani, ja monissa vastauksissa nousi esille samoja seikkoja.

Jäsentyneempää tiedonvälitystä

Kun Codentossa oli alle kymmenen työntekijää, meillä käytettiin Skypeä. Skypen ja Slackin suurin ero on, ettei Skypeen saa luotua ryhmiä eri keskuisteluille. Niinpä kaikki codentolaisten yhteinen keskustelu – niin huonot vitsit, kuin tärkeät projekti-asiatkin – jouduttiin käymään samassa keskustelussa. Tämä oli vaikeaa jo pienellä poppoolla, ja yrityksen kasvaessa se kävi nopeasti mahdottomaksi. Tärkeät asiat hukkuivat helposti viestivirtaan.

”Slack on tehnyt sisäisestä viestinnästämme paljon jäsentyneempää,” tuumaa konsulttimme Karoliina Luoto. ”Slackissa on helppoa luoda omat kanavat niin vapaammalle keskustelulle, kuin projektitöille ja vaikkapa isompien tarjousten valmistelulle.”

Vapautus meilitulvasta

Monille codentolaisille Slack on tuonut vapautuksen loputtomaan sähköpostivirtaan. ”Edellisessä työpaikassani minulle tuli jopa yli sata meiliä päivässä. Slack on Codentolla dominoiva tapa kommunikoida, joten minulle ei enää tule sähköpostia ollenkaan,” kertoo konsulttimme Miika Kuha. Ei liene ihme, että meilin vähäisyys aiheuttaa yhdessä jos toisessakin codentolaisessa pientä riemua.

Viestit menevät varmasti perille – ja arkistoituvat

Ohjelmistoarkkitehtimme Mikko Herranen taas kiittelee Slackin varmuutta verrattuna hänen edellisessä työpaikassaan käytettyyn, yrityksen sisäiseen IRC-chattiohjelmaan. ”Slackissä ei periaatteessa koskaan menetä yhtään viestiä, eikä myöskään ole vaaraa siitä, että luulet hyvällä syyllä vastaanottajan saaneen lähettämäsi viestin, vaikka todellisuudessa se ei olekaan mennyt perille. Slack myös arkistoi viestit, toisin kuin IRC,” Mikko toteaa. Karoliina komppaa: ”Tämän ansioista vaikkapa lomalta palatessa on helppoa päivittää ymmärryksensä esimerkiksi tietystä projektista.”

Virtuaalinen tukiverkosto

Slack on luonut Codentolle hyvän avun pyytämisen – ja saamisen – kulttuurin. Eri aiheista on helppoa avata keskusteluja. ”Se on sellaista keskinäissparrailua,” luonnehtii Karoliina.

Karoliinan mukaan Slack nousee arvoon arvaamattomaan etenkin, kun on pitkiä aikoja poissa omalta toimistolta. ”Jos asiakkaan luona syystä tai toisesta on stressaava hetki, niin toisinaan on mukava palata omien työkaverien ystävällisen yhteisön pariin.”

Myös Miikan mielestä yksi Slackin suurimpia henkilökohtaisia hyötyjä on se, että vaikka ei pääsisi aina käymään toimistolla, tietää silti, mitä tapahtuu. ”Sellainen pieni kohina kuuluu koko ajan,” Miika toteaa.

Lisää avoimuutta kulttuuriin

Slack tuo myös lisää avoimuutta yrityskulttuuriin. Codentolaiset ovat tottuneet keskustelemaan melkeinpä mistä tahansa Slackissä – ja keskustelut ovat kaikkien niistä kiinnostuneiden nähtävillä. ”Siitä tulee avoimempi kulttuuri väkisinkin,” tuumii ohjelmistoarkkitehtimme Matti Kinnunen. Tämä avoimuus on tietenkin mitä suurimmassa määrin Codenton arvojen mukaista.

Hauskuutta työpäiviin…

Karoliinan mielestä Slackin pienin hyöty ei suinkaan ole se, että siellä pidetään myös hauskaa. “Maailmassa ei ole liikaa insinöörivitsejä, ja nekin ovat tärkeitä,” hän sanoo. Toinen Slackin myötä syntynyt, hauska ilmiö on kustomoidut hymiöt. “Meillä on esimerkiksi kissa, joka haluaa unohtaa näkemänsä, muttei voi. Se on sellaista hauskaa do it yourself -meininkiä,” Karoliina jatkaa.

Äkkiseltään vitsailu ja hymiöt voivat tuntua ajanhukalta, mutta sitä ne eivät suinkaan ole. Vietämme ison osan ajastamme työpaikalla, joten ei ole yhdentekevää, millainen ilmapiiri siellä on. Jos työkaverien kanssa vitsailu parantaa yhteishenkeä ja edistää työssä jaksamista, se on todella arvokasta. Kaikkihan me tiedämme, että aika kuluu nopeammin silloin, kun on hauskaa – miksi siis töissä(kin) ei saisi olla mukavaa?

…mutta myös häiriötekijöitä

Entäpä sitten Slackin haitat? Slack tuo Codenton kulttuuriin ja tiedonvälitykseen paljon hyvää, mutta on selvää, että se voi joskus myös estää flown toteutumista. Jos käsillä on erityistä keskittymistä vaativa työtehtävä, voi jatkuvasti pingaava Slack olla häiriötekijä – tulee houkutus mennä tarkistamaan uudet viestit. “On se tietysti vähän oma vikakin,” tuumii Matti. “Ei olisi pakko mennä aina katsomaan.”

Toisaalta Codentossa on kulttuurisesti hyvin sallittua, että keskittymistä vaativan työn aikana Slack laitetaan kiinni. Jos kollegalla on Slack suljettuna, häneen uskaltaa heti ottaa yhteyttä siitä huolimatta. Kysymyksensä tai asiansa voi viestittää tietäen, että viesti ei häiritse vastaanottajaansa juuri nyt, mutta hän kuitenkin näkee sen heti kun kirjautuu takaisin sisälle. Näin sekä omat, että vastaanottajan työt etenevät joutuisasti.

Kun Codento hyötyy, asiakkaat hyötyvät

Miten sitten Codenton asiakkaat hyötyvät Slack-kulttuuristamme? Lienee ilmiselvää, että kun työaikamme ei kulu turhaan meilivyöryn kahlaamiseen, meillä on enemmän aikaa asiakkaidemme pulmien ratkaisuun.

Vähemmän ilmeinen, mutta silti merkittävä hyöty on myös se, että Codenton työtavat eivät jää toimistomme seinien sisälle. Parhaat käytännöt, hyvän flown ja loistavan yhteishengen – sekä tietenkin insinöörivitsimme – voimme viedä myös asiakkaillemme.

Kuva: Flick Creative Commons, Jeremy Miles

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

Kuinka ohjelmistoja tulee ostaa

Tietojärjestelmähankinnat menevät Suomessa yleensä pieleen, etenkin julkisella sektorilla. Koska olen vuosien varrella useaan kertaan kertonut, 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:

  1. Ostamalla palveluna (pilvestä)
  2. Ostamalla valmiin standardituotteen
  3. 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 keskeintä, 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. 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 kuin 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 nimenomaan 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
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ä. Usein annetaan myyjän kertoa, että mitä oikeastaan kannattaisi ostaa, koska hehän alan parhaiten tuntevat. Jos yhteistyö ei 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.

Teskti on julkaistu alkujaan blogissani OtsoKivekäs.fi.

Tämä teksti julkaistaan myös tulevassa pamfletissani Kuinka tietoyhteiskunta korjataan. Kirjaa voi ennakkorahoittaa Mesenaatti.me:ssä 25.1. asti.

// Yläreunan kuva: Flickr CC, alex roberts.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Inspiraatiota uuden IT:n päättäjille – Codenton uutiskirje 06/2014

Tervehdys muutosagentti!

Ohessa valikoima pilvipalveluihin, ketterään kehitykseen, big dataan sekä modernien tietojärjestelmien teettämisen liittyviä artikkeleja. Iloksi ja inspiraatioksi kehitystyöhösi!

Tässä uutiskirjeessä:

  •    Codentolaiset puhumassa
  •    Gartnerin uusi IaaS-pilvipalvelujen markkinanäkemys
  •    Suomessa yksi maailman suurimmista (sisäisistä) pilvistä
  •    Big Data on vaikeaa finanssialalla
  •    Applen uusi Swift-ohjelmointikieli matkapuhelimiin
  •    Codento ja Agile Finland

Codentolaiset puhumassa

Otso Kivekäs oli toukokuussa puhumassa ICT-Expossa ketterästä hankinnasta.

Karoliina Luoto esiintyi Helsingin Yliopiston digifoorumilla huhtikuussa raflaavalla otsikolla Tuoteomistajan supervoimat – visio tiukkana + ihmiset mukaan.

Gartnerin uusi IaaS-pilvipalvelujen markkinanäkemys

Gartner-tutkimusyhtiön uusin markkinanäkemys pilvi-inframarkkinasta on kiinnostavaa luettavaa alan ammattilaisille. Suuri määrä amerikkalaisia kakkossarjan toimijoita on rankattu alemmaksi kuin aiemmin ja Amazonin markkinajohtajuus on toistaiseksi ilmeistä. Jos artikkeli tuntuu liian pitkältä, kannattaa keskittyä Amazonin, Googlen ja Microsoftin pilvestä kertoviin osioihin.

Codenton Petri Aukiaa haastateltiin arvostettuun GigaOm-blogiin suurten IaaS-toimijoiden hinnoittelusta. Voit lukea artikkelin ja Petrin kommentit täältä.

Suomessa yksi maailman suurimmista (sisäisistä) pilvistä

Julkisista pilvistä tulee helposti suhteellisen isoja, sillä ne tuottavat palveluja monille yrityksille samalla laitteistolla. Sisäisestä pilvestä tulee suuri vain jos sen rakentava yritys tarvitsee valtavasti tietojenkäsittelykapasiteettia ja tämä kapasiteetti kerätään pilven muotoon.

Forbesin sisäisistä pilvistä kertovassa artikkelissa mainitaan vaatimattomasti sivulauseessa Nokian 100.000 prosessoriytimen Eucalyptuksen päälle rakennetusta sisäisestä pilvestä. Se on maailman suurimpia sisäisen pilven kokonaisuuksia. Hyvä, Suomi!

Big data on vaikeaa finanssialalla

Suomen ensimmäinen tuotantokäytössä ollut tietokone tuli Postipankkiin vuonna 1958. Data science central blogin mukaan pitkä tietojenkäsittelyn historia on helposti ongelmana pankeissa ja vakuutusyhtiöissä.

Tietoa on paljon, mutta se on kerätty niin pitkän ajan kuluessa, että uusien analyysien ajo sen pohjalta ei olekaan niin helppoa kuin tällä vuosituhannella perustetuille yrityksille.

Artikkeli on hyvä muistutus siitä, kuinka määrätietoinen finanssialalla on syytä data science -projekteissa olla.

Applen uusi Swift-ohjelmointikieli matkapuhelimiin

Apple on oman tien kulkija monessakin mielessä. Yrityksen puhelimeen on sovelluksia tehty alusta saakka yrityksen omalla Objective-C -ohjelmointikielellä, jota on kritisoitu syystä ja syyttä.

Nyt Apple on kaikessa hiljaisuudessa kehittänyt uuden Swift-ohjelmointikielen matkapuhelinsovellusten tekoon.

Etsimme Codentossa asiakasta, jolla olisi tarve uudelle iPhone- tai iPad -sovellukselle, jonka voimme tehdä Swift-ympäristössä. Olemme valmiit tekemään tavallista tiukemman tarjouksen ensimmäiselle Swift-referenssiasiakkaallemme.

Jos haluat tietää lisää tästä mahdollisuudesta, ota yhteys Petri Aukiaan – petri.aukia@codento.com tai 0400 438 610.

Lisätietoja Swiftistä löydät täältä ja täältä.

Codento ja Agile Finland

Ketterän kehityksen puolestapuhujat ovat Suomessa organisoituneet Agile Finland -yhdistykseksi. Olemme ylpeitä siitä, että Codenton hallituksen puheenjohtaja Jussi Markula on myös Agile Finland -yhdistyksen hallituksen puheenjohtaja. Lisäksi Codenton Karoliina Luoto on nyt Agile Finlandin hallituksen varajäsen. Jussi ja Karoliina, tärkeällä asialla!

Agile Finlandissa on myös uusi ketterän ostamisen ja omistajuuden track, joka keskittyy asiakkaan rooliin ketterässä ohjemistokehityksessä. Codento isännöi 22.5. ensimmäisen ketterän omistajuuden aamutapahtuman otsikolla Ketterän omistajuuden ABC. Katso Jani Ruuskasen presentaatio Valtorin kokemuksista ketteränä asiakkaana.

Erittäin mukavaa kesää kaikille!

Petri ja koko Codento-tiimi

Haluatko tutustua muihin uutiskirjeisiimme?

Jos haluat lukea muita uutiskirjeitämme, tässä linkit muutamaan niistä.

Leanillä tehoa liiketoimintaan (12/2015)
Lisenssit ja avoin lähdekoodi (09/2015)
Aamiaisseminaarin antia: tietojärjestelmien omistusoikeudet (06/2015)
Tiedolla johtaminen tuo parempia tuloksia (08/2014)
Uutiset IT:n päättäjille (03/2014)

Jos taas haluat saada tulevat uutiskirjeemme ensimmäisten joukossa suoraan sähköpostiisi, voit liittyä uutiskirjeemme tilaajaksi vaivattomasti blogimme sivupalkissa olevalla lomakkeella.

***

Kuva: Flickr Creative Commons, @sage_solar.