Appearance
Unified Portal — architecture and roadmap
The working knowledge base for the Konrad × Manulife Unified Portal engagement: what the client gave us, what the SOW commits us to, what we are doing about it, and every decision made along the way.
| Engagement | Konrad Group × Manulife — SOW 7 |
| Effective | 2026-08-31 · six weeks |
| Scope of record | resources/SOW7_Konrad_Manulife_Unified Portal Architecture and Roadmap_2026-08-25 SCOPE.docx.md |
| Client team | Manulife IT, Toronto |
The engagement in one paragraph
Manulife Canada's customers hold several relationships with the same company and see several different portals. A programme is under way to replace the post-login product selection page with a unified dashboard that aggregates across business lines. The MVP is built and under review; the target state it is meant to be a foundation for is not agreed. Konrad has been engaged to document that target state architecture, identify the decisions and trade-offs it rests on, align the participating lines of business behind it, and turn it into a sequenced, costed implementation roadmap.
Start here
| Section | What is in it |
|---|---|
| Client resources | Every artifact Manulife has given us, read and summarised — one page each |
| Client requests | What we still need from Manulife — material, access and people — by priority |
| Deliverables | The nine things this SOW commits to, with status and where each is assembled |
| Tasks | The SOW's activities as tracked work, per work stream, plus working notes |
| Decision log | Decisions with their rejected alternatives — and the open questions register |
| Architecture | The target state narrative, by domain — the body of deliverable D2.1 |
| Recommendations | Our position on what should change, one page per theme, each anchored to a client finding |
| Diagrams | Interactive architecture diagrams, with version timelines |
If you are new to the engagement, read the client resources index first. It explains how the seven client artifacts fit together, which is not obvious and which materially changes how the rest of this reads.
The work
Three work streams, from SOW Schedule "A".
| Work stream | Duration | Objective |
|---|---|---|
| WS 1 — Immersion & Validation | 1 week | Build shared understanding of the landscape, vision, objectives and work to date |
| WS 2 — Target State Architecture | 3 weeks | Synthesize a cohesive target state and align stakeholders behind it |
| WS 3 — Implementation Roadmap & Cost Estimate | 2 weeks | Sequence the transition and cost two delivery options |
Where things stand
WS 1 is under way. All seven client artifacts have been read end to end and summarised with citations under Client resources. Nothing has been validated with the client yet, and validation is the substance of the WS 1 deliverables rather than a formality — the client's own executive review names "no agreed North Star" as its second concern, which makes establishing which target state is of record the highest-leverage thing this engagement can do early.
WS 2 and WS 3 have not started. The architecture pages are named but unwritten, and the only diagram in the repository is a placeholder proving the toolchain — every node is a guess, it is registered as not client-safe, and it must not be shown.
28 open items are tracked in open decisions and dependencies, spanning engagement logistics, programme governance, architecture and roadmap dependencies. Separately, 38 requests for material, access and people we do not yet have are tracked in client requests — 22 of them High, meaning they block a named deliverable or sit on the critical path. SOW §10 ties client-caused delay to timeline and cost, so that register is also the evidence trail.
How this repository is organised
docs/ is the site's content root and the knowledge base itself. Source material sits outside it and is never edited: resources/ holds the SOW, client-resources/ holds the client's discovery exports. Synthesis goes in docs/, citing the source it came from.
Diagrams are authored as typed JSON IR in diagrams/src/ and compiled by Archify into standalone interactive HTML with their own viewer — search, guided views, route probing, presentation mode and PNG/SVG export. Diagrams carry structure; prose carries rationale and constraints; neither restates the other.
Content is plain CommonMark so pandoc docs/**/*.md stays a one-liner into Word or Confluence while the handoff format is still open. The repository's root README.md carries the build commands and the full directory layout.
Nothing is deployed
Deliberately. This is internal working material and, in places, commercial. Two things have to happen before it is hosted anywhere: the acceptable handoff format has to be agreed, and access control has to sit in front of it. Target state architecture for an insurer does not go on a public URL. Both are tracked in open questions, items 1 and 4.