Ohjelmistomaailmassa viisi vuotta voi tarkoittaa sekä järjestelmää, joka on yhä hyvin valmis jatkokehitykseen, että teknologista ongelmaa, joka maksaa joka kuukausi yhä enemmän.
Sovelluksen ikä ei kuitenkaan itsessään ole syy vaihtaa sitä.
Tämä on yksi tärkeimmistä asioista, jotka kannattaa sanoa alussa.
Ei ole olemassa yleistä rajaa, jonka jälkeen sovellus pitäisi kirjoittaa kokonaan uudelleen. On järjestelmiä, jotka ovat toimineet yli kymmenen vuotta ja joilla on edelleen järkevä arkkitehtuuri, ajantasaiset riippuvuudet, hyvä dokumentaatio ja toimiva käyttöönottoprosessi. On myös huomattavasti nuorempia sovelluksia, joiden kehitystä ovat vaikeuttaneet virheelliset arkkitehtuuripäätökset, testien puute, hallitsemattomat riippuvuudet tai peräkkäiset nopeat korjaukset.
Ongelma ei siis ole vuosien määrä.
Ongelma on järjestelmän kyky muuttua edelleen.
Tärkein kysymys ei ole: "Onko sovellus vanha?"
Parempi kysymys on: "Paljonko seuraava muutos maksaa meille?"
Jos uuden ominaisuuden lisääminen vaatii yhä enemmän työtunteja, useiden tiimien osallistumista, manuaalisia testejä ja vanhan arkkitehtuurin rajoitusten kiertämistä, järjestelmä alkaa tuottaa kustannusta, joka ei näy pelkässä koodissa.
Tämä on juuri yksi kasvavan technical debtin käytännön merkeistä.
Technical debt voidaan ymmärtää tulevien muutosten kustannuksena, joka johtuu aiemmista teknisistä päätöksistä. Martin Fowler kuvaa sitä lisätyöksi, jota täytyy tehdä järjestelmää muokattaessa, kun sen sisäinen laatu vaikeuttaa kehitystä.
Ja juuri siksi sovellus voi edelleen toimia oikein, mutta samalla olla yhä vaikeampi kehittää.
10 ominaisuutta myöhemmin järjestelmä näyttää aivan erilaiselta
Projektin alku on usein yksinkertainen.
Syntyy MVP.
Sitten tulee lisää vaatimuksia:
- integraatio CRM:n kanssa,
- verkkopohjaiset maksut,
- ylläpitopaneeli,
- mobiilisovellus,
- uudet käyttäjäroolit,
- raportointi,
- automatisoinnit,
- API,
- integraatiot ulkoisiin palveluihin,
- uudet kieliversiot.
Jokainen muutos yksittäin voi olla perusteltu.
Ongelma syntyy silloin, kun arkkitehtuuria ei alun perin suunniteltu tällaista kehityssuuntaa varten.
Silloin uusia ominaisuuksia ei enää lisätä vakaaseen rakenteeseen.
Ne lisätään aiempien poikkeusten, kiertoteiden ja kompromissien päälle.
Mistä tietää, että järjestelmä alkaa vanhentua?
Ei tarvitse odottaa täydellistä vikaa.
Varoitusmerkit ilmestyvät paljon aikaisemmin.
1. Uuden ominaisuuden toteutus kestää yhä pidempään
Ennen ominaisuus vei muutaman päivän. Nyt vastaava muutos vaatii useita viikkoja.
Tämä ei välttämättä tarkoita hitaampaa tiimiä.
Se voi tarkoittaa, että yhä enemmän aikaa kuluu olemassa olevan järjestelmän ymmärtämiseen ja sen suojaamiseen muutoksen vaikutuksilta.
2. Jokainen muutos laukaisee dominovaikutuksen
Yhden moduulin muokkaaminen aiheuttaa ongelmia useissa muissa paikoissa.
Tämä on merkki siitä, että komponentit ovat liian tiiviisti kytkeytyneet tai niiden vastuurajoja ei ole määritelty oikein.
3. Testit ovat pääosin manuaalisia
Jos jokainen suurempi muutos vaatii kymmenien toimintojen manuaalista tarkistamista, käyttöönoton kustannus kasvaa.
Ongelma ei ole automaation puute sinänsä.
Ongelma on se, ettei ole mahdollista saada nopeasti luotettavaa tietoa siitä, rikkoko muutos jotain.
4. Tiimi pelkää koskea tiettyihin järjestelmän osiin
Tämä on hyvin käytännöllinen mittari.
Jos on moduuleja, joita kehittäjät välttelevät, koska "kukaan ei tiedä tarkasti, mitä muutoksen jälkeen tapahtuu", tekninen riski on jo todellinen liiketoimintakustannus.
5. Järjestelmä riippuu vanhentuneista teknologioista
Vanha framework ei itsessään tarkoita ongelmaa.
Ongelma syntyy silloin, kun:
- sitä ei enää tueta,
- asiantuntijoita on vaikea löytää,
- riippuvuuksia ei voi päivittää turvallisesti,
- ajoympäristö on ongelmallinen,
- integrointi uusiin ratkaisuihin on vaikeaa.
Silloin teknologia alkaa rajoittaa liiketoiminnan mahdollisuuksia.
Pitääkö sovellus aina kirjoittaa alusta asti uudelleen?
Ei.
Tämä on yksi yleisimmistä virheistä legacy-softaan suhtautumisessa.
Täysi rewrite voi olla perusteltu, mutta se on suuren riskin hanke.
Vanha järjestelmä sisältää usein kymmeniä tai satoja liiketoimintasääntöjä, poikkeuksia ja käyttäytymismalleja, joita ei ole dokumentaatiossa. Jos se kirjoitetaan uudelleen tyhjästä, on hyvin helppoa luoda teknologisesti uusi mutta liiketoiminnallisesti puutteellinen järjestelmä.
Siksi monissa tapauksissa parempi ratkaisu on vaiheittainen modernisointi.
Yksi osa järjestelmästä pysyy käytössä, ja muita alueita korvataan vähitellen uusilla komponenteilla.
Tämä lähestymistapa tunnetaan muun muassa Strangler Fig -mallina. Sen avulla järjestelmää voidaan modernisoida askel askeleelta, tuottaa arvoa aiemmin ja pienentää koko ratkaisun kerralla migroinnin riskiä.
Milloin modernisointi on järkevää?
Sitä kannattaa harkita, kun:
- järjestelmä toteuttaa edelleen tärkeitä liiketoimintaprosesseja,
- arkkitehtuuri mahdollistaa ainakin osan toiminnallisuudesta irrottamisen,
- data voidaan siirtää tai integroida turvallisesti,
- ongelma koskee tiettyjä alueita, ei koko rakennetta,
- sovellus tuottaa arvoa ja sen täydellinen vaihtaminen olisi riskialtista,
- järjestelmää voidaan modernisoida vaiheittain.
Tämä on erityisen hyvä ratkaisu järjestelmissä, joita ei voi vain sammuttaa muutamaksi kuukaudeksi.
Milloin modernisoinnissa ei ehkä ole järkeä?
On myös tilanteita, joissa vanhan järjestelmän pelastaminen ei enää ole taloudellisesti järkevää.
Esimerkiksi kun:
- arkkitehtuuri on perustavanlaatuisesti ristiriidassa nykyisten vaatimusten kanssa,
- keskeiset teknologiat eivät ole tuettuja,
- järjestelmällä ei ole luotettavia testejä eikä dokumentaatiota,
- tietoturva vaatii perusteellista uudistamista,
- jokainen suurempi muutos vaatii puuttumista lähes koko järjestelmään,
- ihmisiä, jotka ymmärtävät sen toiminnan, ei ole tarpeeksi,
- ylläpidon ja kehityksen kustannukset ylittävät jatkokäytön arvon.
Silloin kannattaa laskea muutakin kuin modernisoinnin kustannus.
On laskettava myös kustannus siitä, että pysytään nykyisessä ratkaisussa.
Kallein sovellus ei aina ole se kallein ylläpitää
Voi olla järjestelmä, jonka kuukausittainen ylläpito maksaa suhteellisen vähän.
Ja samalla jokainen uusi ominaisuus maksaa moninkertaisesti enemmän kuin sen pitäisi.
Siksi pelkkä hosting-, palvelin- tai tukilasku ei vielä kerro, paljonko teknologia maksaa.
Järjestelmän todellinen kustannus sisältää myös:
- kehitysaika,
- testausaika,
- virheiden kustannus,
- käyttöönottoaika,
- katkosten kustannus,
- rekrytoinnin vaikeus,
- tietoturvariski,
- osaamisen menettämisen kustannus,
- uusien ominaisuuksien viivästyminen,
- liiketoiminnan teknologiset rajoitteet.
Jossain vaiheessa teknologiasta lakkaa tulemasta liiketoimintaa tukeva työkalu.
Siitä tulee liiketoiminnan rajoite.
Miten päätöstä kannattaa lähestyä?
Ennen kuin päätetään "kirjoitamme kaiken alusta", kannattaa tehdä tekninen auditointi.
Sen tulisi kattaa ainakin:
Arkkitehtuuri - miten järjestelmä on jaettu ja miten sen osat kommunikoivat.
Koodi - laatu, monimutkaisuus, toisteisuus ja erityisen hankalat ylläpitokohdat.
Riippuvuudet - kehykset, kirjastot, versiot ja niiden tuki.
Tietoturva - haavoittuvuudet, käyttöoikeuksien hallintatapa ja vanhentuneista komponenteista johtuvat riskit.
Testit - automatisoinnin laajuus ja mahdollisuus ottaa muutoksia käyttöön turvallisesti.
CI/CD - sovelluksen rakentamisen, testaamisen ja käyttöönoton tapa.
Data - tietokannan rakenne, migraatiot, integraatiot ja riippuvuudet.
Valvonta - tiedetäänkö, mitä järjestelmälle tapahtuu käyttöönoton jälkeen.
Tuotekehitysprosessi - paljonko seuraavan ominaisuuden toimittaminen todella maksaa.
Vasta tämän perusteella voidaan arvioida järkevästi kolme skenaariota:
- ylläpidämme ja kehitämme,
- uudistamme vaiheittain,
- rakennamme uuden järjestelmän.
Yhtä oikeaa vastausta ei ole. On kuitenkin olemassa oikea tapa päästä vastaukseen.
Teknologian pitäisi mahdollistaa kasvu, ei estää sitä
Hyvä arkkitehtuuri ei tarkoita, että järjestelmä näyttää modernilta.
Se tarkoittaa, että sitä voidaan muuttaa silloin, kun liiketoiminta sitä vaatii.
Siksi sovellusta kannattaa tarkastella muustakin kuin siitä näkökulmasta, toimiiko se tänään.
Täytyy myös selvittää, paljonko uusien ominaisuuksien lisääminen maksaa vuoden, kahden tai viiden vuoden kuluttua.
Sillä järjestelmä, joka toimii mutta estää sujuvan kehityksen, voi olla paljon suurempi ongelma kuin järjestelmä, joka vain kaipaa modernisointia.
