V minulém článku Cloudová architektura v praxi: Proč „lift-and-shift“ nestačí pro finanční instituce jsem vysvětloval, že při digitální transformaci přesun systémů do cloudu neodstraňuje technologický dluh ani manuální řízení provozu. Hodnota vzniká teprve tehdy, když se spolu s infrastrukturou změní architektura, automatizace, odpovědnost týmů a způsob měření výsledků. A popisoval transformační možnosti vhodné pro různé situace a případy, kterým finanční instituce čelí.
Dnes se v přehledné tabulce podíváme na cloud-native transformaci a jaké byznysové dopady přináší. A příklady bank, které transformaci provedly.
Lift-and-shift versus cloud-native transformace
| Oblast | Lift-and-shift | Cloud-native transformace | Dopad na byznys |
| Architektura | Stejná aplikace a závislosti běží na virtuálních serverech v cloudu | Modularita podle obchodních domén, API, vhodně zvolené spravované služby, mikroslužby jen s jasným důvodem | Menší rozsah změn, rychlejší integrace partnerů, nižší koordinační náklady |
| Nasazování změn | Tikety, časová okna a ruční kroky | Verzované pipeline, automatické testy a opakovatelné nasazení | Kratší lead time, menší změny, rychlejší reakce na regulaci |
| Škálování | Trvale rezervovaná kapacita, často kopie původního sizingu | Škálování podle zátěže a architektury služby | Lepší zvládání špiček, možnost růstu bez dlouhého nákupu kapacity |
| Bezpečnost a kontroly | Kontroly převážně dokumentační a následné | Bezpečnostní pravidla, konfigurace a důkazy součástí pipeline | Dřívější zachycení chyby, konzistentnější auditní stopa |
| Provozní odolnost | Monitoring infrastruktury, nejasné vlastnictví aplikace | SLO, distribuované trasování, automatizovaná obnova a jasný vlastník služby | Rychlejší detekce a obnova, menší dopad incidentu na klienty |
| Náklady | Účet za infrastrukturu bez vazby na produkt, časté trvalé předimenzování | Přidělení spotřeby týmům, FinOps a náklad na obchodní jednotku | Rozhodování podle ekonomiky produktu, ne pouze podle celkového účtu |
| Odpovědnost týmů | Vývoj předává změnu provozu, riziko a finance vstupují pozdě | Produktový tým vlastní změnu i provoz, platforma poskytuje bezpečné standardy | Méně předávek, rychlejší rozhodnutí, jasnější odpovědnost |
| Schopnost inovovat | Nový produkt dědí staré integrační a provozní fronty | Znovupoužitelné API, události, datové produkty a samoobslužná platforma | Rychlejší experiment, onboarding partnera a škálování úspěšného řešení |
Rychlost nemusí být na úkor stability
Data z průzkumu DORA 2024 ukazují výrazný rozdíl mezi nejvýkonnějšími a nejpomalejšími technologickými týmy.
| Výkonnostní skupina | Lead time změny | Frekvence nasazování | Podíl neúspěšných změn | Doba obnovy |
| Elite | méně než jeden den | vícekrát denně | 5 % | méně než jedna hodina |
| High | jeden den až jeden týden | denně až týdně | 20 % | méně než jeden den |
| Medium | jeden týden až jeden měsíc | týdně až měsíčně | 10 % | méně než jeden den |
| Low | jeden až šest měsíců | měsíčně až jednou za šest měsíců | 40 % | jeden týden až jeden měsíc |
Elite týmy nasazují změny vícekrát denně, přesto mají pouze pětiprocentní podíl neúspěšných změn. Nejpomalejší skupina nasazuje nejvýše jednou měsíčně, ale podíl neúspěšných změn dosahuje 40 procent.
Vyšší rychlost tedy sama o sobě nemusí snižovat stabilitu. Rozhodující je, zda stojí na automatizaci, malých změnách, kvalitním testování a rychlé zpětné vazbě.
Data vycházejí z téměř 3 000 respondentů ze 104 zemí. Finanční služby představovaly 15,66 procenta vzorku. Jde o sebehodnocení týmů napříč různými odvětvími, nikoli o samostatný audit evropských bank. Zdroj: DORA, 2024 Accelerate State of DevOps Report.
Co ukazují banky, které změnily i provozní model
ING neprezentovala svou transformaci jen počtem migrovaných serverů. V investor update popsala společnou privátní cloudovou platformu, DevOps týmy a standardizaci. Doba nasazení infrastruktury se zkrátila z deseti dnů na minuty.
Současně banka mezi lety 2014 a 2019 vyřadila ve wholesale bankovnictví více než 700 aplikací. Poučení je dvojí: samoobsluha bez racionalizace portfolia nestačí a standardizace má hodnotu, když odstraňuje čekání mezi týmy.
Lloyds Banking Group uvádí, že 50 procent aplikací převedla do cloudu, počet datových center snížila o 40 procent a všechny změny dnes dodává agilně. Banka současně vykazuje zlepšení doby vydávání změn o 35 procent.
Tato čísla sama nedokazují jednoduchou příčinnou souvislost. Ukazují však, že migrace probíhala společně se změnou procesů, produktového řízení a technologického portfolia. To je přesnější obraz transformace než samotné procento aplikací v cloudu.
BBVA vybudovala společnou cloudovou datovou platformu ADA s automatizovanou globální správou. V roce 2025 byla platforma rozšířena napříč skupinou s výjimkou Turecka.
Podle banky pracuje s 8,4 petabajtu dat a více než 30 000 aktivními datovými sadami. Přístup k datům, který dříve trval dny, se zkrátil pod deset minut.
Pozdější vrstva MLOps přidala opakovatelné pipeline a automatizované governance kontroly. V pilotních případech banka uvádí zkrácení vývoje o 20 až 75 procent.
Jde o údaje samotné banky a technologického partnera, nikoli o nezávislý audit. Architektonický princip je však přenositelný: sdílená platforma má odstranit opakovanou práci a současně zabudovat kontrolu.
Riziko koncentrace přitom není jen tématem finančních institucí. Skupina Schwarz, do které patří Lidl a Kaufland, začala v roce 2018 budovat vlastní cloudovou platformu STACKIT. Cílem bylo získat větší kontrolu nad daty a kritickou IT infrastrukturou a omezit strategickou závislost na globálních poskytovatelích. Platforma, jejíž datová centra jsou umístěna v Německu a Rakousku, dnes slouží nejen firmám skupiny Schwarz, ale také externím zákazníkům. Pro banky není hlavním poučením, že si mají stavět vlastní hyperscaler. Příklad ukazuje, že otázky technologické suverenity, přenositelnosti systémů a kontroly nad daty se už přesouvají z regulatorních dokumentů do reálných architektonických rozhodnutí.
