Mikäli vanhan kruununjalokivenne loiste alkaa himmentyä, on uudistustyö syytä saada käyntiin mahdollisimman pian. Tässä artikkelissa kuvataan menetelmä legacy-sovellusten korvaamiseen, eli kuinka vanha työjuhta korvataan kokonaan uudella pilvipohjaisella sovelluksella.

Useimmat modernisoinnit hoituvat huomattavasti helpommilla refactoring- tai rearchitecting – lähestymistavoilla. Tämä artikkeli käsittelee kuitenkin hieman dramaattisempaa lähestymistapaa, jota tarvitaan kun muut keinot pettävät: Sovelluksen teknisen alustan tuki voi olla loppunut, tai jäljellä ei enää ole yhtään kehittäjää, joka tietäisi miten sovellus, sovellusalusta tai kyseinen ohjelmointikieli toimii (yllättyisit jos tietäisit kuinka yleistä tämä on!). Ainoaksi vaihtoehdoksi jää korvaavan sovelluksen rakentaminen.

Tavoitteiden uudelleenmäärittely

Tässä artikkelissa kuvataan menetelmän pääpiirteet jonka avulla vanhentunut, mutta edelleen liiketoimintakriittinen sovellus uudistetaan nykypäivän vaatimuksia vastaavaksi pilvisovellukseksi. Uudistus on haastava, joskus jopa pelottavalta tuntuva projekti, mutta pyrin näyttämään kuinka sekä kustannuksia että läpimenoaikaa voidaan hallita. Menetelmän keskeisin osa on sovelluksen tavoitteiden uudelleenmäärittely. Tavoitteena on tunnistaa liiketoiminnan kannalta keskeiset toiminnot, ja keskittyä prosessissa ensisijaisesti näiden toimintojen toteuttamiseen. Lopputyö automatisoidaan. Koko prosessi hyödyntää sovellukseenne vuosien aikana kertynyttä viisautta liiketoiminnasta.

Soveltuvuus

Menetelmä soveltuu keskikokoisesta suuriin liiketoimintasovelluksiin (Line of Business, LOB apps), jotka tyypillisesti koostuvat muutamasta sadasta tuhanteen taulua sisältävästä tietokannasta, sekä näitä tauluja lähes vastaavista ruuduista joilla kannan sisältöä listataan, luetaan, päivitetään tai luodaan. Sovelluksessa on yleensä liiketoimintalogiikkakerros, joka sisältää logiikan lisäksi integraatiot muihin järjestelmiin. Liiketoimintalogiikka on valitettavan usein koodattu tämän tyyppisissä sovelluksissa joko osittain tai kokonaan käyttöliittymäkerrokseen. Menetelmä itsessään on alustariippumaton, ja sitä voidaan soveltaa esim. Oracle Forms, MS Win Forms, SAP, Lotus Notes tms. alustojen päälle rakennettujen liiketoimintasovellusten uudistamiseen.

Periaatteita

Menetelmä itsessään ei sisällä mitään kovinkaan uutta tai mullistavaa, se vain näyttää soveltuvan tehtäväänsä erinomaisen hyvin. Olemme käyttäneet menetelmää muutamissa uudistusprojekteissa hyvin tuloksin. Sen avulla saavutettavissa olevat hyödyt näyttävät myös kasvavan suhteessa sovelluksen kokoon: Mitä suurempi sovellus, sitä parempi hyöty.

Aluksi on tärkeä ymmärtää, että kyseessä ei ole konversioprojekti. Tämä siksi, että mahdollisesti aikaisemmin saamanne arviot projektin kestosta ja kustannuksista olettavat todennäköisesti kyseessä olevan konversioprojektin. Tavoitteena ei ole konversio; kaikki vanhan sovelluksen piirteet, käyttöliittymät tai tietokanta eivät siirry sellaisenaan uuteen sovellukseen. Keskeistä on tunnistaa sovellukselle asetetut liiketoimintatarpeet. Tämä tehdään jakamalla sovellus liiketoiminnan kannalta olennaisiin toimintoihin sekä tukitoimintoihin. Kumpikin laji käsitellään menetelmässä omalla tavallaan. Menetelmä esittelee myös maagisen 80/20-säännön toimimassa kauneimmillaan.

Seuraavaksi käsitellään itse menetelmän vaiheet.

Olennaiset

Aloita listaamalla sovelluksen tavoitteet, eli syyt miksi sovellus on olemassa. Kirjoita tavoitteet liiketoiminnan näkökulmasta – mitä konkreettista liiketoimintaa edistävää tehtävää sovellus palvelee. Tämä tulee olemaan myöhemmin tarkistuslistasi, joten pidä huolta että kaikki tavoitteet tulee kirjattua. Tämän jälkeen siirrytään tutkimaan itse sovellusta.

Olennaiset käyttöliittymät

Seuraa muutama päivä kuinka eri käyttäjäryhmät käyttävät sovellustasi. Käyttäjäryhmät löytyvät yleensä joko organisaatiorakenteestasi, tai henkilöiden toimenkuvista: Laskutus, markkinointi, myynti, tuotteet ja palvelut jne. Jokainen käyttäjäryhmä käyttää sovellustasi saavuttaakseen oman tavoitteensa, ja tehtävänäsi on löytää kaikki nämä eri käyttäjäryhmien olennaiset tavoitteet. Huomaat hyvin pian, että noin 80% käyttäjien ajasta kuluu enintään 20%:lla sovelluksen kaikista “ruuduista”, eli käyttöliittymistä jonka sovellus sisältää. Ensimmäisessä uudistusprojektissani, 400 ruudun sovelluksessa käyttäjät viettivät suurimman osan aikansa vajaalla kolmellakymmenellä ruudulla. Nämä useimmin käytetyt käyttöliittymät pitäisi korreloida tekemäsi liiketoimintatavoitelistan kanssa. Tarkista samalla listasi – onko listalla kaikki olennaiset liiketoimintatavoitteet (yleensä on).

Olennaiset prosessit

Seuraavaksi tavoitteena on löytää sovelluksesi keskeiset integraatiot muihin järjestelmiin, sekä yleensä eräajoina suoritettavat olennaiset taustaprosessit. Todellisuudessa suurin osa näistäkin löytyy käyttäjien seurannassa. Tarkkaile käyttäjiä haastatellessasi lauseita kuten: “Tarkistan pankista tulleita aineistoja”, tai “Katson miten viime yön postitusajot sujuivat”. Integraatioiden ja taustaprosessien löytäminen voi joskus vaatia lievää salapoliisityötä. Jos kaikki muu pettää, tähänkin on olemassa joukko työkaluja, jotka seuraavat sovelluksen sisään tulevaa ja lähtevää tietoliikennettä.

Asiat tärkeysjärjestykseen

Kahdessa edellisessä vaiheessa selvitit käytännössä järjestelmän keskeiset aktorit (järjestelmän todelliset käyttäjät, että automaatiotilit), sekä järjestelmän tärkeimmät käyttötapaukset (en. use case). Tämän lisäksi sinulla on lista keskeisistä liiketoimintatavoitteista, joka korreloi käyttötapaustesi kanssa. Lista on järjestelmän keskeisten ominaisuuksien vaatimusmääritys. Arvannet miten tarina jatkuu: Tulet rakentamaan uuden sovelluksen, jonka tekemisessä keskitytään tärkeimpiin käyttötapauksiin. Kokemukseni mukaan nämä kattavat noin 20% kaikesta sovelluksen sisältämästä toiminnallisuudesta. Toteuttamalla tämän olennaisen 20% toiminnoista katat kuitenkin 80% sovelluksen todellisesta käytöstä. 80/20 sääntö vie sinut vielä hieman pidemmälle: 80% budjetista annetaan olennaisten 20%:n toteuttamiseen. Rakenna paras sovellus mihin vain kykenet – suunnittele upein käyttäjäkokemus (User Experience, UX), poista kaikki tarpeeton käyttöä häiritsevä tieto, tilaa hienoin grafiikka ja upeimmat raporttien visualisoinnit, koodaa huolella ja testaa hyvin.

Seuraavaksi käsitellään mitä jäi tähteeksi.

Tukitoiminnot

Olen alkanut nimittää jäljelle jäävää 80% sovelluksesta tukitoiminnoiksi. Näihin kuuluvat mm. sovelluksen ohjausparametrien, liiketoimintasääntöjen tai muiden ajonaikaisten parametrien käsittely. Normaaliin työnkulkuun liittyvät poikkeustapaukset. Asiat, joita ei tehdä päivittäin, viikoittain tai edes kuukausittain. Toiminnot joita käyttää vain yksi tai muutama ihminen. Raja ei aina ole selvä, mutta ymmärtänet jo mistä on kyse. Ajonaikaisten parametrien käsittely on aina tukitoiminto. Muutoin arvioi toiminto sen mukaan kuinka montaa käyttäjää toiminto koskee, ja kuinka usein toimintoa tarvitaan. Hyvä puoli on se, että päätöstä ei tarvitse tehdä heti alkuvaiheessa – voit muuttaa myöhemmin mieltäsi.

Tukitoimintojen toteutusstrategia on yksinkertainen: Minimoi näiden siirtämiseen käytettävä aika ja vaiva. Ensimmäinen tehtävä on poistaa kaikki tarpeettomat toiminnot ja tarpeeton data. Tätä ehtii kertyä sovellukseen käsittämättömältä tuntuva määrä vuosien aikana. Seuraavaksi; Ei sääntöjä. Konvertoi, “rumakoodaa”, leikkaa/liimaa – mitä tahansa millä pääset eroon työstä mahdollisimman nopeasti. Hyväksi lähestymistavaksi on osoittanut antaa arkkitehdeille kustannuskatto: Työ saa maksaa 20% siitä mitä olennaisten piirteiden toteutus tulee maksamaan. Tämän jälkeen arkkitehdit yleensä tekevät oikeat päätökset. Vihjeeni on seuraava: Tulette käyttämään Mallipohjaisen ohjelmistotuotannon välineitä tekemään likaisen työn puolestanne, sillä välin kun te keskitytte olennaisiin asioihin.

Hei – Mitä juuri tapahtui?

Vedetäänpä yhteen: Ensin rajasit työn olennaisiin toimintoihin – eli enintään 20% koko sovelluksesta. Tämä vuorostaan pudotti kustannukset viidesosaan koko sovelluksen konversioon verrattuna. Tähteet hoidetaan mieluiten automatisoidusti. Normaali projektisäätäminen ja sählääminen mukaan lukien odotan menetelmällä itse noin 50%:n säästöä sekä kustannuksissa että toteutusajassa verrattuna periteiseen konversioon perustuvaan lähestymistapaan. Tämä luku yleensä pitää, vaikka rakentaisit upeimman ja uudenaikaisimman sovelluksen ikinä toteuttamaan olennaiset toiminnot. Automatisoitu ohjelmistotuotanto hoitaa virheettömän ja nopean ratkaisun tukitoimintojen toteuttamiseksi.

Ei kovin vaikeaa, vai kuinka?