Vanhan ohjelmiston uudistaminen ilman täysremonttia

Lähes jokaisella vakiintuneella yrityksellä on sellainen: ohjelmisto, jota kaikki hiljaa inhoavat. Se on hidas, ruma, puolet tiimistä tietää kiertotien bugille jota kukaan ei koskaan korjannut, ja se ainoa henkilö joka sen ymmärsi lähti vuonna 2019. Vaisto on aina sama — poltetaan se ja rakennetaan tilalle uusi. Ja juuri tuo vaisto on useimmiten se, miten hyvät yritykset menettävät vuoden ja pienen omaisuuden tyhjästä.

Olen nähnyt suuren uudelleenkirjoituksen menevän pieleen niin monta kertaa, että minulle on syntynyt siitä refleksi. Perustaja näyttää minulle natisevan tilausjärjestelmänsä tai ikivanhan aikataulutyökalunsa, huokaisee ja sanoo jonkin version lauseesta ”meidän pitää vain korvata koko juttu”. Ja ehkä jonain päivänä korvaattekin. Mutta täysi uudelleenkirjoitus — vanha järjestelmä revitään irti, kiiltävä uusi rakennetaan rinnalle, kytkin käännetään — on yksi koko ohjelmistoalan riskialttiimmista liikkeistä. Se on kallista, kestää paljon luvattua kauemmin, ja koko ajan toimitte sokkona toivoen että uusi juttu kattaa jokaisen oudon reunatapauksen jota vanha hiljaa hoiti viisitoista vuotta.

Hyvä uutinen on, että täysremontti ei lähes koskaan ole ainoa vaihtoehto, eikä harvoin paras. On olemassa rauhallisempi tapa uudistaa — vaiheittainen, peruutettava ja lempeä liiketoiminnalle, jonka pitää yhä tehdä rahaa työn aikana. Tämä on opas siihen tapaan: miten tunnistaa mikä oikeasti kaipaa korjausta, miten korvata kipeät osat ottamatta koko järjestelmää alas, ja miten tunnistaa milloin täysi uudelleenkirjoitus aidosti on oikea ratkaisu.

Miksi täysremontti on niin houkutteleva — ja niin vaarallinen

Täysi uudelleenkirjoitus viettelee, koska se lupaa puhtaan pöydän. Ei enää legacy-sotkua, ei kompromisseja, tuore koodikanta rakennettuna oikein moderneilla työkaluilla. Fläppitaululla se näyttää itsestäänselvältä. Todellisuudessa sitoudut rakentamaan uudelleen vuosien kertyneen liiketoimintalogiikan — josta suuri osa on dokumentoimatta, osa elää vain lähteneiden ihmisten päässä — kellon käydessä ja laskujen kolahdellessa.

Syvempi ansa on rinnakkaisuniversumin ongelma. Niiden kuukausien tai vuosien ajan, jotka korvaajan rakentaminen kestää, sinulla on kaksi järjestelmää: vanha, jonka pitää yhä pyörittää liiketoimintaa, ja uusi, joka ei vielä ole valmis. Jokainen muutos, jonka liiketoiminta tarvitsee, on tehtävä kahdesti, tai uusi järjestelmä jää todellisuudesta jälkeen ennen kuin se ehtii edes julkaista. Tiimit palavat loppuun pitäessään molempia hengissä. Ja koska kenenkään ei sallita vaihtaa ennen kuin uusi järjestelmä tekee kaiken, ei tule varhaista voittoa, ei palautetta, ei todistetta että se toimii — vain pitkä, ahdistunut odotus yhtä valtavaa, kaikki-tai-ei-mitään -julkaisupäivää varten.

Tässä on tunnettu alan kansanviisaus, ja se on ansaittu: toisella järjestelmällä, suurella uudelleenkirjoituksella, on tapana kestää kolme kertaa arvioitua kauemmin ja saapua vähemmillä ominaisuuksilla kuin se mitä se korvaa. Arvio ei ole väärä siksi että ihmiset ovat huolimattomia. Se on väärä siksi, ettei kukaan voi alussa nähdä kaikkia niitä pieniä asioita joita vanha järjestelmä hiljaa tekee oikein.

Mitä ”legacy” oikeasti tarkoittaa (ei kyse iästä)

Heittelemme sanaa legacy ikään kuin se tarkoittaisi vain vanhaa. Ei tarkoita. Moni ohjelmisto, joka on pyörinyt vuosikymmenen, on aivan kunnossa — tylsä, vakaa, maksettu, hoitaa tehtävänsä. Pelkkä ikä ei ole syy koskea mihinkään. Koko tämän alan kallein virhe on uudistaa jotain joka toimi hiljaa, vain siksi että se näytti vanhanaikaiselta.

Ohjelmisto ansaitsee legacy-leiman, kun se aktiivisesti on tielläsi. Kun et voi turvallisesti muuttaa sitä, koska kukaan ei ymmärrä sitä täysin. Kun se ei voi yhdistyä työkaluihin joista nyt riiput. Kun yksi ainoa henkilö on ainoa joka pystyy pitämään sen hengissä. Kun se on niin hidas tai hauras, että tiimisi on rakentanut sen ympärille kokonaisen kiertoteiden kansanperinteen. Se on todellinen määritelmä — ei se vuosi jolloin se kirjoitettiin, vaan se hinta jonka se sinulle tänään aiheuttaa ja riski jonka se kantaa huomiseen.

Diagnosoi ennen kuin kosket mihinkään

Ennen kuin yhtäkään riviä kirjoitetaan uusiksi, tarvitset rehellisen kartan siitä missä kipu oikeasti asuu. Useimmiten järjestelmä jota kaikki vihaavat on 80-prosenttisesti kunnossa. Vaiva on keskittynyt muutamaan tiettyyn paikkaan — yksi hidas näkymä, yksi rikkinäinen integraatio, yksi työnkulku joka pakottaa kirjaamaan tiedot kahdesti — ja nämä harvat paikat synnyttävät lähes kaikki valitukset. Löydä ne, ja olet löytänyt koko projektisi.

Tapa löytää ne ei ole ensin tekninen auditointi — se on keskustelu. Istu niiden ihmisten kanssa jotka käyttävät juttua joka päivä ja kysy missä sattuu. Missä he odottavat? Mitä he kirjaavat uudelleen? Mitä he välttävät koska se on tuskaista? Missä he pitävät omaa taulukkoaan kiertääkseen virallisen järjestelmän? Nuo kiertotiet ovat kultaa: jokainen niistä on tarkka röntgenkuva korjaamisen arvoisesta ongelmasta.

• Näkymät ja vaiheet joista ihmiset eniten valittavat — ei teoriassa vaan heidän todellisessa arkityössään.
• Joka paikka jossa tiedot kirjataan kahdesti koska kaksi järjestelmää eivät keskustele keskenään.
• Integraatiot jotka rikkoutuivat tai joita ei koskaan ollut, pakottaen manuaaliseen kopiointiin työkalujen välillä.
• Kaikki minkä käyttöä tai korjaamista vain yksi henkilö osaa — yksittäiset vikapisteesi.
• Osat jotka ovat aidosti kunnossa, jotta voit suojella ja jättää ne rauhaan.
• Mitä liiketoiminta tarvitsee ensi vuonna, mihin nykyinen järjestelmä ei yksinkertaisesti voi kasvaa.

Kun teet tämän rehellisesti, projekti yleensä kutistuu. Omistaja joka käveli sisään sanoen ”korvataan kaikki” kävelee ulos oivaltaen tarvitsevansa korjata kolme asiaa. Se ei ole pettymys — se on helpotus. Kolme korjattavaa asiaa on projekti jonka voit saada valmiiksi tällä kvartaalilla. Täysi korvaaminen on vuosi josta et ehkä selviä.

Strangler-lähestymistapa: korvaa se pala kerrallaan

Tähän on olemassa malli jolla sen tekee turvallisesti, ja sillä on hieman synkkä mutta mieleenpainuva nimi: strangler-lähestymistapa, kuristajaviikunan mukaan — köynnös joka kasvaa puun ympärille ottaen vähitellen sen rakenteen haltuun, kunnes lopulta uusi kasvu seisoo omillaan ja vanha runko on poissa. Ohjelmistoon sovellettuna ajatus on kauniin käytännöllinen: et korvaa vanhaa järjestelmää yhdellä sankarillisella vaihdolla. Kasvatat uuden sen ympärille, pala kerrallaan, kunnes vanhasta ei jää jäljelle mitään mitä kukaan tarvitsisi.

Käytännössä se toimii näin. Valitset yhden kipeän palan — vaikkapa laskutusmoduulin jota kaikki vihaavat. Rakennat modernin korvaajan vain sille palalle. Ohjaat laskutuksen uuteen moduuliin samalla kun kaikki muu pyörii koskemattomana vanhassa järjestelmässä. Tarkkailet sitä hetken. Kun se on vakaa, tuo osa vanhasta järjestelmästä hiljenee, ja siirryt seuraavaan palaan. Vanha järjestelmä kutistuu vähitellen, kuin kynttilä, sen sijaan että se kaadettaisiin kerralla.

Tämän tekee niin paljon turvallisemmaksi kuin uudelleenkirjoitus se, että jokainen askel on pieni, elävä ja peruutettava. Et koskaan toimi sokkona. Jokainen uusi pala menee nopeasti todelliseen käyttöön, joten saat nopeasti selville toimiiko se oikeasti. Jos jokin menee pieleen, olet riskeerannut vain yhden moduulin, et koko liiketoimintaa — ja voit yleensä palata vanhaan polkuun korjatessasi. Saat voittoja matkan varrella yhden kauhistuttavan loppujulkaisun sijaan. Ja liiketoiminta pyörii normaalisti koko ajan.

Miltä rytmi oikeasti näyttää

1. 1
   Valitse kipein, omavaraisin pala

   Haluat korkean kivun ja siistit reunat — moduulin joka sattuu paljon eikä pidä sormiaan kaikessa muussa. Se on ensimmäinen kohteesi.
2. 2
   Aseta ohut kerros vanhan järjestelmän eteen

   Pieni reitityskerros päättää mitkä pyynnöt menevät vanhaan järjestelmään ja mitkä uuteen palaan. Tämä on sauma joka tekee kaiken muun mahdolliseksi.
3. 3
   Rakenna ja julkaise vain se yksi pala

   Korvaa yksi moduuli, vie se todellisiin käsiin ja ohjaa siihen vain se siivu työtä. Viikkoja, ei vuosia — eikä muu järjestelmä liikahtanut.
4. 4
   Vakauta, sitten siirry seuraavaan palaan

   Kun uuteen moduuliin luotetaan, vanhan järjestelmän vastaava osa jää lepotilaan. Toista seuraavalla kipeällä palalla, oppien matkan varrella.
5. 5
   Poista vanha järjestelmä käytöstä kun se on tyhjä

   Lopulta legacy-järjestelmä ei tee mitään mihin kukaan tukeutuisi. Vasta silloin sammutat sen — hiljaa, ilman draamaa, koska kaikki tärkeä on jo siirtynyt.

Huomaa mikä tässä on erilaista kuin uudelleenkirjoituksessa: ei ole yhtä julkaisupäivää jota pelätä. Ei rinnakkaisuniversumia ylläpidettävänä. Uusi järjestelmä on tuotannossa kolmannesta viikosta lähtien, ansaiten leipänsä ja opettaen sinulle asioita, sen sijaan että odottaisi laboratoriossa julkaisua joka venyy venymistään.

Joskus sitä ei tarvitse edes korvata

Ennen kuin korvaat mitään, kannattaa kysyä tarvitseeko vanha järjestelmä korvaamista vai pitääkö sen vain lakata olemasta saari. Yllättävän moni ”tarvitsemme uuden järjestelmän” -ongelma on oikeasti ”järjestelmämme eivät keskustele keskenään” -ongelma. Vanha ohjelmisto hoitaa tehtävänsä hyvin — se vain istuu siilossa pakottaen ihmiset kuljettamaan tietoa sisään ja ulos käsin.

Näissä tapauksissa halvin ja nopein korjaus ei ole uusi järjestelmä. Se on silta. Käärit vanhan ohjelmiston yhteyteen — integraatioon joka antaa sen vaihtaa tietoa muiden työkalujesi kanssa automaattisesti — ja moderniin kerrokseen päälle niitä osia varten joita ihmiset oikeasti koskettavat. Vanhanaikainen moottori hyrisee yhä alla; tiimi saa siistin pinnan ja lopun kopioinnille. Se ei ole hohdokasta, mutta se on usein koko ponnistuksen korkein tuotto per euro.

Milloin täysremontti aidosti on oikea ratkaisu

Olen käyttänyt koko tämän oppaan puhuakseni sinut irti suuresta uudelleenkirjoituksesta, joten ollaan reiluja: joskus se todella on vastaus. On perustoja niin lahonneita, ettei mikään paikkailu, sillanrakennus tai pala kerrallaan korvaaminen pelasta niitä, ja muunlainen teeskentely vain viivyttää väistämätöntä samalla kun käytät rahaa ruumiin pönkittämiseen.

Rehelliset merkit ovat tarkkoja. Teknologia jonka päälle järjestelmä on rakennettu on kuollut tai kuoleva — ei tukea, ei tietoturvapäivityksiä, kukaan jäljellä ei pysty työskentelemään sen parissa. Liiketoiminta on muuttunut niin perustavanlaatuisesti, ettei vanha malli enää vastaa todellisuutta lainkaan. Tai järjestelmä on niin sotkuinen, että pienetkin muutokset rikkovat säännöllisesti asioita liittymättömissä paikoissa, mikä yleensä tarkoittaa ettei strangler-lähestymistavalle ole alunperinkään siistejä saumoja. Kun kaksi tai kolme näistä on totta yhtä aikaa, vaiheittainen työ lakkaa olemasta turvallisempi valinta.

Ja tässä on vaiheittaisen työn ensin tekemisen hiljainen palkinto, vaikka lopulta rakentaisitkin uudelleen: siihen mennessä ymmärrät järjestelmän paljon paremmin kuin alussa. Jokainen korvaamasi moduuli opetti sinulle jotain mitä alkuperäiset tekijät eivät koskaan kirjoittaneet ylös. Tuolla tiedolla varustettu uudelleenkirjoitus on täysin erilainen, paljon turvallisempi eläin kuin se joka julkaistiin ensimmäisen päivän optimismilla.

Osa josta kukaan ei puhu: kyse on enimmäkseen ihmisistä

Tässä jotain mitä tekniset oppaat ohittavat. Vanhan ohjelmiston uudistamisen vaikein osa ei yleensä ole koodi — vaan ihmiset jotka ovat vuosia sopeutuneet siihen. He tuntevat sen oikut. Heillä on lihasmuisti sen oudoille oikoteille. Uusi moduuli joka on objektiivisesti parempi voi silti tuntua huonommalta ensimmäiset kaksi viikkoa, yksinkertaisesti koska se on vieras. Jos jätät tämän huomiotta, täydellinenkin tekninen migraatio voi epäonnistua.

Vaiheittainen lähestymistapa auttaa tässäkin, melkein vahingossa. Koska muutos saapuu yksi pieni pala kerrallaan, ihmiset imevät sen vähitellen sen sijaan että heitä pyydettäisiin opettelemaan kaikki uudelleen yhtenä maanantaiaamuna. Tuo päivittäiset käyttäjät mukaan aikaisin. Anna heidän muovata korvaajaa ennen kuin se on valmis. Tiimi joka auttoi suunnittelemaan uuden laskutusnäkymän puolustaa sitä; tiimi jolle se pudotettiin niskaan inhoaa sitä, vaikka se olisi identtinen. Uudistaminen on muutosjohtamisprojekti ohjelmistopuvussa.

Yleisiä kysymyksiä