Bakalářská práce se zabývá architekturou a provozem datového skladu v prostředí retailové banky se zaměřením na návrh opatření vedoucích k modernizaci současného řešení. Autorka provedla analýzu stávající architektury datového skladu, identifikovala hlavní problémové oblasti a navrhla doporučení v oblasti cloudového řešení, modernizace extrakčních procesů a úprav datového modelování.

Práce je zpracována systematicky a logicky. Teoretická část vytváří odpovídající základ pro analytickou a návrhovou část práce. Pozitivně lze hodnotit zejména propojení teoretických poznatků s prostředím bankovní praxe, práci s interní dokumentací a snahu o ekonomické vyhodnocení přínosů navržených opatření. Silnou stránkou práce je především praktická orientace návrhové části a zaměření na aktuální technologické trendy v oblasti datových skladů.

Dílčí rezervy lze spatřovat zejména v omezeném rozsahu hlubší metodické reflexe, detailnější evaluace navržených opatření a místy více popisném charakteru teoretické části. Přesto práce splňuje požadavky kladené na bakalářskou práci a navržená doporučení jsou prakticky využitelná.

1. Celkové hodnocení
Bakalářská práce Natálie Perkové se zabývá analýzou a modernizací datového skladu v české retailové bance. Téma je vysoce praktické a aktuální. Autorka prokázala schopnost orientovat se ve složité vícevrstevné architektuře datového skladu a popsat ji srozumitelným způsobem.
Analytická část práce je její nejsilnější stránkou. Popis jednotlivých vrstev (OSA, rychlý DWH, hlavní DWH, prezentační vrstva, orchestrace) je podrobný, věcně správný a ukazuje, že autorka problematiku pochopila nejen z literatury, ale i na základě reálných konzultací s odborníky ze zkoumané společnosti.
Návrhová část přináší tři vzájemně provázaná opatření – hybridní cloud, CDC a hash klíče. V závěru návrhové části autorka rovněž explicitně rozlišuje, že CDC a hash klíče představují architektonické změny, zatímco cloud je spíše deployment model – toto rozlišení považuji za důležité.
Přesto mám k návrhové části několik věcných připomínek, které formuluji spíše jako doporučení a poznatky z praxe.
2. Obsahové připomínky
2.1 Hybridní model – nejasná operační stránka
Migrační strategie (kapitola 3.1.5) je popsaná ve čtyřech fázích, ale z praxe bych očekával jasnější odpověď na otázku: jak bude hybridní DWH konkrétně fungovat? Jak budou data konzistentně dostupná, když část analytického jádra poběží on-premise a část v cloudu? Jaká bude latence přenosu mezi OSA a rychlým DWH v cloudu? Existuje fallback pro případ krátkodobé nedostupnosti cloudového prostředí? Diagram migrace (Obrázek 5) ukazuje, co se kam přesouvá, ale postrádám architektonický diagram cílového hybridního stavu zachycující datové toky, síťové propojení a body selhání.
2.2 Ekonomické hodnocení – chybějící srovnání TCO
Ekonomická analýza cloudové migrace počítá s investičními náklady a očekávanými úsporami, ale neobsahuje komplexní srovnání celkových nákladů vlastnictví (TCO). V praxi by banka srovnávala současný stav (pronájem datacentra, odpisy HW, licence Oracle, personální náklady na obsluhu infrastruktury, energie) s budoucím stavem (cloudové subscription náklady, licence Azure služeb, personál na cloudové specialisty, síťové propojení). Podstatné je, že v hybridním modelu banka musí platit obojí: udržovat on-premise infrastrukturu pro OSA a historické jádro hlavního DWH a současně hradit cloudové služby. Toto zdvojení nákladů práce explicitně nekvantifikuje.
Tabulka 8 uvádí úspory za hardware a údržbu, ale tyto předpokládají proporcionální zmenšení on-premise infrastruktury. V hybridním modelu je však redukce omezená, protože OSA a jádro hlavního DWH zůstávají – a s nimi i podstatná část serverové a storage infrastruktury.
2.3 Realtime a streaming – nedotaženo do vyšších vrstev
Práce správně identifikuje potřebu near-real-time zpracování a navrhuje CDC s Apache Kafka. Co mi však v architektuře chybí, je dotažení tohoto principu do vyšších vrstev – až k datovým martům a prezentační vrstvě. V současném návrhu data z CDC dorazí přes Kafku do OSA a rychlého DWH, ale datové marty jsou stále plněny dávkově. To znamená, že i když CDC zachytí změnu v sekundách, koncový uživatel v Power BI ji uvidí až po dalším dávkovém běhu. Skutečný near-real-time reporting by vyžadoval, aby se asynchronní messaging propsalo i do vyšších vrstev. Kafka by v tom případě nesloužila jen jako transportní vrstva, ale jako páteř celé datové architektury.
2.4 Data lakehouse jako možný směr
Práce se zaměřuje na modernizaci stávajícího relačního datového skladu, ale nezmiňuje směr, kterým se datové architektury výrazně posunují – koncept data lakehouse, tedy kombinace strukturovaných a nestrukturovaných dat v jednom prostředí. Pro banku, která začíná pracovat s texty, dokumenty, API odpověďmi nebo daty z mobilní aplikace, je tento koncept velmi relevantní a mohl by být nosným tématem případné diplomové práce.
2.5 Drobné věcné poznámky
Tabulka 6 uvádí dostupnost hybridního cloudu na 99,5 %, zatímco on-premise na 99,9 %. Cloudoví poskytovatelé typicky garantují vyšší SLA než běžná on-premise infrastruktur Topics for thesis defence:

1. 1. Jak by v cílovém hybridním modelu vypadal tok dat od zdrojového systému až k reportu v Power BI? Můžete na konkrétním příkladu popsat, které komponenty běží on-premise a které v cloudu? 2. CDC s Kafkou umožňuje zachytit změny v řádu sekund — ale jak rychle se tato změna reálně dostane až ke koncovému uživateli v prezentační vrstvě? Co by bylo potřeba změnit, aby se latence zkrátila i v dalších vrstvách? 3. Hybridní model znamená, že banka po určitou dobu platí jak za stávající on-premise infrastrukturu, tak za cloudové služby. Jak byste tento faktor zohlednila v ekonomickém hodnocení návratnosti?