Legacy-süsteemi moderniseerimine: ümber kirjutada, asendada või järk-järgult parandada?_

Legacy-süsteem ei ole lihtsalt vana süsteem. Sellest saab äriprobleem siis, kui see takistab vajalikke muudatusi, loob vastuvõetamatu tegevusriski või maksab ülal pidada rohkem kui selle toetatav väärtus.

Keeruline küsimus ei ole, kas süsteemi moderniseerida, vaid kuidas. Levinumad valikud on täielik ümberkirjutus, asendamine olemasoleva tootega või järkjärguline parandamine ja asendamine.

Kõik kolm võivad olla õiged. Kõik kolm võivad valel põhjusel valides ka tõsiselt ebaõnnestuda.

Alustage ärilisest piirangust

Tehnilised meeskonnad kirjeldavad legacy-probleeme sageli tehnoloogia keeles: aegunud raamistikud, toetuseta andmebaasid, monoliidid või puuduvad testid. Need võivad olla päris riskid, kuid moderniseerimisotsus vajab ärilist sõnastust.

Näited:

• uue toote turuletoomine võtab kuid, sest iga muudatus puudutab tuumsüsteemi;
• kriitiline protsess sõltub ühest pensionile jäänud või ülekoormatud spetsialistist;
• katkestused loovad olulise tulu- või vastavusriski;
• süsteem ei toeta uut turgu või tegevusmudelit;
• taristu- ja litsentsikulu kasvab ilma võimekust parandamata;
• turvanõudeid ei saa enam ohutult täita;
• süsteemi ümber tehtavast käsitööst on saanud teine varjatud toode.

Iga ülaltoodud väide annab äriliselt mõõdetava põhjuse edasi otsustamiseks.

Valik 1: täielik ümberkirjutus

Ümberkirjutus asendab praeguse süsteemi uue arendusega, püüdes tavaliselt säilitada või parandada olemasolevat ärivõimekust.

Ümberkirjutus tundub atraktiivne, sest lubab puhast algust. See võib olla põhjendatud, kui:

• olemasolev arhitektuur ei toeta vajalikku tegevusmudelit;
• suurem osa tehnoloogiast on toetuseta või ebaturvaline;
• ärireeglid on piisavalt hästi mõistetud ja stabiilsed;
• organisatsioon suudab rahastada paralleelset käitamist ja migratsiooni;
• uut süsteemi saab tarnida kasulike osadena, mitte ühe lõpliku ümberlülitusena.

Peamine oht on varjatud käitumise alahindamine. Legacy-süsteemid sisaldavad aastate jooksul kogunenud erandeid, ajutisi lahendusi ja vaikimisi reegleid, mida kasutajad ei pruugi enam osata kirjeldada. Dokumentatsiooni järgi uuesti ehitav meeskond avastab need sageli alles siis, kui toodangukäitumine erineb oodatust.

"Suure paugu" ümberkirjutus lükkab ka päris tagasiside saamise edasi. Vana süsteem muutub edasi, samal ajal kui uus püüab sellele järele jõuda, ning siht liigub pidevalt eest ära.

Valik 2: asendamine olemasoleva tootega

Valmistoote ostmine võib olla tõhus, kui protsess ei ole strateegiliselt unikaalne ja organisatsioon on valmis kohanema standardse tööviisiga.

Asendamine on atraktiivne, kui:

• vajalik võimekus on levinud ja küps;
• tarnija pakub usutavat pikaajalist tuge;
• seadistamine katab olulisemad vajadused;
• integratsioonid ja andmemigratsioon on hallatavad;
• organisatsioon on valmis protsesse muutma;
• ärimudel jääb vastuvõetavaks ka tulevase mahu juures.

Viga on võrrelda ainult litsentsikulu ja arenduskulu. Asendamise kogukulu sisaldab protsessimuutust, seadistamist, integratsioone, migratsiooni, koolitust, andmete puhastamist, tarnijasõltuvust ja tulevast kohandamist.

Toode, mis katab 80% nõuetest, võib olla parim valik, kui ülejäänud 20% saab muuta äriprotsessis. See võib olla halvim valik, kui just see 20% on ettevõtte konkurentsieelis. Tihti saab sellistest piirangutest teada alles juurutusfaasis või selle lõpus.

Valik 3: järkjärguline parandamine ja asendamine

Järkjärguline moderniseerimine muudab süsteemi kontrollitud sammudena. Meeskond võib isoleerida ühe funktsionaalsuse, lisada testid, parandada jälgitavust, asendada komponendi või viia protsess uue liidese taha.

See sobib sageli, kui:

• praegune süsteem loob endiselt märkimisväärset väärtust;
• katkestusteta toimimine on kriitiline;
• ärireeglid ei ole täielikult mõistetud;
• enne suurt asendamist tuleb riski vähendada;
• ettevõte vajab kasu varem, kui terviksüsteem suudab tarnida;
• eri valdkondadel on erinev kiireloomulisus.

Järkjärguline töö annab varem tõendeid ja hajutab migratsiooniriski. Samas nõuab see tugevat arhitektuurilist distsipliini. Ilma fookust hoidmata võib kohalike paranduste jada säilitada vana arhitektuuri lõputult.

Kasutage otsustusmaatriksit, mitte tehnoloogiaeelistust

Hinnake valikuid mitme mõõtme järgi.

Äriline eristumine

Kas protsess annab konkurentsieelise või peaks ettevõte kasutama standardset tööviisi?

Tegevuse järjepidevus

Kas organisatsioon talub pikka paralleelset arendusprojekti või suure riskiga ümberlülitust?

Valdkonnateadmine

Kas praegused reeglid on dokumenteeritud ja mõistetud või peituvad need koodis ja kasutajaharjumustes?

Muutussurve

Kui kiiresti peab äri toetama uusi tooteid, turge, mahtusid või regulatsioone?

Andmed ja integratsioonid

Kui keeruline on ajalooliste andmete migratsioon ja sõltuvate süsteemide koordineerimine?

Organisatsiooni võimekus

Kas ärieksperdid, süsteemiadministraatorid ja tehniline meeskond saavad üleminekut toetada igapäevatöö kõrvalt?

Väljumine ja pööratavus

Kas eelduste valeks osutumisel saab suunda muuta?

Üks valik ei anna lõplikku vastust, kuid maatriks teeb kompromissid nähtavamaks.

Moderniseerige ärivõimekuste kaupa

Suured legacy-süsteemid muutuvad hallatavamaks, kui need korraldada ärivõimekuste, mitte tehnoloogiakihtide järgi. "Andmebaasi vahetamise" või "mikroteenustele liikumise" asemel määratlege kasulik funktsionaalsus, näiteks kliendi liitumine, hinnastamine, aruandlus või tellimuse täitmine.

Võimekusepõhine osa võib sisaldada kõike väärtuse loomiseks vajalikku: andmeid, kasutajaliidest, integratsioone, reegleid, käitamist ja migratsiooni. See vähendab riski, et valmib moodne tehniline kiht, mis sõltub iga päris tulemuse jaoks endiselt vanast süsteemist.

Kaitske teadmisi ülemineku ajal

Legacy moderniseerimine on ka teadmiste moderniseerimine. Süsteem peab talletama:

• miks olulised reeglid eksisteerivad;
• millised erandid on endiselt vajalikud;
• kes kasutab mitteametlikke töövõtteid;
• milliste eeldustega töötavad välised süsteemid;
• millised tegevuskontrollid ennetavad vigu;
• milliseid andmekvaliteedi probleeme varjab käsitöö.

Valdkonnaekspertide ja inseneride ühine töö, päris stsenaariumide testimine ja kasutajate vaatlemine paljastavad sageli rohkem kui vana dokumentatsioon.

Ärge looge legacy-süsteemi uuesti uues tehnoloogias

Levinud ebaõnnestumine on iga olemasoleva käitumise kopeerimine uude süsteemi ilma küsimata, kas seda endiselt vajatakse. Tulemuseks on sama keerukuse moodsam teostus.

Eristage iga funktsionaalsuse puhul:

• seaduse või lepinguga nõutud käitumine;
• äriväärtust loov käitumine;
• ainult vana süsteemi tõttu vajalik käitumine;
• käitumine, mida keegi ei oska põhjendada;
• tulevikuvõimekus, mida ei tuleks esimesse reliisi suruda.

Moderniseerimine peab juhuslikku keerukust eemaldama, mitte seda automaatselt säilitama.

Määratlege edu ärilistes terminites

Edukat projekti ei mõõdeta ümber kirjutatud koodi hulgaga. Paremad mõõdikud on:

• lühem ärimuudatuse läbimisaeg;
• vähem kriitilisi intsidente;
• väiksem sõltuvus üksikutest spetsialistidest;
• kiirem sisseelamine;
• vähem käsitööd;
• võime siseneda uuele turule;
• lihtsam vastavuse tõendamine;
• prognoositav taristu- ja litsentsikulu;
• konkreetsete kõrge riskiga komponentide pensionile saatmine.

Õige strateegia võib kombineerida kõiki kolme valikut: osta standardne võimekus, kirjutada ümber eristav osa ja parandada ülejäänud süsteemi järk-järgult. Eesmärk ei ole moekas arhitektuur. Eesmärk on äriliste piirangute ja tegevusriski kontrollitud vähendamine.