Appearance
GARB ADS (MVP Phase)
| Source | client-resources/Unified-GARB ADS (MVP Phase)-090926-115239.pdf |
| Type | PDF, 15 pages — Confluence export of an Architecture Design Specification |
| Origin | Unified Project delivery team, submitted for GARB architecture approval |
| Dated | Exported 2026-09-09 |
| Status | Submitted for approval; assessed and recommended for return |
What it is
The architecture the delivery team is actually building, written up for the Global Architecture Review Board. Everything else in the client material is either the strategy above it or a review of it. This is the artifact under dispute, and it is worth reading on its own terms before reading its critics.
Its topology is redrawn as Unified Dashboard MVP — GARB ADS as submitted, which carries only what the ADS itself asserts. The assessment's findings are deliberately not drawn into it.
What the MVP is — and explicitly is not
The initiative is framed as a long-term programme reducing fragmentation across Retirement, Group Benefits, Banking, Wealth, Insurance and future business lines, moving from product-centric to relationship-centric. The ADS then narrows hard:
The MVP does not introduce a new portal, unified customer profile, automatic product linking, or centralized authorization capabilities.
Instead it replaces the existing Product Selection Home Page with a Unified Dashboard inside the existing customer portal. Customers keep linking products manually with BU-specific identifiers, and keep going to existing BU portals to transact. The stated purpose is a common post-login entry point with minimal disruption, "a foundation for future phases."
Impacted customers: Group Retirement and Wealth (GWAM-owned); Group Benefits, Investment, Bank and Individual Insurance (CA Segments-owned).
Phasing
| Phase | Content |
|---|---|
| Phase 0 | Mobilization and alignment — scope, governance, delivery streams, success metrics |
| Dark Launch (Oct end, TBD) | Shell only, 10–15 internal employees, minimum BU cards: GB and GR |
| Phase 1 — Unified Experience MVP | Shell, LOB-specific MFEs, CIAM ID mapping, lightweight BU integrations |
| Phase 2 — Customer linking and MDM | Identity resolution, ECID mapping, auto-linking, MDM foundation for GB and Retirement |
| Phase 3 — Enterprise expansion | Unified profile, consent, preferences, PDP/UES authorization, more business lines |
Phases 2 and 3 are where the strategy document lives. They are out of this ADS.
The technology stack
| Layer | Technology | Purpose |
|---|---|---|
| Framework | Next.js | SSR, routing, API routes |
| Frontend | React | SPA UI |
| Backend | Next.js route handlers, Node.js | REST endpoints, server actions |
| Database | CosmosDB (MongoDB API) | Session store |
| API caching | Azure Managed Redis | Short-TTL per-downstream cache; envelope encryption, AES-256-GCM DEKs, Key Vault KEKs |
| CDN / edge | Akamai | Global edge caching for static assets and HTML; WAF, DDoS, bot protection |
| Content | Adobe Experience Manager | Content fragments |
| Feature flags | Unleash | Runtime toggles, gradual rollout |
| Infrastructure | Cloud Catalog, Terraform, Azure | All platform infra |
| CI/CD | WAVE, GitHub Actions | Build, test, deploy |
| Observability | New Relic, PromStack, ADX | Metrics, logs, errors |
New components: the Dashboard Shell (BFF experience — serves shell and MFEs, session lifecycle, CIAM and Unleash, delegates cross-domain calls), the Integration API (channel-agnostic orchestration — fans out to BU Data APIs, aggregates, caches in Redis), and the per-BU MFEs.
The downstream APIs
| API | Domain | Contract |
|---|---|---|
| CIAM (ForgeRock) | Identity | OIDC auth code + PKCE |
| BU Mapping Service | Identity / authz | POST /mappings/search — CIAM ID to product relationships; drives which MFEs render |
| Group Benefits Core API | GB | MemberRecentClaimsNCQuery — claims overview, coverage |
| Canada Retirement / GRS | CR | GET /v1/persons/{person-id}/assets (AssetBalance v1) |
| Manulife Bank API | Banking | GET /v2/accounts/ — asset, liability, credit card accounts |
| Individual Insurance API | Insurance | CSS policyDetails |
| Wealth API | Wealth | cw-mobile-exp-api — /api/v1/home, /api/v2/accounts/holdings |
| Seg Funds and GIAs | Investments | GET /api/v1/investments?ciamId= |
| Affinity API | Health/dental | claimsMemberService — de-prioritized for the initial release |
Two business-unit notes are recorded in the ADS itself: Canada Retirement needs a Login Handler change to augment a new Group Retirement token, and Wealth needs a new experience API — with the note that "FCC currently supports 25 concurrent transactions per second" and the team is evaluating page load and will request more capacity. Capacity planning is marked in progress.
Security and authorization, as written
- Information classification: Highly Confidential (customer investment, wealth and portfolio data).
- Identity and access management: "existing… No Change." CIAM performs authentication; the dashboard trusts only validated CIAM tokens.
- Authorization: "No change to authorization for the MVP. Authorization remains enforced in existing product portals." The BU Mapping Service (CIAM-owned, populated by the manual linking process) supplies CIAM-ID-to-product mapping.
- Integration API to backend services: service-to-service authentication plus a ForgeRock JWT, identity type service principal.
- Data protection: "The MVP does not introduce new customer data stores and continues to rely on existing authoritative systems."
- Technical debt: "No technical debt."
Those last two statements, together with the CosmosDB session store and Redis cache listed in the technology table, are the basis of four of the assessment's blocking findings.
Non-functional requirements
The NFR table is extensive and cites five MFC-STA standards. Headline commitments:
| Category | Commitment |
|---|---|
| Availability | 99.99% (52.6 min/year) |
| API response | 99% under 800 ms · 95% under 500 ms · 90% under 300 ms |
| Page load | 99% of Shell pages under 1 s |
| Capacity | 6,000,000 registered · 20,000 concurrent · 1,000 simultaneous on the same API |
| Throughput | 1,200 rps (auth, token, HOTP, verification, access, search) · 250 rps (create/update/self-service) |
| DR | RTO 0–52.6 min · RPO 0–5 min |
| Reliability | 99.0% non-5xx · fault rate under 0.05% |
| Deployment | Blue-green, zero downtime |
| Residency | All PII at rest in Canada; PII in transit not accessible outside Canada |
| Regulation | SOC 2, "PIPIEDA" (sic) |
| Localization | English and French |
| Accessibility | AODA, AMA, WCAG 2.1 AA |
Key design decisions
Both recorded as pending LARB approval while build proceeds:
- Design system selection (MUX vs GDS) — recommended Option C, MUX as a Canada Segment library on the GDS core.
- Frontend composition strategy — recommended Option C, hybrid shell plus MFE for web, thin native for mobile, shared Integration APIs.
Why it matters here
This is the current-state-of-the-plan. Our target state has to be reachable from it, and the roadmap has to start from it. It also sets three constraints worth carrying forward: the estate is Azure and Next.js on AKS; identity is ForgeRock and is not being replaced; and the MVP has deliberately deferred exactly the capabilities the segment strategy treats as foundational.
Read alongside the segment assessment and the readiness review — both respond directly to this document, and several of their findings are about what it says rather than what it builds.
Open questions raised
- Is the ADS being revised in response to the assessment, and against what date?
- The conceptual architecture is marked "for reference only… not part of this GARB review" while the MVP's value is stated as being a foundation for it. Is target-state alignment in scope for any board?
- Is the Wealth dependency descoped if FCC does not commit above 25 TPS?
- Does the NFR table govern this system, or was it inherited? (See assessment finding C-09.)