Informatika / Systémová Analýza

Staňte se Architektem Informačních Systémů

Vítejte v interaktivním cvičení. Vaším úkolem je navrhnout řešení a pochopit rozdíly mezi různými typy architektur. Od přísně střežených státních systémů, přes rychlé komerční aplikace, až po zvládání extrémních zátěží a optimalizace výkonu.

Veřejný sektor

Bezpečnost & Data

Infrastruktura

Zátěž & Škálování

Integrace & Caching

Fronty & Výkon

Část 1: E-Government pro mladé

V této sekci se vžijete do role analytika Portálu občana. Stát potřebuje motivovat studenty k využívání digitálních služeb. Vaším úkolem je navrhnout mini-aplikaci (funkci), která bude užitečná, ale zároveň musí respektovat přísná bezpečnostní pravidla a využívat správné státní registry.

Konfigurace Funkce

1. Vyberte novou funkci

2. Potřebná data (Data Flow)

Jméno a Příjmení (ROB) Status Studenta (Matrika studentů) Fotografie z OP (Evidence OP)

3. Úroveň zabezpečení (Auth)

Identita občana je vyžadována pro přístup k registrům.

Portál Občana

Vítejte, Jane

Část 2: "Restaurace Budoucnosti"

Zde navrhujete systém pro moderní bistro. Cílem je rychlost a minimalizace chyb. Vyzkoušejte si simulaci toku objednávky od zákazníka až do kuchyně. Klíčovou součástí návrhu je krizový scénář – co se stane, když vypadne internet?

Internet: ONLINE

1. Zákazník

Skenuje QR kód

2. Cloud API

Zpracování dat

3. Rozdělení

Kuchyně / Bar

4. Sklad

Odpis surovin

> Systém připraven...

Část 3: Zátěžový test a Škálování

Infrastruktura musí reagovat na provoz. U státních systémů často zažíváme kolapsy (např. spuštění e-dálničních známek, daňové portály) kvůli tradičnímu "monolitickému" návrhu. Vyzkoušejte si, jak se chová server při náhlé zátěži (Spike) v závislosti na zvolené architektuře.

Vyberte architekturu

Tradiční Monolit

1 obří fyzický server (Státní IS)

Cloud Autoscaling

Dynamické přidávání instancí

Požadavky uživatelů

10 req/s

Hlavní Server OK

Zátěž CPU 5%

Část 4: Zpracování objednávky (Integrace)

Když zákazník klikne na "Dokončit objednávku", systém musí provést mnoho věcí (strhnout platbu, vygenerovat fakturu, odeslat e-mail, zapsat do skladu). Při synchronním zpracování uživatel celou dobu čeká. Při asynchronním zpracování se jen uloží událost do "Fronty" (Message Broker) a uživatele pustí ihned dál. Zkuste si rozdíl v uživatelském zážitku.

Vyberte způsob zpracování

Synchronní (Lineární)

Klient čeká na všechny kroky

Asynchronní (Fronta)

Použití RabbitMQ / Kafky

Zákazník

Čeká na akci

E-shop API

Backend

Fronta událostí

Message Broker

Faktura PDF

Čas: 1.5 sekundy

Zápis do ERP

Čas: 1 sekunda

Odeslání E-mailu

Čas: 1 sekunda

> Systém připraven...

Část 5: Uživatelský pohled (UX / UI)

Data na pozadí systému jsou vždy stejná – tabulky, UUID identifikátory a číselné stavy. Jako architekt ale musíte zohlednit, kdo se na data dívá. Porovnejte, jak vypadá detail poplatku za komunální odpad z pohledu databázového administrátora (systému) a z pohledu běžného občana v mobilní aplikaci.

Zvolte vizualizaci dat

Architektonický princip: "Separation of Concerns" (Oddělení zodpovědností). Backend řeší přesnost a integritu dat. Frontend (UI) řeší emoce, srozumitelnost a navigaci k cíli (konverzi).

Část 6: Zrychlení výkonu (Caching)

Číst data přímo z hlavní databáze (např. SQL) je pomalé a drahé. Proto architekti používají vrstvu zvanou "Mezipaměť" (Cache, např. Redis), která si pamatuje časté dotazy v operační paměti (RAM) a vrací je bleskově. Vyzkoušejte si načíst profil s vypnutou a zapnutou Cache.

Ovládání Cachování

Aktivní Cache vrstva

Redis in-memory store

Doba načtení: 0 ms

Mobilní appka

API Server

Redis Cache

Vypnuto

SQL Databáze

Pomalé čtení (Disk)

Část 7: Závěrečné srovnání

Jako architekt musíte chápat kompromisy. Žádný systém nemůže být dokonalý ve všem. Podívejte se na radarový graf, který vizualizuje priority obou typů systémů, a odpovězte na diskuzní otázky.

Priority Architektury

Diskuzní otázky (Klikněte pro odpověď)

1. Kde je důležitější "Cool Design"?

Gastro (Komerční sféra). Zákazník si vybírá očima. Pokud je aplikace pomalá nebo ošklivá, půjde jinam. U státního webu "nemáte na výběr", tam je prioritou funkčnost (i když by měl být přívětivý také).

2. Kde řešíme více autentizaci?

Veřejný systém (Stát). Přístup k citlivým údajům (zdravotní záznamy, majetek) vyžaduje nejvyšší úroveň ověření (NIA, eObčanka). V gastru stačí často jen číslo stolu nebo email.

3. Co je horší únik dat?

Státní data. Únik seznamu, co měl kdo k obědu, je nepříjemný (GDPR), ale únik rodných čísel, adres a majetkových poměrů může vést ke krádeži identity a celoživotním problémům pro občany.

4. Proč státní weby často "spadnou"?

Historická monolitická architektura. Státní systémy jsou často navrženy na fixní "železo" (hardware). V běžném roce mají zátěž 10 %, ale v den uzávěrky (např. daní) stoupne zátěž na 1000 %. Moderní komerční firmy používají Cloud, který automaticky pronajme další servery na pár hodin a pak je zase zruší.

5. Kdy se NEhodí použít fronty a asynchronní zprávy?

Když zákazník potřebuje znát výsledek okamžitě. Typickým příkladem je ověření přihlašovacích údajů, kontrola dostupnosti na skladě nebo samotná platba kartou. Zákazníkovi nemůžete říct "Zaznamenali jsme požadavek na platbu, možná to projde za 5 minut." Platba musí být synchronní, ale odeslání e-mailu s účtenkou už asynchronní být může.

6. Proč neukazujeme uživateli všechna dostupná data ze systému?

Zabraňuje to kognitivnímu přetížení (Cognitive Overload). Obyčejného člověka nezajímá 32místné UUID záznamu ani sekundy v datu splatnosti. Zajímají ho jen tři věci: Co to je, kolik to stojí a jak se toho co nejrychleji zbavit (zaplatit to). Dobrý návrh UX skrývá složitost systému a předkládá jen to nezbytné pro akci.

7. Když je Cache tak super, proč necachujeme úplně všechno?

Kvůli riziku zastaralých dat (Stale Data). Můžete snadno cachovat statické věci (seznam kategorií v e-shopu, profilové foto). Ale nesmíte cachovat kritická dynamická data – např. zůstatek na bankovním účtu, nebo přesný počet vstupenek zbývajících v prodeji. Tzv. "Invalidace cache" (kdy a jak data smazat) je považována za jeden z nejtěžších problémů v IT.