# Applied Business Architecture Practitioner Analysis Work Pack

Free working templates from StephenKlahr.com for Cookbook Recipes 10, 12, 15, 16, and 25.

Use only the sections needed for the decision at hand. Preserve sources, assumptions, unresolved disagreements, and decision ownership. A completed template is not the outcome; a better-governed business decision is.

---

## 1. Business-Object Rationalization Workbook

### Decision and boundary

**Decision or use case this model must support:**  
**In-scope business area, value stream, or scenario:**  
**Out of scope:**  
**Business-object inclusion rule:**  
**Decision owner:**  
**Business content owners / stewards:**  
**Review date:**  

### Candidate-term register

Do not delete terms during collection. Preserve their source and local meaning until a decision is recorded.

| Candidate term | Local definition or usage | Source | Proposed classification | Proposed canonical object | Parent or specialization | Lifecycle distinction | Status / decision |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

Suggested classifications: canonical candidate, synonym, specialization, grouping or parent, attribute, state, event, representation or document, actor, organization, application, or out of scope.

### Canonical business-object record

**Canonical name, singular:**  
**Plain business definition:**  
**What distinguishes it from neighboring objects:**  
**Accepted aliases:**  
**Parent object, if any:**  
**Specializations, if any:**  
**Key lifecycle states:**  
**Created when / by capability:**  
**Changed when / by capabilities:**  
**Referenced by capabilities:**  
**Transferred or shared when:**  
**Retired when / by capability:**  
**Material business rules:**  
**Steward / decision owner:**  
**Sources and effective date:**  
**Confidence / unresolved issue:**  

### Merge or separate test

Keep two terms separate only when at least one durable distinction exists:

- They represent different business meanings, not merely different labels.
- They have materially different lifecycles, rules, ownership, or stakeholder use.
- One is a legitimate specialization that inherits the parent meaning and adds stable rules.
- Separating them changes scope, accountability, integration, policy, measurement, or another decision.

Do not create separate business objects merely because two applications, teams, reports, or jurisdictions use different names.

### Object-to-capability lifecycle matrix

| Business object | Create | Change | Reference | Transfer / share | Retire | Steward | Open issue |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

### Completion check

- Every retained object has a distinct business meaning or lifecycle.
- Aliases and source terms remain traceable.
- Attributes, documents, states, events, actors, organizations, and systems are not disguised as peer business objects.
- Parent-child relationships express inheritance, not convenient filing.
- Ownership follows business meaning and lifecycle decisions rather than application custody alone.
- Unresolved disputes have a decision owner and review date.

---

## 2. Capability-Decomposition Decision Worksheet

### Decision context

**Parent capability:**  
**Decision requiring more detail:**  
**Affected scenario or value-stream stages:**  
**Current level and level contract:**  
**Scope boundary:**  
**Evidence available:**  

### Candidate-child test

| Candidate child | Distinct outcome or ability | Distinct object lifecycle or rules | Separate assessment useful? | Separate investment or ownership useful? | Comparable level? | Keep, combine, or defer | Rationale |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

### Required tests

For the proposed set of children, answer:

1. Do the children collectively explain the parent capability within the defined boundary?
2. Can each child be distinguished by meaning rather than current organization, process step, application, channel, or product name?
3. Are the children at comparable breadth and abstraction?
4. Does each retained child change at least one decision about performance, investment, accountability, dependency, sequence, scope, or risk?
5. Does the structure remain intelligible across more than one scenario?
6. Would a plausible reorganization or system replacement leave the capability names valid?

### Peer-branch consistency check

| Peer capability | Current depth | Reason for depth | Evidence of decision use | Adjustment needed |
|---|---|---|---|---|
| | | | | |

### Definition record for each retained child

**Capability name:**  
**Definition:**  
**Parent:**  
**Boundary and exclusions:**  
**Business outcomes enabled:**  
**Business objects acted upon:**  
**Value-stream stages enabled:**  
**Known measures or evidence:**  
**Owner / steward:**  
**Reason separate treatment is decision-relevant:**  

### Stop or defer decision

**Next possible level:**  
**Decision that additional depth would change:**  
**Evidence currently missing:**  
**Defer until / trigger:**  

If no consequential decision can be named, stop decomposing.

---

## 3. Initiative Overlap and Redundancy Analysis

### Portfolio question

**Decision required:**  
**Decision owner / forum:**  
**Portfolio boundary and time horizon:**  
**Strategic outcomes in scope:**  
**Constraints on funding, capacity, or sequence:**  

### Normalized initiative register

Replace project slogans with comparable business statements.

| Initiative | Intended outcome and measure | Business change proposed | Sponsor / owner | Timing | Cost or capacity | Evidence confidence |
|---|---|---|---|---|---|---|
| | | | | | | |

### Architecture cross-map

Use additional rows when an initiative affects multiple elements.

| Initiative | Capability and change type | Value-stream stage | Stakeholder | Business object | System / platform | Policy or organization dependency | Predecessor / successor |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

Suggested capability change types: create, enhance, sustain, retire, or no material change.

### Overlap-cluster assessment

| Cluster | Initiatives | Shared outcome or architecture element | Overlap type | Evidence | Value / risk implication | Proposed disposition | Decision owner |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

Suggested overlap types:

- **Duplicate:** materially the same change and value claim.
- **Complementary:** distinct contributions to the same outcome.
- **Conflicting:** target states, rules, timing, or ownership cannot coexist cleanly.
- **Enabling dependency:** one initiative supplies a prerequisite for another.
- **Deliberate resilience:** intentional parallel capacity or risk control.
- **Superficial similarity:** similar terminology but materially different scope or value.

Suggested dispositions: merge, sequence, narrow, share a foundation, stop, defer, or deliberately retain.

### Coverage-gap check

| Strategic outcome or material capability gap | Required change | Funded initiative | Coverage quality | Owner / next decision |
|---|---|---|---|---|
| | | | | |

### Decision record

**Decision:**  
**Initiatives affected:**  
**Expected effect on value, cost, capacity, timing, or risk:**  
**Conditions and dependencies:**  
**Accountable owner:**  
**Review trigger and date:**  

Do not label an initiative redundant solely because it maps to the same capability. Investigate the intended outcome, scope, lifecycle, dependency, timing, and value contribution.

---

## 4. BA Discovery Session Brief

### Session purpose

**Decision or architecture question:**  
**Decision owner:**  
**Decision date:**  
**Minimum outputs required:**  
**Explicit non-goals:**  
**Session date, duration, and method:**  

### Participant design

| Participant / role | Contribution needed | Decision right or knowledge held | Known position or concern | Preparation requested |
|---|---|---|---|---|
| | | | | |

Include the decision owner, business content owners, materially affected stakeholders, informed skeptics, and only the technical participants needed to answer the business question.

### Pre-read

**Known facts and sources:**  
**Working assumptions:**  
**Disputed points:**  
**Constraints:**  
**Existing models or evidence:**  
**Focused questions participants should consider:**  

### Discovery question set

Use only the domains needed for the decision.

**Outcome and measure**  
- What observable result must change, for whom, and by when?
- What evidence would show success or failure?

**Stakeholder and value**  
- Who receives, creates, loses, or governs value?
- Where does the value experience currently fail?

**Value stream and capability**  
- Which value-stream stages are affected?
- Which business abilities must improve, be created, be sustained, or be retired?

**Information and rules**  
- Which business objects are created, changed, referenced, transferred, or retired?
- Which policies, rules, controls, or decision rights govern those changes?

**Organization and operating model**  
- Who owns the outcome and the enduring capability?
- What capacity, skill, accountability, or coordination constraint is material?

**Technology and dependency**  
- Which existing technologies constrain or enable the outcome?
- Which upstream decisions or initiatives must occur first?

### Working-surface structure

Prepare visible areas for:

1. Decision and boundary
2. Evidence and sources
3. Architecture elements and relationships
4. Assumptions and confidence
5. Disagreements and alternatives
6. Decisions made
7. Parking lot
8. Actions, owners, and dates

### Closeout readback

**Decisions made:**  
**Facts confirmed:**  
**Assumptions retained:**  
**Disagreements requiring adjudication:**  
**Evidence still needed:**  
**Actions, owners, and dates:**  
**Repository or governance destination:**  
**Follow-up circulation date:**  

The session is complete when the minimum outputs exist and unresolved work is owned. It does not require universal consensus or a complete enterprise model.

---

## 5. Technology-as-Business-Solution Challenge

### Original request

**Requested product, platform, or technology:**  
**Requester / sponsor:**  
**Stated reason:**  
**Requested decision and date:**  
**Vendor, renewal, contract, or timing pressure:**  

### Solution-neutral reframing

**Business outcome sought:**  
**Stakeholder affected:**  
**Observable current problem:**  
**Target measure and baseline:**  
**Affected value-stream stage:**  
**Capability unable to produce the required result:**  
**Evidence supporting the gap:**  

### Root-cause test

| Domain | Current constraint or gap | Evidence | Change required | Technology necessary, helpful, or irrelevant? |
|---|---|---|---|---|
| Organization and accountability | | | | |
| Policy and decision rights | | | | |
| Process and coordination | | | | |
| Information and data quality | | | | |
| Measurement and incentives | | | | |
| Skills and capacity | | | | |
| Technology | | | | |

### Business requirements before product features

**Required business outcomes:**  
**Capabilities to be enabled or changed:**  
**Business objects and lifecycle requirements:**  
**Rules, controls, and decision rights:**  
**Stakeholder and usability needs:**  
**Volume, timeliness, resilience, security, privacy, or audit needs:**  
**Integration and interoperability constraints:**  
**Operating owner after implementation:**  

### Option assessment

| Option | Outcome contribution | Capability fit | Non-technology changes required | Cost and capacity | Dependencies | Risk and reversibility | Evidence confidence |
|---|---|---|---|---|---|---|---|
| Policy / rule change | | | | | | | |
| Organization / accountability change | | | | | | | |
| Process or information improvement | | | | | | | |
| Existing-platform change | | | | | | | |
| New technology | | | | | | | |
| Staged experiment | | | | | | | |
| Do nothing / defer | | | | | | | |

### Proposed-technology fit

**Capabilities genuinely enabled:**  
**Requirements fully met:**  
**Material gaps and workarounds:**  
**Duplicate functionality introduced:**  
**Integration and migration impact:**  
**Vendor or platform lock-in:**  
**Security, privacy, legal, or policy exposure:**  
**Total cost of ownership:**  
**Operating-model and adoption change:**  
**Retirement and exit implications:**  

### Recommendation and gates

**Recommendation:**  
**Why this option best supports the outcome:**  
**Assumptions:**  
**Conditions before commitment:**  
**Pilot or staged-learning design:**  
**Outcome and adoption measures:**  
**Decision gates:**  
**Exit or stop condition:**  
**Accountable business owner:**  

Technology is part of a business solution only when it credibly enables the required capability change, fits the information and policy environment, and is accompanied by the ownership and operating changes needed to realize value.