R6.4 · Approve the micro-frontend pattern; do not build seven of them for MVP1

Theme	R6 · Open decisions
Domain	Portal and application architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R5.3 — this is its independent-deployability test applied to MVP1 scope · R3.1 — the clause of Option C that carries mobile
Anchored in	The ADS's Frontend Composition Strategy KDD, recommended Option C and pending LARB · readiness review concern 1 · assessment domain F
Open questions	Takes a position on 38; constrains 34; depends on 14
Deliverables	D2.1 · D3.1

Concern

The ADS records Frontend Composition Strategy as a key design decision, recommends Option C — "Hybrid (Shell + MFE for web, thin native for mobile, shared Integration APIs)" — and marks it pending LARB approval while the build proceeds. Its own stated fallback is a condition: "Single-application fallback remains viable if teams stay small and mobile is deferred."

The decision is being carried at two altitudes at once. Option C is a target-state pattern; what is being built against it is seven micro-frontends in MVP1. The readiness review's first executive concern counts eleven new components — four platform plus seven business-unit micro-frontends — "with no shared platform team funded to run them." Seven of the eleven come from this one decision, and the board that would approve it has not.

Recommendation

Approve the hybrid pattern as the target state. Scope MVP1 to the shell plus a tile contract, and promote a business unit to its own micro-frontend when it has something to deploy independently.

The KDD couples two decisions that are independent

Option C's fallback condition fails on mobile — 56.6% of authentications are mobile and the strategy does not defer it — which reads as settling the question. It does not. Nothing about rendering the web tier as seven remotes makes mobile work. Mobile works because composition sits below the web shell and serves a channel-agnostic API, which is R3.1's position and the "shared Integration APIs" clause of Option C itself.

Option C's mobile argument is carried entirely by its third clause, and the micro-frontend clause is along for the ride. Separate them and the web-composition question has to be argued on its own merits.

On its own merits, MVP1 does not have them yet

Micro-frontends buy independent deployability. MVP1's tiles are read-only renderings of a fan-out whose cadence is the BFF's: the MVP "replaces the current Product Selection Home Page" and nothing else, and servicing stays in the business-unit portals. A tile that cannot change without the BFF changing cannot deploy independently of it, so the pattern's one benefit is unavailable while its costs arrive in full — seven pipelines, seven release trains, seven sets of runtime dependencies on one design system (R6.5).

R5.3 makes independent deployability the test for this pattern. This page is what applying that test to MVP1's actual scope returns.

Build the seam, not the seven applications

The risk of deferring is the familiar one: the shell absorbs business-unit logic and the boundary never gets built. Three things prevent it, and all three together cost less than seven micro-frontends.

• A declared tile contract — data shape, degraded and error states (R2.1), design tokens, telemetry fields (R5.4).
• One business unit promoted to a real remote in MVP1, as a working proof of the loading mechanism rather than a diagram of it (open question 34).
• A written promotion criterion — a business unit gets its own micro-frontend when it has servicing functionality to ship on its own cadence.

This is also how the KDD gets approved

It has been pending LARB since before the build started, and the assessment's domain F names unapproved KDDs as a governance finding. A board asked to approve seven applications for a page of read-only tiles has a reason to keep deferring. A board asked to approve a pattern, a contract and one proof does not.

What it changes

It removes six components from MVP1's critical path without changing what the customer sees. Against an executive review whose first concern is component count with no funded platform team, that is the largest scope reduction available that costs no capability.

It splits the LARB submission in two — a target-state pattern and an MVP1 composition scope. That is the difference between a decision that can be approved this month and one that has been pending while the thing it governs was built.

It gives open question 34 a smaller first answer. The loading mechanism still needs a ruling, but it is chosen once for one proof rather than seven times under delivery pressure — which is how a mechanism gets chosen by whoever ships first.

What we are not recommending

Single-application as the target state. The pattern is right for six autonomous lines of business and we are not arguing against it. The disagreement is about when, not whether.

Deferring the shell. The shell, the session, the navigation and the channel-agnostic API are MVP1 work regardless. They are the parts mobile depends on, and they are four of the four platform components — none of the six this page removes.

Collapsing business-unit ownership of their tiles. A tile is still owned, reviewed and versioned by its business unit. Ownership is an organisational fact; independent deployment is a runtime one, and MVP1 only needs the first.

Dependencies and open questions

• Open question 38 — whether the two ADS key design decisions have been approved, and against what date. This page is a position on the composition one.
• Open question 34 — the loading mechanism. Still needs a ruling for the one promoted remote, and R5.3 is the position.
• Open question 14 — the accountable owner for the shared runtime. The shell and the tile contract need one more visibly than seven micro-frontends do, because they are the part every business unit shares.
• Is servicing functionality in MVP1 scope for any business unit? If one is shipping servicing, that unit is the promotion candidate and this page supplies its criterion rather than arguing against it. The material describes MVP1 as dashboard-only, but does not say so for every unit.