Technický dluh v praxi: Je čas na retrofit, nebo na vývoj na zelené louce?

Mnoho firem používá interní systémy, které vznikly před deseti lety a dodnes tak nějak fungují. Vedení je často vnímá jako dobré systémy, navíc už jsou dávno zaplacené a zaměstnanci jsou na ně zvyklí. Realita uvnitř je ale většinou trochu jiná. Z původně jednoduchého nástroje se postupným nabalováním funkcí stal nepřehledný bastl kódu, do kterého se vývojáři bojí sáhnout, aby nerozbili něco na druhé straně. Tomuto stavu se říká technický dluh a dříve či později si vybere svou daň.

TL;DR

• Zdánlivě levný provoz je past. Starý systém spolkne většinu IT rozpočtu na neustálé opravy chyb místo toho, aby firmě přinášel inovace.

• Mrtvé technologie nelepte. Refaktoring dává smysl jen u zdravého jádra. Pokud jsou základy prohnilé, vyjde vývoj od nuly levněji.

• Nejdražší jsou skryté náklady. Účet za legacy systémy nedělají servery, ale ušlý byznys, nulová flexibilita a frustrovaní vývojáři na odchodu.

‍

Jak spolehlivě poznáte, že starý software vaši firmu vyloženě brzdí? Prvním varovným signálem je pomalé nasazování novinek. To, co by u moderní aplikace zabralo dny, zde trvá týdny. Dalším neduhem je neschopnost napojit systém na nové nástroje, typicky chybějící API pro moderní cloudové služby nebo AI funkce. Pokud navíc vaši vývojáři tráví většinu času lepením kritických chyb místo tvorby reálné byznysové hodnoty, systém už dávno nevydělává, ale naopak peníze pálí.

V takové chvíli stojíte před rozhodnutím, jestli aplikaci postupně opravovat, nebo ji vyhodit a napsat úplně znovu. Refaktoring dává smysl v situaci, kdy je jádro systému zdravé, použitá technologie má stále aktivní podporu a potřebujete jen vyčistit nepřehledný kód. Je to jako citlivá rekonstrukce starého domu. Pokud je ale aplikace postavená na prehistorických technologiích a její architektonické základy jsou chatrné, pouhé nahození nové omítky už nepomůže. V tu chvíli dává ekonomický smysl vývoj na zelené louce.

Největším problémem zastaralého softwaru jsou totiž jeho skryté náklady. Nejde jen o faktury za provoz serverů a práci programátorů (i když to možná bude na první pohled nejvyšší položka). Cenou je ale i ušlý zisk z obchodních příležitostí, které kvůli nepružnému systému nedokážete včas využít. K tomu připočítejte každodenní frustraci zaměstnanců, kteří musí klikat a kopírovat sem a tam.

Správné načasování velkého přepisu je klíčové pro konkurenceschopnost celé firmy. Nečekejte na moment, kdy starý systém definitivně zkolabuje a zastaví vám výrobu nebo expedici. Udělejte si upřímný audit současného stavu, spočítejte si reálné kvartální/roční náklady na údržbu a porovnejte je s investicí do nového řešení. Často totiž zjistíte, že vývoj nové aplikace může stát podobné peníze jako lepení současného systému. A návratnost nového projektu může být kratší, než odhadujete. Důkazem toho může být firma Petainer, kde jsme konsolidovali tři systémy do jednoho a investice se jim vrátila za 16,3 měsíce.