Modernizace legacy systému bez velkého přepisu

Starší systém uchovává ceny, výjimky i pracovní postupy, které nikdo úplně nezapsal. Velký přepis musí toto chování znovu objevit, zatímco původní aplikace dál přijímá nové požadavky. Náhrada tak dohání pohyblivý cíl.

Postupná modernizace přebírá jeden vymezený obchodní tok a během přechodu nechává dostupnou původní cestu. Tento přístup popisuje Strangler Fig pattern. Menší zásahy omezují rozsah změny. Bezpečný návrat ale musí tým navrhnout zvlášť.

1. 01

   1. Změřte chování

   Toky, chyby, výkon a to, kdo vlastní data.

2. 02

   2. Vytvořte hranici

   Facade nebo adapter před starým systémem.

3. 03

   3. Migrujte jeden tok

   Začněte hodnotným, ale zvládnutelným řezem.

4. 04

   4. Porovnejte výsledky

   Kontrakty, paralelní běh a porovnání přes celý obchodní cyklus.

5. 05

   5. Odstraňte starou cestu

   Až po důkazu, monitoringu a zkoušce, jestli se dá vrátit zpět.

Zjistěte, na čem provoz skutečně závisí

Vedle dokumentace sledujte používané obrazovky, plánované úlohy, integrace a ruční opravy. Zdánlivě pomocný export může být souborem, který účetnictví potřebuje při každé uzávěrce.

U kritických toků zapište vstupy, správné výsledky, zdroj pravdy a závislosti. Každý tok potřebuje vlastníka. Zachyťte chování při výpadku dodavatele i ruční obchvat, který lidé používají. Ověřte také přístupy, licence a účty potřebné pro náhradu.

Začněte problémem s pozorovatelným dopadem, například opožděnou uzávěrkou, opakovanou opravou nebo nepodporovanou databází. Zjištěné chování převedete do regresních testů. Pokud starý systém počítá slevu nezvykle, ale smluvně správně, nový ji nesmí potichu změnit.

Zvolte zásah podle problému

Celý systém není nutné nahrazovat kvůli každému nedostatku.

Volby se mohou kombinovat. Přihlášení lze stabilizovat a objednávky nahrazovat po etapách. Dlouhý souběh nemusí být praktický ani tehdy, když regulace původní platformu vylučuje. Také úplný přepis však potřebuje popsané chování, migraci dat a plán obnovy.

Do celkových nákladů vlastnictví zahrňte podporu, licence, infrastrukturu, školení a paralelní provoz. Počítejte i čas interních lidí. Kalkulačka poskytne první rámec možného přínosu, nikoli slíbenou návratnost.

Najděte hranici pro převzetí toku

Hranicí může být API cesta, obrazovka nebo noční import. Fasáda před starou a novou implementací rozhodne, kam požadavek odešle. Vnější kontrakt zůstane stabilní a vnitřek se změní po etapách.

Pro pilot vyberte tok s jasným vlastníkem, pozorovatelným výsledkem a omezenými závislostmi. Ověříte na něm nasazení, monitoring i návrat. Nejtěžší modul nemusí být vhodným začátkem, přestože dnes působí největší potíže.

Překladová vrstva převede staré identifikátory a stavy do nového modelu. Určete podmínku jejího odstranění. Nové části mohou zůstat modulární, dokud provozní důkazy neodůvodní samostatnou službu.

Jeden údaj má jednoho vlastníka

Pokud oba systémy zapisují stejný údaj, mohou vytvořit rozdílné stavy. Pro každý migrovaný tok proto určete jeden systém záznamu. Druhá strana dostane kopii pro čtení, ale nerozhoduje o změně.

Přesun vlastnictví dat je samostatný krok. Ověřte mapování polí a kvalitu dat. Přenos musí jít opakovat a bezpečně obnovit po přerušení. Po přepnutí zastavte zápis ve starém systému nebo ho veďte přes nový kontrakt.

Dvojitý zápis z aplikace je křehký při částečném výpadku. Jedna potvrzená změna s opakovatelným doručením se kontroluje lépe. I tento mechanismus potřebuje dohled nad zpožděním a místo pro nezpracovatelné zprávy.

U osobních a finančních údajů určete oprávnění ke změně, záznam rozhodnutí a postup obnovy. Otázky k přístupům rozvádějí naše bezpečnostní zásady.

Výsledky porovnejte před přepnutím

U výpočtů mohou obě implementace zpracovat stejný vstup. Uživatel dostane původní výsledek a systém porovná výstupy. Rozdíly rozdělte na chyby, schválené změny pravidel a důsledky historických dat.

Platbu ani zákaznický email nespouštějte kvůli porovnání dvakrát. Použijte zaznamenané vstupy a izolovaný režim bez vedlejších účinků. Rozhraní pomohou ověřit kontraktové testy z produkčních příkladů.

Podmínky přijetí dohodněte před měřením. Potřebujete vzorová data, přípustné rozdíly, dobu odezvy a kontrolu ztracených událostí. Určete schvalovatele a postup při neshodě. Nová zjištění při převzetí mohou změnit rozsah. Způsob řešení změn popisují obchodní podmínky.

Cestu zpět připravte před vydáním

Přepínač vrátí požadavky na starou cestu pouze tehdy, pokud je původní systém stále umí zpracovat. Databázové změny proto musí během přechodu zachovat kompatibilitu.

Jestliže nová verze vytvořila záznamy, které stará neumí číst, samotné vypnutí funkce nestačí. Plán určuje dobu možného návratu, zacházení s novými daty a člověka oprávněného rozhodnout. Patří do něj nejhorší přijatelný dopad a způsob jeho odhalení.

Po přepnutí sledujte dohodnuté výsledky, zpoždění a ruční zásahy. Starou cestu vypněte až po uzavření období návratu a přijetí výsledků vlastníkem procesu. Jinak firma dál provozuje oba systémy.

1. 01

   Úplný přepis

   Dává smysl při malém rozsahu, známých pravidlech a krátkém souběhu.

2. 02

   Postupná výměna

   Chrání průběžné změny, nejasné chování a systém, na kterém firma závisí.

Před další etapou potvrďte odpovědnost

• Vedení potvrdí obchodní výsledek, rozpočtový strop a sponzora rozhodnutí.
• Vlastník procesu schválí chování, povolené výjimky a akceptační kritéria.
• Provoz určí vlastníka nasazení, plán návratu a odpovědnost při incidentu.
• Finance potvrdí náklady vlastnictví a hranici pro zastavení etapy.

Žádný audit nenajde všechna skrytá pravidla. První etapa má ověřit malý tok a ukázat, zda ubylo ručních oprav, zrychlila se obnova nebo šlo bezpečně vypnout část starého systému. Počet přepsaných řádků to nedokazuje.

Modernizace softwaru proto začíná vymezením toku a jeho vlastníků. Technologie se vybírá až po dohodě, co má etapa zachovat a podle čeho ji firma přijme.