Architektúra · Allianz Brief

ODPORÚČANÝ ARCHITEKTONICKÝ PRÍSTUP

80 % infraštruktúra v súlade s AT štandardmi, 20 % selektívna inovácia

Odporúčaný architektonický prístup zachováva všetky Allianz Technology kontrolné body (landing zone, hub-spoke, identity, observability), pričom selektívne inovuje tam, kde to dáva biznisovo zmysel: multi-tier compute, multi-model AI, MCP-native integration layer.

C4 Level 1 — System Context

Aktéri a externé systémy okolo Allianz CRM platformy. Naša platforma číta z existujúcich zdrojov (API Mgmt, DWH, M365), nereplikuje core dáta, a využíva oba Group AI kontrakty.

Diagram 4 — C4 Level 1 (System Context). Modré = naša platforma a Azure-tenant zdroje, oranžové = externí dodávatelia / existujúce systémy, zelené = aktéri.

C4 Level 2 — Container view

Interné kontajnery platformy hostované na Azure Container Apps / AKS. Web a API tier sú stateless TS, AI/MCP/background tier sú Python.

Diagram 5 — C4 Level 2 (Containers). Všetky compute kontajnery v jednom Azure tenant; data tier je AT-managed.

C4 Level 3 — AI Worker components

Vnútorné komponenty AI worker tier-u. LLM Orchestrator je entry-point pre rozhodovanie o modeli, cache, tooloch a guardrails.

Diagram 6 — C4 Level 3 (AI Worker components). Orchestrator centralizuje routing, caching, RAG, guardrails a audit pre každú inference.

3.1 MULTI-TIER ARCHITEKTÚRA

Stateless web tier + separate AI worker tier — clear separation of concerns

Web tier je stateless TS/Node.js, ktorý škáluje na 2 000 concurrent connections bez problému. AI joby sú v separate Python worker tier — to bol pôvodný klientov concern („Node.js + 2 000 conn + AI joby naraz“), ktorý je tu vyriešený separation of concerns.

Diagram 1 — Multi-tier compute s clear separation: stateless TS web/API, Python AI worker tier, MCP adaptery, background workers. Data tier obsahuje len to, čo my generujeme.

3.2 DATA ACCESS TOPOLOGY

4-source hybrid — žiadna replikácia core Oracle dát

Architektúra explicitne nereplikuje customer/contract/claims dáta z Oracle. Real-time queries idú cez existujúci Allianz API Management, analytics queries cez existujúci Allianz DWH (federated, read-only). Naša Postgres DB obsahuje len to, čo my generujeme.

Diagram 2 — 4-source hybrid data access. Existujúce Allianz zdroje (oranžové) sa nereplikujú; naša Postgres obsahuje len to, čo my generujeme.

3.3 AI ARCHITEKTÚRA — MULTI-MODEL + MCP-NATIVE

Re-use OBOCH Group kontraktov: Anthropic Claude + Azure OpenAI

Multi-model stratégia neznamená nový vendor — naopak, využíva oba existujúce Allianz Group AI kontrakty. Každý model má jasnú, neoverlap-ujúcu funkciu v stack-u.

Model	Use case	Rationale
Anthropic Claude (Sonnet)	Main agentic workflows, chat, tool use, long context	Native MCP support, agentic ergonomics, Group kontrakt
Anthropic Claude (Haiku)	Routing, fast classification, lightweight queries	Cost optimization (10× cheaper than Sonnet)
Anthropic Claude (Opus)	Phase 3 complex reasoning (agent twin coordination)	Reserved, selectively
Azure OpenAI text-embedding-3-large	Embeddings pre RAG / vector search	Production-grade embeddings; Anthropic nemá comparable model
Azure Document Intelligence	OCR a document parsing pre Phase 2 dokumenty	Microsoft-native, integrated into Azure tenant
Azure OpenAI GPT-4o-mini	Narrow classification (sentiment, intent)	Volume-cheap pre high-volume narrow tasks

MCP-natívna integration layer

Diagram 3 — MCP-natívna integration layer. Päť thin adapter serverov, každý na existujúci source. Phase 2/3 pridá agent-twin servery a x-sell engine.

3.4 OPERATIONS MODEL

3-stage transition s explicit exit criteria

Operations model je explicitne navrhnutý tak, aby sa nedalo povedať „budú tu navždy v retainer-i“. Každá fáza má jasný owner, exit criteria a knowledge transfer artefakty.

Stage	Trvanie	Vlastník	Zodpovednosti
Build	2026 (~8 mes.)	My (lead) + Allianz internal devs (embedded)	Code, infra deploy, testing, docs
Hyper-care	6 mes. post go-live	Dual ownership (my + AT)	Knowledge transfer, run-book completion, AT shadowing
Steady state	24–36 mes. ramp-down	AT (L1/L2) + my (L3 retainer)	AT operates incident mgmt; my fix application bugs, evolve features

3.5 IDENTITY, NETWORK, CI/CD

Hub-spoke od AT, golden pipelines, workload identity bez statických credentials

Identity, network a CI/CD vrstvy sú explicitne v súlade s AT štandardmi. Tieto rozhodnutia patria do tých 80 % súladu, ktoré nepotrebujú obhajobu pred AT review.

Topik	Rozhodnutie / predpoklad	Confidence
Azure tenant	Distribučný kanál v separate Azure AD tenant (HYP A); Allianz Group governance scope unclear	OQ-1
Identity protocol	Azure AD SSO, OIDC, conditional access policies	High
Brokers identity	B2B guest accounts alebo federated; toto dramaticky zvyšuje threat surface	OQ-3
Network topology	Hub-spoke od AT (central firewall, egress, identity); naša app v spoke VNet	Medium-High
Public exposure	Všetok ingress cez central Front Door / API Management; žiadne public IPs na app tier	High
Egress to Anthropic / Azure OpenAI	Cez central egress firewall; FQDN-pinned allowlist	OQ-4
CI/CD platform	GitHub Enterprise managed by AT (golden pipelines, mandatory security scanning)	High
Code repo	GitHub Enterprise (AT-managed inštancia)	High
Container registry	Azure Container Registry (AT-managed)	High
Secrets	Azure Key Vault (AT-managed); workload identity (no static credentials)	High
Observability	Azure Monitor + Log Analytics + Application Insights; Microsoft Sentinel pre SIEM	High

3.6 ARCHITECTURAL DECISION RECORDS

12 ADRs — každé non-trivial rozhodnutie s explicit AT alignment line

Každý ADR má pole „Allianz Technology alignment“, ktoré explicitne mapuje rozhodnutie na AT reference architecture alebo dokumentuje zámerné odchýlky a ich obhajobu.

ADR-001 Multi-tier architecture vs monolith

Accepted

Context: 2 000 concurrent obchodníkov + AI joby naraz. Decision: Multi-tier (web stateless TS, API stateless TS, AI worker Python, MCP server, background workers). Alternatives: monolith TS+Python (rejected: GIL contention), pure TS s Workers API (rejected: AI knižnice sú Python-native). Consequences: clear separation, more services to deploy. AT alignment: Container Apps pattern je AT-supported.

ADR-002 TypeScript primary + Python pre AI workers

Accepted

Context: Web/API tier potrebuje stateless HTTP/SSE; AI tier potrebuje LLM SDK + RAG knižnice. Decision: TS pre web/API, Python pre AI worker tier a MCP servery. Alternatives: all-TS (rejected: Anthropic Python SDK je primary, RAG ekosystém je Python). Consequences: dual-language operations. AT alignment: AT-managed CI/CD už podporuje multi-language.

ADR-003 Next.js 15 App Router (hybrid SSR/CSR) vs pure SPA

Accepted

Context: Sidecar SPA pre 2 000 agentov, SEO N/A, ale TTI a auth flow matter. Decision: Next.js 15 App Router s RSC, Server Actions, Streaming SSE. Alternatives: pure SPA React/Vite (rejected: horší auth flow, väčší bundle). Consequences: SSR runtime overhead. AT alignment: Container Apps + Next.js je tested pattern.

ADR-004 Multi-model AI strategy (Claude + Azure OpenAI)

Accepted

Context: Allianz Group má kontrakty na oboch. Decision: Claude pre agentic + chat, Azure OpenAI pre embeddings + narrow classification + Document Intelligence. Alternatives: Claude-only (rejected: nemá comparable embeddings), Azure OpenAI-only (rejected: slabší tool use a long-context). Consequences: dual SDK. AT alignment: re-use OBOCH Group kontraktov, žiadny nový vendor.

ADR-005 MCP-native integration layer

Accepted

Context: Phase 3 vízia agent twin vyžaduje robust tool layer. Decision: MCP servery ako thin adaptery on top of existing sources. Alternatives: custom function calling (rejected: vendor-specific, reinvent the wheel). Consequences: MCP runtime overhead. AT alignment: sedí ON TOP of API Management, nereplikuje funkcionalitu. OpenAI MCP support 2025 = industry standard.

ADR-006 No replication of core Oracle data

Accepted

Context: Customer/contract/claims data v Oracle, AT pravdepodobne odmietne ďalšiu replikáciu. Decision: Real-time cez API Management, analytics cez DWH federated, žiadna own copy. Alternatives: event-driven replication (rejected: GDPR, DORA exit complexity). Consequences: dependency na API Mgmt latency. AT alignment: plná konformita s data governance.

ADR-007 Redis cache s TTL a toggle-off mode

Accepted

Context: Profile data hot path optimization. Decision: Redis Premium 5–15 min TTL, AT-managed Key Vault keys, encryption-at-rest, opt-out toggle. Alternatives: no cache (rejected: latency), persistent cache (rejected: GDPR). Consequences: ďalšia copy v scope DPIA. AT alignment: Key Vault + private endpoints = v súlade s AT štandardmi.

ADR-008 Postgres ako own DB (vs Cosmos / Azure SQL)

Accepted

Context: Vlastné dáta — chat history, kampane, audit log, agent notes. Decision: Azure Database for PostgreSQL Flexible Server HA. Alternatives: Cosmos DB (rejected: cost + nepotrebujeme global), Azure SQL (rejected: pgvector ecosystem). Consequences: Postgres ops. AT alignment: AT podporuje Postgres Flexible.

ADR-009 Azure Container Apps vs AKS

Proposed

Context: Hosting platform pre web/API/worker/MCP tier. Decision (TBD per AT preference): Container Apps default (managed, lower ops). Switch to AKS ak AT preferuje. Alternatives: AKS-only (rejected: vyšší ops overhead pre Phase 1). Consequences: dependency na AT preference. AT alignment: oboje sú AT-supported.

ADR-010 Vector store — Azure AI Search vs pgvector

Proposed

Context: Embeddings pre VPP, dokumenty, semantic search. Decision (TBD): Azure AI Search default (production-grade hybrid search, AT-supported). pgvector ako fallback. Alternatives: dedicated vendor (Pinecone — rejected: nový vendor). Consequences: vendor lock-in to Azure stack. AT alignment: Azure-native = v súlade s AT konvenciami.

ADR-011 Anthropic deployment topology

Proposed

Context: Anthropic Direct API / AWS Bedrock / Private Link? Decision: TBD na OQ-2. Drives network egress (Azure → public internet vs Azure → AWS Bedrock), data residency, DPA terms. Alternatives: Direct API (simplest, public egress), Bedrock (cross-cloud), Private Link (best isolation). Consequences: ovplyvňuje firewall + ZDR claim. AT alignment: Private Link preferred ak je dostupný.

ADR-012 Adapter pattern pre Oracle → ADP migration

Accepted

Context: ADP-SK roadmap unknown, Oracle existuje teraz. Decision: MCP servery sú thin adaptery — keď príde ADP, vymeníme adapter; rest of stack unchanged. Alternatives: direct DB queries (rejected: tight coupling). Consequences: miernu indirection v každom data calle. AT alignment: future-proofing pre Group data strategy.

ARCHITECTURE BOTTOM LINE

Odporúčaná architektúra obstojí pred AT review s ~60–70 % pravdepodobnosťou

Žiadna architektonická voľba nie je „experiment“ — každá má alternatívu (fallback), counter-argument na očakávanú AT objection a explicitnú alignment line s reference architecture.

ADRs

každé s AT alignment line

Red-team counters

pre-empted AT objections

Súlad s AT

80 / 20

AT reference / selektívna inovácia

Diagramy C4 Level 1 → L2 → L3 budú pridané v Phase 5 ako interactive ArchitectureNavigator widget. Tento dokument popisuje content; vizuálna vrstva nadviaže.