Skip to content

IT:n nousu ja rappio

marraskuu 5, 2014

Olen aloittanut IT-opinnot 1972 ja siirtynyt työelämään 1979. Olen valmistunut maisteriksi Turun Yliopistosta pääaineenani tietojenkäsittely 1980. Olen tehnyt siis koko työurani 1979 – 2011 sovelluskehitystehtävissä tai lähimaastossa. Olen työskennelty 10:ssä yrityksessä sekä ohjelmistotaloissa.

Koko alaa on leimannut voimakas muutos koko tuon ajan. Kun aloitin uraani Ylellä ATK-suunnittelijana, oli tietotekniikka vielä todella lapsenkengissään. Ympäristöni oli IBM-360 ja sovellus, jota silloin ylläpidin oli Ylen palkanlaskenta, joka oli eräajosovellus ja se olin koodattu Cobolilla. Silloin kaikki oli suurta ja kankeaa – ikään kuin vanha höyryveturi. Seuraavaksi siirryin HP:lle järjestelmäasiantuntijaksi ja ympäristö oli HP3000 kaupallinen minikoneympäristö. Tällöin silmäni avautuivat ja tajusin, että suuri ja jäykkä ei tietojenkäsittelyssä olekaan välttämätöntä saatikka sitten hienoa. Olin todella ymmälläni, miten kaikki voikin olla niin yksinkertaista, suoraviivaista ja toimivaa. Ihastuin. Se kokonaisuus oli todellinen HP:n edistyksellisten insinöörien taidonnäyte.

Kun sitten seurataan tuota alan kehittymistä minikonevaiheen jälkeen, seuraava aalto oli PC:iden nousu. Se tapahtui 1980-luvun lopulta lähtien. Jo 1990 kaikki Cobol- ohjelmointu IBM- isokoneille oli jo siirtynyt PC:hen.

Aluksi PC:tä käytettiin taulukkolaskentaa ja IBM:n isokoneiden päätteenä. Seuraava vaihe kehityksessä oli client-server teknologia 1990-luvulla. Keskikokoisten tietokoneiden synty ja Unix-kj mahdollistivat sovelluskohtaisten palvelimien synnyn. Näin sovellus muodostui useista asiakaslaitteista, jotka tyypillisesti olivat PC:itä ja yhdestä tai useammasta palvelimesta, joiden käytön asiakaslaitteet jakoivat. Näin voitiin toteuttaa lähtöhinnaltaan paljon halvempi ratkaisu, kuin ison ja kalliin keskuskoneen tapauksessa. Aluksi sovellukset toteutettiin hajautetusti, niin että ne sisälsivät sekä jaetun palvelimen ohjelmiston, että käyttäjäkohtaisen päätelaitteen ohjelmisto. Päätelaitteen ohjelmisto piti siis asentaa jokaisen sovelluksen käyttäjän päätelaitteelle erikseen.

Tämä sovellustyyppi sisälsi kovin kirjavan joukon teknisesti hyvin edistyneitä että aivan surkeita ratkaisuja. Vuosikymmenen lopulle tultaessa käyttöliittymän ryhdyttiin käyttämään selainta ja tällöin kaikki sovelluksen koodi sijaitsi palvelimella. Tyypillisin palvelin sisälsi tietokantatoiminnot. Toteutimme Finnairilla hajautetun Smalltalk- sovelluksen, jonka palvelimena toimi IBM isokoneen DB2-tietokanta 1994.

Pienen ylimenovaiheen jälkeen tutustuin 1989 oliokehittämiseen ja Smalltalkiin. Tämä vaihto saneli sitten työympäristöni työurani loppuun saakka. Oliomallilähtöinen sovelluskehittäminen oli ja on edelleen ehdottomasti tehokkain tapa tuottaa laadultaan korkeatasoisia tietojärjestelmiä. Menetelmä on kuitenkin selvästi ammitaidollisesti vaativa.

Oliopohjainen sovelluskehitys oli Smaltalkin myötä laajentunut. Kun Sun Microsystem julkaisi Java 1997 ja alkoi jakaa tulkkia ilmaiseksi selainten kylkijäisen räjähti oliokielten käyttö sovelluskehityksen ohjelmointikielenä. Kun koko ajattelu oli kovin uusi, eivät oliojärjestelmien kehittäjät olleet kovin osaavia. Näin uusi kehittämistapa sai painolastikseen huomattavan määrän perusteettomia argumentteja.
Aluksi oliokehitystä vitiin tehdä vain työasemassa ja palvelinpuolen infrastruktuuri puuttui. Vasta Java toi mukanaan EJB:n, joka oli palvelinkehitysympäristö. Tämä pulmana pitkään oli infran todella heikko oliotuki.
Vaikka Java kehitysympäristöt systemaattisesti 2000-luvulla esittivät järjestelmien noudattavan kolmikerrosrakennetta, ei kehitysmenetelmä vielä tukenut tätä alusta loppuun. Tämän johdosta sovelluskehitys oli keskimäärin liian monimutkaista ja aiheutti huomattavasti pettymyksiä. Eräs merkittävä este sen leviämiselle oli ja on se, että alan pioneeri eivät jostain käsittämättömästä syystä eivät kuitenkaan erottaneet abstraktia liiketoiminnan oliomallin laatimista ja liiketoimintalogiikan kehittämistä selkeästi omaksi kehittämistyön ensimmäiseksi vaiheeksi. Kun liiketoimintamallia ja sovellusta yritetään kehittää rinnakkain lisääntyy yksityiskohtien määrä liian varhain. Tämä mutkistaa ja puurouttaa koko kehittämistä merkittävästi. Tätä on mahdollisesti ohjannut edellinen sovelluskehittämismalli, jossa pyrittiin suunnittelemaan tuleva järjestelmä alusta alkaen hyvin yksityiskohtaisesti. Tämä johti nopeasti aivan liian monimutkaiseen suunnitelmaan, jonka virheettömyyttä ja toimivuutta ei pystytty todentamaan. Sovellusrakenteessa syntyy nopeasti hyvin monimutkainen riippuvuuksien verkosto ja on mahdotonta organisoida suunnittelua niin, että tämä kokonaisuus pysyisi kokonaisuutena käsissä. Ketterän kehittämisen tutkimus on jo aikaa sitten osoittanut, että ainoa tehokas toteutusstrategian on alkuvaiheessa lyödä lukkoon vain sovelluksen karkeat suuntaviivat. Tämän jälkeen edetään prioriteettijärjestyksessä tärkeimmistä ominaisuuksista vähemmän tärkeisiin ja joka vaiheessa varmennetaan oikealta käyttäjäyhteisöltä, että valitut ratkaisut toimivat. Koko työurani näin suurissa ohjelmistotaloissa käsittämätöntä laajojen sovellusten kehittämistä, missä todelliset käyttäjäryhmät eivät osallistuneet kehittämiseen ollenkaan. Tällainen toimita on jo alkaessaan tuomittu epäonnistumaan.

Samanaikaisesti tämän kehityskulun kanssa kansainväliset ohjelmistotalot lisäsivät voimakkaasti valmiussovellustarjontaa. Ohjelmistotalo oli kehittänyt sovelluksen jollekin asiakkaalleen ja sen jälkeen se muokkasi sitä vähän yleisemmäksi ja alkoi myymään tämän kopiota ”tuotteena”.

Tällaiset tuotteet olivat siis heti valmiita, mutta niillä oli rajapinta joilla tuotetta voi jonkin verran mukauttaa kunkin asiakaan erityistarpeisiin. Saksalainen SAP julkaisi ensimmäisen clien-server sovelluksensa tuotantovirtojen suunnitteluun 1992. Sen nimi on R/3 ja se oli todellinen myyntimenestys.

Ohjelmistopaketit kasvoivat ja laajenivat ja samalla niistä tuli isoja, monimutkaisia, jäykkiä ja kalliita ja niiden asiakaskohtaistaminein kävi aina hitaammaksi ja kalliimmaksi.

2000-luvulle tultaessa suurten ohjelmistotalon myyntiponnistelut pakettiohjelmistojen osalta alkoi kantaa hedelmää, kun samaan aikaan isot räätälöidyt hankkeet olivat kalliita ja epäonnistuivat usein. Tämä johtui lähinnä ammattitaidon jälkeen jäämisestä ja hyvin vanhanaikaisten työmenetelmien käytöstä.

Näin isojen yritysten ohjelmistomarkkinan valloittivat joko suuret kotimaiset tai ylikansalliset ohjelmistotalot pakettiratkaisuineen. Tämä kehityslinja oli ostajan kannalta valitettava, mutta myyjän kannalta kultakaivos. Tämä kehityslinja tuntuu jatkuvan edelleen vaikka kaikki järkisyyt tämän taustalta ovat aikaa kadonneet.

Pienten innovatiivisten ohjelmistoyritysten asema Suomessa oli erityisen tukala, kun isot yritykset ostivat kaiken ohjelmointityö isoilta ohjelmistotaloista varmaan jatkuvuuteen vedoten. Aikoinaan perustelu oli joltain osin perusteltu, mutta tänään näin ei enää ole asian laita.

Uusien mobiilikäyttöympäristöjen myötä 2010-luvulta alkaen sovelluskehityksen tilanne on vain vaikeutunut. Kun selainpohjaiset sovellukset syntyivät, olivat sovelluskehitysvälineet todella ankeita ja huonoja – oikeastaan editori ja HTML-koodi.

Uusien mobiiliympäristöjen myötä tilanne on vain pahentunut. Kehittämisessä ollaan tekemisissä aivan liian pienten ja alkeellisten elementtien kanssa, kun tehokas kehittäminen edellyttäisi kehitysympäristöä, jossa pienet yksityiskohdat – ainakin alussa – toteutuisivat automaattisesti oletusarvoilla ja käyttöliittymän toteutuksessa voitaisiin keskittyä toiminnallisesti oleelliseen.

Aikoinaan Grady Booch sanoi jossain 2000-luvun alun oliokonferenssissa, että tällaisia ei enää järjestetä viiden vuoden kuluttua. Ennustus piti paikkaansa, mutta syy siihen ei ollut se jota Booch luuli. Hän minittäin sanoi, että siihen mennessä oliokehittämisestä on tullut valtavirtaa ja kaikki tekevät niin. Valitettavasti näin ei käynyt vaan väärinymmärrysten siivittämänä ja vanhojen tietokantaympäristöjen tuottajien kovasti puskemana kehitys peruutti ainakin isot kaksi askelta ja palasi proseduraaliseen kaksikerrosarkkitehtuurin ja vanhoin tietokantoihin, jota tämä vastaliike kutsui SOA:ksi (service oriented architecture ) ja josta Booch kirjoitti katkeran satiirin SOA (= Snake Oli Achitecture) ja jossa hän kuvasti SOA -kauppiaita ihmerohtojen myyjiksi.

Sovelluskehityksen tulvaisuus näyttäytyy minulle tällä hetkellä synkkänä hajaannuksen aikana. Uuden ajan airut onkin taas nousemassa taivaanrannassa. Ne ovat hermoverkkopiirit ja niihin perustuvat uuden piiriteknologia ’aivokoneet’. Tunnetusti läpimurrosta täysimittaiseen käyttöönottoon on aiemmin kulunut n. 20 vuotta, joten uusi aika koittanee 2028 korvilla.

Mainokset

From → Uncategorized

Jätä kommentti

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggers like this: