5 · Recommendations & Considerations
| Slide budget | 3 slides, 7 minutes, plus one appendix slide |
| Skeleton asks for | Recommendations made against the observations, with the benefits on the business side and on the technology side, sold through to Banking, Global WAM and Insurance |
| Assembled from | Recommendations R1–R5 — fourteen positions in five themes. R1 .1 .2 · R2 .1 .2 .3 .4 · R3 .1 · R4 .1 .2 .3 · R5 .1 .2 .3 .4 · open questions |
| Status | 🟡 Outline — slides not built |
The line the section has to land
Five themes, not fourteen recommendations. Three of them are one architectural seam seen three times; the fourth is the layer underneath, and it is the client's own proposal; the fifth is the product selections all four are drawn in.
Fourteen recommendations in seven minutes is a list. Five themes is an argument, and it is the unit a line of business can take away and staff. Each theme is also a working-session agenda and a research thread — the detail lives in the knowledge base, not on the slide.
Status is Proposed on all fourteen. These are positions to argue in the WS 2 working sessions, and the ruling is Manulife's.
Slide 5.1 — Five themes
Claim: identity, resilience and channel are the same decision seen three times. API mediation is that decision one tier down, in the client's own words. Technology stack is the floor all four are built on — and three of its four positions promote something Manulife already runs.
| Theme | The question | Recommendations | Answers observation |
|---|---|---|---|
| R1 · Identity and authorization | Who is a request for, and which system decides? | R1.1 — launch each BU application through one CIAM SSO; one token contract, not one shared bearer | 2 — authorization relocated |
| R2 · Resilience and capacity | Can the composed path carry the load, and what happens when it cannot? | R2.1 — render with N of seven business units available, by design, against a budget that is derived rather than inherited (R2.2) | 3 — availability arithmetic |
| R3 · Composition and channel | Where does composition happen, and which channels does it serve? | R3.1 — the shell renders; it does not compose | 4 — the mobile majority |
| R4 · API mediation | What must the enterprise layer enforce, and where is its boundary? | R4.1 govern the fan-out · R4.2 carry data protection · R4.3 dashboard first | 5 — the eighth artifact |
| R5 · Technology stack | What is the target state built out of, and which MVP choices carry into it? | R5.1 the BFF is a registered service, not routes inside the shell · R5.2 one named identity stack · R5.3 micro-frontends that release independently · R5.4 one trace across the fan-out | Carried items — two BFFs in one estate, and no owner for the shared runtime |
The visual. One diagram with the seam drawn across it, R1–R3 labelled where they land, and the mediation layer drawn beneath as the tier R4 governs. R5 does not add a region to that drawing — it labels the boxes. The stack is what the components are made of, and its four positions are four of those labels changing.
This is the slide that needs the target-state drawing, and it is the slide most worth the diagram budget. Until a registered client-safe diagram exists, it is a placeholder — see Our Progression.
The appendix slide. R5's full stack table — every layer, what the material names, and whether we carry it forward — is reference material, not an argument. It belongs behind the deck for the people who go looking, and on stage R5 is four decisions.
Speaker note. Anything above the seam is web-only by construction — that single sentence is why R1, R2 and R3 are one conversation and not three. R4 is a different conversation with a different owner: Enterprise Architecture's proposal, reviewed at their request, and its three positions each reinforce one of the first three from below. Say that, and the fourteen recommendations stop looking like a list of complaints.
R5 is the cheap theme, and it is worth saying so out loud. Three of its four positions promote a component already running in Manulife's estate rather than proposing a new one, and one of them — which of the two BFFs already described in the material is the BFF — is answerable by people who will be in the room. It is the theme that costs a decision rather than a programme, which makes it the right one to close the section on.
Slide 5.2 — What each theme buys, business and technology
The offsite's stated requirement: the benefit on the business side and the benefit on the technology side, in language each LOB can carry back.
| Theme | Business benefit | Technology benefit | What it costs |
|---|---|---|---|
| R1 | The customer signs in once, opens each BU application without another credential prompt, and the BU keeps enforcement over its own data | One CIAM SSO domain and one OIDC/OAuth contract; each launched BU application receives its own client- and audience-specific tokens rather than trusting a portal assertion | MVP1 becomes navigation-first, so less customer data appears on the shared dashboard; each BU app must align client registration, session, logout and step-up behaviour |
| R2 | A Group Benefits outage costs the Group Benefits tile, not the front door to every Canadian digital servicing journey | Bulkheads, per-BU deadline budgets and error boundaries; an availability budget derived from the dependency model instead of inherited | A product decision per failure mode — what the customer actually sees — and keeping the legacy Product Selection route alive behind a flag |
| R3 | The 56.6% of customers who authenticate on mobile are served by the same architecture rather than a second build. Bank's 82.9%-mobile population is the sharpest case | One experience layer, two channels; entitlement and degradation logic written once | A design conversation now about the session and composition contract; mobile enters the roadmap as a consumer |
| R4 | The portal ships without waiting on an enterprise programme, and becomes the proof the enterprise rollout needs rather than its dependent | One enforced ceiling on FCC instead of seven APIs defending themselves; redaction written once at a chokepoint rather than seven times; the existing gb-core-authx exchange pattern made standard | Three capabilities move from optional to mandatory, and the Inter/Intra boundary rule has to be written before the first API is onboarded |
| R5 | The target state is assembled from what Manulife already runs and already pays for — three of the four positions promote an existing component rather than adding one. A business unit can ship its own tile without waiting for a shell release | One BFF runtime instead of two descriptions of one; one identity product set instead of three vocabularies across four documents; micro-frontends that are independently deployable rather than libraries under a different name; one trace that survives the fan-out, without which the R2 budget cannot be attributed | Two key design decisions have to clear LARB, and trace propagation becomes a clause in six business units' API contracts |
Per-LOB framing, for the readout rather than the slide
- Banking — R3 is the argument that matters: the tile with the second-largest underlying population is currently delivered to the channel that population does not use.
- Global WAM — R2 and R4 together. The documented 25 TPS ceiling at FCC sits under the fan-out, and the mediation layer is where a limit protecting it would actually be enforced.
- Individual Insurance and Group Benefits — R1. Aggregated display is where the authorization boundary moved, and these are the products whose entitlement rules are least uniform. Group Benefits also owns both assets R4 leans on:
gb-core-authxand GB-APIM. - Enterprise Architecture — R4 is theirs. The proposal is their document, the review was requested, and R4.1–R4.3 are improvements to it rather than a verdict on it.
- Every line of business — R5.3. It is the only position that decides whether a business unit can release a change to its own tile without a shell release, which is the delivery-autonomy half of the business case and the thing Conway's Law takes away around line of business number four.
- Canada Digital Identity and Enterprise Technology Services — R5.2 and R5.4. Both are selections over components already registered in production, not proposals to build.
"What we've seen" — requested on the check-in draft, not yet written. A short industry thread per theme, drawn from Konrad's delivery experience: token exchange (RFC 8693) as the standard aggregation-tier pattern — already present in Manulife's own estate; graceful degradation with bulkheads and circuit breakers as table stakes for a composed front door; channel-agnostic experience APIs with thin per-channel clients; two-tier mediation proved on one domain before an estate-wide rollout; runtime module composition and the independent-deployability test that separates a micro-frontend from a library; W3C Trace Context carried through a managed gateway that terminates it by default. Two lines each, no client names. At 7 minutes the honest answer is narration, not a fourth slide.
Slide 5.3 — Considerations: what we need leadership to rule on
A recommendation does not close an open question. These are the rulings the target state waits on, and the reason this section ends by asking rather than telling.
| Decision | Owner named in the register | Theme | Our position |
|---|---|---|---|
| Which statement of target state is the North Star of record, and who owns it — Q8 | Chief Architect / R2R Design Authority | — | No position. The client's to rule, and the highest-leverage item on the list |
| Identity propagation vs service-principal fan-out with compensating controls — Q17 | Engagement Lead, ruled by Manulife | R1 | R1.1 sequences around the fork for MVP1: launch the BU app through OIDC SSO and keep protected data there; Q17 reopens if aggregation returns |
| Is the API Mediation proposal live, endorsed and funded, or superseded — Q29 | Chief Architect | R4 | No position — but all of R4 is conditional on the answer, and nothing written in eighteen months cites it |
| Does the Inter layer replace, front or rename PIE-APIM and GB-APIM — Q30 | Enterprise Technology Services | R4 | R4.3 — state it per gateway; the difference is a vocabulary or a multi-year migration of ~4,200 operations |
| Does the mediation layer orchestrate — Q31 | Chief Architect | R4 | R4.3 — rule before WS 3 prices the Integration API as target-state or interim |
| Does the legacy Product Selection page survive as a bypass, and for how long — Q22 | Programme sponsor | R2 | R2.3 argues yes, retired against a written gate rather than a date |
| Application criticality tier: Gold or Critical Digital Properties — Q13 | R2R Design Authority | R2 | No position — every RTO and RPO in the degradation design is measured against it, and the tiers differ by roughly an order of magnitude |
| Is MVP1 scope fixed at no ECID, MDM, consent or centralized authorization — Q12 | Programme sponsor | R1 | The R1.1 launch-first path fits only if MVP1 is navigation-first and protected BU data is not aggregated |
| Is converged experience inside the target state we document — Q16 | Programme sponsor | R3 | No position; it sets how far R3.1 reaches |
| Which of the two components described in your own material is the Dashboard BFF — Q19 | Unified Project delivery team | R5 | R5.1 — the standalone registered service. The alternative cannot be governed by the gateway or called by anything that is not a browser |
| How is a micro-frontend loaded, and what is the design system's version contract — Q34 | LARB / Unified Project delivery team | R5 | R5.3 — runtime remotes, with independent deployability as the acceptance test. Both KDDs are pending while the build proceeds |
The dependency we cannot work around: per-BU volumetry and a committed FCC capacity figure with a date — Q24. No degradation design survives contact with an undersized dependency, and no mandatory rate limit can be set to the right number without it. The per-tenant APIM limits that exist today are the fastest partial answer — Q27.
Speaker note. Eleven decisions is the honest number and far too many to ask for in a 30-minute offsite. Ask for three — Q8, Q17 and Q29 — and table the rest as the WS 2 working-session agenda, one session per theme. Q29 is the cheap one: it is a yes-or-no from someone who will be in the room, and it either activates R4 or retires it. Q19 is cheaper still and is not really an ask — it is a question to the delivery team that can be settled in the corridor, and settling it changes whether WS 3 prices a promotion or a build.
What this section must not do
- Present a recommendation as a decision. Status is Proposed on all fourteen. An audience that hears "decided" will ask who decided it, and the answer is nobody yet.
- Read out fourteen recommendations. Five themes, three asks. The recommendations are where the detail lives for the people who go looking; the slide is not that place.
- Turn R5 into a technology review. The stack table is appendix material and the room is not there to approve a list of products. On stage R5 is four decisions, three of which are promotions of things Manulife already runs.
- Grade the mediation proposal. It is the client's own document, reviewed at their request, and its two-tier shape is right. R4.1–R4.3 are three changes needed before it can carry the dashboard, not a verdict — and its mandatory JWT Exchange is the strongest client-side support R1 has.
- Drift into implementation. SOW Schedule "A" §3.0 puts API specifications, data models, schemas and infrastructure configuration out of scope. These recommend a pattern, a boundary and a control. They do not specify an endpoint.
- Argue R1 as a security finding alone. It is a design fork the client's own condition 02 already framed. Leading with the CVE-shaped version puts the delivery team on the defensive and loses the room.