Töötav vana süsteem on väärtus, mitte probleem. Probleem on see, et keegi ei julge seda enam puutuda. Katame selle testidega, tõstame välja kaupa haaval ja lülitame vana osa välja alles siis, kui uus on tõestanud, et töötab.
Pärandsüsteem on harva katki. Ta töötab — see ongi põhjus, miks teda ei puututa. Hind ei tule seisakust, vaid sellest, mis jääb tegemata: iga uus funktsioon on läbirääkimine koodiga, mida keegi enam täielikult ei mõista, iga liidestus nõuab eraldi erandit, ja iga inimene, kes süsteemi tundis, viib lahkudes osa teadmisest kaasa.
Moderniseerimine ei tähenda kõige ümber kirjutamist. See on rida otsuseid selle kohta, mis väärib säilitamist, mis väärib ümberehitamist ja mis tuleks lihtsalt välja lülitada. Enamik neist otsustest tehakse enne esimest koodirida — auditis, kus selgub, kus äriloogika päriselt istub ja mis seda hoiab töös.
Moderniseerimine käib kolmes osas: kõigepealt selgitame välja, millega on tegu, siis ehitame ümber selle, mis seda väärib, ja alles siis kolime. Ükski neist ei nõua, et süsteem vahepeal seisma jääks.
Alustame koodist, andmebaasist ja taristust. Kaardistame, kus äriloogika istub, millised osad on ärikriitilised, millised sõltuvused on toeta jäänud ja kus on turvaaugud. Tulemus on kirjalik ülevaade koos prioriteetidega — mitte hinnang tunnetuse põhjal.
Struktureerime rakenduse ümber nii, et tehniline võlg väheneb ja äriloogika säilib. Monoliit laguneb hallatavateks osadeks siis, kui see end ära tasub — mitte moe pärast. Enne iga muudatust kirjutame testid, mis fikseerivad praeguse käitumise.
Andmebaaside, operatsioonisüsteemide ja rakenduste kolimine tänastele platvormidele — AWS, Azure, Google Cloud või teie oma serverid EL-is. Migratsiooni harjutatakse toodanguandmete koopial, ja päris üleminek tehakse alles pärast puhtaid proove.
Vana süsteem, mis ei räägi ühegi tänase tööriistaga, on saareke. Ehitame ette API-kihi, mis teeb olemasoleva loogika kättesaadavaks, ilma et peaks selle all olevat kohe välja vahetama.
Vanades süsteemides on andmed tavaliselt olemas, aga kättesaamatud. Toome need välja kujul, mida saab päriselt kasutada — ilma et raporti koostamine nõuaks kellegi käsitsi tööd igal esmaspäeval.
Suurim risk vanas süsteemis ei ole kood, vaid see, et selle kohta pole midagi kirjas. Iga moderniseerimise etapp lõpeb dokumentatsiooniga, mis lubab järgmisel inimesel tööd jätkata ilma arheoloogiata.
Moderniseerimisel on sihtplatvorm alati kompromiss selle vahel, mis on uusim, ja selle vahel, mille jaoks te saate viie aasta pärast veel inimesi palgata. Valime teise.
Moderniseerimise põhjendus ei ole see, et süsteem on vana. Need neli on mõõdetavad enne ja pärast, ja need on ainsad, mille pärast tasub programmi alustada.
Vana süsteemi arve ei ole litsentsitasu. See on aeg, mis kulub selle töös hoidmisele.
Vana rakendus ei olnud ehitatud tänaste turvanõuete järgi, ja aastatega lisatud lapid on sageli ise uus rünnakupind.
Enamik võitu ei tule uutest funktsioonidest, vaid nende sammude kadumisest, mida keegi praegu käsitsi teeb.
Kõige kallim asi vanas süsteemis on see, mida te ei saa teha — ja mida konkurent saab.
Enamik ebaõnnestunud moderniseerimisi algas enne, kui keegi tervikpilti nägi. Küsige seepärast kõigepealt, mis juhtub enne arendust: kas tehakse audit, kas iga rakendus seotakse konkreetse äriliste tulemusega, ja kas te saate enne koodi kirjutamist etapiviisilise teekaardi koos põhjendusega, miks just selles järjekorras.
Küsige ka, kuidas vana ja uus vahepeal kõrvuti töötavad, sest just seal läheb enamik programme kalliks. Ja küsige, kellele kuuluvad repositooriumid, pilvekontod ja dokumentatsioon — moderniseerimine, mis vahetab ühe sõltuvuse teise vastu, ei ole moderniseerimine.
Me ei hinda vana süsteemi ümberehitust enne, kui oleme koodi näinud. Audit on eraldi tellitav ja selle tulem jääb teile ka siis, kui edasi lähete kellegi teisega.
Iseloomustavad testid fikseerivad praeguse käitumise — koos vigadega — enne kui midagi liigutatakse. Nii on hiljem selge, mis muutus tahtlikult.
Funktsioonid liiguvad ükshaaval ja vana süsteem töötab kõrval edasi. Iga samm on tagasi pööratav kuni viimase hetkeni.
Auditi teinud insener on sama, kes ümberehituse teeb. Üleandmist meeskondade vahel ei toimu, sest teadmine vanast süsteemist ei ole kirja pandav täies mahus.
Repositooriumid, pilv, domeenid. Moderniseerimise mõte on sõltuvusest vabaneda, mitte seda ümber tõsta.
Asume Tallinnas, samas ajavööndis ja samas lepinguraamistikus. Andmed jäävad soovi korral täielikult EL-i.
Ei, ja soovitame seda peaaegu mitte kunagi. Kasutame strangler-mustrit: uus süsteem võtab funktsioone üle ükshaaval, vana töötab kõrval edasi ja lülitatakse osade kaupa välja alles siis, kui asendus on toodangus tõestatud.
See on pigem reegel kui erand. Alustame koodi ja andmebaasi auditist ning kirjutame iseloomustavad testid, mis fikseerivad praeguse käitumise — ka vead. Nii on hiljem selge, mis on tahtlik ja mis mitte.
Migratsiooni harjutatakse toodanguandmete koopial nii mitu korda, kui vaja, ja iga käivitusel on kirjalik tagasipöördumisplaan. Päris üleminek tehakse alles siis, kui proov on läinud puhtalt läbi vähemalt kaks korda järjest.
Märgid tulevad tavaliselt korraga. Arendajad kulutavad suurema osa ajast olemasoleva töös hoidmisele, mitte uue ehitamisele. Iga liidestus tänase teenusega nõuab erilahendust. IT-kulu kasvab, aga väljund ei kasva koos sellega. Ja kogenud inimesed ei taha selle koodibaasiga töötada — mis muudab ka värbamise kalliks.
Tööstuses kasutatakse seitset: tõsta ümber (rehost), vaheta platvormi (replatform), kirjuta ümber (refactor), muuda arhitektuuri (rearchitect), asenda (replace), lülita välja (retire) ja jäta rahule (retain). Viimane on täiesti õige vastus sagedamini, kui tarnijad tunnistavad.
Valik tehakse iga rakenduse kohta eraldi, hinnates seda kuuel teljel: ärivajadusele vastavus, äriline väärtus, muudetavus, kulu, keerukus ja risk. Rakendused, mis saavad korraga mitmel teljel halva hinde, on selged kandidaadid. Päris programmis kombineeritakse peaaegu alati mitut lähenemist korraga.
See sõltub täielikult sellest, kui palju rakendusi on mängus ja kui sügavale minnakse. Lihtne ümbertõstmine uuele platvormile on nädalate küsimus. Ärikriitilise süsteemi arhitektuuri muutmine koos andmemigratsiooniga on kuude, suuremas majas aastate küsimus.
Seepärast me ei anna tähtaega enne auditit. Auditi tulem ongi etapiviisiline teekaart, kus igal etapil on oma maht ja oma äriline tulem — nii et te ei pea kogu programmi korraga heaks kiitma.
Korralikult üles ehitatud programmis ei häiri. Vana ja uus töötavad kogu tarne vältel kõrvuti ja funktsioonid liiguvad ükshaaval — eesmärk on järjepidevus, mitte ühekordne suur üleminek, mis kas õnnestub või mitte.
Praktiline kaitse selle riski vastu on põhjalik avastusfaas enne arendust: sõltuvused, andmeriskid ja liidestuspunktid peavad olema teada enne, kui midagi liigutatakse. Kui keegi pakub moderniseerimist ilma selle etapita, on see risk, mitte kokkuhoid.
Vana rakendus ei olnud ehitatud tänaste turvanõuete järgi, ja aastatega lisatud lapid ja möödaviigud on sageli ise uus rünnakupind, mitte selle sulgemine. Toeta jäänud versioonidele turvapaiku enam ei tule, mis tähendab, et teadaolev haavatavus jääb lihtsalt lahtiseks.
Rangema regulatsiooniga valdkondades — finants, tervishoid, kindlustus — lisandub sellele vastavusrisk: nõuded muutuvad, ja süsteem, mida ei saa muuta, ei saa ka nõuetega kaasa liikuda.
Kirjeldage oma olukorda paari lausega. Vastame ühe tööpäeva jooksul.