Modernizácia legacy systému bez veľkého prepisu

Starší systém drží ceny, výnimky aj pracovné postupy, ktoré nikto úplne nezapísal. Veľký prepis sľubuje čistý začiatok, no počas vývoja sa pôvodná aplikácia ďalej mení. Náhrada musí dobiehať nové požiadavky aj správanie, ktoré tím objaví až za pochodu.

Postupná modernizácia preberá jeden obchodný tok po druhom. Nová časť obslúži vymedzenú požiadavku a stará cesta zostane dostupná počas dohodnutého prechodu. Takto funguje Strangler Fig pattern. Zmenšuje rozsah jednotlivého zásahu, ale bezpečný návrat treba navrhnúť osobitne.

1. 01

   1. Zmerajte správanie

   Toky, chyby, výkon a to, kto vlastní dáta.

2. 02

   2. Vytvorte hranicu

   Facade alebo adapter pred starým systémom.

3. 03

   3. Migrujte jeden tok

   Začnite hodnotným, ale zvládnuteľným rezom.

4. 04

   4. Porovnajte výsledky

   Kontrakty, paralelný beh a porovnanie cez celý obchodný cyklus.

5. 05

   5. Odstráňte starú cestu

   Až po dôkaze, monitoringu a skúške, či sa dá vrátiť späť.

Najprv zistite, čo systém naozaj robí

Dokumentácia opisuje zámer. Pred zmenou preto sledujte aj používané obrazovky, dávkové úlohy, integrácie a ručné opravy. Pomocný export môže byť súbor, na ktorom účtovníctvo každý mesiac závisí.

Audit potrebuje mapu kritických tokov a ich vlastníkov. Pri každom toku zapíšte vstup, správny výsledok, zdroj pravdy a závislosti. Zachyťte aj ručný obchvat a správanie pri výpadku dodávateľa. Overte prístupy k systémom, licencie a účty, ktoré bude nová časť potrebovať.

Začnite problémom, ktorý má pozorovateľný dopad. Môže ísť o oneskorenú uzávierku, opakovanú ručnú opravu alebo nepodporovanú databázu. Zistené správanie sa stane základom regresných testov. Ak stará aplikácia počíta zľavu zvláštne, ale zmluvne správne, nová ju nesmie potichu zmeniť.

Vyberte spôsob zmeny podľa problému

Nie každý problém potrebuje náhradu systému.

Možnosti sa dajú kombinovať. Firma môže stabilizovať prihlasovanie a objednávky nahrádzať postupne. Pri úplnom prepise stále potrebuje spísané správanie, migráciu dát aj návratový plán. Zmysel môže dávať aj vtedy, keď regulácia starú platformu vylučuje a dlhý súbeh by bol nepraktický.

Do rozpočtu zahrňte podporu, licencie, infraštruktúru aj školenie a paralelnú prevádzku. Pripočítajte čas interných ľudí. Kalkulačka dá prvý rámec pre prínos, nie sľub návratnosti.

Nájdite hranicu, cez ktorú sa dá prevziať tok

Hranicou môže byť API cesta, obrazovka alebo nočný import. Fasáda pred starou a novou implementáciou rozhodne, kam požiadavku pošle. Navonok zachová stabilný kontrakt, zatiaľ čo vnútro sa mení po častiach.

Na prvú etapu vyberte tok s jasným vlastníkom a pozorovateľným výsledkom, ktorý má málo závislostí. Tím si na ňom overí nasadenie, monitoring aj návrat na pôvodnú verziu. Najťažší modul na to nemusí byť vhodný, hoci dnes prekáža najviac.

Prekladová vrstva prevedie staré identifikátory a stavy do nového modelu. Nemá sa stať trvalou súčasťou bez rozhodnutia. Zapíšte podmienku jej odstránenia a nechajte nové časti modulárne, kým prevádzkové dôkazy neodôvodnia samostatnú službu.

Každý údaj potrebuje jedného vlastníka

Ak oba systémy zapisujú rovnaký údaj, môžu vytvoriť rozdielne stavy. Pre každý migrovaný tok preto určte systém záznamu. Druhá strana môže dostať kópiu na čítanie, ale nerozhoduje o zmene.

Presun vlastníctva dát má vlastný krok. Najprv overte mapovanie polí a kvalitu údajov. Prenos musí byť opakovateľný a vedieť bezpečne pokračovať po prerušení. Po prepnutí zastavte zápis na starej strane alebo ho presmerujte cez nový kontrakt.

Dvojitý zápis z aplikácie je krehký pri čiastočnom výpadku. Lepšie sa kontroluje jedna potvrdená zmena s opakovateľným doručením druhej strane. Aj tento mechanizmus potrebuje dohľad nad oneskorením a miesto pre neúspešné správy.

Pri osobných a finančných údajoch určte, kto smie záznam zmeniť, ako sa rozhodnutie uloží a ako sa obnoví stav po chybe. Otázky k prístupom dopĺňajú naše bezpečnostné zásady.

Porovnajte výsledky pred prepnutím

Pri výpočtoch môžu stará a nová implementácia spracovať rovnaký vstup. Používateľ dostane pôvodný výsledok a systém porovná výstupy. Rozdiely roztrieďte na chyby, schválené zmeny pravidiel a dôsledky historických dát.

Platbu ani zákaznícky email nespúšťajte dvakrát kvôli porovnaniu. Použite zaznamenané vstupy a izolovaný režim bez vedľajších účinkov. Kontraktové testy z produkčných príkladov pomôžu overiť rozhrania.

Podmienky prijatia dohodnite pred meraním. Určte vzorové dáta, prípustné rozdiely, odozvu a spôsob kontroly stratených udalostí. Musí byť jasné, kto výsledok schváli a čo sa stane pri nezhode. Nové zistenia pri prevzatí systému môžu zmeniť rozsah. Postup riešenia zmien opisujú obchodné podmienky.

Návrat patrí k návrhu, nie k incidentu

Prepínač môže vrátiť požiadavky na starú cestu, iba ak s nimi pôvodný systém stále vie pracovať. Databázové zmeny preto musia počas prechodu zachovať kompatibilitu.

Ak nová verzia už vytvorila záznamy, ktoré stará nevie čítať, vypnutie funkcie nestačí. Plán musí určiť, dokedy je návrat možný, čo sa stane s novými údajmi a kto o návrate rozhodne. Súčasťou je aj najhorší prijateľný dopad a spôsob, ako ho tím zistí.

Po prepnutí sledujte dohodnuté výsledky, oneskorenia a ručné zásahy. Starú cestu odstráňte až po skončení obdobia návratu a po odsúhlasení výsledkov vlastníkom procesu. Inak zostávajú v prevádzke dva systémy.

1. 01

   Úplný prepis

   Dáva zmysel pri malom rozsahu, dobre známych pravidlách a krátkom súbehu.

2. 02

   Postupná výmena

   Chráni priebežné zmeny, nejasné správanie a systém, od ktorého firma závisí.

Pred ďalšou etapou potvrďte zodpovednosť

• Vedenie potvrdí obchodný výsledok, rozpočtový strop a sponzora rozhodnutia.
• Vlastník procesu schváli správanie, povolené výnimky a akceptačné kritériá.
• Prevádzka určí vlastníka nasadenia, návratový plán a človeka zodpovedného pri incidente.
• Financie potvrdia náklady vlastníctva a hranicu pre zastavenie etapy.

Žiadny audit neodhalí všetky skryté pravidlá. Prvá etapa má preto overiť malý tok a ukázať, či sa znížil počet ručných opráv, skrátila obnova alebo sa dala bezpečne vypnúť časť starého systému. Počet prepísaných riadkov taký dôkaz nedáva.

Modernizáciu softvéru začíname vymedzením toku a jeho vlastníkov. Výber technológie nasleduje až po dohode, čo má etapa zachovať a podľa čoho ju firma prijme.