The Architecture Decision — options comparison

Source	client-resources/Unified Customer Experience — The Architecture Decision.pdf
Type	PDF, 12 pages, executive deck
Origin	Canadian Enterprise Architecture
Dated	August 2026
Subtitle	Comparing BFF, Federated GraphQL and Event-Driven paths for Workstream 2

What it is

The options paper. It frames the architectural choice for the experience layer as three paradigms, compares them on seven axes, then lists what the authors are worried about. It recommends nothing outright, which is unusual and useful — it is the clearest articulation of the trade-off space we have.

The framing

It opens with the customer: someone with a mortgage, a policy, a benefits plan and a segregated fund holds four relationships with one company — four logins, four portals, four visual languages, and nowhere that says here is everything you have with us.

Then it names the bet WS 2 is making, in the client's own words: that Manulife can prove in production one authenticated shell, aggregating every line of business, behind an integration layer, governed by one identity the customer already trusts. "If this proof works, every future digital experience at Manulife Canada gets faster and cheaper. If it doesn't, we ship another portal."

The problem is Conway's Law

The deck is explicit that this is an organisational problem wearing an architectural costume. Marketing wants one cohesive experience on the glass; the company is organised as six autonomous lines of business with their own roadmaps, stacks, security postures and release cadences. It names four fragmentations — on the glass, in the backend, in delivery, and in governance — and poses the question directly: how do we unify the UI without creating a backend monolith, or a governance one?

Eight dimensions are called out as things the transformation will change regardless of MVP scope: team topologies, domain boundaries, federated governance, CIAM's shrinking scope, BU API volumes, legal and privacy, security posture, and brand and design. "None of these are optional. The MVP scope may be narrow — the transformation surface is not."

The three options

Axis	BFF (REST / gateway)	Federated GraphQL	CQRS + materialized view
Latency	Low on cache hit; on miss bounded by slowest LOB	Low/moderate — router planning hop ~10–30 ms, then parallel resolution	Very low and flat — reads hit a denormalized projection
Risk	Low — reads from source, Redis as safety net	Low/moderate — typed contracts; N+1 and query complexity	High — stale balances create compliance and trust exposure
BU autonomy	Very high — teams own the vertical slice	High — each LOB owns a subgraph	Moderate — producers independent, coupled at the read model
Cost	Moderate — six BFFs plus APIM products	Moderate/high — router, schema registry, persisted queries	Very high — Kafka/Event Hubs, projections, replay, DLQ
Resilience	Moderate/high — last-good cached view within TTL	Graceful — nullable fields and @defer	Excellent — upstream outages invisible
Cross-BU insight	Hard — aggregation lives in the UI	Natural — one federated Customer entity via @key	Excellent — the projection is the unified view

Four topologies are drawn: a single BFF (di-dashboard-services, Fastify, behind APIM with Redis), the GWAM North Star micro-BFF pattern (per-LOB BFFs, shared APIM/CIAM/flags/design system), federated GraphQL (per-LOB subgraphs behind a supergraph router), and DDD + event-driven (LOB producers, event bus, projectors, a Customer-360 projection and query API).

Two of those carry explicit positions. The micro-BFF page records that "Confluence KDD explicitly recommends this pattern and cautions against a single centralised aggregation layer." The event-driven page calls itself "best fit as a Phase-3 target, not an MVP."

Five concerns about the MVP path

Offered as "opinions about the MVP, not facts — but informed opinions", each with a mitigation:

1. Blast radius. One bad BFF release breaks all six LOBs for all customers. Architecturally unavoidable in the single-BFF pattern. → canary and flags, per-LOB circuit breakers, contract tests, a rollback SLO under five minutes.
2. Organizational scaling. Conway's Law will strangle velocity around LOB #4; the BFF team becomes the queue for six roadmaps. → the MVP must ship with a written sunset date or explicit migration trigger to per-LOB BFFs or federated GraphQL.
3. Latency under partial degradation. Without parallel fan-out and per-LOB breakers, homepage P95 is dictated by the worst LOB. → Promise.all fan-out with hard per-LOB deadlines, hedged reads, tile-level skeletons.
4. PII aggregation and Tier-0 classification. The BFF's posture must match the sum of LOB postures, not the average. → Tier-0 threat model up front, per-LOB token scoping, no PII in telemetry, joint Privacy/Security/CISO sign-off before GA.
5. LOB backend capacity. Fan-out will expose iFast and GB throughput limits nobody sized for. → signed per-LOB load projections, backpressure and concurrency caps, short-TTL edge caching.

A final page lists the non-architectural workstreams the transformation will stand or fall on: LOB API impact, legal and privacy, security risk surface, test strategy, BC/DR, operating model and team topology, cost and funding model, and change management and brand.

Why it matters here

This is the closest thing in the material to the SOW's "architectural decisions, trade-offs, dependencies, constraints" deliverable, already half-written by the client. Our WS 2 job is not to redo it — it is to resolve it: take a position, record the alternatives and why they lost, and make the recommendation defensible in an executive readout.

Concern 2 deserves particular attention. A sunset date or migration trigger for the single-BFF pattern is a concrete, cheap, high-leverage architectural commitment, and it is exactly the kind of thing that never gets made unless someone writes it into a target state document.

Open questions raised

• Which of the three paradigms is the engagement expected to land on — or is that our call?
• The deck cites a Confluence KDD recommending per-LOB BFFs and cautioning against a single central aggregation layer; the MVP builds the thing it cautions against. Was that decision made knowingly, and by whom?
• Is di-dashboard-services (Fastify) the same component the ADS calls the Next.js Dashboard BFF? See the experience map, which documents it running in DEV.
• What is the sunset date or migration trigger for the MVP aggregation layer?