Co technický dluh vlastně znamená
Technický dluh je zjednodušeně řečeno „splátka za rychlé řešení“. Vzniká tehdy, když vývojáři, firmy nebo státní instituce záměrně zvolí rychlejší, levnější a méně čistý postup, aby systém fungoval hned teď. Jenže stejně jako u finančního dluhu se i tady později platí úroky: složitější údržbou, vyšší chybovostí, pomalejším vývojem a větším rizikem výpadků.
V bankách a úřadech je tenhle problém obzvlášť citlivý, protože jejich systémy zpracovávají obrovské množství transakcí a dat. Když je software napsaný nesourodě, bez dokumentace nebo na staré platformě, každá změna je drahá a riziková. Někdy stačí drobná úprava a rozbije se část systému, která se na první pohled změnit neměla.
Proč staré systémy přežívají desítky let
Velká část bank a veřejné správy stále běží na systémech, které vznikly v době, kdy internet nebyl běžnou součástí života. Důvod je prostý: fungují a jsou hluboko provázané s dalšími aplikacemi. Přepsat core banking systém nebo centrální registry znamená riskovat rozsáhlý výpadek, který by mohl ochromit výplaty, platby i interní procesy.
Podle odhadů společnosti IBM a dalších technologických firem běží významná část kritických podnikových systémů stále na mainframech, zejména v bankovnictví a pojišťovnictví. Mainframy nejsou samy o sobě problémem – problém je, když na nich leží software psaný v jazycích a architekturách, které znají už jen jednotky specialistů. V praxi se pak stává, že organizace nemá dost lidí, kteří by kód bezpečně upravili, nebo se bojí do něj vůbec sáhnout.
V českém prostředí tento problém připomněly například potíže některých státních agend při velkých změnách systémů, ale i opakované výpadky bankovních služeb, kdy se ukázalo, jak citlivá je infrastruktura na chyby v propojení starých a nových komponent. Nejde přitom jen o techniku. Každý zásah do starého systému znamená také testování, audit, bezpečnostní prověrky a často i schvalování regulátorem.
Jak technický dluh vzniká v každodenním provozu
Technický dluh většinou nevznikne jedním velkým rozhodnutím, ale desítkami malých kompromisů. Tým má dodat novou funkci do konce čtvrtletí, a tak místo kompletního přepracování jen „nalepí“ další vrstvu kódu. Jindy se kvůli rozpočtu odloží modernizace databáze, přepis rozhraní nebo úklid neudržovaných skriptů. Každý takový odklad je sám o sobě levný. Dohromady ale vytváří systém, který je křehký a pomalý.
Mezi nejčastější zdroje technického dluhu patří:
- nepřehledný nebo nedokumentovaný kód,
- ruční zásahy do procesů, které měly být automatizované,
- zastaralé programovací jazyky a knihovny,
- duplicitní databáze a systémy bez jednotných pravidel,
- odkládané bezpečnostní záplaty a aktualizace.
Ve veřejné správě se navíc přidává další vrstva: systémy vznikaly v různých obdobích, často od různých dodavatelů, kteří používali odlišné standardy. Výsledkem jsou informační „ostrovy“, které spolu komunikují jen přes složité mosty. Pokud se jeden z nich porouchá, problém se rychle přenese dál.
Jak špatně napsaný kód paralyzuje banky
Banky pracují s režimem, v němž je přesnost důležitější než rychlost. Jedna chyba v převodu může znamenat duplicitní platbu, zablokovaný účet nebo nesprávně spočtený úrok. Když je systém postavený na starém kódu, je každá změna násobně složitější. Nová mobilní aplikace sice může vypadat moderně, ale pod ní často běží desítky let starý backend, který drží celý provoz pohromadě.
Typickým problémem je kompatibilita. Nové aplikace chtějí pracovat s API, datovými formáty a bezpečnostními standardy, které starý systém nezná. Vývojáři pak vytvářejí mezivrstvy, převodníky a dočasná řešení. Ta sice umožní provoz, ale přidají další místo, kde může vzniknout chyba. V bankovnictví se navíc vše testuje v produkčním rozsahu velmi těžko, protože simulovat miliony transakcí denně je náročné a drahé.
Časté jsou také incidenty způsobené nečekaným chováním zastaralých komponent. V roce 2021 například výpadek americké banky TSB po migraci na nový systém vedl k tomu, že část klientů neměla přístup ke svým účtům a banka čelila i sankcím regulátora. Podobné případy ukazují, že problém nebývá jen v jedné chybné řádce, ale v celém řetězci závislostí, které už nikdo přesně nemá pod kontrolou.
Úřady a registry: když chyba zastaví stát
Ve státní správě má technický dluh jiný, ale stejně závažný dopad. Když selže systém dávek, registr vozidel, daňová aplikace nebo komunikační platforma mezi úřady, problém necítí jen IT oddělení. Dotkne se to občanů, firem i samotných úředníků, kteří nemohou vyřídit agendu v zákonných lhůtách.
Česká veřejná správa dlouhodobě upozorňuje na to, že velká část informačních systémů byla budována po etapách a bez jednotné architektury. Největší slabinou bývá závislost na konkrétním dodavateli a na historickém know-how několika lidí. Jakmile odejdou, nastává problém s údržbou i dalším rozvojem. U některých agend se navíc ukazuje, že systém je provozuschopný jen za předpokladu, že se do něj sahá co nejméně.
To je ale v rozporu s realitou. Zákony se mění, přibývají nové formuláře, datové schránky, propojení s evropskými systémy i požadavky na kyberbezpečnost. Každá nová povinnost znamená další úpravu starého řešení. Pokud je kód špatně napsaný, mohou náklady na změnu převýšit samotný přínos. I proto se modernizace často odkládá a dluh roste.
Kolik technický dluh stojí a proč je tak těžké ho splatit
Přesnou cenu technického dluhu nelze spočítat jedním číslem, protože závisí na velikosti systému, stáří kódu i počtu závislostí. Mezinárodní studie ale dlouhodobě ukazují, že údržba a provoz starých systémů může tvořit většinu IT rozpočtu organizace. U velkých institucí pak modernizace běží v řádu let, ne měsíců. Důvod je jednoduchý: systém je třeba přepsat, otestovat, paralelně provozovat a teprve potom vypnout starou verzi.
Podle americké vládní účetní kanceláře GAO patří zastaralé informační systémy mezi dlouhodobá rizika federálních úřadů, protože jejich provoz je dražší a bezpečnostně slabší. Podobně i v Evropě upozorňují auditorské zprávy na to, že staré aplikace zvyšují náklady na změny a prodlužují dobu, než instituce dokáže reagovat na nové požadavky.
Splacení technického dluhu navíc není jednorázový projekt. Nestačí napsat nový systém a všechno přepnout. Je nutné postupně čistit kód, dokumentovat rozhraní, zavádět automatizované testy a budovat architekturu, která umožní další změny bez chaosu. Bez toho se starý problém rychle vrátí v jiné podobě.
Co pomáhá omezit riziko v praxi
Firmy i úřady, které technický dluh zvládají lépe, mají společné některé postupy. Nepřepisují všechno najednou, ale rozkládají modernizaci na menší části. Důležité je také průběžné testování a jasná dokumentace, aby změny nebyly závislé jen na paměti jednotlivců.
- Pravidelné audity kódu odhalí místa, kde jsou největší rizika.
- Automatizované testy sníží šanci, že nová funkce rozbije starou.
- Moderní rozhraní API umožní napojit nové aplikace bez zásahu do jádra systému.
- Postupná migrace je bezpečnější než jednorázový „velký třesk“.
- Správa znalostí brání tomu, aby celý provoz stál na jednom člověku.
Technický dluh tak není jen problém programátorů. Je to manažerské, finanční i bezpečnostní téma, které rozhoduje o tom, jak rychle mohou banky a úřady reagovat na změny. Čím déle se odkládá, tím dražší a riskantnější je jeho splácení. A v systémech, které drží v chodu mzdy, daně, účty nebo dávky, se tahle odkladová strategie může velmi rychle proměnit v problém, který pocítí miliony lidí.
