Recommendations
Konrad's position on the Unified Portal architecture, one page per recommendation, grouped into six themes. Each page names a concern found in Manulife's own material, cites it, and says what we recommend doing instead.
The SOW makes this a deliverable rather than commentary. §7 assigns Konrad R/A for "Provide architecture POV and recommendations" as a line distinct from "Document target state architecture", and WS 2's objective states that the work stream "will incorporate Konrad's perspective and recommendations."
Read O4 before presenting any of these. Canada Segment EA's target architecture draft arrived after all 22 were written. Its v2 adopts three, contradicts five — R1.1, R1.3, R5.5, R6.1 and R6.3 — and removes the premise of three. It also replaces the gateway, edge, token-exchange, session-store, CI/CD and observability rows of the R5 stack table below, and omits its design-system, content and feature-flag rows. Statuses are unchanged until each page is revised or re-argued.
Manulife has since ruled on one contradiction. MDM is the enterprise relationship registry, and ECID is rel_id (ADR-0006). R5.5 is withdrawn, and R1.3 is revised so that its ownership event lands in MDM.
For the Informatica technical-lead session, use the MDM system-of-record meeting brief. MDM's authority is now decided, so what remains of the brief is its product-fit gate and the target architecture's event-fed operational read model.
Themes
A theme is a decision area, not a document index. Each one is a coherent research assignment, a coherent working session, and — for the offsite — one slide instead of six.
| Theme | The question it answers | Recommendations |
|---|---|---|
| R1 · Identity and authorization | Who is a request for, what do they hold, and which system decides? | R1.1 · R1.2 · R1.3 |
| R2 · Resilience and capacity | Can the composed path carry the load, and what happens when it cannot? | R2.1 · R2.2 · R2.3 · R2.4 |
| R3 · Composition and channel | Where does composition happen, and which channels does it serve? | R3.1 · R3.2 |
| R4 · API mediation | What must the enterprise mediation layer enforce, and where does its boundary sit? | R4.1 · R4.2 · R4.3 |
| R5 · Technology stack | What is the target state built out of, and which of the MVP's technology choices carry into it? | R5.1 · R5.2 · R5.3 · R5.4 · R5.5 |
| R6 · Open decisions | Of the choices the client has already put options against, which one should they take? | R6.1 · R6.2 · R6.3 · R6.4 · R6.5 |
R1, R2 and R3 resolve at one architectural seam — the boundary below the web shell. That is the through-line of the first three recommendations and the reason they arrived first: each changes the shape of the architecture rather than its detail. R4 is a different altitude. It is the enterprise API layer the client asked us to review, it has a different owner and a different audience, and its three recommendations each reinforce one of the first three from one tier down. R5 is the floor under all of them. The first four argue about boundaries; R5 argues about the product selections and fit tests those boundaries are drawn in, which are decidable earlier and by fewer people. R6 is a different axis entirely. R1 to R5 are organised by subject matter; R6 is organised by the state of the decision. Its five entries are the places where Manulife has already published the options and not chosen between them, which makes them the only recommendations in this register that answer a question the client asked out loud.
R1 · Identity and authorization
Aggregating the dashboard moved the authorization decision out of the product portals and into a new component, and the design says it did not.
The contradiction is internal to one document, before any reviewer is involved. The ADS asserts "No change to authorization for the MVP" (p. 11); its authentication table on the same pages gives both new hops identity type Service Principal, while the legacy SSO hop to the product portals keeps Authenticated Customer Identity. The segment assessment rates that a blocker (B-01) and sizes it at 1,435,783 customer logins a month, 3,309,891 with mobile (L-05); the experience map shows it already built — on the PROD path di-dashboard-services strips x-federated-id, and gb-core-authx token exchange is unimplemented with memberId hardcoded.
| # | Recommendation | Anchored in | Status |
|---|---|---|---|
| R1.1 | Launch BU applications through one CIAM SSO | ADS OIDC + PKCE and existing SSO hop · B-01 as the scope guardrail | Proposed |
| R1.2 | Source enterprise visibility from PingAuthorize | B-01, B-02, K-10 · readiness review cancellation list | Proposed |
| R1.3 | Derive product ownership from a business-unit event, not from the customer | B-02, K-10 · strategy workstream 03 · the UCL deck's BU questionnaire | Proposed (revised for ADR-0006) |
The three are one argument from three ends. R1.1 keeps the first release navigation-first: the portal launches each independently secured BU application through the shared CIAM SSO session under one token contract. R1.2 makes PingAuthorize the source of the dashboard's enterprise visibility decision while BU applications retain action authorization; R1.3 gives that decision a verified input the customer did not type. MDM is the enterprise relationship registry (ADR-0006): it issues rel_id and masters accepted relationships. CIAM authenticates, and PingAuthorize uses the trusted context.
All three demote the BU Mapping table — from a disclosure control to a navigation projection, and from a form customers fill in to a view supplied from verified BU events and resolution outcomes. None substitutes for another: with only R1.1 the customer gets one-login handoff but the portal still chooses links from a hand-built table; with only R1.2 the visibility decision improves but protected aggregation still cannot use service-principal fan-out; with only R1.3 the ownership record is accurate and still load-bearing. They are separate pages because they have different counterparties — R1.1 is an OIDC client and session contract across BU applications, R1.2 is one conversation with the Canada Digital Identity platform team, and R1.3 is six conversations about what each business unit can emit, each terminating at MDM.
Research thread. OIDC Authorization Code + PKCE for every independently launched BU application; one CIAM browser SSO session; one enterprise token contract with client- and audience-specific tokens; PingAuthorize for enterprise visibility at the BFF; resource- and action-level authorization inside each BU. RFC 8693 remains the later aggregation pattern if protected BU data returns to the portal surface. On entitlement the same shape holds: a policy administration, distribution and per-audience decision path is already registered in PROD on the Canada Digital Identity platform, and nothing in the corpus connects it to the dashboard. On ownership the shape is different and worth naming as such: event-sourced product association, the provisioning-versus-resolution split, both inside MDM as the relationship registry, and what a business unit can assert at enrolment. There the client has written the question — "what is the earliest system-confirmed signal that a product is owned, and can you emit it?" — and holds none of the answers.
R2 · Resilience and capacity
The MVP replaces the only post-login route to every business-unit portal and specifies no way for that route to fail partially, against a committed availability the dependency model cannot reach.
| # | Recommendation | Anchored in | Status |
|---|---|---|---|
| R2.1 | The dashboard must degrade, not fail | D-01, D-03, D-04, D-06, L-03 | Proposed |
| R2.2 | Publish an availability and latency budget derived from the dependency model | C-01, C-09 | Proposed |
| R2.3 | Keep the legacy route alive behind a written cutover gate | D-01 · readiness review | Proposed |
| R2.4 | Plan to the documented capacity ceiling | C-02, L-03, L-04, L-06 | Proposed |
The four are one argument at four decision points. R2.1 is the contract, R2.2 is the number it is measured against, R2.3 is what covers a failure of the new surface itself, and R2.4 is the downstream ceiling all three have to survive. They are separate pages because each has a different owner and a different decision date — the contract belongs to the solution architecture team, the budget to whoever signs the NFR catalogue, the bypass to the programme sponsor, and the capacity assumption to WS 3's estimate. Argued as one page they are traded as one package, and the cheapest of them is the first to go.
Research thread. Bulkheads, per-dependency deadline budgets, circuit breakers and error boundaries as the standard shape for a composed front door; availability budgets derived from a dependency model rather than inherited; planning assumptions as a substitute for absent volumetry. The blocking input is volumetry — open question 24 — which R2.4 argues should stop being blocking.
R3 · Composition and channel
The programme exists to reduce channel fragmentation. On current scope it unifies the smaller half of the customer base first, because the composition technology is browser-native.
| # | Recommendation | Anchored in | Status |
|---|---|---|---|
| R3.1 | Put the composition boundary below the web shell | L-01, L-02 | Proposed |
| R3.2 | Put server-driven UI on the loading-mechanism decision, and price it as a Path B commitment | L-01, L-02, table L.2 · ADS composition KDD, pending LARB | Proposed |
Research thread. Channel-agnostic experience APIs with thin per-channel clients; token-shaped rather than cookie-shaped session contracts; micro-frontends as a web rendering choice rather than an architecture's composition model; server-driven UI as the rendering contract that crosses the channel boundary, and what delegated identity it costs to cross it.
R4 · API mediation
Client-requested, and the newest material in the corpus. The API Mediation proposal is the only artifact that states an enterprise position on API architecture — everything else describes one programme's integration needs. Our review is D2.5; these three recommendations are its positions.
| # | Recommendation | Anchored in | Reinforces | Status |
|---|---|---|---|---|
| R4.1 | Make the mediation layer govern the fan-out, not just observe it | C-01, C-02, D-01, D-03, D-06, L-03, L-04 · slide 5 capability legend | R2.1 | Proposed |
| R4.2 | The mediation layer must carry data protection, not only transport | A-02, E-01, domain G · ADS residency NFR · slides 4 and 5 | R1.1 | Proposed |
| R4.3 | Make the dashboard critical path the first mediation domain | API landscape (~4,200 operations) · experience map (42 APIs) · slides 3 and 4 | R3.1 | Proposed |
Token exchange is not on the launch-first path. R1.1 uses front-channel OIDC SSO for MVP1 and keeps protected BU data inside the launched application. If aggregation returns, the proposal's mandatory JWT Exchange capability becomes relevant and R4 must settle where that boundary sits. That remains open question 29's to resolve.
Research thread. Two-tier mediation — enterprise gateway plus per-LOB service mesh; strangler sequencing and coexistence for a live gateway estate; retry budgets and load-shedding across composed tiers; centralised redaction and classification tagging at a policy enforcement point.
R5 · Technology stack
The stack is specified in one document, contradicted in two, and unspecified in the two places that decide whether it holds. This theme states it in one table and argues the four entries that should change.
The stack, as the material names it
From the ADS technology table unless another source is named. Carry forward means we found nothing that warrants reopening it and the target state should record it as a constraint — not that we have tested it.
| Layer | Named in the material | Position |
|---|---|---|
| Web shell | Next.js — SSR, routing, API routes; React for the UI | Carry forward |
| Micro-frontends | Per-BU MFEs. Loading mechanism unnamed; the composition KDD is pending LARB | Gap — R5.3 |
| Design system | MUX as a Canada Segment library on the GDS core. KDD pending LARB | Carry forward; the version contract is R5.3's |
| Experience tier (BFF) | ADS: Next.js route handlers, Node.js · estate: di-dashboard-services, Fastify, registered in APIM DEV (experience map, options deck) | Contested — R5.1 |
| Aggregation | Integration API — channel-agnostic fan-out to BU Data APIs | Carry forward; its boundary is R3.1's and its governance R4.1's |
| API style | REST across the APIM estate. Federated GraphQL sits on the options deck's comparison as the named alternative | REST carries the MVP; what would change it is Q18, not an R5 position |
| Gateway | Azure APIM, hub and spoke — PIE-APIM (2,889 operations) and GB-APIM (1,311), per the API landscape | Carry forward; the Inter mediation layer's relationship to it is Q30 and R4.3 |
| Edge | Akamai for CDN, WAF, DDoS and bot protection, then F5 GTM and Azure Application Gateway | Carry forward |
| Identity provider | ForgeRock CIAM, OIDC authorization code with PKCE. "Existing… No Change" | Settled — record it as a constraint. R5.2 |
| Relationship registry | Informatica MDM issues rel_id and masters accepted relationships; ForgeRock IDM is the event-fed ECR replica; the BU Mapping Service is registered in the estate | Decided by Manulife — ADR-0006. R5.5 is withdrawn |
| Token exchange | gb-core-authx, an RFC 8693 service in Group Benefits. JWT Exchange is mandatory in the mediation proposal | Retain for later delegated aggregation — R5.2; R1.1 keeps it off the launch-first path |
| Authorization | MVP: nothing new — the BU Mapping Service supplies mapping and enforcement stays in the product portals. Target: PingAuthorize decides enterprise visibility, the BFF enforces it, and launched BU applications and APIs retain object- and action-level authorization | Confirm the boundary — R5.2; the enterprise visibility contract is R1.2's |
| Consent | OneTrust as system of record; a v3 preferences and consent API already in PROD | Out of MVP scope; named for completeness |
| Session store | CosmosDB, MongoDB API | Carry forward — and it is a customer data store, per finding A-02 |
| Cache | Azure Managed Redis, short-TTL per downstream, envelope encryption with AES-256-GCM DEKs under Key Vault KEKs | Carry forward — finding D-03 limits what may be claimed for it |
| Content | Adobe Experience Manager content fragments | Carry forward |
| Feature flags | Unleash — not yet wired into the BFF (experience map) | Carry forward |
| Runtime and infrastructure | Azure, AKS, Terraform, Cloud Catalog | Carry forward |
| CI/CD | WAVE, GitHub Actions | Carry forward |
| Observability | New Relic, PromStack, ADX | Gap — R5.4 |
Five entries are not carried forward, and none of them is a procurement.
| # | Recommendation | Anchored in | Reinforces | Status |
|---|---|---|---|---|
| R5.1 | Run the Dashboard BFF as a standalone service, not the shell's route handlers | ADS stack table · experience map runtime section · options deck topology · D-06 | R3.1 | Proposed |
| R5.2 | Fix one CIAM SSO and one token contract as the identity stack | ADS security section · June 2026 strategy · mediation proposal · API landscape | R1.1 · R1.2 | Proposed |
| R5.3 | Specify how a micro-frontend is loaded, and make independent deployability the test | ADS stack table and both pending KDDs · options deck concerns 1 and 2 | R3.1 | Proposed |
| R5.4 | One trace context across the composed path | ADS observability row · C-01, F-04, conditions 4 and 7 · stripped x-federated-id | R2.2 · R4.1 | Proposed |
| R5.5 | Assess PingIDM as the enterprise relationship registry implementation | ForgeRock IDM and BU Mapping registrations · June strategy relationship graph · UCL customer identifiers | R1.3 | Withdrawn (ADR-0006) |
Two are selections and two are specifications. R5.1 and R5.2 choose between things that already exist — two BFF runtimes, several names for one identity stack. R5.3 and R5.4 specify how a remote is loaded and what trace identifier crosses the fan-out. R5.5 was a product-fit assessment of PingIDM as the relationship registry. It was withdrawn when Manulife gave the role to MDM.
Nothing here recommends buying anything. The positions select, promote, specify or test capabilities already named in the estate; one adds a trace collector. That is deliberate: a stack recommendation that arrives as a procurement is a different conversation with a different sponsor.
Research thread. Runtime module composition — Module Federation, multi-zone routing — against build-time packaging, and the independent-deployability tests that separate them; design-system singletons across independently released remotes; RFC 8693 exchange as a shared platform component rather than a per-domain build; PDP and PEP placement in a two-tier mediation estate; W3C Trace Context and OpenTelemetry propagation across a managed gateway that terminates by default.
R6 · Open decisions
Manulife has published the options for five architectural choices and closed none of them. Two decks compare alternatives and recommend nothing; two key design decisions recommend an option and sit pending a board while the build proceeds against them; one capability is marked optional at a layer where its presence decides whether a component exists.
| # | Recommendation | The options, as the client framed them | Where they were framed | Status |
|---|---|---|---|---|
| R6.1 | Ship the single BFF, and write the trigger that ends it | Single BFF · per-LOB micro-BFFs · federated GraphQL · DDD and event-driven | Options deck — seven axes, four topologies, "recommends nothing outright" | Proposed |
| R6.2 | Centralize the contract, federate the implementation | Centralized vs federated API management | Mediation proposal slide 3 — fourteen rows, no recommendation | Proposed |
| R6.3 | The mediation layer mediates; it does not orchestrate | Orchestration at the Inter layer — marked optional | Mediation proposal slide 5 capability legend | Proposed |
| R6.4 | Approve the micro-frontend pattern; do not build seven of them for MVP1 | Hybrid shell and MFE vs single-application fallback | ADS KDD — Option C recommended, pending LARB | Proposed |
| R6.5 | The design system is a shared runtime dependency, and nobody owns it | MUX vs GDS vs a blended Canada layer | ADS KDD — Option C recommended, pending LARB | Proposed |
This theme is organised by the state of the decision, not by its subject. R1 to R5 each take a domain and argue it. R6 takes the five places where the client has already done the comparison and stopped one step short, and supplies the step. That makes it the cheapest theme to agree and the most expensive to keep deferring: every entry has a client-authored options list behind it, so the conversation starts at which rather than at whether there is a choice to make.
Four of the five close in two conversations. R6.2 and R6.3 are one meeting with the mediation proposal's co-author — the register already groups open questions 29 to 31 and 37 that way. R6.4 and R6.5 are one LARB submission. R6.1 is the only entry whose ruling is ours to make rather than the client's, and it is the one the other four have to be consistent with.
Two of them argue for less, not more. R6.4 removes six components from MVP1 and R6.3 removes a capability from an enterprise reference architecture. Against a programme whose own executive review counts eleven new components with no funded platform team, a recommendation that subtracts is worth more than one that specifies.
What R6 does not do is close anything. Four of the five are the client's ruling to make, and the fifth still needs their agreement that it is ours. The open decisions register stays the system of record; these are the positions it is ruled against.
Research thread. Migration triggers and sunset conditions as architectural commitments rather than roadmap items; the federated-versus-centralized split expressed as contract against implementation; gateway-hosted orchestration as the ESB failure mode and the coexistence patterns that avoid it; independent deployability as the admission test for micro-frontends; design systems as distributed shared dependencies, with supported-version windows and fork-with-deprecation rules.
The register
Finding IDs belong to Canada Segment Architecture's pre-ARB assessment. Every recommendation rests on at least one finding the client's own architecture function rated BLOCKER, or — for R4, R5 and R6 — on the client's own material: the enterprise mediation proposal, two key design decisions still pending LARB, one options deck that compares four paradigms and picks none, and one component that two of their documents describe differently. The concern is theirs, the position is ours. That is deliberate: a recommendation built on a defect we assert and they dispute starts the conversation in the wrong place.
| # | Recommendation | Theme | Domain | Status |
|---|---|---|---|---|
| R1.1 | Launch BU applications through one CIAM SSO | R1 | Identity and access | Proposed |
| R1.2 | Source enterprise visibility from PingAuthorize | R1 | Identity and access | Proposed |
| R1.3 | Derive product ownership from a business-unit event, not from the customer | R1 | Identity and access | Proposed (revised for ADR-0006) |
| R2.1 | The dashboard must degrade, not fail | R2 | Infrastructure, integration | Proposed |
| R2.2 | Publish an availability and latency budget derived from the dependency model | R2 | Infrastructure, integration | Proposed |
| R2.3 | Keep the legacy route alive behind a written cutover gate | R2 | Infrastructure, integration | Proposed |
| R2.4 | Plan to the documented capacity ceiling | R2 | Infrastructure, integration | Proposed |
| R3.1 | Put the composition boundary below the web shell | R3 | Portal, application | Proposed |
| R3.2 | Put server-driven UI on the loading-mechanism decision, and price it as a Path B commitment | R3 | Portal, application | Proposed |
| R4.1 | Make the mediation layer govern the fan-out, not just observe it | R4 | Integration and API | Proposed |
| R4.2 | The mediation layer must carry data protection, not only transport | R4 | Security, data | Proposed |
| R4.3 | Make the dashboard critical path the first mediation domain | R4 | Integration and API | Proposed |
| R5.1 | Run the Dashboard BFF as a standalone service, not the shell's route handlers | R5 | Application and platform | Proposed |
| R5.2 | Fix one CIAM SSO and one token contract as the identity stack | R5 | Identity and access | Proposed |
| R5.3 | Specify how a micro-frontend is loaded, and make independent deployability the test | R5 | Portal, application | Proposed |
| R5.4 | One trace context across the composed path | R5 | Infrastructure, operations | Proposed |
| R5.5 | Assess PingIDM as the enterprise relationship registry implementation | R5 | Identity and access | Withdrawn (ADR-0006) |
| R6.1 | Ship the single BFF, and write the trigger that ends it | R6 | Application, integration | Proposed |
| R6.2 | Centralize the contract, federate the implementation | R6 | Integration and API | Proposed |
| R6.3 | The mediation layer mediates; it does not orchestrate | R6 | Integration and API | Proposed |
| R6.4 | Approve the micro-frontend pattern; do not build seven of them for MVP1 | R6 | Portal, application | Proposed |
| R6.5 | The design system is a shared runtime dependency, and nobody owns it | R6 | Portal, platform | Proposed |
Nothing here has been validated with Manulife. These are positions to be argued in the WS 2 working sessions, not conclusions. Status stays Proposed until it is. The one ruling so far, ADR-0006, withdrew R5.5 rather than accepting anything.
What a recommendation is, and is not
Five registers run in parallel in this repository, and blurring them is how a knowledge base stops being useful:
| Register | Answers | Written when |
|---|---|---|
| Client resources | What did the client say? | On reading the material |
| Open questions | What is unresolved? | When a gap is found |
| Recommendations | What should happen, and why? | When we have a defensible position |
| Decision log | What did we commit to, and what lost? | When the position is accepted |
| D2.1 target state | What is the target state? | Once decided |
A recommendation argues; an ADR records. The recommendation carries the evidentiary case — the concern, quoted, with finding IDs — because that is what an executive readout needs and what would bury an ADR's Context section. Rejected options get a sentence each here; the full alternatives table waits for the ADR that follows acceptance.
A recommendation does not close an open question. Items in the open decisions register stay Open until Manulife rules on them, and several of these recommendations exist precisely to give them something to rule on.
Conventions
- Filename
NNNN-kebab-case-title.md, numbered sequentially, never renumbered or reused. Cited in prose as R1.1 … R4.3. The filename number is the creation order and does not track the theme number; a recommendation added to an existing theme takes the next free filename and the next free suffix within its theme. - Every page declares its theme in the front table, and the theme table above is the index. A recommendation belongs to exactly one theme; where it bears on another, the front table names it under Reinforces rather than claiming two homes.
- Themes are added, not split. Renumbering a theme breaks every citation in the deck and the deliverables. A concern that fits none of the four is a fifth theme.
- Every page opens with the concern, and the concern is cited. A recommendation whose problem statement rests on our assertion rather than a source is an opinion, and the SOW did not engage us for those.
- Status is
Proposed,Accepted (ADR NNNN),Superseded by RNNNN, orWithdrawn. A recommendation is never deleted — the reasoning trail is the point. - One position per page. A theme can be large; R4 holds three. "And also" within a page means two recommendations.
- Stop at the architecture. SOW Schedule "A" §3.0 puts implementation-level solution design — API and integration specifications, data models, schemas, infrastructure configuration — out of scope. These pages recommend a pattern, a boundary and a control. They do not specify an endpoint.
What comes next
R1 and R3 started at one recommendation each because the first three were chosen for structural weight, not for coverage; R2 now holds four because splitting it separated four decisions that were being argued as one. R5 is the first theme whose unit is a product rather than a boundary — the stack table is the part of it that will date fastest, and it should be re-read against any ADS re-issue. R6 arrived last and is the first theme whose unit is a client-published options list, which also bounds it: it can only grow when Manulife frames another choice, or when a choice we currently carry elsewhere turns out to have options already written down.
One candidate for R6 was deliberately left out. The application criticality tier — Gold versus Critical Digital Properties — is the clearest two-option decision in the corpus, stated in conflict by two client documents, with roughly an order of magnitude between the recovery commitments each implies. It sits in the register as open question 13 under programme and governance rather than architecture, and it is a tier assignment rather than an architectural choice. It belongs to the seventh theme below, and it is the strongest argument for opening it.
More arrive as WS 2 works through the domains in D2.1; the candidate list is the ADR table in the WS 2 task notes. Cache design and classification lands in R2, and MVP forward-compatibility in R3.
The seventh theme is commitments. The NFR table's provenance beyond availability and latency — throughput, residency, accessibility, bilingual — plus the criticality tier and the recovery objectives measured against it. Those are not resilience concerns, so R2 is the wrong home and R2.2 only covers this theme's share of the defect; and a commitment is not a component, so R5 is the wrong home too.