# End-to-end business architecture delivery template

**Blank reusable structures · No case-study answers · No AI required**

Use these structures with Cookbook methods 40–45. Copy only the sections needed for your decision into your preferred document, whiteboard, spreadsheet, or repository. Replace the blank cells with your own evidence and judgments.

The six structures connect organizational contribution, capability constraints, operating change, readiness, value realization, and policy impact. They are not a phase-gate method. Organization design, operations, delivery, change management, risk, legal, compliance, and benefit owners retain their respective authorities.

For current completed teaching examples, use the [Northstar worked examples](https://stephenklahr.com/downloads/northstar-worked-examples.zip). For the learning path and material choices, see the [materials guide](https://stephenklahr.com/downloads/northstar-materials-guide.md).

## Shared engagement header

Use once when several structures support the same decision.

| Field | Working entry |
|---|---|
| Engagement / change | |
| Decision to be made | |
| Decision owner | |
| Decision forum and date | |
| Outcome to improve | |
| Scope included / excluded | |
| Evidence cutoff date | |
| Architecture baseline and version | |
| Assumptions requiring validation | |
| Contributors and authorities | |
| Stop condition | |
| Review / reopen trigger | |

## 40 · Organization-to-value contribution map

Show how organizational units contribute to capabilities, value-stream stages, information stewardship, and outcomes without treating the organization chart as the architecture.

### Organization register

| Org ID | Organizational unit | Mandate / contribution | Accountable executive | Scope / geography | Material capabilities | Value-stream stages | Business information stewarded | Evidence | Confidence |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

### Contribution relationships

Use one row for each decision-relevant relationship. Avoid forcing a single owner where contribution is distributed. Contribution types can include accountable, operates, contributes, governs, assures, and stewards.

| Relationship ID | Organizational unit | Accountable role / actor | Capability or value stage | Contribution type | Decision / accountability right | Inputs provided | Outputs or value enabled | Dependency | Friction / ambiguity | Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | |

| Question | Finding | Consequence for the decision | Owner / next action |
|---|---|---|---|
| Is accountability absent, duplicated, or disconnected from operating authority? | | | |
| Are critical contributions split across units without coordination? | | | |
| Does one unit steward information another must use or change? | | | |
| Does the formal structure differ from how value is delivered? | | | |
| Would an organizational change alter capability or value outcomes? | | | |

Completion: bound the organizational scope; keep capabilities distinct from departments; distinguish contribution, accountability, stewardship, and governance; assign unresolved ambiguities to an owner and forum.

## 41 · Capability improvement assessment

Diagnose why a selected capability cannot produce the required outcome. Assess constraints that could change the decision rather than assigning generic maturity scores.

| Field | Working entry |
|---|---|
| Capability | |
| Required outcome / performance | |
| Current observed condition | |
| Gap and urgency | |
| Stakeholders and value-stream stages affected | |
| Evidence period | |
| Decision supported | |

Suggested dispositions: `not limiting`, `contributing`, `material constraint`, `unknown`. Rate only where evidence is sufficient.

| Dimension | Required condition | Observed condition | Evidence | Disposition | Confidence | Causal hypothesis | Owner |
|---|---|---|---|---|---|---|---|
| People / skills | | | | | | | |
| Process / ways of working | | | | | | | |
| Information | | | | | | | |
| Technology | | | | | | | |
| Policy / rules | | | | | | | |
| Governance / decision rights | | | | | | | |
| Organization / accountability | | | | | | | |
| Capacity / demand | | | | | | | |
| Measures / incentives | | | | | | | |
| External dependencies | | | | | | | |

| Option | Constraints addressed | Expected mechanism | Dependencies | Risks / side effects | Evidence gained | Reversibility | Recommendation |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

| Assessment conclusion | Working entry |
|---|---|
| Primary limiting conditions and contributors | |
| Conditions ruled out and evidence | |
| Unknowns that could change the conclusion | |
| Recommended intervention boundary | |
| Decision required | |
| Reassessment trigger and date | |

Completion: separate observations, judgments, and hypotheses; retain confidence and disagreement; address the demonstrated constraint; stop when more assessment would not change the decision.

## 42 · Operating-model change record

Define how an initiative changes the way the enterprise operates. Include capabilities, value, organization, information, policy, governance, process, measures, and enabling technology.

| Element | Current condition | Target condition | Why it must change | Change owner | Dependency | Evidence / source |
|---|---|---|---|---|---|---|
| Stakeholder / value proposition | | | | | | |
| Value-stream stage | | | | | | |
| Capability | | | | | | |
| Organization / role | | | | | | |
| Decision right / governance | | | | | | |
| Process / operating practice | | | | | | |
| Business information | | | | | | |
| Product / service | | | | | | |
| Policy / control | | | | | | |
| Measure / incentive | | | | | | |
| Technology enablement | | | | | | |

| Transition ID | Required condition | Predecessor | Accountable owner | Evidence of completion | Needed by | Risk if absent | Status |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

| Decision | Options considered | Architecture consequence | Decision owner / forum | Disposition | Conditions | Review trigger | Record reference |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

| Discipline / owner | Architecture contribution | Detail owned outside this record | Handoff evidence | Acceptance |
|---|---|---|---|---|
| Organization design | | | | |
| Process / operations | | | | |
| Product / service management | | | | |
| Change and adoption | | | | |
| Technology / solution architecture | | | | |
| Risk / legal / compliance | | | | |
| Delivery management | | | | |

Completion: connect each change to an outcome, obligation, or constraint; name observable transition conditions and owners; preserve specialist ownership; make the operating change sufficient to test release scope and readiness.

## 43 · Value-realization trace

State how the change is expected to contribute to outcomes, how the contribution will be observed, and which result would change the next decision. Preserve measure definitions and uncertainty.

| Trace ID | Intended outcome | Operating change / capability contribution | Testable contribution hypothesis | Assumptions / confounders | Outcome owner |
|---|---|---|---|---|---|
| | | | | | |

| Measure | What it measures | Definition and unit | Numerator / denominator | Population and scope | Baseline and dates | Target / guardrail | Source and limitations | Owner | Review horizon |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

Distinguish delivery completion, adoption, capability condition, stakeholder outcome, and financial benefit. Describe any change in measurement scope before comparing periods. Missing evidence is not zero.

| Review date | Observed result and period | Evidence | Interpretation / limits | Unintended effects | Disposition | Follow-up owner | Next trigger |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

Possible dispositions: continue, adapt, scale, investigate, or stop. The accountable forum decides; a favorable metric does not itself authorize expansion.

Completion: own the measures, definitions, baselines, and horizons; describe a testable contribution rather than automatic causation; retain guardrails and unintended effects; agree who acts and on what evidence.

## 44 · Operational-readiness assessment

Decide whether the receiving organization can operate a release safely and sustainably. Use observable operating conditions, not task completion alone.

Suggested status: `ready`, `ready with condition`, `not ready`, `not applicable`, `unknown`.

| Readiness area | Required condition | Evidence / acceptance test | Accountable owner | Status | Residual risk | Condition / action | Due date |
|---|---|---|---|---|---|---|---|
| Operating ownership | | | | | | | |
| Roles and capacity | | | | | | | |
| Skills and training | | | | | | | |
| Process and procedures | | | | | | | |
| Information quality / access | | | | | | | |
| Policy and controls | | | | | | | |
| Product / service support | | | | | | | |
| Technology and service support | | | | | | | |
| Measures and monitoring | | | | | | | |
| Suppliers / external dependencies | | | | | | | |
| Business continuity / rollback | | | | | | | |
| Communications and adoption | | | | | | | |

| Readiness disposition | Working entry |
|---|---|
| Release / operating change | |
| Readiness decision requested | |
| Decision owner and forum | |
| Overall disposition | |
| Conditions that must precede release | |
| Accepted residual risks and acceptance authority | |
| Deferred items and owner | |
| Early-life support period | |
| Escalation threshold | |
| Recheck / rollback trigger | |

| First-cycle signal | Expected range / behavior | Actual observation | Evidence owner | Review point | Response if outside range |
|---|---|---|---|---|---|
| | | | | | |

Completion: require evidence and accountable ownership; keep unknowns visible; specify conditions, dates, and risk authority; agree early-life signals, escalation, and rollback triggers.

## 45 · Policy and regulatory impact assessment

Translate an authoritative obligation or policy change into architecture impacts, decisions, controls, evidence, and readiness conditions. Record interpretation separately from implementation. Qualified legal or compliance authorities own legal and regulatory interpretation.

| Obligation ID | Authoritative source | Effective date | Jurisdiction / scope | Interpretation owner | Requirement / obligation | Ambiguity | Penalty / consequence | Evidence reference |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

| Obligation ID | Stakeholder / outcome | Value-stream stage | Capability | Organization / role | Business information | Product / service | Process / practice | Technology | Existing control |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

| Gap | Current evidence | Required condition | Response options | Recommended response | Accountable decision owner | Dependency | Due date | Residual risk |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

| Obligation | Policy / rule | Control objective | Control owner | Operating procedure | Evidence produced | Evidence steward / retention | Test / monitoring | Exception route |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

| Interpretation question | Interpretations considered | Legal / compliance advice | Architecture consequence | Decision owner | Disposition | Assumptions | Review trigger |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

Completion: record source, scope, date, and authority; separate interpretation from architecture impact; trace obligations to operating owners and evidence; include compliance evidence and exception handling in readiness and later review.

## Connected decision and open-item index

Use this index when the six structures are maintained separately.

| ID | Type | Question / item | Source section | Owner | Forum / due date | Status | Disposition / link | Reopen trigger |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

Types can include decision, assumption, risk, dependency, or evidence gap.

## Stopping rule

Stop adding detail when the accountable forum can understand the contributions and constraints that matter, compare the necessary operating changes, decide readiness, observe value, and trace applicable obligations into controls and evidence. Reopen when a named trigger, new evidence, changed obligation, operating failure, or value result could alter that decision.