The real cookbook

Applied business architecture recipes.

Each recipe begins with a real organizational problem, identifies the minimum useful inputs and moves, and ends with a stop condition so the architecture does not become work for its own sake.

How to use the cookbook

Do not run every recipe and do not produce every artifact. Find the decision you need to improve, choose the closest problem pattern, and tailor the moves to the situation.

The recipes assume that capabilities, value streams, stakeholders, information, organization, products, strategies, initiatives, policies, and metrics form a linked body of knowledge. They are separated here only to make the work manageable.

Turn an executive question into a BA engagement

The request arrives as a solution, a vague transformation, or a demand for “a capability map.”

Use when

The sponsor has a decision but no architecture question
Multiple functions are describing different problems
The team is already arguing about solutions

Inputs

Sponsor statement
Decision date and decision owner
Known constraints
Existing strategy, initiative, or problem material

Moves

Rewrite the request as a decision to be made
Name the affected stakeholders and value outcome
Identify what must be true to make the decision
Select only the architecture domains needed to answer it
Agree on the smallest useful package and review point

Outputs

One-page engagement brief
Named decision and decision rights
Artifact plan
Boundary and stop condition

Stop condition: Stop when the sponsor can state what decision the architecture work will enable and what evidence will be sufficient. Do not begin modeling merely because a map was requested.

Build a capability map without drawing the org chart

The first draft mirrors departments, applications, or process steps instead of stable business abilities.

Use when

The enterprise has no usable capability baseline
Maps differ by business unit
Capability names begin with department labels or system names

Inputs

Business model and products/services
Value streams
Reference models
Subject-matter expertise
Existing org and process material as evidence—not structure

Moves

Start with what the business must be able to do
Name capabilities as stable nouns or gerunds
Separate the ability from who performs it and how
Normalize duplicates and inconsistent levels
Test every capability against more than one scenario
Assign definitions and a steward before adding color

Outputs

L1/L2 capability map
Definitions
Mapping rules
Open issues and ownership

Stop condition: Stop decomposing when the next level no longer changes a decision. A capability map is not improved by detail that nobody can govern or use.

Build a value stream without slipping into process

The “value stream” becomes a swimlane full of activities, systems, and handoffs.

Use when

Stakeholders disagree on where value begins or ends
Process maps are too detailed for strategic analysis
Initiatives optimize steps without improving the outcome

Inputs

Stakeholder and triggering need
Value proposition
Outcome and exit criteria
Representative scenarios

Moves

Name the stakeholder receiving value
State the triggering need and value proposition
Define 5–8 outcome-oriented stages
Give each stage entry and exit criteria
Map enabling capabilities to stages
Add processes only when implementation requires them

Outputs

Value-stream definition
Stage cards
Capability-stage cross-map
Scenario variations

Stop condition: If a stage is written as a sequence of tasks, move that detail to a process model. The value stream should remain stable when a team or system changes.

Scope an initiative with a capability–value impact grid

Scope is expressed as features, applications, or a project charter with no enterprise impact logic.

Use when

A proposal crosses functions
Benefits are broad but delivery scope is narrow
Leaders need to compare initiatives consistently

Inputs

Problem and intended outcome
Affected value streams
Capability baseline
Known information, stakeholders, policies, products, and systems

Moves

Identify the value-stream stages affected
Map impacted capabilities and current pain
Classify impact as create, enhance, sustain, retire, or no change
Record dependencies across information, organization, policy, and technology
Separate required scope from adjacent opportunity
Define measures and decision gates

Outputs

Impact grid
Scope boundary
Dependency map
Outcome measures
Architecture decision points

Stop condition: Stop when every major scope item traces to an outcome and affected architecture element. Anything that cannot trace is a candidate for removal or explicit exception.

Connect strategy to execution without a slogan cascade

Objectives, capabilities, initiatives, and metrics exist in separate decks and cannot explain one another.

Use when

Strategy is clear but prioritization is not
Initiatives compete without common criteria
Executives cannot see which abilities must change

Inputs

Drivers and assessments
Objectives and outcomes
Capability and value-stream baselines
Initiative portfolio
Performance measures

Moves

Translate strategic language into explicit outcomes
Identify value propositions and stakeholders affected
Determine capabilities that must change
Assess current performance and gaps
Map initiatives to capability changes and outcomes
Expose gaps, redundancy, and unsupported objectives

Outputs

Strategy-to-capability linkage
Capability heat map
Initiative rationalization view
Measures and assumptions

Stop condition: A strategic objective is not operationalized until an owner can see the capabilities that must change, the investments doing the work, and the measures that would disconfirm success.

Prepare a decision-ready architecture review

Architecture review becomes a document checkpoint rather than a forum for resolving consequential choices.

Use when

A solution or initiative needs formal review
Risks are buried in technical detail
The board receives information but no decision request

Inputs

Decision request
Current and target state
Options and tradeoffs
Standards and constraints
Risk, cost, value, and transition evidence

Moves

Put the decision and recommendation first
Show business outcome and affected capabilities/value stages
Present viable alternatives, not a false binary
State assumptions and irreversible commitments
Name risks, owners, and exception duration
Record the disposition and follow-through

Outputs

Review brief
Decision record
Conditions and exceptions
Named follow-up owners

Stop condition: Do not bring a review forward until the board can approve, reject, conditionally approve, or return a clearly stated decision. “For awareness” belongs elsewhere.

Stand up a lean business architecture practice

The organization wants BA but starts with a huge metamodel, a tool purchase, or an unfunded center of excellence.

Use when

Business architecture is new
Demand is higher than architecture capacity
Stakeholders do not yet understand the value

Inputs

Enterprise priorities
Sponsor and decision rights
Current architecture/strategy ecosystem
Practitioner capacity
One visible use case

Moves

Choose one high-value decision scenario
Define the minimum method and artifact set
Establish naming, ownership, and version rules
Embed BA into existing portfolio and governance forums
Measure decisions improved—not maps produced
Expand the metamodel only when a recurring use case demands it

Outputs

Practice charter
Service menu
Minimum standards
Engagement intake
Governance cadence
Adoption measures

Stop condition: Do not scale the repository faster than the organization can govern and use it. The first proof of a practice is a better decision, not a complete inventory.

Turn workshop output into governed architecture knowledge

The workshop succeeds, but the whiteboard dies in a deck and the enterprise relearns the same facts later.

Use when

Models are recreated for every initiative
Different teams use conflicting names
AI or search cannot reliably answer architecture questions

Inputs

Workshop models and decisions
Canonical vocabulary
Repository schema
Ownership and review cadence

Moves

Separate observations, assumptions, proposals, and approved facts
Normalize names and definitions
Create typed relationships among elements
Attach source, owner, status, and effective date
Publish a decision-appropriate view
Schedule review or retirement

Outputs

Canonical records
Relationship links
Source and confidence metadata
Reusable views
Change log

Stop condition: Knowledge is not governed until a consumer can tell what is authoritative, who owns it, when it changed, and what evidence supports it.

Downloads

Copy the templates. Change them. Use them.

Plain Markdown keeps the material portable: open it in any text editor, Word, Google Docs, Notion, Obsidian, or a repository. No account is required.

Applied BA Starter Kit

Engagement brief, capability definition canvas, value-stream stage card, initiative impact grid, and review checklist.

Download Markdown

SCALE Reference Architecture

A vendor-neutral design brief for a governed AI assistant over linked business architecture knowledge.

Download Markdown

Six-Week CBA Study Plan

An integrated case-based study sequence across the ten official exam domains.

Download Markdown

Mentoring Session Log

A simple private record of goals, work reviewed, decisions, progress, and next actions.

Download Markdown