Niskalenkki pilvestä!

Julkaistu alunperin 20.5.2010 Tivi -lehden kolumnina.

Rajaton laitteistokapasiteetti kaikkien saatavilla, juuri silloin kuin sitä tarvitaan. Voiko sovelluskehittäjä parempaa toivoa?

Ovathan ohjelmoijat tunnettuja siitä, että he pystyvät käyttämään kaiken saatavilla olevan prosessointivoiman. Sovellusten ohjelmoijat osaavat jo ottaa tarpeen mukaan dynaamisesti käyttöön lisää alustan resursseja, kun käyttö lisääntyy.

Hyvä juttu, sillä prosessoritunti maksaa vain kymmen senttiä ja kerralla voi saada käyttöönsä useita prosessoritunteja. Vaikka sata tai tuhat. Halpaa kuin saippua.

Entäpä, jos jokaisella pilven palvelimella varattu resurssi jää varatuksi?

Kulut juoksevat, mutta mitään ei tehdä. Siksi uusien sovellusten on osattava myös nopeasti vapauttaa alustansa resursseja heti, kun niitä ei tarvita. Tätä pilvitarjoajat kuitenkin helpottavat tuottamalla automaattisesti ylös ja alas skaalautuvia palvelukerroksia. Ohjelmoijan seitsemäs taivas?

Mitähän muuta kehittäjien pitää osata? Ainakin pitää osata säieturvallinen ja molempiin suuntiin skaalautuva ohjelmointi. Perinteinen tietokanta-ajattelu on vanhanaikaista eikä sille oikein löydy perusteita pilviteknologioissa.

Paljon paremmille jäljille päästään, kun ajatellaan datan persistenssiä. Jääkin nähtäväksi, millaiset datamallit lopulta voittavat.

Sovelluskohteita on useita, eikä mikään estä kehittäjien luovuutta, kun heidät päästää irti. Interaktiiviset viestintäpalvelut ja mobiilisovellukset, joissa ei tarvita jatkuvaa yhteyttä, ovat varmoja menestyjiä.

Rajaton laitteistokapasiteetti kaikkien saatavilla, juuri silloin kuin sitä tarvitaan. Onko tämä ohjelmoijan seitsemäs taivas?

Samoin kertaluontoiset, rajua voimaa tarvitsevat eräajotyyppiset tehtävät ovat omiaan pilveen. Esimerkiksi sään ennustaminen, animaatioelokuvan renderöinti ja raskaat matemaattiset sovellukset ovat usein käytettyjä esimerkkejä pilviteknologian hyödyntämisestä. Verkkoinfrastruktuurin ja pilvien on vielä kehityttävä, ennenkuin ne soveltuvat hyvin myös latenssiherkkiin tai transaktiopohjaisiin sovelluksiin.

Sovelluskehittäjät eivät ole jääneet toimettomiksi tämän uuden mahdollisuuden edessä. Opetella pitää!

Erään ystäväni lähestymistapa oli yllättävä: hän päätti tutkia asiaa perustamalla oman pilven. Sosiaalisessa mediassa hän kävi keskustelua muiden kiinnostuneiden kanssa siitä, millaisista komponenteista kyseinen pilvi muodostuisi. Tarvitaan jonkinlainen datan säilytys- ja saantiliittymä sovellukselle sekä API muille sovelluksille, datan replikointi, webbiliittymä datan hallintaa varten ja jokin työpöytäkäyttöliittymä.

Datan replikointi lienee se pullonkaula. Saapas nähdä, miten homma kehittyy…

Teknisten asioiden lisäksi tarvitaan uusia käyttöön perustuvia hinnoittelu- ja lisensointimalleja. Kun ohjelmiston pyörittäminen pilvessä tuottaa kuluja käytön mukaan, pitää sen mukaan myös voida rahastaakin. Kyllä tämä asiakkailta menee läpi, mutta ovatko kehittäjäfirmat valmiita ottamaan maksun sovelluksesta pikkuhiljaa tipoittain?

Näihin asioihin pyrimme vastaamaan syyskuun perinteisellä Sytyke Ry:n laivaseminaarilla.

Jos uskot, että tiedät vastauksia, ota yhteyttä ja tule kertomaan niistä muillekin!

ICT:n erilaiset ihmiset

Julkaistu alunperin 8.4.2015 CxO mentorit Oy:n blogina.

Tapasin kerran henkilön kulttuurialalta. Minun oli hyvin vaikeaa saada hänet ymmärtämään, mitä tein työkseni. Ongelma johtui siitä, että hänen ajatusmaailmassaan kaikki ICT-alan ihmiset ovat ohjelmoijia. Hän ei ymmärtänyt, että minun työtäni ovat ihmiset eivätkä tietokoneet.

Kuinka hyvin organisaation johto ymmärtää erilaisuutta ICT-ammattilaisten välillä? Uskoakseni huonosti, sillä alan sisälläkin toisenlaisten asiantuntijoiden ymmärtäminen on vaikeaa. Tämä johtuu ihmisten erilaisista ajatusmaailmoista. Se häristä puhuu, joka härillä kyntää!

Kerran isoa konesalihanketta auditoidessani havaitsin, että siihen osallistui toistakymmentä erilaista asiantuntijaa. Näillä ei ollut edes keskenään käsitystä siitä, mitä muut tekivät. Muut näkivät, että siellä olivat ne tietoliikennetyypit. Nämä näkivät toisissaan IP-suunnittelijan, runkoverkkoasiantuntijan, konesaliverkon asiantuntijan, palomuurien asiantuntijan ja vielä sen kaverin, joka veti fyysistä piuhaa seinään ja lattian alle.

Ovatko sitten DBA:t, keskenään samaa porukkaa? Vain sovellusasiantuntijat saattoivat tietää, miten tietokannan scheman rakenne on tehty. Varsinaiset tietokantahoitajat eivät schemasta välittäneet, vaikka näin olisi voinut luulla. Heidän hommiansa olivat tietokannan hallintajärjestelmän asetukset ja tietokannan tiedostot. Tosin levylle asti he eivät tiedostoja hoitaneet, sillä levytallennus oli tietysti tallennusverkkoasiantuntijoiden hommaa.

Ihan yhtä hajanainen tilanne on ohjelmointipuolellakin. Käyttöliittymäihmiset eli UX -suunnittelijat ja -devaajat eivät juuri transaktioiden eheydestä huolehdi. Minäkin olin ennen UX -asiantuntija. Silloin UX oli HP:n oma UNIX-versio. Ohjelmoinnin kohde, käytetty kieli, ohjelmointiympäristö ja jopa kehitysparadigmakin vaikuttavat hyvin paljon maailmankuvaan, sovellusalueesta puhumattakaan. Kavereilla on ihan eli lelut, vaikka muista leikki näyttää samalta.

Otetaan vielä mukaan testaus: eri tasoilla ihmiset tekevät eri asioita. Osa tekee työnsä käsin ja toiset rakentavat laajoja testausalustoja. Kerran asiakkaan testausihmiset ja laatupäällikkö menivät testauksen suunnittelutekniikkakurssille ja hämmästyivät, kun siellä käytiin läpi matemaattisia malleja. Siellä ei kerrottu kuinka käyttötapauksista johdetaan testitapauksia hyväksymistestaajien käyttöön.

Ohjelmoijien ja laitteistoihmisten välissä on usein joukko arkkitehteja. On järjestelmäarkkitehti, sovellusarkkitehti ja yritysarkkitehti (engl. enterprise architect). Ensimmäinen miettii jonkin yleiskäyttöisen palvelun tai järjestelmän asioita, esimerkiksi julkaisujärjestelmää. Toinen miettii jonkin tietyn sovelluksen elämää käyttäjältä koneeseen asti ja kolmas miettii koko organisaation tietojenkäsittelytarpeita. Nämäkin ihmiset puhuvat eri asioista, osittain samoilla termeillä.

Laajassa tietojärjestelmähankkeessa pääsee tapaamaan useita edellä mainituista asiantuntijoista. Hanketta johtaa parhaimmillaan ammattimaiset projektipäälliköt ja hankkeen omistavat liiketoimintajohtajat. Näistä kummankaan ammattiryhmän kulttuuriin ei kuulu tietotekniikkaihmisten ajatusmaailmoiden tunteminen. Kuitenkin heidän pitää ymmärtää, mitä ihmiset heille kertovat ja kuinka tärkeästä asiasta kulloinkin on kyse. Asiantuntijoilla on nimittäin kyky nähdä omien asioidensa merkitys projektiin tärkeimpänä onnistumisen edellytyksenä. Mikähän näistä näkemyksistä on milloinkin se kaikkein kriittisin?

Projektit onnistuvat tai epäonnistuvat oikea-aikaisen ja oikein tulkitun viestinnän ja ohjauksen ansiosta. Siksi isoissa hankkeissa on aina tarvetta tekniselle johtajalle. Tekninen johtaja ymmärtää eri alojen kulttuureja ja ajatusmaailmoja. Hän ymmärtää eri asiantuntijoiden motivaatioiden lähteitä ja osata viestiä kunkin omalla kielellä. Onnistumisen perusedellytyksenä on laaja perehtyneisyys ICT-alaan ja monipuolinen kokemus eri toimialoilta. Tällaista repertuaaria ei hankita parissa vuodessa. Ehkäpä meille keski-ikäisillekin on vielä jotain käyttöä!