D2.2 · Executive target state architecture presentation

Work stream	WS 2 — Target State Architecture
SOW source	§3 (Services) item 4; Schedule "A" WS 2 activity 5
Status	⚪ Not started
Indicative window	Weeks 2–4, presented at WS 2 close

A note on provenance

This is listed as a deliverable here on the strength of SOW §3, which commits Konrad to "prepare an executive level target state architecture presentation", and Schedule "A" WS 2 activity 5, which repeats it. Schedule "A"'s WS 2 deliverables list does not name it separately.

We treat it as a deliverable. A commitment in §3 is a commitment, and activity 7 requires an executive readout that needs something to read out from. But the ambiguity is real and it is tracked as an open question, because it interacts with the format question below.

What the SOW asks for

Prepare an executive level target state architecture presentation that communicates the vision, architectural components, expected business and technology benefits, and considerations for participating lines of business

Four required elements, and the fourth is the one that is easy to miss: considerations for participating lines of business. This is not a generic architecture deck. Group Benefits, Retirement, Bank, Wealth, Individual Insurance, Seg Funds and Affinity each need to see what the target state means for them specifically.

What it contains

1. The vision — one slide, in business language, that survives being quoted back.
2. Architectural components — what is being built, drawn not listed.
3. Expected business benefits — what the customer and the business get.
4. Expected technology benefits — reuse, cost, delivery velocity, risk reduction.
5. Per-line-of-business considerations — what changes for each participating BU: API load, contract obligations, release coordination, ownership.
6. Key decisions and trade-offs — the ones an executive audience actually has to endorse.
7. What we need from you — the decisions and validations required, with owners.

Where the content comes from

Assembled from D2.1, the decision log, and D2.3. It should contain no new analysis — if something appears here that is not in the architecture document, one of the two is wrong.

Diagrams

This is where the diagram pipeline pays for itself. Every rendered diagram supports presentation mode (F), guided views (P) that walk an audience through a topology one step at a time, and PNG/SVG export for slides. A guided view can also be deep-linked into a prose page or embedded.

Which means the deck's architectural content is not redrawn for the deck — it is the same validated artifact, exported. That matters here specifically: Domain K of the segment assessment shows what happens when the diagram in front of the board disagrees with the document behind it.

The open format question

Neither executive presentation has a tool, a format, or a home in this repository. A narrative slide deck is not the same artifact as this knowledge base, and Archify's presentation mode is a working-session tool for a single diagram, not a deck.

The options, briefly:

Option	For	Against
PowerPoint, diagrams exported as PNG/SVG	Universally accepted; matches how the client's own EA decks are made	Content forks from the knowledge base the moment it is edited
The knowledge base itself, presented	Single source of truth; no fork	Not how executives at this client consume architecture
Long-form document, pandoc to Word	Single source; matches the assessment memo format the client already writes	Not a presentation

The client's own material uses all three shapes. The decision is cheap now and expensive at WS 2 close. It is tracked as item 3 in open questions.

Acceptance

Delivered at the final architecture review and executive readout (WS 2 activity 7), with written acceptance per SOW §5.