R6.1 · Ship the single BFF, and write the trigger that ends it

Theme	R6 · Open decisions
Domain	Application and integration architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R3.1 — the boundary the chosen paradigm has to sit below · R5.1 — the runtime it runs in
Anchored in	The options deck's three-paradigm comparison, four topologies and five MVP concerns · the Confluence KDD it cites · readiness review concern 1 · the experience map's DEV estate
Open questions	Takes a position on 18; depends on 14 and 19
Deliverables	D2.1 · D3.1

Concern

The options deck compares three paradigms across seven axes, draws four topologies, lists five concerns about the MVP path — and recommends nothing outright. Meanwhile the MVP is already building one of the four.

Two of the four carry positions, and they point opposite ways. The micro-BFF topology records that "Confluence KDD explicitly recommends this pattern and cautions against a single centralised aggregation layer." The event-driven topology calls itself "best fit as a Phase-3 target, not an MVP." The pattern being built is the one the client's own design authority cautioned against, and nothing in the corpus records that as a decision anyone made.

Recommendation

Three rulings. The third is the one that matters.

1 · The single BFF carries MVP1. It exists — di-dashboard-services runs in DEV behind APIM with Redis, and the estate around it "already powers ~80% of the target UI." MVP1's fan-out is six read-only product tiles on one page for one consuming surface. That is the simplest aggregation problem the programme will ever have, and re-paradigming to solve it costs the date and buys nothing the MVP needs.

2 · Per-LOB micro-BFFs are the target state. Federated GraphQL is the option that opens after them, not instead of them. The event-driven path is out on the client's own evidence.

3 · The trigger that ends the single BFF is a numeric condition written into D2.1, not a date.

Why not go straight to micro-BFFs

The cost lands before the benefit. Micro-BFFs buy per-LOB release independence, and MVP1 has one consuming surface and no per-LOB release to be independent of — servicing stays in the business-unit portals. Six BFFs for one consumer is six pipelines, six on-call rotations and six APIM products, added to a programme whose executive review already counts eleven new components "with no shared platform team funded to run them."

Why micro-BFFs and not federated GraphQL

The deck's own table gives federation one decisive advantage: cross-BU insight, "one federated Customer entity via @key". That is a Phase 2 and 3 product capability — customer linking, MDM, the unified relationship — and buying the router, schema registry and persisted-query infrastructure before the product needs the join is paying for the hard part first.

The order also matters. Per-LOB BFFs and per-LOB subgraphs are the same organisational move — each line of business owns its slice — differing in whether the join happens in a router or in the caller. Single BFF to micro-BFF to an optional supergraph is one organisational change, then one technology change. Single BFF straight to a federated graph is both at once, into a team topology the readiness review says is not funded.

Why the event-driven path is out

The client says so first: "best fit as a Phase-3 target, not an MVP." The product objection is sharper than the phasing one. The deck rates its risk High — "stale balances create compliance and trust exposure" — and a dashboard rendering account balances, claim status and coverage cannot be eventually consistent without a published freshness contract. The ADS NFR table carries availability, latency, throughput and recovery figures and no staleness figure at all.

Why the trigger is a condition, not a date

The deck's own mitigation offers both: "a written sunset date or explicit migration trigger (e.g., >2 LOBs blocked in a quarter)". Take the second. A date slips silently and costs nothing to move; a condition is observed by the people it is harming, which is what makes it fire.

Conway's Law is the stated cause, so the conditions have to be organisational. Latency, error rate and component count will all look healthy while the queue forms in front of the BFF team. Three that would not:

• more than two lines of business blocked on a BFF change in a quarter — the deck's own example
• any line of business unable to ship a change of its own without a BFF release
• BFF change lead time exceeding the slowest line of business's release cadence

What it changes

It settles open question 18 in both halves. The question asks for the composition pattern and the written trigger that changes it. Naming a paradigm without the trigger answers half of it and leaves the half the client's own deck asked for.

It is the cheapest architectural commitment in the engagement. The trigger is a paragraph in D2.1. Concern 2 of the options deck is the client's argument for writing it, already made, in their own document — and it is exactly the kind of commitment that is never made unless a target state document makes it.

It changes what D3.1 prices. One aggregation tier plus a conditional migration is a different plan from a re-platform, and a different plan again from a single BFF with no exit.

What we are not recommending

Rejecting federated GraphQL. It is deferred, not lost, and the migration order above keeps it reachable. What would bring it forward is a product requirement for cross-BU joins — which is Phase 2 and 3 scope, and open question 16 has not confirmed that scope is inside what we are documenting.

Re-opening the runtime. Which process serves composed data is R5.1's position, and it holds whichever paradigm wins.

Treating the trigger as a plan. A trigger fires; it does not schedule. The migration it starts needs a funded owner for the shared runtime either way, which is open question 14 and not this page's to close.

Dependencies and open questions

• Open question 18 — the composition pattern and its trigger. This page is the position; the ruling is the client's.
• Open question 19 — whether di-dashboard-services is the MVP's BFF. Ruling 1 assumes it is, or that the ADS's route-handler BFF replaces it; R5.1 argues which.
• Open question 14 — the accountable owner for the shared runtime. A single BFF with no named owner is the deck's Concern 2 without the mitigation.
• Who authored the Confluence KDD, and does it still stand? The deck cites it as cautioning against a single central aggregation layer. If it is live design-authority guidance, the MVP needs a recorded exception rather than silence, and this page supplies the terms.