Kuinka NSA:n vakoiluun kannattaa varautua

Kaikki teknouutisia seuraavat tietänevät jo, että NSA vakoilee amerikkalaisten yritysten palvelimilla olevia sähköposteja, nettikeskusteluja ja niin edelleen.  Valvonnan tarkasta laajuudesta ja toimintatavoista on vielä epäselvyyttä, mutta sen olemassaolosta ei.

Seurattuja ovat ainakin yleisesti käytetyt amerikkalaiset pilvipalvelut, kuten Gmail, Skype, Facebook, Google drive ja Google Apps. Voidaan myös kysyä, kuinka turvallisia pilvialustat Google App Engine ja Amazon Web Services ovat. Varmasti turvallisuusviranomaiset haluavat tietoja niistäkin, mutta valvonnan tekninen vaikeus saattaa rajoittaa sitä.

Miten tähän valvontaan sitten pitäisi reagoida?

Henkilökohtaisesti en ajatellut muuttaa mitään. Valvonta ei todellakaan tullut minulle yllätyksenä, ja olen opetellut elämään sen kanssa, että toimiani netissä luultavasti seurataan.

Myöskään yritystoiminnassa en näe syytä muuttaa toimintatapoja. Pilvipalvelut ja nykyaikaiset kommunikaatiovälineet tuovat valtavasti etuja pienen yrityksen toimintaan. Ilman niitä olisi vaikea, ellei mahdoton pärjätä kilpailussa. Jos pitää valita, ottaako sen riskin, että USA:n turvallisuusviranomaiset päättävät myydä tietomme kilpailijalle vai lopettaa toiminta, valinta on helppo.

Jopa poliittisessa toiminnassa suosittelen käyttämään Facebookia ja muita hyvin toimivia välineitä, koska edelleenkin: ne ovat niin käteviä, että ennemmin kannattaa toimia vakoiltuna, kuin olla toimimatta. Ja oikeasti NSA:ta eivät ehkä jotkin Helsingin kunnallispolitiikan juonet niin kauheasti kiinnosta…

Mutta viranomaisilla ei tätä samaa harkintavaltaa ole. Viranomaiset käsittelevät toisten – kansalaisten – tietoja. Osaa niistä tietojen kohteet eivät halua levittää, ja jotkin tiedot koskevat kansallista turvallisuutta. Viranomaisten järjestelmiä ei voi rakentaa tällä laissez faire -tietoturvalla, jota itse suosin. Se valitettavasti tarkoittaa, että monia pilvipalveluita yksinkertaisesti ei voi käyttää.

Julkishallinnolle oma pilvi

Tästä ei kuitenkaan seuraa, että julkinen sektori voisi jämähtää 90-luvulle ja hankkia erillisen raudan jokaiselle mahdolliselle sovellukselle. Ei se voi. Jos virallisesti käytettävät palvelut eivät ole riittävän toimivia, siirtyvät virkamiehetkin amerikkalaisten pilvipalvelujen käyttäjiksi, kuten ulkoministerin esimerkki osoittaa. Julkishallinnolle tarjottavien palveluiden täytyy olla riittävän käytettäviä ja riittävän kustannustehokkaita, jotta ne tosiasiassa mitenkään parantaisivat turvallisuutta. Siksi tarvitaan julkishallinnon oma pilvi.

Julkishallinnon pilven täytyy tietenkin sijaita Suomessa. Pelkkä sijainti ei kuitenkaan takaa muuta kuin kustannuksia. Lisäksi pilven pitää:

  • olla julkisen tahon tai valtionyhtiön tarjoama
  • täyttää perustason tietoturvavaatimukset (myöhemmin tasoja voidaan lisätä)
  • tarjota palveluita pilvipalveluna, s.o. veloitus käytön mukaan, nopea saatavuus
  • tarjota palvelua kaikille kiinnostuneille julkishallinnon organisaatioille

Luonteva taho tarjoamaan palvelua voisi olla Tieteen tietotekniikan keskus CSC, joka on ennenkin tuonut Suomeen uusia internet-palveluita, alkaen internetistä.

Pilven ominaislaatuun kuuluu kokeilu ja järjestelmien laajentaminen käytön mukaan. Nyt ei siis tarvita kolmen vuoden suunnitteluhanketta, jonka lopuksi on laadittu määritykset, vaan järjestelmä pitää rakentaa kokeilun kautta, tarjoten helposti tarjottavissa olevia palveluita ja katsoen, mitkä saavat suosiota.

Palveluiden osalta luonteva aloitus olisi tarjota AWS:ää vastaavaa infrastruktuuria Eucalyptuksella. Tällä saataisiin julkishallinnon palvelukehitykseen ja uusiin palveluihin helposti käytettävissä oleva alusta, jonka turvallisuutta ei tarvitsisi miettiä.

Esimerkinomaisesti: pyöritämme muuankin 10 000 ytimen Eucalyptus-järjestelemää 5 hengen tiimillä. Eikä ensimmäisessä versiossa tarvita 10 000 ydintä, vaan vasta kun käyttäjiä alkaa ilmaantua. Beta-version julkispilvestä saisi pystyyn kuukausissa.

Alustan päälle voi myöhemmin lähteä tarjoamaan myös käyttäjätason palveluita, dokumenttijakoa ja sähköpostia, kun pohjataso on ensin saatu toimimaan. Mitä vaan palveluita, jotka on syytä saada helposti käyttöön, mutta joihin amerikkalainen yritys mahdollisine takaovineen ei ole vaihtoehto.

Julkispilven tarkoitus ei ole tarjota kaikkia valtionhallinnon IT-palveluita. Monet järjestelmät vaativat erikoistuneita ratkaisuja, jotka on helpoin tehdä tapauskohtaisesti. Kyse on pikemminkin pienestä lisästä ja uudenlaisesta ajattelusta: tarjotaan niitä palveluita, joita on helppo tarjota, ja katsotaan mille on kysyntää. Tällä voidaan parhaimmillaan saada yksityisen sektorin nauttimista huomattavista tehokkuushyödyistä osa julkiselle puolellekin – ja samalla parempi turvallisuus.

// Kuva: Flickr CC, Javier.

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

5 asiaa, jotka julkishallinnon pitäisi oppia IT:stä

Kirjoitan uudessa Sytyke-lehdessä viidestä tietotekniikan trendistä, joita julkishallinnon on syytä seurata huolella.

Media keskittyy päivittelemään valtion tietojärjestelmätyön korkeita kustannuksia, vaikka todellinen ongelma on järjestelmien toiminnallisuudessa ja niiden tekotavassa. Liian monet niistä pyrkivät toimimaan vähän parempina arkistokaappeina, teollisen ajan jäänteinä, jossa virkamiehet ovat keskipisteessä, ja tietojärjestelmän tehtävänä on välittää lomakkeita ja pitää ne tallessa.

Tietojärjestelmien toiminnallisuuden ja niiden tekotapojen muuttaminen on ensiarvoisen tärkeää. Elämme kansakuntien globaalissa kilpailussa, jossa Suomi maana joko kuihtuu tai kukoistaa. Hyvillä järjestelmillä luodaan nykyistä parempi elinympäristö kustannustehokkaasti. Nykyiset järjestelmät karkottavat menestyvät yritykset maihin, jotka ovat ketterämpiä ja ottavat ajan vaatimukset paremmin huomioon kuin Suomi.

Tämä tietojärjestelmäongelma on vaikeasti korjattava. Tietotekniikan hyödyt jäävät lupauksiksi, jos palveluprosesseihin ei kosketa. Hyvillä järjestelmillä valtion toiminta voitaisiin uudistaa vastaavasti kuin yksityisellä puolella. Pankkisali ei enää muistuta 1970-luvun pankkia eikä rautakaupalla ole mitään tekemistä lapsuuteni rautakaupan kanssa. Molemmissa on muutettu palvelumallia ja sen myötä tietojärjestelmiä. Samaa palvelukehitystä ei riittävästi näy julkisella puolella. Lääkäri on lääkäri ja tuomari on tuomari.

Valtiolle voi käydä kuin Nokialle, jos suuntaa ei muuteta.

Valtiollisessa mattimyöhäisyydessä on etunsakin. Voimme tutustua ulkomaisiin esimerkkeihin ja hyötyä niiden parhaista opeista. Esittelen viisi merkittävää trendiä, joista Suomessa kannattaisi ottaa mallia.

1. Avoin lähdekoodi

Avoin lähdekoodi tarkoittaa asiakaskohtaisten ohjelmien lähdekoodin vapaata jakamista. Tämä on ollut enemmän sääntö kuin poikkeus tiedemaailmassa jo kymmeniä vuosia, mutta toimialan siiloutuneen luonteen vuoksi nämä hyvät tavat eivät levinneet kauas. Hyvänä esimerkkinä on CERN-tutkimuskeskuksessa keksitty www-ympäristö ja sen ympärille avoimen lähdekoodin pohjalta muodostuneet selaimet ja palvelimet.

Avoin lähdekoodi on vallannut markkinaosuutta hivuttautumalla yhä uusille aloille. Hyviä esimerkkejä sen toimivuudesta löytyy varsinkin verkkopalveluista. Lähdekoodinsa avoimesti jakavat esimerkiksi www.whitehouse.gov Yhdysvalloissa ja www.gov.uk Britanniassa. Nämä molemmat ovat hyviä esimerkkejä verkkopalveluista, joissa parhaat käytännöt ovat muiden käytössä sekä omalla maaperällä että kansainvälisesti. Yhä useammissa maissa avoin lähdekoodi on määritelty suositelluksi tavaksi hankkia valtion tietojärjestelmiä.

Avoin lähdekoodi on samalla ohjelmistoalan luontevin yhteistyötapa. Kun kaikki laittavat reseptinsä näkyville, on helpompi siirtyä korkeammalle abstraktio- ja tehokkuustasolle. Kaikki hyötyvät.

Avoin lähdekoodi sopii erityisen hyvin kunnalliselle puolelle. Yhdessä kunnassa kerran tehty työ auttaa muita kuntia vastaavissa tilanteissa.

Linkkejä:

2. Ketterät menetelmät

Ketterä eli iteratiivinen kehitys on ollut varsinkin web-hankkeissa valtavirtaa jo vuosia. Ketteryydestä puhuu nyt myös kansainvälinen julkishallinto. Anglo-amerikkalaiset lainsäätäjät ovat tehneet määrätietoista työtä ketteryyden puolesta julkisella sektorilla. Ketteriä menetelmiä käytettiin äskettäin pelastamaan katastrofaalinen, satojen miljoonien hintainen FBI:n Sentinel-vesiputoushanke. Englannissa kansalaisille tehtävien kaikkien uusien palvelujen pitää perustua palvelumuotoilumalliin, jossa palvelu kehitetään ketterästi ja vielä betatestataan loppukäyttäjillä ennen tuotantoonsiirtoa.

Ketterä hankintamalli on vaatinut yksityisellä puolella muutoksia toimintatavoissa ja uusia roolituksia. Samoin käynee julkishallinnossa. Ketterä kehitystiimi on kuin ajopuu ilman määrätietoista asiakkaan tuoteomistajaa. Uusia tuoteomistajia tarvitaan satapäin. Toivottavasti nämä löytyvät virkamiehistä; uutta tuoteomistajakonsulttien armeijaa tuskin kukaan haluaa.

Ketterissä menetelmissä suurin muutos on tuoteomistajan ja päätöksentekijän välillä. Hankkeen ensimmäisessä vaiheessa etsitään palvelun sopiva muoto, usein yrityksen ja erehdyksen kautta. Ketterä hanke etsii rehellisesti uutta toimintamallia perinteisen vesiputousmallin sijaan. Vesiputous sopii rakennusalalle, mistä se on solahtanut IT-alalle. Ketteryyttä vaaditaan aidosti eikä vain termien tasolla, opettavat amerikkalaiset virkamiehet. Ketterissä menetelmissä asiakkaan pitää olla tiimin iholla koko hankkeen ajan.

Briteissä on asetettu tavoitteeksi, että puolet IT-hankkeista on ketteriä jo parin vuoden sisällä. Muutos on merkittävä jäykkien PRINCE- ja ITIL-mallien kotimaassa.

Linkkejä:

3. Pilvipalvelut

Pilvipalvelut eli verkosta vuokratut IT-palvelut tehostavat tietotekniikan kehitystä ja ylläpitoa. Ketterät menetelmät vaativat ketterät pilvipalvelimet. Entä jos palvelu loppujen lopuksi tarvitsee aivan eri palvelimet kuin alun perin ajateltiin? Montako viikkoa tai kuukautta palvelimia pitää odottaa?

Ketterät menetelmät ja avoin lähdekoodi helpottavat uusien hankkeiden aloittamista valtavasti: ei enää pitkiä vuosien mittaisia määrittelyhankkeita eikä miljoonalisenssejä. Pilvipalvelut sopivat nykyiseen kokeilukulttuuriin kuin nenä päähän. Pilvipalvelut ovat käytössä heti ja niitä voi muokata kunnes oikea palvelukokonaisuus löytyy. Hyvässä pilvipalvelussa tietokantoja ja muita moduleja saa tuntivelotteisesti. Uuden rakentaminen tällaisista duplo-palikoista on paljon tehokkaampaa, kuin totuttu palvelujen nyhrääminen.

Kokeilukulttuuriin sopii pilvipalveluissa myös se, että niistä pääsee helposti eroon. Jos ei tullut takkia eikä kintaita, ei palvelimesta ja sen ylläpidostakaan tarvitse maksaa.

Linkkejä:

4. Avoin tieto

Avoin tieto tarkoittaa organisaation tietomassojen jakamista verkossa raakamuodossa muiden jatkojalostettavaksi. Tässäkin amerikkalaiset ovat muiden edellä; ei Piilaakso sattumalta siellä sijaitse. Esimerkiksi maailman Internet-sääpalvelut ovat perustuneet alusta asti amerikkalaisten ilmaiseksi jakamaan tietoon. Tätä toimintatavan etumatkaa on vaikea kuroa kiinni. Amerikkalaisessa data.gov-palvelussa on jo yli 400.000 datajoukkoa vapaasti käytettävissä – ja tiedon hyökyaalto kasvaa koko ajan.

Kansainvälisisten tutkimusten mukaan avointa tietoa käytetään eniten julkishallinnossa naapurihallinnonaloilla. Sen sijaan että tutkimustietoa pitäisi ruinata naapuriosastolta, sen voi hakea suoraan verkosta ilman hankalia korvauksia.

Avoin tieto tehostaa julkishallinnon tiedonnälkää ja luo ympärilleen ekosysteemejä tiedon jalostamiseen.

Linkkejä:

5. Big data

Big datan eli valtavien tietovarantojen käyttäjänä valtio on pitkään ollut edelläkävijä. Sääennusteet, tiedustelu ja sotilassimulaatiot eivät olisi onnistuneet ilman supertietokoneita.

Hallinto perustuu tiedon laajamittaiseen keräämiseen ja sen jalostamiseen päätöksenteon pohjaksi. Tässä on helposti monta rikkinäistä puhelinta jonossa. Big datan parhaat käytännöt sopivat hallinnon käyttöön kuin valettu. Big data -järjestelmissä tietoa ja sen esitysmuotoja yhteismitallistetaan keskitetysti niin, että lähtötietojen suhteen ei tarvitse olla ihan tarkka. Näkisin, että big datalle on käyttöä ministeriössä kuin ministeriössä.

Linkkejä:

Uusi toimintatapa

Yhdessä näistä opeista muodostuu toimintatavan muutos, jossa kokonaisuus on enemmän kuin osiensa summa.

Valtiot ympäri maailman, Suomi muiden mukana, käyvät tällä hetkellä ihastelemassa Viron moderneja tietoteknisiä ratkaisuja. Muutaman vuoden ponnistus ja määrätietoinen pyrkimys uuteen toimintatapaan voisi nostaa Suomen julkishallinnon tietotekniikan eturintamaan.

Kirjoittaja:

Petri Aukia (Tekn.lis.) on Codento Oy:n toimitusjohtaja ja osakas. Pilvipalvelujen hyödyntäminen, vaativat arkkitehtuurit sekä ketterä hankinta ovat asiakasorganisaatioiden Top3-listalla juuri nyt. Petrillä on 20 vuoden kokemus tietojärjestelmien ja -arkkitehtuurien kehittämisestä sekä yksityisellä että julkisella sektorilla. Petri on myös aktiivinen kasvuyritysten mentori ja Ohjelmistoyrittäjät ry:n jäsen.

petri.aukia (at) codento.com, +358 400 438610, Twitter @aukia

Mitä lääkkeeksi eReseptille?

Perjantaina nousi pieni haloo siitä, kuinka sähköiseen reseptiin mahtuu vain 50 merkin pituinen selitys käyttötarkoituksesta.

“Ongelman korjaaminen tulee kalliiksi ja vie aikaa, kertoo projektipäällikkö Riitta Konttinen THL:stä.

– Siinä menee noin puolitoista vuotta. Kärsivällisyyttä tarvitaan ennen kun uudistus saadaan käyttäjälle. Muutosten tekeminen ei ole myöskään halpaa.”

Onhan se tietenkin vähän omituista, että puolen päivän työltä kuulostava muutos vie puolitoista vuotta. Mutta todellisuus on joskus omituisempi kuin mitä uskoisi. Tämä ei nimittäin ole suinkaan ensimmäinen omituisuus sähköisen reseptin historiassa.

Valtiontalouden tarkastusviraston surullisenkuuluisa raportti Sosiaali- ja terveysalan IT-hankkeista käsittelee sähköistä reseptiäkin:

  • Hanke on eri muodoissaan elänyt 80-luvulta asti, myöhästyen toistuvasti. Suurin syy myöhästymisiin on ollut kiire.
  • Vuonna 2002 eReseptiä oli tarkoitus pilotoida 2003. Pilotti viivästyi vuoteen 2005.
  • Vuonna 2007 KanTa-palvelut (joista eResepti on ensimmäinen osa) oli tarkoitus toteuttaa noin vuodessa. Tämänhetkisen aikataulun mukaan resepti on käytössä julkisella sektorilla tänä vuonna ja yksityisellä 2015 mennessä. Muut KanTa-palvelut tulevat myöhemmin.
  • Alkuperäinen kustannusarvio oli 20 miljoonaa, nyt eReseptin kokonaiskustannuksiksi arvioidaan 70 miljoonaa.
  • Sekä aikataulut että kustannusarviot ovat olleet vaihtelevia. VTV:n sanoin: “Sosiaali- ja terveysministeriöllä ei ole ollut selkeä ja realistista näkemystä KanTa-hankkeen kokonaisaikataulusta. Eri toimijoille esiteyt aikataulut ovat siirtyneet toistuvasti, mikä on johtanut terveydenhuiollon toimijoiden epäluottamukseen minsteriön ohjeistusta kohtaan.”

50 merkin raja ei sinänsä ole kauhean merkittävä ongelma. Itse asiassa voi olla, ettei se ole ongelma ollenkaan. Käyttötavan kohdalle kun voi kirjoittaa myös “erillisen ohjeen mukaan”. En ole oikea ihminen arvioimaan, paljonko tilaa tarvitaan. Jos kuitenkin katsotaan projektipäällikkö Konttisen tavoin, että 50 merkkiä on liian vähän, niin tässä on kaksi vähän merkittävämpää ongelmaa:

  1. Miksi tätä ei havaittu aiemmin, ja
  2. Miten korjaus voi kestää puolitoista vuotta (ja maksaa paljon).

No, miksi tätä ei havaittu aiemmin?

Ensimmäinen kysymys voidaan esittää oikeastaan kaikille IT-hankkeille. Sellaista projektia ei nimittäin olekaan, jossa kaikki olisi keksitty etukäteen. IT-hankkeet ovat luonteeltaan ennen kaikkea oppimisprojekteja, joissa opitaan ymmärtämään, mitä hankkeessa oikeastaan pitääkään tehdä. Sivutuotteena sitten syntyy softa.

Vaikka ennakkomäärittelyissä olisi ollut mukana kuinka monta lääkäriä, apteekkaria ja potilasta, on silti selvää, että kunhan järjestelmä saadaan käyttöön, tulee esiin tarpeita joita ei ennalta ajateltu. Se on ihan normaalia.

Ketterissä menetelmissä tämä tosiasia pyritään tunnustamaan, ja tuottamaan loppukäyttäjille toimiva järjestelmä mahdollisimman usein, ideaalisti kahden viikon välein. Kun lääkärit pääsevät kokeilemaan järjestelmää pian, selkiytyvät tulevat tarpeetkin nopeammin. Vuoden 2002 jälkeen eReseptiä olisi ehditty demota 250 kertaa. Niissä olisi varmasti löytynyt muutamakin virhe ja kehitysidea.

Sähköisen reseptin kehitysjakso ei kuitenkaan ole kaksi viikkoa, vaan ilmeisesti kaksi vuotta. Jos ja kun nyt huomataan pieni puute, sen saaminen korjatuksi vie 18 kuukautta. Potilasturvallisuuden takia tarvitaan tietysti aika paljon parempi testaus kuin jossain webikaupassa. Ja kokonaisuudessa on toki monia toimittajia. Mutta vähintäänkin kolmen kuukauden kehitysjaksojen pitäisi olla hajautetussa monitoimittajaympäristössäkin aivan realistista.

Tämä ei kuitenkaan vastaa itse kysymykseen:

Miten tämä voi olla näin?

Politiikan kommentaattori Veikko Eranti kertoo fiktion keinoin, miten tämä lapsus olisi voinut tapahtua. “Koko sektorin liiketoimintamalli nimittäin perustui sekundan myymiseen ymmärtämättömille keiloille, ”huipputeknologian” kauppaamiseen pohjimmiltaan kirjoituskoneajassa eläville ihmisille, joiden sihteerit hoitivat heidän sähköpostinsa.”

Kuten yleensäkin, todellisuus on tietenkin hiukan monimutkaisempi. Viidenkymmenen merkin raja ei ole syntynyt yhdessä palaverissa, eikä kyse ole vain yhdestä järjestelmästä.

eResepti koostuu Reseptikeskuksesta ja sitä käyttävistä potilastietojärjestelmistä sekä apteekkijärjestelmistä. Suomessa on yli 300 kuntaa, 20 sairaanhoitopiiriä, 4000 yksityisen terveydenhuollon toimijaa ja 800 apteekkia. Jokaisella näistä on oma järjestelmä ja jokaisella niistä toimittava yritys. Kyse on siis tuhansista asiakkaista ja kymmenistä softantoimittajista.

Eri osapuolien kommunikaatio perustuu XML-muotoisiin CDA R2-sanomiin, jotka määritellään HL7-standardeissa. Kaikille eri kentille annetaan kiinteät pituudet, ja käyttötarkoituksen pituus sattuu olemaan 50 merkkiä. Alle 12-vuotiaan painolle on muuten 5 merkkiä, joten parasta olla tekemättä satakiloisia lapsia.

XML sinänsä ei tekstimuotoisena formaattina vaadi kentille pituusrajoja. Itse asiassa olisi helpompaa tehdä sanomajärjestelmä, jossa ei rajoja ole. Mutta sitten kaikkia eri järjestelmiä päivittävät softatalot eivät tietäisi etukäteen, täsmälleen minkä mittaisilla teksteillä eResepti pitäisi testata. Nykyaikaiset systeemit toki selviäisivät helposti pitkistäkin teksteistä, mutta kaikki järjestelmät eivät ole nykyaikaisia.

Jossain on siis olemassa apteekkitietojärjestelmä, joka kykenee vain tähän määrään. Monet kykenevät enempään. Nyt luotiin uusi kansallinen järjestelmä rajoittaen sen toimintaa heikoimman vanhan järjestelmän speksein.

Mitä vähemmän edistystä, sitä enemmän rahoitusta

Suomessa, toisin kuin vaikka Tanskassa, ei ole mitään kansallista tahoa, joka ohjaisi terveydenhuollon järjestelmien kehitystä yhteentoimivaan – tai ylipäänsä toimivaan – suuntaan. Sen sijaan jokainen taho tekee asiat omalla tavallaan, ja ainakin eReseptiä kehitettiin vahvasti konsensusperiaatteella, eli ratkaisujen tuli sopia kaikille. Ja VTV:n sanoin:

“Hankkeen toteuttamisen etenemiselle ei ole riittävää ponninta, koska jatkuva rahoitus on omiaan edistämään eri osapuolten jatkorahoituksen saamista omalle henkilöstölleen.”

Eli suomeksi: Mitä vähemmän edistystä, sen enemmän rahoitusta. Ihmekös tuo jos kestää. Ei ole tietenkään projektin toimittajan vastuulla ajatella asiakkaan etua. Se on asiakkaan vastuulla. Pitäisi osata ostaa IT-järjestelmiä.

Ei ole normaalitila tai business as usual, että hankkeet myöhästyvät kymmenen vuotta tai budjetti kolminkertaistuu. Se kertoo siitä, että asiat ovat vakavasti pielessä. Ulkopuolisen on mahdotonta sanoa, tarkalleen mihin aika ja rahat ovat menneet. Niillä tuskin on lennelty Bahamalle, vaan hyvä arvaus on, että ne ovat menneet vääriin toimintatapoihin. Esimerkiksi siihen, että yritetään pakottaa kaikki toimijat käyttämään samoja protokollaversioita.

Ydinviestissään Eranti on siis täysin oikeassa: ongelmana on, että tilaajan puolella pöytää ei ole riittävää osaamista hankkia IT-järjestelmiä. Valtiontalouden tarkastusvirasto päätyi aivan samaan johtopäätökseen: “Kokonaisuudessaan arvioiden Sosiaali- ja terveysministeriöllä ei ole ollut osaamista eikä edellytyksiä johtaa KanTa-hanketta eikä sitä edeltänyttä sähköistä potilaskertomushanketta osana kansallista terveyshanketta.”

Lääkkeet terveydenhuollon IT:lle

No, mitä lääkettä terveydenhuollon IT:lle sitten pitäisi määrätä? Tässä kolme ideaa:

  1. Pitää perustaa Tanskan Medcomia vastaava organisaatio THL:n tai Sosiaali- ja terveysministeriön yhteyteen vastaamaan terveys-IT:n kokonaisarkkitehtuurista.
  2. Järjestelmät pitää päivittää vähintään neljä kertaa vuodessa. Kaikki sellaiset ohjelmistot ja toimintatavat, jotka tekevät tiheästä julkaisusta ongelmallisia, pitää korjata.
  3. Jokaiseen IT-hankkeeseen pitää palkata yksi ihminen, joka ymmärtää mitä siinä ollaan tekemässä. Kokemukseni mukaan se parantaa merkittävästi hankkeen onnistumismahdollisuuksia.

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

Miten gaussin käyrä liittyy teknologiastrategiaan?

Fyysisten laitteiden maailmassa on ilmeistä tarvitaanko F1-kilpuria vai ihan vaan tämän vuoden vuosimallia olevaa perheautoa, mutta ohjelmistopuolella tilanne ei ole ollenkaan niin suoraviivainen.

Tilanteesta riippuen sekä konservatiiviselle Java-sovellukselle että uusimpia tekniikoita käyttävälle HTML 5 -sivustolle on paikkansa. Mutta milloin on minkäkin tekniikan aika? Kuka tarvitsee uusimpia työkaluja?

Kirjoitan aiheesta, sillä uusien asiakkaiden kanssa käyn toistuvasti samoja keskusteluja työkaluista. Onko yhtä selvää Tekniikan Maailman testivoittajaa vai onko sittenkin niin, että työkaluvalinta on tapauskohtaista?

Tarvitsetko uusinta uutta?

Uusimpien työkalujen ja jo käytössä koeteltujen ohjelmointikielien käyttäjien on usein vaikeaa ymmärtää toisiaan. Kumpikin on tottunut omaan katsantokantaansa ja toisen näkökulma tuntuu vieraalta. Mistä valinnassa oikein on kyse? Onko toinen koulukunta ihan väärässä? Sama konflikti on jatkunut jo pitkään, eikä vieläkään ole löydetty yhteisymmärrystä siitä, millä työkaluilla softaa kannattaisi tehdä.

Uusien ideoiden omaksuminen

Alkuperäisen tutkimustuloksen löysi vuonna 1948 maanviljelijä kuvan oikeassa laidassa, viimeisten farmareiden löytäessä idean kahdeksan vuotta myöhemmin.
Alkuperäisen tutkimustuloksen löysi vuonna 1948 maanviljelijä kuvan oikeassa laidassa, viimeisten farmareiden löytäessä idean kahdeksan vuotta myöhemmin.

Tässäkin tilanteessa on kyse on uusien ideoiden omaksumisen lainalaisuuksista. Aiheen popularisoi riskisijoittaja Geoffrey Moore kirjassaan Crossing the Chasm vuodelta 1991. Uudet ideat eivät nouse kerralla kaikkien tietoisuuteen vaan valuvat ensimmäisten käyttäjien kautta hiljalleen kaiken kansan hyödyksi.

Uutena mainostettu malli on paljon vanhempi ja yleispätevämpi kuin voisi kuvitella. Uuden teknologian omaksumista tutkittiin vuonna 1957 Yhdysvaltain keskilännessä helppolukuisessa ja yllättävän kiinnostavassa Adopters of New Farm Ideas -julkaisussa.  Omaksumisen nähtiin noudattavan gaussin käyrää.

Alussa tekniikan ottavat käyttöön vain harvat, heitä seuraa vähän suurempi joukko ja vasta sitten valtavirta. Uusien siemenlajien ja uusien ohjelmointikielien välillä on enemmän yhteistä kuin ensi hätään luulisi. Tarkemmin ajateluna ei ole ihme, että moni suuryrityksen johtaja on vapaa-ajallaan myös menestynyt kartanonherra.

Innovaattorit

Niin maataloudessa kuin ohjelmistotekniikankin alalla innovaattorit näkevät uuden teknologian mahdollisuudet ja ovat valmiit muuttamaan yrityksessään paljonkin saadaakseen uusimman uuden käyttöön. Innovaattorit vievät uudet keksinnöt nopeasti tuotantoon ja käyttävät osin keskeneräisiäkin työkaluja hyötyäkseen keksinnöistä. He ovat uuden teknologian kannalta tärkeitä niin maanviljelyksessä kuin tietotekniikassakin.

Mallin mukaan innovaattoreita on vain noin kaksi prosenttia väestöstä. He kuluttavat keskimääräistä enemmän aikaa ideoiden etsimiseen ja kokeiluun, mutta toisaalta saavuttavat näin kilpailuetua. Suomalaisessa maataloudessa innovaattorit ovat kasvattaneet monia kannattavia suurtiloja rohkeiden kokeilujensa kautta.

Valtavirta

Valtavirtaan kuuluvilla ei ole mahdollisuutta omaksua keskeneräistä uutta teknologiaa. Kyse on yhtä lailla asenteesta sekä priorisoinnista. Uutta otetaan käyttöön siinä vaiheessa, kun sen käyttö on kilpailijoiden toimesta jo hyvin todistettu.  Tekniikkaa ei oteta käyttöön ennen kuin sen rajat tunnetaan hyvin ja se sopii olemassa olevaan rakenteeseen. Tuolloin tekniikan käyttöönotto koetaan helpoksi ja vaarattomaksi, sillä hyödyt ovat ilmeisiä ja vähällä vaivalla saavutettavissa.

Miten gaussin käyrä liittyy teknologiastrategiaan?

Omaksuminen on kategorisoitu sekä alkuperäisessä maanviljelystutkimuksessa että Geoffrey Mooren julkaisussa suoraan tilastollisen keskihajonnan eli sigman mukaan.
Omaksuminen on kategorisoitu sekä alkuperäisessä maanviljelystutkimuksessa että Geoffrey Mooren julkaisussa suoraan tilastollisen keskihajonnan eli sigman mukaan.

Innovaattorit ovat pääsääntöisesti ratkaisemassa ongelmia, joita aiemmalla tekniikalla ei voitu ratkaista. He löytävät markkinarakoja, joiden täyttäminen tuo nopeaa ja kannattavaa kasvua. Innovaattorit valitsevat uusimpia työkaluja saadakseen ideansa kilpailijoita nopeammin valmiiksi. Esimerkiksi pilvipalvelujen ja uusien ohjelmointikielien avulla etsitään voittavaa asemaa markkinoilta.

Valtavirrassa uivalla yrityksellä on turvallinen markkinaosuus ja tutut asiakkaat, joille tarjota ratkaisuja tunnettuihin ongelmiin. Valtavirran rooli on ylläpitää innovaattorien ja muiden propellipäiden aikanaan kehittämiä systeemejä. Tämä on tehnyt heistä varovaisia. Valtavirrassa toimivalle ylläpidettävyys, tuttuus ja virheettömyys ovat arvossaan.

Ohjelmistoalalla tarpeet vaihtelevat suuresti. Harva työkalu sopii sekä perheauton että F1:n luomiseen. Turvallista taloushallinnon järjestelmää tutuille asiakkaille tehdään edelleen pääsääntöisesti Javalla. Se ei ole työkaluista ketterin eikä seksikkäin, mutta osaamista löytyy kaikkiin toiminnan osiin. F1:stä, eli uusinta uutta, tehdään harvoin Javalla. Osaavissa käsissä ohjelmistokielistä Python, Ruby, Scala tai Javascript tuottaa nopeammin tuloksia. Uusimman uuden tekijätiimi joutuu tosin ajoittain etsimään tekijöitä kissojen ja koirien kanssa, kun valitun alustan osaajia ei löydykään helposti.

Työkaluvalintojen arvostelussa saa olla kieli keskellä suuta. Kun ohjelmistoa tehdään mahdollisimman nopeasti, tarvitaan erilaiset työkalut kuin silloin, kun jokainen koodirivi jää elämään omaa elämäänsä vuosiksi tai vuosikymmeniksi.

Mihin pilvistrategiaa tarvitaan?

Useampi tapaamani järjestelmäarkkitehti on kysynyt minulta mihin pilvistrategiaa tarvitaan. Ensimmäisillä kerroilla kysymys yllätti ja tuli täysin puun takaa, ja vastauksenikin oli vähän takelteleva. Kysymyksen toistuttua siihen on oppinut vastaamaan luontevasti.

Teknologiastrategioiden aika ei ole ohi, jokaiseen uuteen teknologiavallankumoukseen kannattaa reagoida systemaattisesti.

“Eikö yrityksemme yleinen strategia riitä?”

Ei. Yrityksen yleinen strategia on lähes poikkeuksetta kuvattu yrityksen ydinliiketoiminnan näkökulmasta eikä juuri auta tekemään hyviä valintoja uusien teknologioiden suhteen. Jotkin uuden teknologian murrosvaiheet ovat niin merkittäviä, että useimpien yritysten kannattaa suunnitella, miten muutos vaikuttaa heidän liiketoimintaansa.

Muutos pilvimallisiin järjestelmätoimituksiin on tällainen muutos.

“Mihin teknologiastrategiaa tarvitaan?”

Uuden teknologian käyttöönotto on työlästä isossa organisaatiossa. Kaikki oleellinen tehdään määritellyin prosessein ja kaikki teknologiavalinnat vaikuttavat useiden tiimien ja jopa osastojen väliseen työjakoon. Yksittäisen tiimin on vaikea muuttaa status quota ja onnistuessaankin tällainen toiminta on työlästä ja kallista tai vähintään aikaavievää. Yksittäisessä hankkeessa ei pääsääntöisesti löydetä parasta yleistä ratkaisua uusiin haasteisiin. Tulee valittua väärät kumppanit ja työkalut, työmenetelmistä puhumattakaan.

Uuden teknologian tehokas käyttöönotto on merkittävä tekijä yritysten menestyksessä. Jotkut uudet ratkaisut sopivat kilpailutilanteeseen niin hyvin, että nopealla käyttönotolla kaapataan jo näennäisen paalutettuja markkinoita kilpailijoilta.

Teknologiastrategiaa ei siksi pidä jättää tekniikan pojille.

“Millainen on hyvä teknologiastrategia?”

Hyvä teknologiastrategia on kaksiosainen.

Ensinnäkin osassa, jota puristit kutsuvat strategiaksi, kuvataan miten uusi teknologia otetaan käyttöön ja miltä osin sen käyttö on kiellettyä. Parhaimmillaan siinä kuvataan jopa alueita, joissa uuden toimintamallin käyttö on pakollista tai ainakin erittäin suositeltua. Tämä korkean tason suunnitelma kirjoitetaan kielellä, jota yrityksen ylin johto ymmärtää ja on sen jokaisen sanan takana.

Teknologia-ala on täynnä erinomaisia esimerkkejä tällaisesta strategiatyöstä ja sen tuottamasta lisäarvosta. Steve Jobs lakkautti useimmat Applen tuotelinjat ja keskitti paukut niihin muutamiin, jotka vastasivat hänen näkemystään yrityksen tulevaisuudesta ja Google panosti lähes 100% voimistaan verkkopalveluihin jättäen kilpailijoille sen aikaisen valtavirran, yritysten omiin verkkoihin asennettavien ohjelmien markkinan.

Toisekseen käyttökelpoinen teknologiastrategiahanke sisältää selvän reseptin siitä, miten strategia aiotaan käytännössä toteuttaa. Tätä voi kutsua vaikkapa strategian jalkauttamissuunnitelmaksi. Suunnitelmassa on kuvattu tarkemmin kumppanuuksia, budjetteja, aikatauluja, pilottihankkeita ja vaatimuksia organisaation roolien ja vastuiden muuttamiselle.

Uuden teknologian läpilyönti isossa organisaatiossa vaatii johdon tuen, strategian, vastuuhenkilön, budjetin ja selvän jalkauttamissuunnitelman.

Ilman jalkauttamissuunnitelmaa strategiatyö ei tuota tuloksia.

“Strategialla päähän”

Teknologiastrategiaa ei silti kannata käyttää toiminnan jarruna. Pienet yritykset voivat muodostaa ja viestiä teknologiastrategian hyvinkin informaalisella tavalla, työn ohessa tai saunaillassa. Kun kaikki tuntevat kaikki yrityksessä, on valintojen teko helpompaa.

Isossa yrityksessä strategiatyöhön kuuluu olennaisena osana pilvipilotointi. Tilanteesta ja yrityksestä riippuen sen voi tehdä ennen lopullisen strategian asettamista, rinnan strategiatyön kanssa vai vasta strategian lukkoonlyönnin jälkeen.

Opettavainen pilotti on aina hyvä tapa aloittaa strategiatyöhön valmistautuminen.

“Ei Iisakinkirkkoja”

Hyvän teknologiastrategian saa tehtyä muutamassa kuukaudessa. Mikäli työ tuntuu vievän vuosineljännestä pitempään, on jotain pielessä. Tyypillisesti ongelmana on hankkeen matala prioriteetti, liian kunnianhimoinen laajuus tai työhön liian kokematon tiimi. Oikealla porukalla, laajuudella ja selvällä aikataululla työ saadaan valmiiksi, eikä strategiatyön viivästyminen häiritse projektityötä.

Tee pilvistrategia yhden vuosineljänneksen aikana.