Ä¢¹½Ö±²¥

Kun reaalimaailma muuttuu, ohjelmiston pitää jatkuvasti muuttua. Jyväskylän yliopisto kouluttaa tieto- ja ohjelmistotekniikan diplomi-insinöörejä, jotka hallitsevat jatkuvaan muutokseen perustuvien järjestelmäkokonaisuuksien tarpeet ja mahdollisuudet, kirjoittaa ohjelmistotekniikan professori Tommi Mikkonen Jyväskylän yliopistosta.

 Kukapa ei olisi joskus tuskastunut siihen, että juuri silloin kun on joku tärkeä tehtävä käsillä, tietokone – on se sitten kännykkä, tabletti, PC tai pilvipalvelu – ilmoittaa että valitettavasti juuri nyt on pakko suorittaa ohjelmistopäivitys.  Miksei kaikkea tehdä kerralla valmiiksi?

Ohjelmistojen evoluutio – mitä tiede sanoo?

Vaikka ilmiö loppukäyttäjien riesana on melko tuore, ohjelmistoevoluution perusteet, niin kutsutut , ovat olleet tunnettuja jo melko pitkään. Meir ’Manny’ Lehman muotoili ne perustuen kolmenlaisiin ohjelmistoihin, S-, P- ja E-tyyppisiin. Näistä S-tyypin ohjelmistot perustuvat täsmälliseen spesifikaatioon, kuten matemaattiseen kaavaan, ja P-tyypin ohjelmistot toteuttavat tietyt operaatiot, jotka määrittävät kaiken mitä ohjelmisto koskaan voi tehdä – kuten vaikkapa shakkipelin siirrot.

E-tyypin ohjelmistot puolestaan ovat osa reaalimaailman prosesseja, ja ne ovat kiinteästi tekemisissä ympäristönsä kanssa.

E-tyypin ohjelmistot eroavat S- ja P-tyyppisistä siten, että ne vaativat jatkuvaa hienosäätöä palvellakseen käyttäjiä ja toimiakseen muuttuvassa kontekstissa.

Jatkuva hienosäätö puolestaan tarkoittaa kasvavaa monimutkaisuutta, mikä puolestaan vaatii työtä monimutkaisuuden hallitsemiseksi ohjelmistoarkkitehtuurin keinoin. Kaikki tarvittava työn organisointi puolestaan vaatii vakaata organisaatiota, joka usein alkaa muistuttaa rakenteeltaan ohjelmistoa.

Iso osa ohjelmistotekniikkaa on ollut teknisien ja menetelmällisien ratkaisujen keksiminen kasvavan monimutkaisuuden hallinnoimiseen ja organisoimiseen. Ohjelmistokehykset (framework), kontit (containers), jatkuva käyttöönotto (continuous deployment) ovat esimerkkejä siitä, miten ohjelmistojen jatkuvaan muutostarpeeseen on pyritty vastaamaan.

Monet yritykset, kuten vaikkapa Facebook, päivittävät palveluitaan monta kertaa päivässä, ja vastaavasti peliteollisuudessa käytetään useita keskenään kilpailevia toteutuksia, jotta löydettäisiin käyttäjiä – tai pelitaloa – mahdollisimman hyvin palveleva versio.

Samaan aikaan on suuria organisaatioita, jotka hankkivat suuria kokonaisuuksia siinä uskossa, että hankittu järjestelmä palvelisi organisaatiota pitkään muuttumattomana, kunhan vain ohjelmiston vaatimukset olisivat riittävän hyvin formuloitu – huomioimatta sitä, että mikä tahansa järjestelmä, joka kohtaa muuttuvan maailman on väistämättä E-tyypin ohjelmisto: vaikka sen vaatimukset olisivat kuinka hyvin muotoiltu, ei ole tunnettua keinoa muuntaa sitä S- tai P-tyyppiseksi.

Hinnoittelussa toimittaja varautuu muutoksiin, vaikka ostaja ei sellaisia pohdikaan

Koska organisaatiot, jotka osallistuvat tällaisiin kilpailutuksiin toimittajana, tietävät että kyseessä on E-tyypin järjestelmä, ne varautuvat ohjelmiston jatkuvaan muutokseen ja siihen vaadittavan organisaation ylläpitoon hinnoittelussaan.

Tämä puolestaan tarkoittaa sitä, että ostava organisaatio saa usein hintaluokaltaan odotukset moninkertaisesti ylittäviä tarjouksia järjestelmän toimittamisesta, varsinkin silloin kun kyse on isosta, satojen työvuosien suuruisesta kokonaisuudesta, jota kokonaisuutena ei ehkä ymmärrä kukaan, ainakaan ostajan puolella.

Toisaalta koska järjestelmä usein on välttämätön edellytys ostajan ydintoiminnoille, kuten vaikkapa potilaiden hallinnalle, järjestelmäkokonaisuuden ulkoistaminen kokonaan IT-toimittajalle luo valtavan riskin.

Lisäksi, koska kyse on räätälöidystä kokonaisuudesta, on sitä usein mahdoton sovittaa toimimaan yhteen jonkun toisen toimittajan vastaavan järjestelmän kanssa, joka on käytössä esimerkiksi naapurikunnassa tai sairaanhoitopiirissä.

Mikropalveluarkkitehtuuri yksinkertaistaa kokonaisuutta

Ohjelmistoteknisesti yksinkertaisin keino hallita toimittajaketjuja on jakaa järjestelmäkokonaisuus joukoksi palveluita, joiden hallinnointi on mahdollista toisistaan riippumatta.

Esimerkiksi pilvipalveluissa tällaisesta mallista käytetään nimitystä mikropalveluarkkitehtuuri. Tällöin ostaja hallinnoisi mikropalveluita, jotka voitaisiin ostaa eri palveluntuottajilta ja/tai keskitetysti esimerkiksi Digi- ja väestötietovirastolta.

Koska yksittäisen palvelun päivittäminen tai muuttaminen voidaan tehdä keskitetysti ja hallitusti, tämä puolestaan yksinkertaistaisi kokonaisuuden kehittymistä – mikä on väistämätöntä, kun kyse on E-tyypin ohjelmistoista.

Jyväskylän yliopiston uuden DI-koulutuksen tavoitteena on kouluttaa ammattilaisia, jotka ymmärtävät tällaisten järjestelmien kehittämisen haasteet ja mahdollisuudet, yhdistäen tietojärjestelmätiedettä ja tietotekniikkaa sopivassa suhteessa. Lisäksi ohjelmistoliiketoiminnan ulottuvuus on keskeisessä roolissa, kun mietitään eri tilanteisiin sopivaa liiketoimintamallia ja ansaintalogiikkaa. Tavoitteena on, että yksikään ohjelmistoprojekti ei koskaan enää kaatuisi siihen, että ostaja ja toimittaja puhuvat toistensa ohitse ymmärtämättä toisen reunaehtoja.

Tommi Mikkonen työskentelee ohjelmistotekniikan professorina informaatioteknologian tiedekunnassa Jyväskylän yliopistossa.