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

Starší systém môže byť technicky nepríjemný a pritom pre firmu nevyhnutný. Pozná ceny, výnimky aj procesy, ktoré nikto úplne nezapísal. Veľký prepis sľubuje čistý začiatok, no počas mesiacov vývoja sa pôvodný systém ďalej mení. Nová verzia potom naháňa pohyblivý cieľ.

Bezpečnejší prístup rozdelí modernizáciu na malé obchodné schopnosti. Nová časť preberie konkrétnu požiadavku, stará zostane dostupná a presmerovanie sa dá vrátiť. Používateľ nemusí čakať na deň, keď bude hotové všetko.

1. 01

   1. Zmerajte správanie

   Toky, chyby, výkon a vlastníctvo dát.

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 obchodný cyklus.

5. 05

   5. Odstráňte starú cestu

   Až po dôkaze, monitoringu a rollback skúške.

Najprv zistite, čo systém naozaj robí

Dokumentácia opisuje zámer. Prevádzka ukazuje skutočnosť. Pred zásahom preto sledujeme používané obrazovky, dávkové úlohy, integrácie, chybové stavy a ručné opravy. Dôležité sú aj exporty, ktoré sa tvária ako pomocné, no účtovníctvo na nich každý mesiac závisí.

Audit nemá vytvoriť encyklopédiu. Potrebuje mapu kritických tokov, vlastníkov dát a miest s najvyššou cenou zmeny. Ku každému toku patrí merateľné správanie. Koľko objednávok prejde, aký výsledok sa považuje za správny a čo sa stane pri výpadku dodávateľa.

Tento zoznam sa stane základom regresných testov. Chráni správanie, nie historickú štruktúru kódu. Ak pôvodná aplikácia počíta zľavu zvláštnym, ale zmluvne platným spôsobom, nový systém ju nesmie potichu opraviť bez obchodného rozhodnutia.

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

Vhodná hranica môže byť cesta v API, obrazovka, import súboru alebo udalosť. Pred starý a nový systém sa vloží fasáda, ktorá rozhodne, kam požiadavku poslať. Navonok zostane kontrakt stabilný, zatiaľ čo vnútro sa mení po častiach.

Prvý kandidát nemá byť najťažší modul len preto, že najviac prekáža. Lepší je tok s jasným vlastníkom, pozorovateľným výsledkom a obmedzeným počtom závislostí. Tím si na ňom overí nasadenie, monitoring aj návrat bez ohrozenia jadra firmy.

Hranica zároveň bráni tomu, aby nový kód kopíroval starý dátový model. Prekladová vrstva môže staré identifikátory a stavy previesť do jazyka novej domény. Táto vrstva má byť dočasná a jej odstránenie musí mať podmienku.

Jedna pravda pre každý údaj

Najväčšie riziko postupnej migrácie vzniká, keď oba systémy zapisujú ten istý údaj. Konflikt sa často ukáže až po týždni. Preto pre každý migrovaný tok určujeme systém záznamu. Druhá strana môže dostať kópiu na čítanie, ale nevlastní rozhodnutie.

Presun vlastníctva dát potrebuje vlastný krok. Najprv sa overí mapa polí a kvalita údajov. Potom sa údaje prenesú opakovateľným procesom, ktorý vie bezpečne pokračovať. Po prepnutí sa zápis na starej strane zastaví alebo presmeruje cez nový kontrakt.

Dvojitý zápis z aplikácie je lákavá skratka, no čiastočný výpadok zanechá rozdielne stavy. Spoľahlivejšia je jedna potvrdená zmena a mechanizmus, ktorý ju doručí druhej strane opakovateľne. Aj ten potrebuje kontrolu oneskorenia a miesto pre neúspešné správy.

Paralelná prevádzka dáva dôkaz pred prepnutím

Pri výpočtoch môžu stará a nová implementácia chvíľu spracovať rovnaký vstup. Používateľ stále dostane výsledok z pôvodnej verzie, zatiaľ čo systém porovná výstupy. Rozdiely sa triedia na chyby, vedomé zmeny pravidiel a rozdiely spôsobené nekvalitnými historickými dátami.

Nie každý tok sa dá spustiť dvakrát. Platbu alebo odoslanie emailu nesmieme zopakovať len kvôli porovnaniu. Vtedy použijeme zaznamenané vstupy, izolovaný režim bez vedľajších účinkov alebo kontraktové testy voči produkčným príkladom.

Prepnutie potrebuje vopred dohodnutú podmienku. Môže to byť počet spracovaných prípadov bez nevysvetleného rozdielu, čas odozvy a nulová strata udalostí. Nejasné konštatovanie, že nová časť vyzerá dobre, nie je prevádzkový dôkaz.

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

Každá etapa má mať malý dosah zlyhania. Prepínač toku umožní vrátiť požiadavky na starú cestu. Databázová zmena musí byť kompatibilná počas prechodu a starý konzument nemá prestať fungovať po prvom nasadení novej schémy.

Návrat nie je vždy jednoduché vypnutie funkcie. Ak nový systém už vlastní nové záznamy, starý ich nemusí vedieť čítať. Plán preto určuje, dokedy je návrat možný, čo sa stane s údajmi vytvorenými po prepnutí a kto má právo rozhodnúť.

Po úspešnej etape treba starú cestu odstrániť. Inak firma začne platiť za dva systémy navždy. Podmienky odstránenia môžu byť ukončené obdobie návratu, uzavreté finančné porovnanie a potvrdenie vlastníka procesu.

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í.

Kedy môže byť úplný prepis správny

Postupná modernizácia nie je dogma. Veľký prepis môže dávať zmysel pri malom systéme s krátkou životnosťou dát, stabilným rozsahom a možnosťou zastaviť zmeny počas prechodu. Podobne pri regulácii, ktorá starú platformu úplne vylučuje, nemusí dlhé spolunažívanie stáť za cenu.

Aj vtedy treba spísať existujúce správanie, migráciu dát a návrat. Čistý repozitár neodstraňuje obchodné riziko. Iba mení spôsob, akým sa k nemu dostaneme.

Pri väčšom živom produkte býva rozumnejšie doručovať modernizáciu po schopnostiach. Firma získava výsledok priebežne a rozhodnutia sa opierajú o produkčné údaje. Verejná prípadová štúdia projektu Slates ukazuje dôraz na obnovu a testovanie staršej platformy. Netvrdí však, že každý systém používa rovnaký migračný vzor.

Modernizácia je riadenie zmeny

Technický plán má byť spojený s obchodným výsledkom. Jedna etapa môže skrátiť spracovanie dokumentu, odstrániť nepodporovanú databázu alebo znížiť počet ručných opráv. Tak sa dá rozhodnúť, či pokračovať rovnakým smerom.

Architektúra nových častí môže zostať modulárna a neskôr oddeliť službu, keď na to vzniknú dôkazy. Rozhodovací rámec pre modulárny monolit a mikroslužby má vychádzať z prevádzkových potrieb. Samotnú realizáciu vieme prevziať cez službu modernizácie softvéru.

Úspech nie je moment, keď sa prepíše posledný riadok. Je to stav, v ktorom firma vie bezpečne meniť dôležité procesy, prevádzka rozumie zlyhaniam a staré riziko sa každý mesiac zmenšuje.

Pokrok preto nemeriame počtom nových riadkov. Lepší obraz dávajú migrované obchodné toky, menej ručných zásahov, kratšie obnovenie po chybe a časti starého systému, ktoré sa podarilo bezpečne vypnúť.

Rýchla odpoveď

Nezačínajte otázkou, či je starý kód pekný. Začnite tým, ktorý obchodný tok dnes stojí peniaze, dôveru alebo schopnosť meniť pravidlá. Stabilizácia je správna, keď potrebujete najprv zastaviť incidenty. Refaktoring dáva zmysel pri lokálnom probléme s overeným správaním. Postupná náhrada je vhodná, keď systém žije a jeho pravidlá treba spoznávať počas práce. SaaS môže prevziať štandardný proces. Úplný prepis patrí skôr k malému a uzavretému rozsahu.

Rozhodovacia matica pre modernizáciu

Rozhodnutie môže kombinovať viac možností. Firma môže stabilizovať prihlasovanie, refaktorovať výpočet ceny a postupne nahrádzať objednávky. Modernizácia softvéru má preto začať hranicami rozhodnutia, nie zoznamom technológií.

Obchodné a technické spúšťače

Obchodný signál je opakovaná ručná oprava, stratený predaj pri výpadku, oneskorené uzávierky alebo neschopnosť zaviesť nové pravidlo. Technický signál je nepodporovaná databáza, neznámy vlastník integrácie, slabé zálohy alebo zmena, ktorej sa tím bojí nasadiť. Zozbierajte oba druhy dôkazov. Jeden bez druhého vedie buď k drahej technickej čistote, alebo k rýchlemu riešeniu, ktoré sa nedá prevádzkovať.

Audit závislostí a dát

Pri každom toku si zapíšte vstup, výstup, vlastníka, zdroj pravdy, časovú závislosť a ručný obchvat. Overte prístupy k dodávateľom, licencie, dávky, exporty a účty používateľov. Pri osobných alebo finančných údajoch si určite, kto smie údaje meniť, ako sa zaznamená rozhodnutie a ako sa obnoví stav po chybe. Bezpečnostné zásady pomôžu nastaviť otázky k prístupom a zodpovednosti.

Náklady vlastníctva a riziko migrácie

Celkové náklady vlastníctva nie sú iba cena vývoja. Patria sem prevádzkové zásahy, podpora, licencie, infraštruktúra, školenie, paralelný beh a čas vedenia pri riešení sporov. Pri migrácii stanovte najhorší prijateľný dopad, napríklad oneskorenú objednávku alebo dočasne nedostupný report. Potom určite, čo ho zistí skôr, než zasiahne zákazníka. Kalkulačka dá prvý rámec pre prínos, nie sľub návratnosti.

Kontrakty a akceptačné kritériá

Pred vývojom sa pýtajte, aké výstupy musí nový tok zachovať, ktoré staré výnimky sú vedomé pravidlá a kto potvrdí zmenu. Akceptačné kritériá majú obsahovať ukážkové dáta, meranie chýb, vlastníka schválenia a postup pri rozdiele. Ak dodávateľ preberá starý systém, rozsah zistený počas auditu sa môže zmeniť. Obchodné podmienky popisujú, ako sa nové zistenia riešia transparentne.

Etapový plán a plán návratu

Prvá etapa nech doručí malý tok s jasným výsledkom. Pred nasadením si tím pripraví kontraktové testy, monitoring, prepínač smerovania a vlastníka rozhodnutia. Po prepnutí sleduje dohodnuté obdobie výstupy, oneskorenia a ručné zásahy. Plán návratu uvádza hranicu, dokedy sa dá vrátiť, čo sa stane s novými dátami a kto návrat schváli. Starý tok sa vypne až po splnení týchto podmienok.

Súhlas vo firme

Pred ďalšou etapou si potvrďte štyri vlastnícke rozhodnutia:

• Vedenie potvrdí očakávaný obchodný výsledok, rozpočtový strop a sponzora rozhodnutia.
• Vlastník procesu potvrdí dnešné správanie, povolené výnimky a akceptačné kritériá.
• Prevádzka potvrdí vlastníka nasadenia, plán návratu a zodpovednosť počas incidentu.
• Financie potvrdia predpoklady celkových nákladov vlastníctva a hranicu, pri ktorej sa etapa zastaví.

Tento zoznam nie je formalita. Odhalí spor o pravidlá skôr, než sa zmení produkčný systém.

Limity a ďalší krok

Žiadny audit neodhalí všetky skryté pravidlá. Paralelný beh nie je bezpečný pri platbách ani pri správach zákazníkom a SaaS nenahradí proces, ktorý tvorí Vašu odlišnosť. Preto začnite jedným tokovým auditom, rozhodovacou maticou a vlastníkmi. Ďalšie postupy nájdete v blogu Rise, kde priebežne dopĺňame praktické rozhodnutia pre firmy.