BU deep-dive sessions · format and facilitation guide
| Work stream | WS 2 — Target State Architecture |
| SOW source | Schedule "A", WS 2 activity 6 — working sessions with lines of business IT and leadership |
| Feeds | D2.3 Stakeholder alignment summary |
| Audience | Each business unit's solution architects, 60 minutes (cut from 120) |
| Deck | deliverable/public/presentation-bu/index.html. Add ?bu=gb, retirement, wealth, bank, insurance or affinity to show that unit's playback slide; with no parameter it shows all six |
| Status | 🟡 Draft guide and deck — not yet run with any BU |
What the session is for
Validate what the target architecture asks of the BU against what is true in its estate. It is neither a requirements workshop nor a feasibility review.
- A requirements workshop invites wish lists. We are not asking what a BU wants from the portal.
- A feasibility review invites a design debate and a veto, in a room of people trained to solve. How to build token exchange at a BU gateway is a working session after ratification.
- What the session collects is feasibility facts: for each obligation, is it true today, true with change, not possible, or unknown, with an owner and a date. That is evidence the D2.1 §19 gates and fallbacks can use, and it involves no design.
The sessions approve nothing. Ratification belongs to the Design Authority (D2.1 §19, item 1). They produce attributed feedback, a readiness read per obligation and a list of what would change the architecture.
The client has already planned this step. The UCL deck shows validation with BU IT architects, VPs and CIOs as not yet done, and its BU discovery questionnaires are written for it. Present the sessions as that step, in that vocabulary.
Run of show
| Min | Block | What happens |
|---|---|---|
| 0–5 | Frame | Purpose, what this is not, the three status labels, the parking-lot rule |
| 5–15 | Our reading of your estate | APIs, auth model, feeds, UI, roadmap, played back for correction (the pattern of group-benefits-alignment-presentation.html) |
| 15–25 | The target in one pass | Six layers, the current state and MVP in a minute each, the evolution from the MVP, who is responsible for what, the enterprise and BU boundary, then the eight asks. Not eighteen sections |
| 25–55 | Four seams, 7 minutes each | The ask (1), what is true for you today (3), what would change the architecture or what you would need (3) |
| 55–60 | Read-back | Read each captured row aloud; confirm owner and date; state what happens next |
Sixty minutes does not hold a second pass, so two things move before the session. The pre-read carries the BU's playback page, so the room corrects it rather than hearing it. The pre-read also asks for the inputs in CR-22, CR-24 and CR-32. If the BU skips either, the seams shorten first: do not cut the read-back.
For Insurance and Affinity, discovery is pending, so the 10-minute playback becomes a 20-minute fact-finding block and the seams drop to five minutes each, or one moves to a follow-up.
The four seams
| Seam | The ask of the BU | D2.1 | Question to put |
|---|---|---|---|
| Authority and feeds | Supply an authoritative signal per profile facet: start, correction, termination, and freshness measured from your write | §8, §19 #5, #17 | "What is the earliest system-confirmed signal that a product is owned, and can you emit it?" · "Where could we accidentally show a product as ready when it is not?" · "Can the BU consume profile from a central source without local persistence, and if not, why?" (UCL deck, BU questionnaire) |
| Identity and record authorization | Validate the exchanged token, resolve a local subject, authorize the requested record; define proofing evidence; name staff and partner actors | §9, §17, §19 #6, #7, #8 | Can the API that serves your record do this today? If not, what stops it and by when? Which staff or partner users act on customer records, and through which identities? |
| Integration and mediation | Publish contracts through enterprise mediation; meet the admission criteria; state ceilings; prove private routes from both regions | §7, §19 #2, #11, #13 | What fronts your API today? What are its owner, spec, degraded mode, version window and documented ceiling, with what evidence? |
| Experience and ownership | Own the tile contract and content; accept portal rendering; run your content and exclusions; set onboarding order and legacy routes | §5, §6, §12, §13, §19 #3, #4, #14, #18, #20 | What UI release cadence do you need, and what would a queue on the portal team cost you? What would justify your own micro-frontend? |
The UCL deck's questionnaire covers five capabilities (slides 4–8). Only the three questions above are quoted in the knowledge base; pull the rest from the deck before the first session.
Parking-lot test. If the answer changes a boundary or responsibility, capture it. If it changes an implementation, park it.
Status labels
Every topic shown carries one label, so the room knows what is open to challenge.
| Label | Meaning | Examples |
|---|---|---|
| Baseline | Already decided by Manulife. Not reopened. | MDM issues rel_id (ADR-0006); ForgeRock CIAM, the Next.js shell and Redis carried from MVP1; "enterprise coarse, BU fine" (UCL deck) |
| Proposed | Our position, with rejected alternatives in D2.1 §17. Challenge it with evidence. | Web and Mobile BFFs; portal-rendered tiles; D3 and the Profile API as the read path; token exchange with BU final authorization; MuleSoft mediation; D4; active-active |
| Open | A D2.1 §19 item. We need an answer or evidence, and a fallback already exists. | All twenty §19 items |
Readiness scale and capture format
| Readiness | Meaning |
|---|---|
| Today | True now, with evidence the BU can point to |
| With change | True after a named change; state its size and date |
| No | Not possible as stated; state why |
| Unknown | Owner to find out; state by when |
| Obligation (D2.1 §19 #) | Readiness | Owner | Date | What was said (attributed, verbatim) | Would it change the architecture? |
|---|---|---|---|---|---|
| n, or which boundary |
One row per obligation per BU. D2.3 is more credible for recording disagreement as disagreement, so rows are not softened. Send each row back to attendees within a day for factual correction only. What changed in the architecture as a result goes into D2.3 "What changed as a result", and proposed edits to §19 owners and dates go through hand authoring there.
What we know about each BU
Pre-fill for the "what changes for you" page and the playback block. Each cell cites its source; anything uncited is a question, not a finding.
| BU | What we hold | Likely friction | Close before the session |
|---|---|---|---|
| Group Benefits | CIAM CAN with employer SSO; product data in several applications, not mapped; no match and merge (UCL slide 21). Own gateway, with production enumeration blocked, so about 1,311 operations are read from UAT (CR-16). Building AuthX, a Member Experience Service and an experience platform for October 2027 (group-benefits-alignment-presentation.html). MVP1 pilot with Retirement | Identity and experience services overlap what GB is already building. No match and merge makes relationship facts the hardest feed to supply. AuthX and the Member Experience Service target October 2027, a month after GB's September 2027 go-live in the portal. Settled on October 1 (alignment sessions slide in the v3 deck): portal-rendered metadata-driven tiles, read-only sponsor fields, existing CIAM assertions until token exchange is validated. Confirm those, do not reopen them | What is production, in build or intent (the question the GB deck already asks), and what must exist at go-live. Whether AuthX meets the §19 #7 exchange semantics or sits beside them. Production API enumeration |
| Retirement | CIAM CAN; product data on MPS and SLX (UCL slide 21). The ADS records a Login Handler change to augment a new Group Retirement token (ADS summary). Named with GB as the first-release tiles in §19 #3 | The Login Handler change is a token obligation in its own right. Portal-rendered tiles replace the MVP's micro-frontend | Date and owner of the Login Handler change (CR-33) |
| Wealth | A net-new experience API is required, and FCC supports 25 TPS against a stated 1,200 requests/sec (CR-23, ADS summary). 81 operations on the shared gateway (API landscape). Product data in EDL and a vendor system | The capacity ceiling means the D3 read path is the only viable one, which turns on vendor-system feeds | Written FCC capacity commitment and the experience API date (CR-23, CR-33) |
| Manulife Bank | Product data mostly centralized on core banking, with match and merge in place; credit card via CIAM federation; 351 operations (UCL slide 21, API landscape). 82.9% of authentications are mobile (CR-35) | Likely the most ready on feeds. The Mobile BFF contract and session model (§19 #4) matter most here | Bank's mobile authentication and session model |
| Individual Insurance | 1,075 operations, the largest tenant on the shared gateway (API landscape). Retail product data on DMO; seg funds and Vitality on Salesforce (UCL slide 21). Current-state discovery pending | Largest APIM estate, so the heaviest coexistence and retirement sequencing (§19 #2, #20). Otherwise unknown | The whole fact base. Treat the playback block as discovery |
| Affinity | Product data in MDM (UCL slide 21). De-prioritized in the initial release (ADS summary). Discovery pending | Low pressure, but unknown | Whether onboarding order matters to Affinity (§19 #20) |
Pre-read (client-facing draft)
Send three or more days ahead, one page. Fill the BU name and attach that BU's "what changes for you" page.
Unified Portal target architecture · [BU] deep dive
What the session is. Sixty minutes to check the target architecture against your estate. We will confirm our reading of your systems, show what the architecture asks of [BU], and record for each ask whether it is true today, true with change, not possible, or unknown.
What it is not. It does not approve the architecture, choose or defend products, or commit [BU] to scope or dates. Ratification sits with the Enterprise Architecture Design Authority. We will not design implementations in the room: anything that would change a boundary or a responsibility is captured, and anything about how to build it is held for a later working session.
How to read the material. Each topic is labelled. Baseline is already decided by Manulife and is not reopened. Proposed is our position, with the alternatives we rejected; challenge it with evidence. Open is a decision or proof Manulife has yet to make, and each has a fallback so that no business unit is committed by the gap.
What limits your exposure. Each open item has a fallback that applies if its gate is not met. If portal intake and capacity are not agreed, the first release is limited to the Group Benefits and Retirement tiles and onboarding of further units waits. Until delegation is approved, staff and partner users stay on their existing channels. Where a business-unit API cannot yet enforce the final record check, its System API acts as a recorded transition control and unsupported actions are blocked. Until a feed contract exists, only profile facets backed by an authoritative contract are served.
What we ask beforehand. Current request rates and documented headroom for your APIs, your gateway rate limits, and your line-of-business roadmap, as they stand.
Who should attend. Solution architects who can speak for your data, API and security owners, or those owners themselves.
What happens to what you say. It is recorded and attributed in the stakeholder alignment summary. Disagreement is recorded as disagreement. You receive the record within a day to correct facts.
Status. The architecture document has not yet been validated with the authors of the material it draws on.
The fallbacks quoted above are D2.1 §19 items 3, 6, 7 and 5. If §19 changes, change this paragraph.
Facilitator notes
- Product challenges. Architects will test MuleSoft, PingAuthorize and Cosmos. Answer from the rejected alternatives in §17, point to the §19 gate that proves fit, and do not defend a product in the room.
- "We are already building that." Expect it from Group Benefits on identity and experience services. Treat it as a seam to align, not a conflict to settle: record what exists, its status and its date, and where it meets the enterprise contract. Group Benefits has already accepted portal-rendered tiles, so confirm that rather than reopening it.
- Attendance is a decision for the team. If only architects attend, the seams collect items; if the §19 owner roles attend, rows can close in the room. Ask each BU which it will bring.