Jak neuvíznout v legacy pasti: Budování moderní digitální vrstvy bez zastavení byznysu

V rozhovorech s potenciálními klienty z finančního sektoru se pravidelně vracíme ke stejnému tématu. Firma má připravené nápady na nové produkty, jejichž realizace stagnuje kvůli obavám z toho, co všechno se může pokazit, když se sáhne na starý core systém. V prostředí, kde má každé rozhodnutí velkou váhu, je takový respekt naprosto přirozený. Nikdo nechce riskovat stabilitu fungujícího byznysu kvůli nejistému experimentu.

Proč legacy systém působí jako past

Core systémy v bankách nebo pojišťovnách spravují kritická data a transakce, kde může mít i drobné pochybení přímý dopad na klienty nebo regulátora. Tyto systémy obvykle obsahují velké množství vazeb na další interní aplikace a integrace třetích stran. Každá, byť menší změna, proto vyžaduje náročnou koordinaci napříč týmy i externími dodavateli.

K tomu se přidávají reálná kapacitní a personální omezení. Specialisté, kteří spravují jádro systému, bývají primárně vytíženi jeho údržbou a každodenním provozem, takže jim nezbývá prostor na rozvoj. Detailní znalost architektury navíc často drží jen několik konkrétních lidí, což výrazně komplikuje zastupitelnost i předávání know-how. Výsledek? Změny, které byznys potřebuje nasadit okamžitě, se kvůli těžkopádnosti starého systému realizují celé měsíce.

Řešením ale není snaha lépe koordinovat dva odlišné světy. Řešením je jejich důsledné architektonické oddělení.

Stabilní jádro a moderní uživatelský zážitek jsou dvě odlišné disciplíny

Právě toto rozlišení často chybí u projektů, které nedopadnou podle očekávání. Core systém a digitální frontend totiž mají zcela odlišné priority, technologický stack i tempo změn.

Hlavním úkolem core systému je spolehlivě, bezpečně a auditovatelně uchovávat data a zpracovávat transakce. Prioritou je stabilita a maximální minimalizace rizika, což přirozeně vede k pomalejšímu a opatrnějšímu tempu změn. Digitální produkt má naopak uživatelům přinášet rychlé, responzivní a personalizované rozhraní. Jeho prioritou je flexibilita a neustálé zlepšování na základě zpětné vazby z trhu.

Pokud se tyto dvě disciplíny spojí do jednoho celku, vzniká neefektivita. Buď stagnuje digitální produkt, protože core systém nedokáže reagovat dostatečně rychle, nebo se snižuje stabilita samotného jádra kvůli změnám, které do něj technologicky nepatří. Řešením je integrační vrstva, která zajistí kontrolovanou a bezpečnou komunikaci mezi oběma prostředími.

Nová vrstva jako samostatný produkt

Cílový stav, který klientům doporučujeme, je vybudovat digitální vrstvu jako autonomní produkt bez ohledu na to, zda jde o web, mobilní aplikaci nebo klientský portál. Takový produkt má vlastní vývojový tým, nezávislý release cyklus a jasně definované cíle.

Nová vrstva funguje na vlastním integračním backendu, který komunikuje s core systémem prostřednictvím striktně definovaných API rozhraní. Díky tomu lze nasazovat byznysové změny i úpravy designu bez dopadu na stabilitu jádra. Celá vrstva má navíc vlastní infrastrukturu pro monitoring, bezpečnost a caching, díky čemuž není závislá na výkonnostních limitech starého systému.

Tento přístup samozřejmě přináší dodatečné náklady na správu nové vrstvy. Naše zkušenosti z projektů v bankovním a fintech sektoru ale potvrzují, že tyto náklady jsou výrazně nižší než ztráty vznikající ve chvíli, kdy každá změna frontendu blokuje vývojovou kapacitu core týmu. Core systém zůstává chráněný, digitální produkt se vyvíjí vlastním tempem a interní kapacity se nemusí dělit mezi provoz a inovace.

Osvědčené technické přístupy

V praxi existuje několik vzorů, které se při budování moderní digitální vrstvy nad legacy systémem opakovaně osvědčily. Každý z nich přináší specifické byznysové výhody i limity a představuje jinou cestu postupné transformace systému.

API integrační vrstva

Tento přístup izoluje core systém od okolního prostředí tím, že převádí starší protokoly a formáty do moderních a čistých rozhraní. Zajišťuje překlad mezi legacy datovým modelem a doménovým jazykem nových aplikací, zároveň spravuje oprávnění, limity i logování. Je však potřeba počítat s tím, že tato vrstva je plně závislá na kvalitě vstupních dat. Pokud core systém poskytuje nekonzistentní data, integrační vrstva je sice dokáže transformovat, ale nedokáže opravit jejich logické chyby.

BFF (Backend for Frontend)

Architektura BFF se přizpůsobuje potřebám konkrétního klientského kanálu, takže mobilní aplikace i webový portál mají vlastní optimalizované řešení. Současně agreguje data z více subsystémů a předává je frontendové aplikaci v jednom optimalizovaném volání. Mobilní aplikace tak stahuje pouze objem dat potřebný pro smartphone, zatímco web pracuje s komplexnějším kontextem. Rizikem je situace, kdy se do BFF vrstvy začne přesouvat složitá byznysová logika, která patří do jádra systému. V takovém případě by postupně vznikal nový technologický dluh.

Strangler pattern

Jde o strategii postupné migrace funkcionalit ze starého systému do nového prostředí bez přerušení provozu. Nové byznysové požadavky se vyvíjejí výhradně v moderní vrstvě a původní funkce se do ní postupně přesouvají po jednotlivých use casesech. Oba systémy fungují paralelně, dokud není původní modul zcela nahrazen. Tento přístup však vyžaduje vysokou projektovou disciplínu. Pokud migrace nedojde až do úspěšného konce, organizaci zůstanou dva paralelní systémy a s nimi dlouhodobě zvýšené náklady na provoz.

Mikrofrontendy

Mikrofrontendy umožňují rozdělit klientské rozhraní na nezávislé moduly, na kterých mohou pracovat samostatné týmy a nasazovat je bez vzájemné závislosti. Pro středně velké a menší digitální produkty však často představují zbytečný architektonický over engineering. Přinášejí složitější správu konzistentního UX a zároveň zvyšují nároky na výkon aplikace.

Praktické tipy pro integrační API nebo BFF

Aby nová architektura zůstala stabilní i v dlouhodobém horizontu, opíráme se o pět základních principů, které by měly být součástí diskuse od samého začátku.

• Mapa core systému ještě před prvním řádkem kódu: Před zahájením vývoje nové vrstvy je nezbytné analyzovat core systém pomocí reálných testů a konzultací s interním týmem. Oficiální dokumentace totiž jen zřídka zachycuje skutečné chování systému v produkci.
• Plán pro nedokonalá data: Legacy systémy mohou vracet chybná, neúplná nebo historicky nekonzistentní data. Ta je potřeba upravit nebo doplnit ještě před jejich zobrazením v aplikaci. Integrační vrstva by proto měla obsahovat jasná validační pravidla a umět pracovat s nevalidními daty tak, aby se chyba z core systému nepřenášela přímo na uživatele.
• Cache strategie od prvního dne: Volání do legacy systémů bývají pomalá a náročná na infrastrukturu. Data, která se nemění v reálném čase, by měla být ukládána do cache, například pomocí in memory databáze Redis. Tento přístup výrazně zkracuje odezvu systému a zlepšuje uživatelský zážitek.
• Audit a bezpečnost jako součást návrhu, ne dodatek: Každý požadavek procházející integrační vrstvou by měl být logovaný, chráněný pomocí rate limiting mechanismů a řízený kontrolou oprávnění na úrovni jednotlivých endpointů. V regulovaných odvětvích je navíc nutné počítat s tím, že auditní logy musí být dohledatelné zpětně a musí být možné prokázat, kdo, kdy a s jakými daty pracoval. U klientů to obvykle řešíme také napojením na jejich existující bezpečnostní monitoring, například SIEM systémy.
• Minimalizace citlivých dat: Z core systému by měly přes API odcházet pouze ty atributy, které frontendová aplikace v daný okamžik skutečně potřebuje zobrazit uživateli.

Kompletní rewrite, nebo postupná transformace?

Rozhodnutí kompletně nahradit legacy core systém novým řešením na zelené louce může být správnou cestou pro menší organizace nebo systémy na konci životního cyklu. Tímto krokem se eliminuje technologický dluh a organizace získá moderní stack, na kterém lze bezpečně stavět.

Pro velké hráče v bankovnictví nebo pojišťovnictví je však kompletní rewrite spojený s extrémním rizikem. Jde o rozsáhlou investici na několik let, během kterých je nutné paralelně financovat i provozovat původní systém. Funkcionalita bývá často nedokumentovaná a existuje pouze ve znalostech konkrétních lidí. Migrace dat navíc bývá výrazně složitější, než naznačují první odhady. Proto v GoodRequestu nikdy nerozhodujeme o podobě transformace intuitivně. Vždy vycházíme z detailního auditu systému, kapacit týmu a strategických cílů byznysu.

Jak začít

Na základě našich zkušeností doporučujeme začít transformaci třemi pragmatickými kroky:

1. Definujte jeden byznysový use case. Nesnažte se měnit celou architekturu najednou. Vyberte jeden konkrétní klientský proces, například digitální založení účtu nebo online likvidaci škody.
2. Zmapujte datové toky. Ověřte, která data proces vyžaduje z core systému a v jaké podobě jsou skutečně dostupná prostřednictvím existujících API.
3. Postavte funkční prototyp. Vytvořte omezenou digitální vrstvu pro jeden konkrétní scénář. V GoodRequestu dokážeme funkční prototypy dodat během několika týdnů. Právě hmatatelný výsledek nejlépe posouvá interní diskusi o transformaci, protože odhaluje reálné integrační limity namísto hypotetických úvah.

Tímto přístupem získáte tři věci současně: konkrétní poznatky o stavu core systému, první funkční část produktu pro uživatele a důvěryhodný plán pro širší transformaci.

Podíváme se na váš konkrétní stack

V GoodRequestu máme tým designérů, frontend a backend inženýrů, kteří tímto procesem úspěšně provedli řadu institucí z bankovního, pojišťovacího i fintech sektoru. Rádi s vámi projdeme aktuální stav a navrhneme první kroky ke změně.

Závěr

Původní core systém nemusí být důvodem, proč digitální produkty instituce stagnují. Stabilní jádro a moderní klientské rozhraní představují dvě odlišné disciplíny. Z architektonického i byznysového pohledu dává největší smysl umožnit každé z nich rozvíjet se vlastním tempem. Nástroje jako samostatná integrační vrstva, architektura BFF nebo strategie postupné migrace funkcionalit vám umožní udržet vysoké tempo inovací. Díky nim můžete flexibilně reagovat na dynamiku finančního trhu, aniž byste ohrozili stabilitu systémů, na kterých stojí váš každodenní byznys.