Situace

Bezici legacy aplikace potrebuje plan modernizace, ne dalsi improvizaci

Typicka situace, kdy aplikaci uz tym zna a provozuje ji, ale dalsi rozvoj je pomaly, nejisty a zbytecne drahy.

Legacy aplikace neni problem jen proto, ze je starsi. Problem nastava tehdy, kdy ji tym sice provozuje, ale kazda dalsi zmena je pomala, draha a plna nejistoty.

Prakticka modernizace proto nezacina prevzetim ciziho kodu ani pranim cisteho startu, ale rozlisenim, co ma smysl stabilizovat, co oddelit, co prepsat a co zatim ponechat v provozu.

Typické projevy problému

Pokud legacy system zustane bez planu modernizace, firma plati vyssi cenu za kazdou dalsi zmenu, roste provozni riziko a tlak na velke rozhodnuti bez dostatecneho podkladu.

kazda zmena nese velkou nejistotu nebo regresni riziko
architektura a zavislosti jsou pro tym spatne citelne
technicky dluh blokuje dalsi roadmapu
system je dulezity pro provoz, ale chybi realisticky plan zlepsovani

Jak k tomu přistupuji

Zacinam mapovanim kritickych zavislosti, provoznich rizik, release slabin a mist, kde dava modernizace nejvetsi pomer dopadu k riziku. Teprve pak dava smysl rozhodovat mezi postupnou modernizaci a vetsim prepisem.

Co by měl být výsledek

Cílem není jen rychlá oprava. Smyslem je vrátit projektu kontrolu, jistotu a rozumný další krok.

realistictejsi plan modernizace bez velkych gest
mensi provozni riziko pri dalsich zmenach
lepsi orientace v architekture a prioritach
silnejsi zaklad pro dalsi rozvoj nebo selektivni rewrite

Pro koho je to vhodné

firmy s bezici legacy aplikaci, ktera porad drzi provoz
tymy, ktere chteji modernizovat bez ztraty kontroly
situace, kde je treba spojit takeover, stabilizaci a dalsi rozvoj

Kdy to vhodné není

projekty s predem narizenym rewrite bez analyzy
aplikace bez pristupu ke kodu nebo prostredi
ciste kosmeticke redesigny bez provozniho dopadu

FAQ

Je legacy aplikace automaticky kandidat na rewrite?

Ne. Dulezite je, jake konkretni provozni a delivery problemy zpusobuje, ne jen jeji stari nebo technologie.

Lze modernizovat jen nejkritictejsi casti?

Ano. U mnoha bezicich aplikaci je to bezpecnejsi a ekonomicky rozumnejsi nez velky restart.

Je to jen jiny nazev pro takeover aplikace?

Ne. Tato stranka miri hlavne na situace, kdy tym uz aplikaci provozuje nebo ji ma pod kontrolou, ale potrebuje rozumny plan modernizace bez velkeho restartu.

Další krok

Máte podobnou situaci?

Stačí krátce popsat současný stav, největší riziko a očekávaný další krok.

Nezávazně probrat zadání