# Practical Business Architecture Starter Charter

Free practitioner template from StephenKlahr.com for Applied BA Cookbook Recipe 09, **Create a practical BA starter charter**.

This is a lightweight alignment artifact, not a full practice operating model or project charter. Complete only what is needed to establish a credible mandate, start one useful engagement, govern the initial knowledge, and review the practice after 90 days. Delete the prompts and guidance before approval. The finished charter should usually remain within one or two pages, with supporting detail kept separately.

---

## Document Control

| Field | Entry |
|---|---|
| Organization / business area | |
| Charter owner | |
| Executive sponsor | |
| BA practice lead | |
| Version and status | Draft / Approved / Superseded |
| Approval date | |
| Effective date | |
| 90-day review date | |
| Authoritative location | |

---

## 1. Charter Statement

Complete this paragraph first. It should make sense to an executive who does not use business architecture terminology every day.

> Business architecture at **[organization]** exists to help **[decision makers and stakeholders]** make better decisions about **[strategic or operational concerns]** by connecting **[outcomes, value, capabilities, information, organization, initiatives, policies, and measures as relevant]**. During its first 90 days, the practice will focus on **[first decision or use case]** and will demonstrate value through **[decision or outcome evidence]**.

---

## 2. Working Definition

**Business architecture means:**  

> [Define business architecture in language the organization will recognize. Describe the discipline as a way to connect strategy, stakeholder value, capabilities, information, organization, initiatives, and performance to consequential decisions.]

**Business architecture does not mean:**  

> [State the most likely misunderstandings. Examples may include owning every process model, documenting the organization chart, selecting applications, replacing enterprise architecture, or taking delivery accountability from product and program teams.]

---

## 3. Mandate and Value Proposition

**Business need or institutional problem:**  
[What recurring decision, fragmentation, duplication, risk, or strategy-to-execution problem justifies the practice?]

**Decisions the practice is authorized to support:**  

- [Decision type 1]
- [Decision type 2]
- [Decision type 3]

**Primary stakeholders:**  
[Who sponsors, uses, contributes to, governs, or is affected by the work?]

**Value proposition:**  

> By providing **[linked evidence, shared vocabulary, impact analysis, reusable architecture, or other service]**, the practice will help **[stakeholders]** improve **[scope, priority, accountability, investment, risk, sequence, or outcome]**.

---

## 4. Initial Objectives

Limit the charter to three or four objectives that can produce evidence within the first 90 days.

| Objective | Decision or outcome supported | 90-day evidence | Accountable owner |
|---|---|---|---|
| 1. | | | |
| 2. | | | |
| 3. | | | |

---

## 5. Scope and Boundaries

### Initial scope

- **Business area or enterprise boundary:** [ ]
- **First strategy, initiative, value stream, or decision scenario:** [ ]
- **Architecture domains needed:** [ ]
- **Minimum reusable knowledge to govern:** [ ]
- **Forums the practice will support:** [ ]

### Explicit non-scope

- [Work the practice will not perform]
- [Decision rights the practice does not own]
- [Repositories, models, or business areas not included initially]
- [Delivery, solution, process, or project responsibilities retained elsewhere]

### Expansion trigger

The practice may expand when **[a recurring use case, sponsor decision, demonstrated value, available stewardship, or governance capacity]** justifies the additional scope. Expansion is not justified by repository completeness alone.

---

## 6. First Decision Scenario

**Decision to be improved:**  
**Decision owner:**  
**Decision date or planning horizon:**  
**Stakeholder outcome:**  
**Why current evidence is insufficient:**  
**Minimum architecture questions:**  

1. [ ]
2. [ ]
3. [ ]

**Minimum useful artifact package:**  
**Review forum:**  
**Completion or stop condition:**  

---

## 7. Initial Service and Engagement Model

### Initial services

Select only services supported by current capacity.

- [ ] Decision and engagement framing
- [ ] Capability and value-stream analysis
- [ ] Strategy-to-execution linkage
- [ ] Initiative impact and overlap analysis
- [ ] Business-object and information analysis
- [ ] Target-state and transition framing
- [ ] Architecture review support
- [ ] Governed knowledge and reuse
- [ ] Other: [ ]

### Engagement path

1. **Request:** A sponsor or decision owner submits a focused business question.
2. **Triage:** The practice confirms the decision, owner, horizon, scope, evidence, and confidentiality boundary.
3. **Engagement:** The practice agrees on the smallest useful architecture package and participants.
4. **Validation:** Business content owners validate facts, definitions, relationships, and unresolved disagreements.
5. **Decision:** The authorized forum makes or records the decision.
6. **Governance:** Reusable knowledge, sources, ownership, status, and review dates enter the authoritative repository.

**Intake channel:**  
**Triage owner:**  
**Expected initial response time:**  
**Prioritization criteria:**  
**Conditions for declining, deferring, or returning a request:**  

---

## 8. Roles and Decision Rights

| Role | Named person or group | Accountabilities | Decisions owned |
|---|---|---|---|
| Executive sponsor | | Protect mandate, remove barriers, confirm enterprise relevance | Charter approval, priority conflicts, expansion or reset |
| BA practice lead | | Run the practice, frame engagements, maintain standards and measures | Method application, engagement acceptance, publication readiness |
| Business content owner | | Validate meaning, scope, rules, performance, and ownership for assigned content | Approval or escalation of business content |
| Contributors / SMEs | | Provide evidence, scenarios, constraints, and review | Recommendations within delegated expertise |
| Portfolio / strategy partner | | Connect architecture to planning, investment, and outcomes | Existing portfolio or strategy decisions |
| Enterprise / solution architecture partner | | Connect business intent to broader architecture and solution decisions | Existing technology architecture decisions |
| Governance forum | | Adjudicate material conflicts and record decisions | Decisions assigned by existing governance |

### Decision-rights test

- The practice can distinguish who recommends, validates, approves, contributes, and must be informed.
- Business content approval remains with an accountable business owner.
- The sponsor can resolve scope, priority, and ownership conflicts that exceed the practice lead’s authority.
- Existing portfolio, strategy, risk, data, and technology forums retain their formal authority unless this charter explicitly changes it.
- Unresolved ownership is recorded as a governance issue, not silently assigned to the architect.

---

## 9. Minimum Practice Principles

Adapt, approve, and keep the list short.

1. Start with the decision, outcome, or stakeholder problem rather than a requested artifact.
2. Produce the smallest architecture package that changes scope, sequence, priority, accountability, risk, or another formal decision.
3. Separate what the business must be able to do from who performs it, how work flows, and which technology enables it.
4. Link architecture domains only as far as the decision requires.
5. Preserve source, owner, status, effective date, confidence, and unresolved disagreement for governed knowledge.
6. Reuse existing knowledge when it remains valid, but do not force false standardization across materially different contexts.
7. Embed decisions in existing governance whenever practical instead of creating a parallel approval structure.
8. Protect employer, customer, employee, security, legal, and proprietary information.

**Approved naming or modeling standards:**  
**Required metadata:**  
**Exception authority and duration:**  

---

## 10. Governance and Cadence

| Forum or review | Purpose | Decision right | Cadence / trigger | Owner |
|---|---|---|---|---|
| Sponsor review | Priority, mandate, barriers, value evidence | Continue, redirect, expand, or reset | Monthly during first 90 days | |
| Content validation | Definitions, boundaries, relationships, ownership | Validate, reject, or escalate content | As required by engagement | |
| Portfolio / strategy forum | Investment and strategic alignment | Existing forum authority | Existing cadence | |
| Architecture review | Cross-domain implications, standards, exceptions | Existing forum authority | Existing cadence or trigger | |
| 90-day charter review | Practice evidence and next operating decision | Continue, revise, expand, pause, or retire | Date: [ ] | Sponsor |

---

## 11. Knowledge, Repository, and Change Control

**Authoritative repository or interim location:**  
**Minimum objects and relationships to govern:**  
**Naming and identifier rule:**  
**Version and effective-date rule:**  
**Required source and confidence metadata:**  
**Publication authority:**  
**Change-request path:**  
**Review and retirement cadence:**  
**Tooling explicitly deferred:**  

Do not acquire or expand a repository merely to demonstrate practice maturity. Tooling should follow a recurring use case, sustainable stewardship, and a clear source-of-truth decision.

---

## 12. First 90 Days

| Period | Priority | Minimum output | Decision or evidence produced | Owner |
|---|---|---|---|---|
| Days 1 to 30 | Approve charter, frame first scenario, confirm standards and participants | Approved charter and engagement brief | Mandate, boundary, and decision rights confirmed | |
| Days 31 to 60 | Perform and validate the first architecture analysis | Minimum useful architecture package | Decision options, impacts, dependencies, and open issues visible | |
| Days 61 to 90 | Support the decision, govern reusable knowledge, assess the practice | Decision record, governed baseline, and 90-day review | Evidence for continuation, revision, expansion, pause, or retirement | |

### Dependencies and constraints

- [Sponsor availability]
- [Business-owner participation]
- [Planning or portfolio timing]
- [Repository or source access]
- [Practitioner capacity]
- [Other]

---

## 13. Measures and Evidence

Choose measures that indicate better decisions and sustainable use. Record a baseline when one exists.

| Measure | Baseline | 90-day target or expected evidence | Source | Owner |
|---|---|---|---|---|
| Decisions materially supported | | | | |
| Scope, dependency, risk, or ownership issues exposed before commitment | | | | |
| Architecture knowledge reused in another decision | | | | |
| Business content with named ownership and source | | | | |
| Stakeholder adoption in existing forums | | | | |
| Cycle time from focused request to usable decision evidence | | | | |

### Measures not to use as primary evidence of value

- Number of maps produced
- Number of repository objects created
- Number of workshops held
- Percentage of an arbitrary metamodel completed
- Tool adoption without decision use

---

## 14. Assumptions, Risks, and Stop Conditions

| Type | Statement | Evidence or trigger | Owner | Response |
|---|---|---|---|---|
| Assumption | | | | |
| Dependency | | | | |
| Risk | | | | |
| Open decision | | | | |

**Reset condition:**  
[Example: If the first scenario has no sponsor-owned decision or cannot obtain necessary business ownership, reduce scope and reframe before expanding the repository.]

**Pause or retirement condition:**  
[Example: If the practice cannot show decision use, reusable knowledge, or a viable sponsor after the 90-day review, pause expansion and decide whether to revise or retire the practice.]

---

## 15. Approval and 90-Day Review

### Approval

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | | Approve / Approve with conditions / Return | |
| BA practice lead | | Accept mandate and accountabilities | |
| Relevant governance owner | | Acknowledge integration and decision rights | |

### 90-day review questions

1. Which decisions did the practice materially improve?
2. What evidence was unavailable before the engagement?
3. Which knowledge was reused or is likely to be reused?
4. Where did ownership or governance fail?
5. Which services generated demand, and which created activity without value?
6. Is current capacity sufficient to govern what has been created?
7. Should the practice continue, revise, expand, pause, or retire?

### Charter completion test

The starter charter is sufficient when the sponsor and core participants can explain:

- Why the BA practice exists
- Which decisions and outcomes it will support first
- What is in scope and explicitly out of scope
- Who owns sponsorship, practice operation, business content, and formal decisions
- How a team engages the practice
- Which minimum standards and governance paths apply
- What will happen in the first 90 days
- What evidence will justify continuation or expansion

Stop there. Do not wait for a complete operating model.

---

## Illustrative Example: Hypothetical United Airlines Application

This brief example is fictional and is included only to demonstrate how the blank charter can be used. It does not describe United Airlines’ actual organization, architecture, governance, systems, plans, or performance.

**Charter statement:**  
Business architecture for this hypothetical United Airlines scenario exists to help leaders make more coherent investment and operating decisions affecting the passenger disruption-recovery experience. During the first 90 days, the practice will focus on one decision concerning how proposed improvements should be scoped and sequenced across passenger communication, reaccommodation, and customer-care capabilities.

**First decision scenario:**  
Determine the smallest coordinated change that improves the passenger disruption-recovery outcome without duplicating active initiatives or treating a technology platform as the complete business solution.

**Initial scope:**

- Passenger Disruption Recovery value stream
- Passenger, Itinerary, Disruption Event, and Reaccommodation Option business objects
- Passenger Communication, Reaccommodation Management, and Customer Care capabilities
- Relevant initiatives, policies, measures, and technology dependencies

**Explicit non-scope:**

- Redesigning detailed operating processes
- Selecting a vendor or application
- Replacing product, program, operations, or technology decision rights
- Building an enterprise-wide capability inventory

**Minimum outputs:**

- Decision-centered engagement brief
- Value-stream and capability impact view
- Business-object lifecycle and ownership view
- Initiative overlap and dependency assessment
- Options, measures, assumptions, and decision record

**90-day evidence:**

- A sponsor-owned decision was made using the architecture analysis
- Material duplication, dependency, ownership, or policy questions were resolved or assigned
- The approved knowledge was governed and reused in at least one adjacent planning discussion
- The sponsor can decide whether to continue, revise, or expand the practice based on evidence rather than the number of artifacts produced