Architecture Hub
One enterprise, two architectural pillars, one entry point. This is the pillar-neutral navigation layer for the whole architecture — it does not restate the authoritative docs, it links them. Use it to move from the enterprise landscape down to applications, their platform dependencies, and deployments — without confusing architectural intent with verified operational reality.
The platform runs on a strict boundary (platform-vs-information-system.md), also stated in
the two-pillar intro:
- 🏗 PLATFORM (minicloud) — the shared technical capabilities (the internal cloud provider).
- 🏢 INFORMATION SYSTEM (ktayl-solution) — the business applications, data and processes of the insurer, which run on and consume the platform.
The litmus test: "If ktayl stopped selling insurance tomorrow, would this survive unchanged?" Yes → Platform. No → Information System. This is a question of ownership, not deployment location — a Claims app running on Kubernetes is still an IS application.
L1 — Enterprise Architecture Landscape
The one-screen relationship: the Information System consumes the Platform. Each box is a group of capabilities/domains (drill down via the L2 views below).
The precise who-consumes-what (with interfaces + ownership) is the Platform ↔ IS Dependency Matrix.
Reading vocabulary (two independent axes)
Do not conflate these — they answer different questions:
| Axis | Values | Means |
|---|---|---|
| Maturity (does the code exist?) | Implemented · Scaffold · Planned | Implemented = real code + substantial functionality · Scaffold = repo/skeleton, little business logic · Planned = no implementation yet |
| Runtime (is it actually running?) | Verified · Unverified | Verified = runtime existence checked against the live cluster · Unverified = inferred from GitOps/repo evidence only |
:::caution Runtime status is currently Unverified The last architecture audit could not reach the Kubernetes cluster, so these views assert implementation maturity, not live deployment. Nothing here claims an app is "running" from the mere existence of its repo or its ArgoCD manifest. Re-verify against the cluster before claiming operational reality. :::
Navigation hierarchy
Enterprise Landscape → Business Capabilities → IS Applications → Platform Services → Deployment / Ops.
| View | What it answers | Authoritative? |
|---|---|---|
| L1 — Enterprise Landscape (above) | how Platform & IS relate | navigation |
| C4 System Design (Platform) | the complete platform as a C4 model — Context → Container → Deployment (Structurizr, as code) | ✅ system design |
| L2 — Platform Architecture / Topology | the platform's technical capabilities (icon topology) | ✅ platform topology |
| L2 — IS Application Landscape | the business apps by insurance domain + maturity | navigation → per-app docs |
| Platform ↔ IS Dependency Matrix | consumer · capability · interface · ownership · evidence | ✅ the contract map |
| Enterprise Architecture Blueprint | the IS functional target + gap analysis | ✅ IS domains |
| Business Capability Map | ~150 L2/L3 capabilities × status/criticality/RTO-RPO | ✅ capabilities |
| IS — Architecture at a Glance | the IS one-screen mental model | ✅ IS overview |
The original hand-made HTML poster was retired 2026-10-17 — superseded by the code-generated C4 System Design + the Platform Architecture views (maintainable, accurate, no pixel-pushing).
Planned: Architecture Decision Records (ADRs) under this section — why ArgoCD, Authentik, Cilium, Longhorn, and the Platform/IS split were chosen — to show not just what was built but why.