Vastine teknologiaselvitykseen

Vesa Lappalainen

• mikä kiire?
• miksi arkkitehtuuri edellä?
• miten välttää usean järjestelmän loukut?
• miten pitää kustannukset kurissa?

Arkkitehtuurivetoisesti vaiko toimintoja painottaen?

Selvitys on tehty poliittisesti korrektisti, eli siinä ei ole mitään vaihtoehtoa asetettu selkeästi toisten edelle. Samalla tämä myös vaivaa selvitystä, koska siinä ei ole otettu kantaa eri vaihtoehtojen kustannuksiin realistisesti. Esimerkiksi vaihtoehtojen A ja B työmäärä on arvioitu todella optimistisesti niin, että kahden vuoden sisällä olisi jotakin käytettävissä. Tämä tuskin on mahdollista.

Selvitys myös pitkältä pohjautuu ajatukseen, että esitetty arkkitehtuuri olisi se mikä on saavutettava. Lisäksi esitellyistä kuvista on jätetty pois valtava määrä Korpin toimntoja, jolloin esittäjän oma kuvaus järjestelmän toiminnoista näyttää yksinkertaiselta. Esimerkiksi mitään salivaraukseen liittyvää ei ole mukana ja nimenomaan salivarauksen ja opetuksen saumaton rinnakkaiselo on yksi Korpin menestystekijöitä.

Perustelua sille miksi esitetty arkkitehtuuri olisi ylivoimainen ei ole esitetty. Toki se on yleisesti hyväksytty, mutta ei ole tieteellistä näyttöä siitä, että ko arkkitehtuuri olisi kokonaiskustannuksiltaan edullisempi kuin joku toinen. Mikäli järjestelmä on jo valmiiksi ko. arkkitehtuurin mukainen, voi järjestelmään olla helpompi vaihtaa esimerkiksi toinen käyttöliittymä. Mutta tällöin säästö tulee vasta sitten kun ko vaihto oltaisiin tekemässä. Siihen ei ole otettu kantaa kuinka monesti tällaisia vaihtoja tehdään, erityisesti kun järjestelmä on jo valmiiksi selainpohjainen. Javascriptin lisääminen olemassa olevaan ei ole tällainen muutos, jossa erilainen arkkitehtuuri maksaisi välttämättä paljoa takaisin ja noita muutoksi Korppiin on jo tehtykin.

Selvityksessä sanotaan että uusi koodi on mittareiden (jotka selvitys itsekin kyseenalaistaa) mukaan parempaa. Lisäksi esitetään lista koodimääristä eri komponenteissa. Missään ei kerrota missä ajassa mikäkin koodi on syntynyt, sillä tuo n. 400 000 riviä (JSP-rivimäärä puuttuu? Rivimääräkään ei todista mitään, mutta antaa pienen vinkin järjestelmän koosta) on syntynyt ensimmäisen 7 vuoden aikana. Kuinka paljon toimintoja ja koodia on tullut seuraavien 7 vuoden aikana? Eli mikä kehitystapa on minkäkin hintaista ja mikä on tuottavuus?

Tekninen velka vaiko taloudellinen säästö?

Selvityksessä puhutaan teknisestä velasta. Toisaalta pitäisi puhua taloudellisesta säästöstä, koska tekemällä alunperin tavoitellun kaltainen arkkitehtuuri, olisi työmäärä ollut merkittävästi suurempi ja suuremmalla työmäärällä ei olisi koskaan päästy nykyisenkaltaiseen toimivaan järjestelmään.

Selvityksessä käytetään ikävänkuuloista termiä "JSP-spagetti". Tässä ei kuitenkaan ole sanottu että tämä on aikanaan ollut tapa tehdä toimivia sovelluksia eikä tarkoita sitä, että sovellukset (joita maailmalla on paljon) olisivat jotenkin muita huonompia muussa suhteessa kuin että on käytetty erilaista arkkitehtuuria. Asiasta ymmärtämätön voi luulla että tämä termi tarkoittaa, että ohjelmat olisivat jotenkin muita huonompia.

Selvityksen vaihtoehdoissa A ja B oltaisiin käyttämässä pitkälti samoja tekniikoita kuin nykyisessä järjestelmässä, tosin erilaisen arkkitehtuurin pohjalta. Koska tekniikat ovat samoja (tai itse asiassa arkkitehtuurin takia hitaampia toteuttaa), ei ole odotettavissa että järjestelmää saataisiin tehtyä oleellisesti pienemmällä työmäärällä kuin ennen. Siksi pitäisikin asettaa kyseenalaiseksi miksi nyt on kiire järjestelmän uusimiseen, sillä seuraavan 10 vuoden aikana on varmasti tulossa tuottavampia työkaluja tämänkaltaisten järjestelmien tekemiseen.

Toimivuuden vs Toiveiden tynnyrit?

Selvityksessä puhutaan "Toiveiden tynnyristä". Olisi reilua aloittaa "Toimivuuden tynnyrillä", sillä nykyisessä järjestelmässä on mittava osa asiakkaita tyydyttäviä ominaisuuksia. Ja aina kun asiakkaat käytävät järjestelmää, tulee luonnollisesti uusia kehitysehdotuksia. Erityisesti järjestelmään, johon aikaisemmin on noita ehdotuksia pystytty lisäämään. Se että "Toiveiden tynnyri" on suuri, ei tarkoita että järjestelmä on kelvoton. Havaitaan "Toimivuuden tynnyri" ja "Toiveiden tynnyri" saadaan vaihtoehtojen A ja B vaatima työmäärä todella haastavaksi nykyisillä työkaluilla toteutettuna.

Missään ei sanota mikä on MVP:n minimitila nykyiseen järjestelmään verrattuna. Käyttäjät odottaisivat varmaan että uudessa järjestelmässä on kaikki ominaisuudet mitä he ovat tottuneet käyttämään vanhassa. Ja tässä on vaikea kuvitella että MVP saavutettaisiin muutamassa vuodessa.

Vaihtoehdossa C sanotaan että 10 htv ei ole riittävä. Mutta jätetään sanomatta että 10 htv vaihtoehdoissa A ja B ei tule riittämään paljoakaan määrittelyä pidemmälle. Ei missään tapauksessa likellekään MVP:tä jossa käyttäjät olisivat valmiita vaihtamaan toiseen järjestelmään.

Onko koko järjestelmä kirjoittetava uudelleen?

Lisäksi vaihtoehdossa C on asetettu tavoitteeksi että koko järjestelmä siirtyy selvityksen tekijän esittämään arkkitehtuuriin ja silloin on sama kuin koko järjestelmä olisi kirjoitettu alusta asti uusiksi. Tämä pitää paikkansa näin sanottuna, mutta siinä vaihtoehdossa ei käyttäjille tule koskaan mitään katkosta verrattuna A-vaihtoehtoon.

Sanomatta on kuitenkin se, että mitään pakottavaa syytä ei ole siirtää kaikkia toimintoja toiseen arkkitehtuuriin, vaan olemassa olevat toiminnot toimivat myös vanhan arkkitehtuurin mukaisesti. Siirtäähän kannattaa vain niitä toimintoja, joihin tulee merkittäviä muutospaineita, ja joilla on paljon käyttäjiä. Vähemmän käytettyjen toimintojen käyttäjät tuskin pohtivat käytettyä arkkitehtuuria. Erityisesti lisäajan ansiosta tulenee uusia ja tuottavampia työkaluja, jolloin arkkitehtuurin vaihtaminen voi olla merkittävästi edullisempaa.

"Osa käyttöliittymätoteutuksista on vanhanaikaisia eivätkä täysimittaisesti hyödynnä nykyaikaisten selainten ominaisuuksia" Tämä on toisaalta etu, koska nykyinen järjestelmä toimii nopeasti tällä hetkellä kaikilla alustoilla ja selaimilla. Eli myös mobiililaitteilla voidaan käyttää! Uudemmat teknologia tuovat tähän selkeitä haasteita ja eivät toimi vanhoilla selaimilla. Eli kaikissa paikoissa uudistamiselle ei ole niin kiire, jopa päinvastoin.

Korppi muihin yliopistoihin

Vaihtoehto Korpin käyttämisestä muissa yliopistoissa sivuutettiin aika kevyesti. Sanotaan ettei ole "suunniteltu". Montaa asiaa voi käyttää muuhunkin kuin alkuperäiseen tarkoitukseen. Ei tekstiviestejäkään suunniteltu ihmisten väliseksi kommunikointikanavaksi.

On totta että nykyinen palvelinteho ei riittäisi syyskuun alkupäivinä palvelemaan koko maan kaikkien opiskelijoiden yhtäaikaista käyttöä. Siksi sanoin haastattelussa että olisi järkevää että kullakin yliopistolla olisi oma Korppi-palvelin. Tää ei tarkoita sitä, että kunkin yliopiston Korppi alkaisi kulkea omia polkujaan, vaan edelleen palvelimen koodita haettaisiin yhdestä ainoasta versionhallinasta ja mahdollisten yliopistokohtaiset muutokset tehtäisiin yhteiseen koodiin.

Tämän vaiheen idea oli siinä, että kaikki voivat aloittaa heti toimivalla järjestelmällä ja sitten käyttöliittymiä voidaan nykyaikaistaa rauhassa ilman että täytyy olla usean järjestelmän loukussa.

Yksi kysymys oli, että mikäli joku yliopisto ei tarvitse kaikki Korpin toimintoja, niin tämä on helppo ratkaista sillä, että eivät käytä niitä. Menuista toimintoja on hyvinkin helppoa sulkea parametrisoimalla pois. Yli kunkin yliopiston Korppi-tietokannassa on tieto siitä, mitkä toiminnota ovat käytössä ja silti voidaan toimia yhdellä koodipohjalla.

Terälehtien havinaa

Lappalaisen esittämästä "terälehtimallista" sanotaan että "Hyväksytään, että muutosten ja uusien ominaisuuksien toteuttaminen voi kestää". Tämä on mielenkiintoinen väite, sillä koko Korppi on kehitetty tekemällä muutoksia olemassa olevaan järjestelmään ja nimenomaan lähdetty siitä, että uusia ominaisuuksia voidaan lisätä. Erikoista om, että tämä esitetään jonkinlaisena eri arkkitehtuurina, koska kyseessä on tapa katsoa olemassa olevaa järjestelmää siitä näkökulmasta, jollaisena se on ollut koko kehityksen ajan. Yksittäiset opiskelijaprojektit ovat lisänneet näitä terälehtiä rikkomatta mitenkään muiden terälehtien toimintaa.

"Hyväksytään, että kaikkia moderneja hyväksi havaittuja teknologioita ei voida arkkitehtuuriin istuttaa". Tällekään väittämälle ei ole mitään perustetta. Mikään ei estä etteikö uusi "terälehti" olisi toteutettu jollakin muulla arkkitehtuurilla.

"Hyväksytään, että isompi arkkitehtuuriremontti on edessä joidenkin vuosien päästä vanhentuneiden käyttöliittymäteknologioiden vuoksi". Mikään ei estä käyttämästä eri käyttöliittymätoteutuksia nykyisessäkään arkkitehtuurissa. Em. väitteet perustuvat sille ajatukselle, että pidettäisiin kynsin hampain kiinni vanhasta arkkitehtuurista ja tähän ei ole mitään tarvetta. On järkevää uudistaa arkkitehtuuria sitä mukaa kun jotakin osaa uudistetaan, mikäli tämä todetaan taloudellisesti kannattavaksi.

"Pakottaa ohuen ytimen ympärille rakentuvat terälehdet monistamaan toiminnallisuuksia, joita ei jaetusta ytimestä löydy" Tämä väite taas lähtee siitä ajatuksesta että järjestelmästä ei löydy yhteisiä toimintoja, joita ei voitaisi käyttää toisaalla. Itse asiassa yhteisiä toimintoja löytyy hyvin paljon ja niitä voidaan kirjoittaa komponenteiksi, jotka eivät ole mitenkään sidoksissa itse Korppi-järjestelmään ja näin ne jopa helpottavat tulevien "terälehtien" kirjoittamista.

Onko massiivinen tietokanta oikeasti ongelma?

Siitä voi olla samaa mieltä, että tietokanta jää merkittäväksi ytimeksi terälehtien sisäpuolelle. Selvityksen tekijä ei ole yrittänytkään selvittää olisiko tietokanta hajautettavissa useammaksi osaksi. Järjestelmästä tehdyn Pro Gradu -työn perusteella tämä olisi todella haastavaa, koska osien välinen kytkentä on todella suuri. Ja tämä tekee A vaihtoehdon toteuttamisen vähintään yhtä haastavaksi selvittäjän esittämässä muodossa. Selvittäjän mallista puuttuu merkittävä määrä kytkentöjä ja siksi "arkkitehtuuri" voi näyttää toteutuskelpoiselta.

Toisaalta pitäisi kysyä että mitä haittaa on siitä, että tietokanta on suuri? Silloin kaikki asiaan liittyvä on selkeästi yhdessä paikassa. Ja palvelut jakavat tätä tietoa ulkopuolisiin järjestelmiin ja mahdollisesti laittavat tietoa hallitusti järjestelmän sisälle. Jos tietokantaa yritetään hajauttaa, niin useita osia joudutaan replikoimaan ja tästä tulee potentiaalinen virhelähde.

Korpin teknologioihin liittyy paljon asitoita, joista voisi hyvin tehdä vähintään opinnäytetöitä tai jopa tieteellisiä artikkeleita. Harvassa paikassa on käytössä järjestelmä joka on tätä kokoluokkaa ja jossa voi mitata mitä minkäkin teknologian käyttö maksaa.

Opiskelijatyö

Selvityksessä on otettu huomioon sekin mahdollisuus, että kehitystä tehdään opiskelijatyönä kuten tähänkin asti. Tässä kuitenkin poissuljetaan perustelemattomasta syystä se, että malleissa A tai C käytettäisiin opiskelijaprojekteja jo kehitysaikana. Mikäli arkkitehtuuri on selkeästi määritelty ja dokumentoitu esimerkein, kykenee opiskelijaprojektit hyvin tekemään myös uuden kehitystyötä.

Mitä sitten pitäisi tehdä?

Piilevästi selvityksessä on sanottu, että vaihtoehdot A ja B tulevat olemaan kustannuksien ja käyttäjien useamman järjestelmän loukussa olemisen kannalta sietämättömiä.

On toki selvää, että mitään järjestelmää ei kannata jättää kehittämättä, mikäli sitä aiotaan käyttää pidempään. Asiakkailta tulee uusia toiveita ja niihin olisi syytä reagoida ja miettiä mitkä toiveet sopivat ydin-Korpin tehtäviin ja mitkä pitää toteuttaa jollakin muulla järjestelmällä jos edes järjestelmää tarvitaan.

Usein riittää että on riittävät yhteydet esimerkiksi Exceliin tms. millä opettajat voivat tehdä tarvittavia seurantaraportteja kurssien edistymisestä. Ja mikäli joku opettaja saa hyviä käytänteitä, niin näitä voidaan monistaa tai siirtää sitten kokonaan Korpin puolelle.

Silloin kun jotakin järjestelmän osaa uudistetaan, pitää katsoa kannattaako samalla korjata muita samaan osaan liittyviä toiveita. Ja tässä yhteydessä koodia kannattaa refaktoroida ja mahdollisesti vaihtaa uudempaan arkkitehtuuriin.

Pelkästään vaihtamisen ilosta ei toimivaa koodia kannata lähteä muuttamaan.

Tärkeää olisi määritellä myös järjestelmälle todellinen omistaja, mikä ei voi olla ylimmän hallinnon henkilöistä koostuva ryhmä. Selvityksessä puhutaan että Korppia on kehitetty ketterillä menetelmillä. Ketteristä menetelmistä ei saisi missään tapauksessa puhua, mikäli asiakkaan rooli on sitä, mitä se on ollut viimeiset 7 vuotta. Omistajana tulee olla todellinen asiakas, eli opettajista ja laitoksen hallintohenkilöistä sekä opiskelijoista koostuva ryhmä.

Eli järkevästi uudistaen vaihtoehto C on pitkällä aikavälillä edullisin ja haittaa vähiten yliopiston ydintoimintaa. Lisäksi saatu lisäaika kääntyy säästöksi, sillä tulevaisuuden työkaluilla uudistaminen on tuottavampaa.