# Applied Business Architecture Starter Kit

Free practitioner templates from StephenKlahr.com. Adapt the structure to the decision and organization; do not produce every artifact by default.

---

## 1. Business Architecture Engagement Brief

**Working title:**  
**Sponsor / decision owner:**  
**Decision required:**  
**Decision date / horizon:**  
**Business problem or opportunity:**  
**Stakeholder receiving or losing value:**  
**Intended outcome:**  
**Known constraints:**  
**In scope:**  
**Out of scope:**  
**Architecture questions that must be answered:**  
**Minimum artifact package:**  
**Participants / subject-matter experts:**  
**Review forum and decision rights:**  
**Stop condition:**  

---

## 2. Capability Definition Canvas

**Capability name:**  
**Plain-language definition:**  
**Business outcome enabled:**  
**Value-stream stages enabled:**  
**Primary stakeholder(s):**  
**Inputs / information concepts:**  
**Outputs / information concepts:**  
**Parent capability:**  
**Child capabilities, only if decision-relevant:**  
**Current performance evidence:**  
**Known pain / gap:**  
**Owner / steward:**  
**In-scope exclusions:**  
**Related processes, organizations, applications, and policies:**  
**Source and effective date:**  

### Capability quality checks

- Describes what the business can do, not who performs it.
- Stable when the organization, process, or application changes.
- Named and decomposed at a consistent level.
- Has a definition strong enough to distinguish it from neighbors.
- Exists for a business reason and can be used in more than one scenario.

---

## 3. Value-Stream Stage Card

**Value stream:**  
**Stakeholder:**  
**Triggering need:**  
**Value proposition:**  
**Stage name:**  
**Entry criteria:**  
**Value item entering:**  
**Outcome / value item leaving:**  
**Exit criteria:**  
**Enabling capabilities:**  
**Information concepts:**  
**Measures:**  
**Common scenario variations:**  
**Known failure modes:**  

### Stage quality checks

- Outcome-oriented rather than task-oriented.
- Meaningful from the receiving stakeholder’s perspective.
- Stable when the internal workflow changes.
- Has observable entry and exit criteria.
- Links to capabilities rather than embedding process steps.

---

## 4. Initiative Impact Grid

| Architecture element | Current state / pain | Change type (create, enhance, sustain, retire) | Intended outcome | Dependency | Owner | Evidence / source | Decision or open issue |
|---|---|---|---|---|---|---|---|
| Value-stream stage | | | | | | | |
| Capability | | | | | | | |
| Stakeholder | | | | | | | |
| Information | | | | | | | |
| Organization | | | | | | | |
| Product / service | | | | | | | |
| Policy | | | | | | | |
| Metric | | | | | | | |
| Application / technology dependency | | | | | | | |

### Scope challenge

For every scope item ask:

1. Which outcome does this support?
2. Which architecture element is changing?
3. What evidence shows the change is required?
4. What happens if it is excluded?
5. Is this required scope, adjacent opportunity, or implementation choice?

---

## 5. Decision-Ready Architecture Review Checklist

### Decision

- The requested decision is stated in the first paragraph.
- The decision owner and formal review body are clear.
- The recommended disposition is approve, reject, conditionally approve, or return.

### Business architecture

- Business outcome and affected stakeholder value are explicit.
- Affected capabilities and value-stream stages are linked.
- Material information, organization, policy, product, and initiative dependencies are shown.
- Current and target states are distinguished.

### Alternatives and tradeoffs

- At least two viable alternatives were considered when a choice existed.
- Assumptions, constraints, costs, risks, reversibility, and path dependence are visible.
- Rejected options and the reason for rejection are recorded.

### Governance and realization

- Conditions, exceptions, owners, and expiration/review dates are named.
- Measures and evidence needed to validate the decision are identified.
- The decision and resulting architecture changes will enter governed records.

---

## 6. Lean BA Practice Charter

**Purpose:** What enterprise decisions will the practice improve?  
**Primary scenarios / services:**  
**Sponsor:**  
**Decision rights:**  
**Engagement intake:**  
**Minimum standards:**  
**Canonical architecture objects:**  
**Repository and source-of-truth rules:**  
**Stewards / owners:**  
**Governance forums and cadence:**  
**Measures of value:** Decisions improved, risks exposed, duplication avoided, time saved, outcomes enabled.  
**Measures to avoid as primary KPIs:** Number of maps, objects, meetings, or repository records.  
**Expansion trigger:** Add a domain, level, tool, or standard only when a recurring use case requires it.  
**Stop / reset condition:** If the practice cannot show decision use, reduce scope and re-anchor on a sponsored scenario.