Brac POC — consolidated demo plan

Single consolidated demo plan for BRAC Bank — merged requirements from the original 9-section email and the v2 demo-scope PDF, with delivery, sequencing, and the live demo flow.

This page consolidates the two BRAC source documents into one plan: the requirements, the architecture, what we reuse vs build, the per-item delivery, the phase sequencing, and the live demo flow.

Operating principle:

• Demo apps run on OpenShift (spoke-dc-v6). Not on the docker-runtime-vm we built earlier for the broader app-dev path.
• dc-lab platform VMs are reused as-is. SigNoz, DefectDojo, Kafka KRaft, Redis Sentinel, WSO2 APIM/IS, Jenkins, GitLab, Nexus, Trivy — no Helm/operator rebuild of services that already run on lab VMs.
• New work is OCP-side: the demo apps + Service Mesh + OTel collector + integration glue (ESO bindings, Routes, NetworkPolicies, mesh canary, the few new operators).
• The live demo is browser-driven. A single-page app (“BRAC POC Demo Dashboard”) served by the MFE Router has one panel per demo requirement. Each panel triggers the actual backend action (canary calls, mTLS verify, Redis primary kill, trace storm, Nexus pull) and renders the result inline. Native admin UIs (Kiali, SigNoz, WSO2 Publisher, DefectDojo, RHACS) are linked or iframed from the SPA; no terminal walls during the demo.

The two source documents (preserved verbatim for the audit trail):

• Requirements email — the 9-section tender qualifying scope.
• v2 Demo-Scope PDF (received 2026-05-11) — 8-item live-demo subset, adds Service Mesh + mesh canary, includes the MFE/BFF reference architecture image.

Merged requirements

The union of both documents, deduplicated, priority-ordered for the live demo. Live-demo priorities come from the v2 PDF; the rest are tender-qualifying scope from the original email.

Original email also mentions “Support Service for 13 Products” but the PDF is truncated at section 9 — sections 10-13 are not captured. Open question to BRAC.

Architecture (consolidated)

The v2 PDF’s reference image translated to OCP + dc-lab terms:

User (browser)
  │ HTTPS (TLS terminate #1 — OCP Route + cert-manager)
  ▼
MFE Router  ── serves ── ► BRAC POC Demo Dashboard (SPA)
  │                          │   one panel per demo req
  │ HTTP                     │   (canary control, redis kill,
  ▼                          │   mTLS verify, trace storm, etc.)
WSO2 API GW              ◀──┘
  │ HTTPS (TLS terminate #2 — existing WSO2 VM, lab CA)
  ▼
BFF Router  ── exposes ── ► /demo/* endpoints (canary, mtls-check,
  │                          redis-kill, trigger-traces, nexus-pull)
  │ HTTP
  ▼
Mesh boundary ─────┐
  │ mTLS strict    │
  ▼                │
Identity ◀────── WSO2 IAM (lateral, token introspection / authz callout — existing WSO2 IS VM)
  │ mTLS           │
  ▼                │
Product            │
  │                │
  └─[mesh observability sidecars → OTel Collector → existing Kafka VMs → existing SigNoz VM + ClickHouse]

Pieces and their hosts:

The BRAC POC Demo Dashboard (SPA)

A single browser app is the demo cockpit. The evaluator opens one URL and clicks through eight tabs. Each tab triggers real backend calls against the actual demo stack and renders the result inline. Native admin UIs (Kiali, SigNoz, WSO2 Publisher, DefectDojo, RHACS, OCP console) are either iframed inside a panel or opened in a new tab via a button — so the SPA stays the orchestrating surface, not the only surface.

Stack: React 18 (or static Astro build for parity with the zahid blog) + Tailwind. Diagrams reuse @xyflow/react (Whiteboard) for the mesh request graph. Live charts via Recharts. WebSocket or Server-Sent Events for live updates (Redis primary changes, request streams).

Served by: MFE Router (NGINX) as a static bundle at /. API calls go through the MFE Router’s reverse-proxy to the BFF Router’s /demo/* endpoints.

Panels (one per v2 demo requirement):

Tender-item tour (bottom of the SPA): smaller cards linking out to the native UIs — Compliance scan results (OCP console), RHACS policy violations (RHACS UI), DefectDojo SBOM view, the BRAC monorepo + Jenkins build page (GitLab + Jenkins UIs), JBoss admin console (port 9990).

Why one SPA, not one app per panel: the evaluator gets a single mental model — open the URL, walk top-to-bottom. The story is the SPA itself, not the cobbled tooling underneath. Every panel renders live data, so the demo is always real-time, not pre-recorded.

Target environment

New tenant namespaces created for the POC, on spoke-dc-v6:

• brac-demo-frontend — MFE Router, BFF Router, optional demo SPA.
• brac-demo-services — in-mesh Open Liberty demo services (Identity, Product), OSSM ambient.
• brac-demo-otel — OTel Collector (Gateway).
• brac-demo-jboss — planned JBoss EAP managed-domain demo (separate from mesh services). For the delivered bank-employees chat implementation, see JBoss Chat app.
• brac-demo-evidence — scratch / artifacts during the live demo.

Reuse vs build matrix

Phase sequencing

Block A items are reuse-walkthroughs (no new code; just narration + screencasts). Block B is the actual build work, sequenced so highest-priority demo items land first. The Demo Dashboard SPA runs as a parallel track from P1 onward — each backend capability ships with its SPA panel ready.

Live demo flow — browser-only

The evaluator opens one URL (the SPA) and walks down the page. Every panel is interactive; nothing requires terminal access. The full session is ~90 minutes — about 5-10 min per panel, with the HIGH-PRIORITY Observability + Kafka section getting the longest slot.

Pre-demo morning-of: all panels render with green health pips. The Demo Dashboard footer shows a Last-Validated timestamp ≤ 1 hour old.

Walk order (the SPA tabs from left to right):

1. API Gateway (5 min) — click “Try the sample API” → response viewer fills in. Open “WSO2 Publisher” tab from the panel; show the policy + key + IS-as-Key-Manager link. Back to SPA.
2. IAM (10 min) — Click Logout → Re-login via OIDC (browser redirect to IS, return with token visible in the user panel). Repeat via SAML. Click “Switch IdP” → Federation to a second IdP source. The user panel updates each time, with claims + federated-source live.
3. Service Mesh + mTLS (10 min) — Live React Flow graph already showing identity → product green edges. Click “Verify mTLS now” → button flashes, returns MUTUAL inline. Open Kiali tab from the panel for the full mesh-wide view.
4. Canary via mesh (5 min) — Slider at 90/10 by default. Click “Send 100 requests” → bar chart fills in real time (~90 to v1, ~10 to v2). Toggle the “x-canary: beta” sticky header → next 100 all land on v2. Slide to 50/50 → next 100 split evenly.
5. Observability + Kafka — HIGH PRIORITY (15 min) — Click “Trigger 50 traces” → varied requests fire. Embedded SigNoz iframe shows the service map filling in. Click “Open .NET Runtime dashboard” → opens dedicated tab showing GC heap moving with the load. Same for App Perf, System, Tracing. Mention sampling/filtering/routing (visible in the trace counts).
6. Redis HA (5 min) — Status panel shows current primary (e.g., redis-0) + replicas. Live read/write rate ticking (~50/s). Click the big red “Hard-kill primary” button. Status panel switches to redis-1 in ~15 seconds. Rate counter dips to zero briefly, then resumes. Sentinel +switch-master event surfaced inline.
7. SigNoz (5 min) — Already mostly seen in step 5. Click the four dashboard cards for a coherent tour. Use the natural flow to show Kafka topic lag (also in SigNoz).
8. Nexus OSS (5 min) — Artifact list shows 4 entries (one each Maven / PyPI / npm / Docker). Click “Pull this” on each — backend returns digest + size + format-specific metadata. “Open Nexus browse” link to the existing Nexus UI for the three-endpoint split.

Tender-item tour (15 min, bottom of the SPA):

Card grid links out to native UIs — one click each:

9. OCP cluster + ODF — opens the OCP console (Storage page).
10. Compliance + PCI-DSS — opens the OCP console ComplianceCheckResult view.
11. RHACS critical-block — opens RHACS Violations page; tab back to SPA, click “Try to deploy CVE-rich image” → policy hit toast appears.
12. Trivy + DefectDojo (SCA + SBOM) — opens DefectDojo product view with both engagements side-by-side.
13. BRAC monorepo + conditional Jenkinsfile — opens GitLab + Jenkins build page; demonstrate by pushing a change to apps/brac-payment-api/ and watching only that build trigger.
14. Hybrid CD — Jenkins page shows the same build artifact deployed to both an OCP Liberty CR and one existing VM target.
15. Kafka Schema Registry + DLQ — small inline panel in the SPA: “Produce valid Avro” / “Produce invalid Avro” buttons; reject message shown inline. “Inject poison record” → DLQ topic count increments.
16. JBoss EAP managed domain — opens the JBoss admin console (port 9990). Show server-group list; trigger a Server Group A rolling reload from the SPA; B keeps serving (visible in the console).

Wrap (5 min): SPA footer has a “View evidence pack” link → reports/brac-poc/. Final slide: thank-you + open Q&A.

Evidence pack

Per workstream, a folder in reports/brac-poc/<NN>-<slug>/:

• 1-page summary of what was demonstrated + which dc-lab assets it consumed.
• CRs + ConfigMaps applied to spoke-dc-v6 (committed to platform-gitops under clusters/spoke-dc-v6/brac-demo/).
• Screenshots of the relevant UIs (RHACS, SigNoz dashboards, WSO2 Publisher, DefectDojo, Kiali mesh graph, JBoss CLI).
• Recorded terminal sessions (asciinema or script) for the live demos.
• Logs from the critical moments (Sentinel +switch-master, RHACS policy hit, canary traffic shift, mTLS handshake, Schema Registry reject).

No secret values, no kubeconfigs, no credential bytes in the evidence pack. Vault paths referenced by name only.

Open questions

1. OCP cluster choice: use existing spoke-dc-v6 (default — fastest) or stand up a separate POC cluster (more demonstrable for the Terraform-automation requirement but adds 2-3 days)?
2. OCP version pin: confirm BRAC’s evaluation tools work against the current spoke-dc-v6 minor; if they want a specific version, plan a controlled upgrade or a side cluster.
3. JBoss EAP image entitlement: valid pull secret for the EAP Operator’s images? Otherwise fall back to community WildFly.
4. WSO2 license / image entitlement: existing WSO2 VMs run fine. Confirm no new license needed for the POC.
5. DC-DR scope: default is “documented procedure + one rehearsed restore in a side namespace” rather than a second live cluster. Confirm.
6. Truncated requirements PDF: original email mentions “13 Products” but PDF ends at section 9. Request sections 10-13 before P5 finalizes.
7. MFE / BFF stack choice: NGINX-only for MFE, or a real micro-frontend aggregator (Module Federation / single-spa)? BFF as Liberty (Java ecosystem fit) or Node (lighter)?
8. “Comply MTLS” interpretation: v2 PDF says “MTLS (Commply MTLS / Service mesh)”. Likely typo for “Compliance-grade mTLS” — strict mTLS + FIPS-ish posture + audit. Confirm.
9. Demo Dashboard SPA stack choice: React 18 (familiar, lots of components) vs. static Astro build (matches the zahid blog stack, simpler hosting). Default: React for the interactive panels (live charts, SSE, React Flow), but consider Astro + React islands if zero-deps is a goal.
10. Redis kill-primary auth model: the SPA’s “Hard-kill primary” button calls a BFF endpoint that runs redis-cli DEBUG SEGFAULT against the lab Sentinel pool. Should the BFF authenticate as a specific Vault-stored user, or is the BFF’s own service identity sufficient? Tradeoff: audit trail vs simplicity.

Resolved:

• (2026-05-11) Redis HA stays on existing VM Sentinel — no OCP-side Redis deployment. OCP carries only a small mock client to demonstrate Sentinel reconnect.
• (2026-05-11) Demo is browser-driven via a single SPA. Live demo cockpit served by the MFE Router. One panel per requirement, real backend calls, no terminal walls.

What’s intentionally not in this plan

• No rebuild of dc-lab services on OCP. SigNoz, DefectDojo, Kafka KRaft, Redis Sentinel, WSO2 APIM/IS, Jenkins, GitLab, Nexus, Trivy — all reused on their existing VMs.
• No deployment of demo apps to docker-runtime-vm. That path exists for the broader app-dev direction (project_app_dev_direction.md), but for this POC the demo apps run on OCP.
• No second OCP cluster unless Q2 = yes.
• No NGINX-based header canary at the application tier — replaced by mesh canary per v2 PDF (the MFE Router still has NGINX hardening: HSTS + custom 404 + rate-limit on login).
• No new ADRs unless a load-bearing direction changes (e.g., adopting OCP-native Redis or migrating Kafka off VMs as strategic direction beyond the demo).
• Sections 10-13 of the original requirements PDF — not in scope until we see them.