Choose the work you need to do.

Use when

• A sponsor requests an architecture artifact without naming the decision it must support
• Several functions describe different problems, outcomes, or boundaries
• A solution or initiative has begun to harden before the business question is clear
• The architect needs to establish a proportionate engagement before collecting or modeling evidence

Inputs

• Original request, source, sponsor, and required date
• Known strategy, initiative, problem, policy, or performance evidence
• Likely decision owner, decision forum, stakeholders, and materially affected parties
• Existing commitments, assumptions, constraints, and proposed solutions
• Available architecture knowledge, practitioner capacity, and governance expectations

Moves

1. Preserve the original request and identify whether it asks for a decision, an artifact, analysis, validation, or implied approval
2. Name the accountable decision owner, authority, forum, required date, and consequence of taking no action
3. Rewrite the request as a choice, disposition, or question whose answer could change scope, priority, accountability, risk, investment, or action
4. Identify who receives or loses value, which enterprise outcomes are affected, and where stakeholders currently disagree
5. Separate confirmed facts, working assumptions, contested claims, constraints, and solution commitments so the engagement does not inherit false certainty
6. Select only the architecture domains and evidence needed to answer the decision, including capability, value, information, organization, policy, product, initiative, performance, or technology as applicable
7. Define the organizational, scenario, time-horizon, and evidence boundaries, including explicit non-scope and matters owned by portfolio, delivery, legal, finance, operations, or technology authorities
8. Agree on participants, work products, review points, decision criteria, confidence expectations, stop condition, and conditions that would reopen the work
9. Publish the engagement brief, obtain confirmation from the decision owner, and update it when the decision or material evidence changes

Outputs

• Decision-centered engagement brief
• Decision authority, forum, date, and stakeholder map
• Evidence, assumption, constraint, and question register
• Architecture scope and work-product plan
• Review cadence, stop condition, and reopening triggers

Use when

• The enterprise has no governed capability baseline for a real decision
• Existing maps differ by business unit, initiative, consultant, or tool
• Capability names are dominated by organizational or technology labels
• Strategy, portfolio, operating-model, or impact analysis needs a common business vocabulary

Inputs

• Decision, scope, scenarios, audience, and required level of precision
• Business model, products and services, stakeholders, and value propositions
• Representative value streams, business objects, policies, outcomes, and measures
• Existing organization, process, application, initiative, and reference-model material as evidence rather than structure
• Business content owners, subject-matter experts, modeling rules, and repository constraints

Moves

1. State the decision the map must support and limit initial depth to the branches needed for that decision
2. Describe what the enterprise must be able to do independently of who performs it, how work flows, or which technology enables it
3. Draft capability names in stable business language and write definitions before arranging hierarchy or assigning color
4. Separate capabilities from organizations, roles, processes, activities, products, business objects, outcomes, applications, and projects while preserving those terms as related evidence
5. Group and decompose capabilities using coherent business scope, outcomes, rules, and business-object lifecycles rather than visual symmetry
6. Normalize synonyms, near-duplicates, mixed abstraction levels, and borrowed terms whose meaning does not fit the enterprise context
7. Test every material capability across more than one value stream, product, organization, or scenario, including a plausible reorganization or technology change
8. Assign stable identifiers, sources, status, steward, effective date, confidence, and unresolved issues before assessment or initiative mapping
9. Validate the decision-relevant baseline with business content owners and publish the level contract, naming rules, and deferred-decomposition backlog

Outputs

• Decision-scoped capability map and level contract
• Capability definitions, identifiers, sources, and stewardship
• Classification and modeling rules
• Scenario validation and duplicate-term findings
• Governed issues and deferred-decomposition backlog

Use when

• Stakeholders disagree about who receives value or where value delivery begins and ends
• Process maps are too detailed or implementation-specific for strategic analysis
• Initiatives optimize local activity without showing an improved stakeholder outcome
• Capability, information, organization, or product analysis needs an end-to-end value context

Inputs

• Decision, scope, audience, and representative scenarios
• Stakeholder, triggering need, value proposition, and expected outcome
• Products, services, channels, policies, and material variants
• Existing process, journey, capability, information, measure, and organization evidence
• Business owners and subject-matter experts who understand normal and exception value delivery

Moves

1. State the decision and identify the stakeholder whose need triggers the value stream and whose outcome defines completion
2. Describe the value proposition in observable business terms without embedding a process, organization, or product feature list
3. Set the trigger, boundary, terminal outcome, and exclusion rules before naming stages
4. Define a small number of outcome-oriented stages that represent meaningful changes in stakeholder or business state rather than work performed
5. Give every stage observable entry and exit criteria, value contribution, measures, and material business objects or state changes
6. Map the primary and supporting capabilities that enable each stage without turning capabilities into sequential activities
7. Identify participating organizations, stakeholders, policies, products, information dependencies, and decision rights only to the depth required by the decision
8. Test the stream against normal, exception, channel, product, and organizational variants; model legitimate variation without multiplying the stable core unnecessarily
9. Validate the stream with the accountable value owner, record sources and unresolved issues, and direct activity, handoff, control, or timing questions to a process model when needed

Outputs

• Governed value-stream definition and boundary
• Outcome-oriented stage cards with entry and exit criteria
• Capability-to-stage cross-map
• Stakeholder, information, organization, product, policy, and measure relationships
• Scenario variations and unresolved evidence needs

Use when

• A proposal crosses functions, products, channels, legal entities, or value-stream stages
• Benefits are broad while delivery scope is narrow or technology-led
• Leaders need a consistent basis for comparing initiative impact and dependencies
• An existing initiative requires reframing before decomposition, release design, or requirements work

Inputs

• Problem, intended outcomes, measures, sponsor, decision rights, and time horizon
• Affected stakeholders, value streams, products, services, and representative scenarios
• Governed capability, information, organization, policy, and performance baselines
• Known systems, processes, initiatives, constraints, commitments, and dependencies
• Current scope, exclusions, benefit assumptions, cost or capacity constraints, and evidence confidence

Moves

1. Restate the initiative as the measurable business outcome and change hypothesis rather than its project, platform, or workstream name
2. Identify the stakeholders and value-stream stages where the problem occurs and where value must materially improve
3. Map the capabilities that the initiative must create, improve, sustain, constrain, or retire at one consistent decision-relevant level
4. Trace material business-object states, policies, products, organizational participation, decision rights, processes, measures, and enabling technology across the affected path
5. Distinguish primary business change from supporting dependency, adjacent opportunity, inherited commitment, and work that does not trace to the outcome
6. Record baseline condition, target condition, evidence, confidence, accountable owner, and material assumptions for each impact
7. Test normal, exception, transition, and cross-business-unit scenarios to expose omitted operating or control obligations
8. Compare credible scope options using outcome coverage, dependency exposure, adoption burden, risk, capacity, reversibility, and timing
9. Present the impact grid with explicit scope, non-scope, decision gates, measures, unresolved issues, and the authority that must disposition them

Outputs

• Capability–value initiative impact grid
• Required scope, explicit non-scope, and option boundaries
• Information, organization, policy, product, process, and technology dependency view
• Outcome measures, assumptions, ownership, and confidence register
• Architecture, portfolio, and delivery decision points

Use when

• Strategic outcomes and measures are sufficiently clear but portfolio coverage is not
• Initiatives claim alignment through labels rather than traceable contributions
• Several investments compete for the same capability, dependency, capacity, or benefit claim
• Leaders need to identify unsupported outcomes and strategically orphaned initiatives before prioritization

Inputs

• Approved strategic outcomes, choices, measures, assumptions, and planning horizon
• Affected stakeholders, value propositions, value streams, and required capability changes
• Active and candidate initiatives with outcomes, owners, timing, investment, and status
• Capability condition, dependencies, capacity, and current commitments
• Portfolio decision rights, prioritization criteria, and authoritative strategy and initiative sources

Moves

1. Confirm that the strategic outcomes are decision-ready; return ambiguous statements to recipe 14 rather than inventing portfolio meaning
2. Create a trace from each outcome to the required capability and value changes, accountable outcome owner, measure, and time horizon
3. Normalize initiatives into their intended business contribution independently of project, technology, or transformation labels
4. Map each initiative to the outcomes and capability changes it materially enables, distinguishing primary contribution from dependency or asserted alignment
5. Test whether benefit measures, baselines, timing, and ownership support the claimed contribution and expose double-counted or ownerless benefits
6. Identify strategic outcomes with no credible initiative, initiatives with no required outcome, and capability changes that are overconcentrated, conflicted, or unfunded
7. Assess sequencing, shared foundations, capacity contention, policy or organizational dependency, and external commitments that constrain prioritization
8. Develop portfolio options to fund, narrow, sequence, combine, defer, stop, or request more evidence without taking formal investment authority from the portfolio forum
9. Record portfolio dispositions, residual gaps, assumptions, measures, owners, and review triggers in the governed strategy-to-execution trace

Outputs

• Strategy-to-portfolio coverage matrix
• Unsupported outcome and strategically orphaned initiative findings
• Benefit, measure, ownership, and timing conflicts
• Capability investment and dependency questions
• Portfolio options, dispositions, and review triggers

Use when

• A business change, initiative, target state, exception, or architecture position needs formal disposition
• Risks and tradeoffs are buried in technical detail or an oversized architecture package
• The review forum receives information but no actionable decision request
• Approval conditions, exceptions, or irreversible commitments require accountable governance

Inputs

• Exact decision request, accountable authority, forum, date, and available dispositions
• Business outcomes, stakeholders, current condition, target intent, and affected architecture
• Viable options, recommendation, tradeoffs, costs, benefits, risks, and transition evidence
• Policies, standards, constraints, commitments, assumptions, and evidence confidence
• Required conditions, exceptions, actions, owners, downstream consumers, and review triggers

Moves

1. Confirm the forum has authority to make the requested decision and distinguish decision, consultation, validation, and awareness items
2. State the decision, recommendation, consequence of no action, and required date before presenting architecture detail
3. Show the business outcome, stakeholder value, affected capabilities, value stages, information, organization, policy, initiative, and operating implications at decision-relevant depth
4. Present credible options including defer or do nothing where valid, and compare them using explicit criteria rather than a preferred-versus-impossible binary
5. Make assumptions, evidence gaps, dissent, uncertainty, irreversible commitments, transition risk, and disconfirming conditions visible
6. Separate architecture advice from formal investment, legal, security, operational, delivery, or executive authority and identify required companion decisions
7. Define approval conditions, exception scope and duration, actions, accountable owners, due dates, and the consequence of noncompliance
8. Design the review material for deliberation, pre-circulate evidence, and remove descriptive content that cannot affect the disposition
9. Capture the disposition and rationale in recipe 39, update affected architecture relationships, and verify that conditions and downstream actions enter their authoritative systems

Outputs

• Decision-first architecture review brief
• Options, criteria, recommendation, and tradeoff view
• Evidence, assumption, dissent, risk, and exception summary
• Disposition, conditions, actions, and accountable owners
• Inputs for the governed business architecture decision record

Use when

• A starter charter has been approved and must become an operating practice
• Business architecture is new or virtual and demand exceeds practitioner capacity
• Stakeholders do not know when or how to engage the practice
• The team risks beginning with a large metamodel, tool program, or unfunded center of excellence

Inputs

• Approved BA charter, mandate, boundaries, sponsor, and review date
• Enterprise priorities and a small set of visible decision scenarios
• Current strategy, portfolio, delivery, architecture, data, risk, and operating forums
• Practitioner capacity, skills, funding, tooling, and repository constraints
• Business content owners, existing architecture knowledge, and adoption or decision-quality evidence

Moves

1. Translate the charter into a small service model organized around recurring decisions rather than a catalog of diagrams
2. Define proportionate intake, triage, engagement thresholds, escalation, refusal criteria, and expected response based on value, risk, scope, and capacity
3. Select one or two bounded decision scenarios that can produce visible value and reusable enterprise knowledge
4. Establish the minimum method, vocabulary, identifiers, evidence, status, ownership, version, publication, and review rules needed for those scenarios
5. Assign roles and handoffs across the practice, business content owners, portfolio, strategy, operations, delivery, and technical architecture without duplicating their authority
6. Embed architecture evidence into existing forums and workflows rather than creating a parallel governance layer by default
7. Choose working and authoritative tools according to knowledge lifecycle and consumer need, deferring repository expansion until recurring demand justifies it
8. Measure decisions improved, ambiguity removed, dependencies found, rework avoided, reuse achieved, cycle time, and stakeholder adoption rather than maps produced
9. Review the operating model at the charter checkpoint and expand, narrow, fund, redesign, or stop services based on demand, capacity, governance, and observed value

Outputs

• Decision-centered BA service model
• Intake, triage, engagement, escalation, and refusal rules
• Minimum method, knowledge, and publication standards
• Forum integration, roles, and handoff model
• Capacity, adoption, decision-quality, and practice-review measures

Use when

• Models and decisions are recreated for every initiative
• Different teams use conflicting names, definitions, identifiers, or statuses
• Search, reporting, analytics, or AI cannot reliably distinguish authoritative knowledge from working material
• An engagement is approaching publication, handoff, reuse, review, supersession, or retirement

Inputs

• Working models, notes, sources, decisions, dissent, assumptions, and unresolved issues
• Canonical vocabulary, identifiers, metamodel, relationship rules, and repository boundary
• Content owners, decision authorities, consumers, access needs, and stewardship capacity
• Required statuses, effective dates, confidence, provenance, retention, review, and retirement rules
• Existing authoritative records, duplicates, downstream links, and publication channels

Moves

1. Inventory the working output and distinguish observation, source evidence, interpretation, assumption, proposal, approved fact, decision, rejected option, and historical material
2. Determine which knowledge is durable, reusable, relationship-rich, and worth governing beyond the source engagement
3. Normalize names, definitions, identifiers, levels, aliases, and relationship types against the existing baseline without erasing legitimate context or dissent
4. Attach source, owner, decision authority, status, effective date, confidence, scope, applicability, and review trigger to every consequential element and relationship
5. Resolve, cross-reference, quarantine, or retire duplicates and conflicting records rather than silently overwriting them
6. Place authoritative content, linked references, working material, and specialist records in their appropriate systems according to recipe 30
7. Publish decision-appropriate views while preserving the underlying governed relationships, access controls, provenance, and version history
8. Notify affected consumers and update strategy, portfolio, initiative, requirement, process, information, organization, technology, and decision links that depend on the change
9. Assign continuing stewardship, review, supersession, archival, and retirement actions, then verify that a future consumer can interpret the record without reconstructing the workshop

Outputs

• Governed architecture elements and typed relationships
• Source, status, scope, confidence, ownership, and effective-date metadata
• Duplicate, conflict, assumption, and unresolved-issue dispositions
• Consumer-specific published views and downstream traceability
• Change, review, supersession, archive, and retirement record

Use when

• A new or virtual BA practice needs a clear mandate
• Sponsors and practitioners describe the practice differently
• Mapping work is starting before ownership and governance are settled

Inputs

• Enterprise priorities and business needs
• Executive sponsor and initial decision scenario
• Current planning, portfolio, and architecture forums
• Available practitioner capacity
• Known business owners and subject-matter experts

Moves

1. Define business architecture in language the organization will recognize
2. State the purpose, value proposition, and first objectives of the practice
3. Name the initial scope, explicit non-scope, and first use case
4. Assign the sponsor, practice lead, business content owners, contributors, and decision rights
5. Set the minimum principles, standards, engagement path, and review cadence
6. Define measures based on decisions improved, reuse created, and adoption achieved
7. Obtain sponsor approval and schedule a 90-day charter review

Outputs

• One- or two-page BA starter charter
• Role and decision-rights summary
• Initial service and engagement model
• First 90-day priorities
• Measures and review date

Use when

• Different teams use different names for the same business concept
• An imported glossary or tool inventory has produced hundreds of weakly defined objects
• Ownership and lifecycle responsibilities cannot be assigned consistently
• Automation, analytics, integration, or AI work needs stable business meaning

Inputs

• Current object list with definitions and sources
• Representative value streams, scenarios, and business rules
• Capability map
• Relevant glossaries, policies, reports, interfaces, and data models
• Business content owners and subject-matter experts

Moves

1. State the decision and scope, then define what will count as a business object for this effort
2. Place every term in a working register with its source and local usage before deleting or merging anything
3. Classify each term as a canonical candidate, synonym, specialization, parent, attribute, state, event, representation, actor, organization, or system
4. Write singular business definitions and compare lifecycle, rules, and meaning before merging apparent duplicates
5. Use parent-child relationships only when a subtype inherits the parent definition and adds stable business rules
6. Map canonical objects to where they are created, changed, referenced, transferred, and retired, then link those changes to capabilities
7. Assign a steward and decision owner, preserve accepted aliases, and record the rationale for disputed terms
8. Publish a thin governed baseline and place unresolved or low-value terms in a visible backlog

Outputs

• Canonical business-object register
• Alias and source-term crosswalk
• Object relationship and lifecycle view
• Object-to-capability ownership matrix
• Decision log and rationalization backlog

Use when

• A rationalized object model needs to support ownership or change decisions
• Teams disagree about where information is created or which source is authoritative
• An initiative changes information across several capabilities or value-stream stages
• Integration, automation, analytics, or AI work needs business context before solution design

Inputs

• Canonical business-object register and accepted aliases
• Capability map with definitions
• Value streams with stage entry and exit criteria
• Representative scenarios, events, rules, and state changes
• Business stewards, capability owners, and subject-matter experts

Moves

1. State the decision and select only the business objects, capabilities, and value streams relevant to it
2. Define the meaningful lifecycle states and business events for each object rather than copying technical create, read, update, and delete operations
3. Locate where each object is created, received, changed, referenced, transferred, retained, and retired across the value stream
4. Link every material lifecycle action to the capability that performs or governs it, then distinguish the producer, authoritative steward, consumer, and technical custodian
5. Test whether stage entry and exit criteria depend on the object reaching a particular state or quality threshold
6. Expose missing ownership, duplicate capture, conflicting authority, uncontrolled handoffs, and capabilities that depend on information they cannot reliably obtain
7. Validate the relationships against normal, exception, and cross-business-unit scenarios
8. Record relationship status, evidence, owner, and review date in the governed architecture repository

Outputs

• Business-object lifecycle map
• Object-to-capability relationship matrix
• Object-to-value-stream-stage cross-map
• Stewardship and authority assignments
• Information dependency, duplication, and control issues

Use when

• Teams disagree about whether a capability needs another level
• Heat-map scores hide materially different problems inside one capability
• Initiative scope or investment cannot be traced precisely enough
• Lower-level capabilities begin to resemble processes, roles, applications, or organizational units

Inputs

• The decision or use case requiring decomposition
• Current capability map and definitions
• Representative value streams and scenarios
• Business objects and lifecycle changes
• Available ownership, performance, investment, and dependency evidence

Moves

1. State which decision requires more detail and limit decomposition to the affected branch
2. Define a level contract for the map so peer capabilities are expressed at comparable breadth
3. Propose child capabilities from distinct outcomes, business-object lifecycles, rules, or reusable abilities rather than current organization or workflow
4. Test whether the children collectively explain the parent, are meaningfully distinguishable, and remain at a consistent level
5. Keep a child separate only when doing so could change assessment, investment, accountability, dependency, sequence, risk, or another formal decision
6. Compare the proposed branch with peer branches to expose false precision and uneven depth
7. Write definitions and boundaries before adding scores, owners, or initiative mappings
8. Validate the branch against multiple scenarios and record deferred decomposition rather than filling the map preemptively

Outputs

• Decision-relevant decomposed capability branch
• Level contract and decomposition rules
• Candidate-child decision matrix
• Definitions and boundary notes
• Deferred-decomposition backlog

Use when

• Capability names mirror the current reporting structure
• The same business ability appears under several departments
• Reorganizations or system changes make the map unstable
• The map contains useful definitions and relationships that should not be discarded

Inputs

• Current map, definitions, sources, consumers, and known uses
• Organization, process, application, product, and information inventories as evidence
• Business model, value streams, business objects, strategies, and representative scenarios
• Modeling rules and the decision the repaired map must support
• Business content owners and practitioners familiar with the existing map

Moves

1. Preserve a versioned copy of the current map and identify which decisions, reports, and repository relationships depend on it
2. Define a capability test based on an enduring business ability, stable business meaning, and independence from who performs it or how it is implemented
3. Classify every existing element as a capability candidate, organization, role, process, activity, application, product, business object, outcome, or unresolved term
4. Rewrite valid candidates in neutral business language and retain source terms as aliases so stakeholder vocabulary is not lost
5. Merge duplicated abilities across departments only after comparing definitions, outcomes, business objects, rules, and lifecycle responsibilities
6. Rebuild parent-child structure using coherent business scope, value delivery, and information lifecycles rather than the organization hierarchy
7. Relate organizations, processes, applications, and owners back to the repaired capabilities instead of embedding them in capability names
8. Test the repaired map against several business scenarios and a hypothetical reorganization to expose remaining structural dependence
9. Migrate downstream mappings deliberately, record changed identifiers and rationale, and publish unresolved terms as governed issues

Outputs

• Repaired capability map and definitions
• Legacy-to-canonical crosswalk
• Reclassified organization, process, system, and information elements
• Duplicate and unresolved-term log
• Downstream relationship migration plan

Use when

• Executives have stated a direction but portfolios cannot translate it consistently
• Different functions interpret the same strategic phrase in incompatible ways
• Initiatives claim strategic alignment without a traceable contribution
• Architecture is asked for a target state before the strategic outcome is operationally defined

Inputs

• Authoritative strategy statement, source, sponsor, and time horizon
• Relevant drivers, assessments, constraints, and assumptions
• Stakeholders, value propositions, and performance evidence
• Capability, value-stream, information, organization, and initiative baselines
• Existing objectives, measures, and investment commitments

Moves

1. Confirm the exact strategy statement, its owner, intended decision, scope, and time horizon before interpreting it
2. Translate aspirational language into observable stakeholder and enterprise outcomes, including what would count as failure
3. Identify the drivers, assumptions, constraints, and strategic choices embedded in the statement and flag language that remains ambiguous
4. Locate the affected value streams and the stages where outcomes must materially change
5. Identify the capabilities that must be created, improved, sustained, or retired and assess the relevant current-state gaps
6. Add the business objects, policies, organization, decision rights, measures, and technology dependencies required for those capability changes
7. Develop candidate intervention options and initiatives without prematurely selecting a preferred solution
8. Create traceability from the strategy statement through outcomes, measures, value stages, capabilities, gaps, and candidate investments
9. Return the translation to the strategy owner for prioritization, correction, and explicit decisions

Outputs

• Operational strategy statement and outcome definitions
• Strategy-to-value-stream and capability map
• Current-state gaps and dependency view
• Outcome measures and assumptions
• Candidate intervention options and decision agenda

Use when

• Recipe 36 or another portfolio review identifies a specific initiative pair or cluster for investigation
• Several initiatives claim similar outcomes, benefits, capability changes, or value-stream effects
• Teams compete for the same information, platform, policy, organization, funding, capacity, or subject-matter dependency
• Portfolio authorities need an evidence-backed merge, sequence, narrow, share, retain, defer, or stop decision

Inputs

• Named initiative pair or cluster, reason flagged, decision owner, forum, and required date
• Charters, scope, outcomes, measures, benefits, sponsors, timing, cost, capacity, status, and commitments
• Capability, value-stream, stakeholder, information, organization, product, policy, process, and technology mappings
• Dependencies, shared foundations, predecessor or successor relationships, and transition assumptions
• Portfolio constraints, formal authority, owner positions, and evidence confidence

Moves

1. State the exact overlap question and limit analysis to the flagged pair or cluster rather than rebuilding the full portfolio heat map
2. Normalize each initiative into its intended outcome, business change, measurable contribution, accountable owner, boundary, and completion condition independent of its project name
3. Compare capability changes and value-stream effects at consistent levels, distinguishing primary change from supporting dependency or common enterprise context
4. Add shared stakeholders, business objects, policies, products, processes, organizations, technologies, capacity, timing, funding, and benefit claims
5. Classify the relationship as duplicate, complementary, conflicting, enabling dependency, deliberate resilience, shared foundation, capacity contention, or superficial similarity
6. Test whether apparently separate benefits are additive, double-counted, mutually dependent, ownerless, or realized at different stages and times
7. Compare dispositions including merge, narrow, resequence, share a foundation, coordinate, deliberately retain, defer, or stop, with consequences for value, risk, cost, capacity, timing, and reversibility
8. Bring the evidence and options to the existing portfolio authority, preserving dissent and distinguishing the architect’s recommendation from the investment decision
9. Record the disposition, affected scope, owners, conditions, benefit changes, dependency actions, downstream updates, and reconsideration trigger

Outputs

• Decision-scoped initiative comparison
• Classified overlap, conflict, dependency, or resilience finding
• Benefit, scope, ownership, timing, and capacity analysis
• Disposition options and architecture recommendation
• Governed portfolio decision and downstream actions

Use when

• A new initiative or strategy needs an initial architecture frame
• Stakeholders describe different problems or boundaries
• A sponsor expects a workshop but has not defined the decision it should support
• The architect needs evidence across several business architecture domains

Inputs

• Decision question, decision owner, and required date
• Available strategy, initiative, process, data, policy, and performance material
• Participant roles and known stakeholder positions
• Working hypotheses, assumptions, constraints, and open questions
• Session duration and collaboration method

Moves

1. Define the decision, the minimum outputs, and what the session will not attempt to resolve
2. Select the decision owner, business content owners, affected stakeholders, informed skeptics, and only the necessary technical participants
3. Send a short pre-read that separates known facts, working assumptions, disputed points, and focused preparation requests
4. Organize questions around outcomes, stakeholders, value stages, capabilities, information, organization, policy, technology, measures, dependencies, and timing
5. Prepare a working surface with dedicated areas for evidence, relationships, decisions, unresolved issues, and the parking lot
6. Facilitate from the decision outward, distinguish observation from interpretation, and resist premature solution detail
7. Close with a readback of decisions, disagreements, owners, due dates, and the evidence still needed
8. Convert the output into governed records and circulate a concise follow-up within the agreed window

Outputs

• Decision-centered session brief and agenda
• Participant and role map
• Structured working board or notes
• Decision, assumption, and issue log
• Named follow-up actions and governance path

Use when

• A new or materially revised capability map needs business review
• Definitions or boundaries are preventing consistent assessment and use
• Several business units must accept a shared baseline while retaining legitimate variation
• A model created from documents or reference material needs operational evidence

Inputs

• Decision, scope, level contract, and validation criteria
• Draft capability map, definitions, sources, and known issues
• Representative value streams, business objects, scenarios, and strategic uses
• Business content owners, subject-matter experts, informed challengers, and decision authority
• Pre-read, working board, timebox, and issue log

Moves

1. Define what the workshop is authorized to validate and what decisions will be deferred or escalated
2. Send the draft, modeling rules, disputed areas, and focused preparation questions before the session
3. Select participants who collectively understand end-to-end value delivery, information lifecycles, policy, and local variation rather than inviting only organizational leaders
4. Begin with the capability concept, level contract, and intended use so comments can be tested against common criteria
5. Review the model branch by branch, testing each name, definition, boundary, parent-child relationship, duplication, and omission against representative scenarios
6. Redirect roles, teams, systems, activities, and ownership arguments into supporting evidence without allowing them to redefine a capability
7. Classify every challenge as an accepted change, rejected change with rationale, evidence request, modeling-rule question, ownership issue, or decision requiring escalation
8. Separate participant agreement from formal content approval and assign every unresolved item an owner, evidence need, decision forum, and due date
9. Close with a readback of approved changes, disagreements, assumptions, and the publication and governance path

Outputs

• Validated capability map and definitions
• Change and rationale log
• Known disagreements and evidence requests
• Ownership and escalation assignments
• Publication status and review date

Use when

• Capability maps contain near-duplicates or competing local terms
• A merger, reorganization, or shared-service effort exposes inconsistent language
• Ownership discussions are being disguised as modeling disputes
• A common capability must accommodate legitimate regulatory, product, regional, or operating-model variation

Inputs

• Competing names, definitions, sources, and examples of use
• Relevant capability parents, children, and modeling rules
• Value streams, outcomes, business objects, lifecycle changes, rules, and stakeholders
• Representative normal and exception scenarios
• Content owners, decision rights, and escalation forum

Moves

1. State the decision the definition must support and separate terminology, scope, and ownership questions before debating a preferred name
2. Collect how each group uses the term in actual decisions, rules, measures, scenarios, and relationships rather than relying on labels alone
3. Rewrite each definition in neutral business language and compare outcomes, business objects, lifecycle responsibilities, value delivered, and enduring business rules
4. Treat terms as synonyms when their business meaning and boundary are materially the same, then select a canonical term and preserve accepted aliases
5. Model specialization only when the proposed child is a true kind of the parent, inherits its meaning, and adds a stable business distinction that changes governance or decisions
6. Treat local implementations as variations of one capability when the enduring ability is shared but organization, process, policy, technology, or performance differs
7. Retain separate capabilities when they produce distinguishable outcomes, govern materially different lifecycles or rules, and can be assessed or changed independently
8. Expose organizational dialect and ownership incentives explicitly so they do not distort the semantic decision
9. Record the decision, rationale, examples, aliases, steward, effective date, and conditions that would trigger reconsideration

Outputs

• Canonical capability definition and boundary
• Alias, specialization, or variation mapping
• Scenario-based decision rationale
• Ownership issues separated from semantic issues
• Governed decision record and review trigger

Use when

• Leaders need to prioritize capability investment or improvement
• Several assessments use incompatible scoring rules
• Strategic importance and current performance are being collapsed into one color
• Stakeholder opinion is the only visible basis for a portfolio recommendation

Inputs

• Decision, audience, scope, and investment horizon
• Governed capability map and definitions
• Strategic outcomes and value-stream impacts
• Performance, risk, cost, maturity, customer, workforce, and dependency evidence
• Assessment owners, evidence dates, and confidence criteria

Moves

1. Define the decision the heat map must support and exclude dimensions that cannot influence it
2. Keep strategic importance, current performance, change urgency, risk, investment exposure, and evidence confidence separate unless a documented decision rule combines them
3. Define each dimension, scale, threshold, evidence requirement, and treatment of missing data before scoring begins
4. Assess capabilities at the lowest consistent level that can change the decision and avoid mixing scores from uneven levels
5. Record the source, date, rationale, assessor, and confidence for every material score
6. Calibrate scores across business units and assessors using common examples, challenge sessions, and reconciliation of outliers
7. Normalize only where comparison requires it, preserve significant variation, and avoid averages that conceal a critical weakness
8. Present layered views that distinguish observed condition from strategic judgment and make uncertainty visible
9. Translate the findings into a small set of investment, validation, or ownership decisions and define the reassessment trigger

Outputs

• Decision-specific capability heat map
• Assessment dimension and scoring guide
• Evidence and confidence register
• Calibration and exception log
• Prioritized decisions and reassessment plan

Use when

• An initiative needs a defensible first release or minimum viable scope
• Stakeholders are adding features without showing incremental value
• A technical foundation is being described as a business outcome
• Funding or capacity requires a smaller release without creating an operational dead end

Inputs

• Intended business outcome, stakeholders, value hypothesis, and measures
• Affected value streams, capabilities, business objects, policies, and organization
• Required technology, controls, adoption, and operating ownership
• Dependencies, constraints, cost, capacity, risk, and timing evidence
• Candidate scope items and quantified benefit assumptions

Moves

1. Define the stakeholder outcome and total expected value independently of the proposed feature list
2. Identify the smallest end-to-end value slice that can be used in real operations and measured after release
3. Map the value-stream stages, capability changes, information states, policies, roles, controls, and technology needed to make that slice complete
4. Separate indispensable dependencies from conveniences, future scale needs, speculative reuse, and gold plating
5. Estimate the share of expected value, cost, risk, adoption burden, and learning produced by several credible scope options
6. Prefer the option that captures substantial value and evidence while preserving safe extension, reversibility, and operational coherence
7. Include training, decision rights, support, data stewardship, controls, and a named operating owner rather than treating deployment as completion
8. Place deferred scope in a governed backlog with the value condition or evidence that would justify adding it
9. Set release measures, decision gates, and a post-release review that can expand, change, or stop the initiative

Outputs

• Smallest useful release definition
• End-to-end value and capability slice
• Required dependency and operating-model scope
• Deferred-scope register with inclusion triggers
• Value measures and post-release decision gate

Use when

• A strategic initiative has stopped advancing despite continued meetings
• The stated blocker changes from one reporting cycle to the next
• Architecture work is complete but no accountable actor is moving the decision forward
• Leaders need to decide whether to unblock, reframe, pause, preserve, or stop the effort

Inputs

• Strategy, intended outcomes, measures, and original decision record
• Initiative charter, funding, governance, milestones, dependencies, and status history
• Capability, value-stream, organization, information, policy, and technology impacts
• Sponsor, owner, delivery, and dependency interviews
• Known assumptions, constraints, risks, and competing commitments

Moves

1. Restate the intended outcome, current decision, and last verifiable point at which the initiative advanced
2. Reconstruct the decision and dependency history from evidence, distinguishing committed dates from aspirations and reported symptoms from actual constraints
3. Test sponsorship, strategic clarity, quantified value, funding, decision rights, capability ownership, capacity, policy, dependencies, solution feasibility, and organizational incentives as separate blocker categories
4. Identify the current limiting constraint and determine whether other cited problems would still block progress if it were removed
5. Map the actor or forum with authority to resolve the constraint and assess whether that actor has the information, incentive, capacity, and mandate to act
6. Develop bounded options to unblock, narrow, resequence, reframe, pause, or stop the initiative, including consequences and reversible next steps
7. Present a decision brief that names the blocker, evidence, owner, required decision, deadline, and what will happen if no decision is made
8. If the initiative pauses or stops, preserve reusable architecture knowledge while retiring obsolete scope, assumptions, and target-state claims
9. Set a review trigger based on changed evidence or authority rather than continuing indefinite status meetings

Outputs

• Evidence-based blocker diagnosis
• Decision and dependency history
• Authority and incentive map
• Recovery, pause, or termination options
• Decision brief and architecture-preservation actions

Use when

• An initiative is too broad to govern or sequence coherently
• Several workstreams claim the same outcome or depend on unowned foundations
• Delivery decomposition obscures cross-functional business change
• Leaders need manageable investment decisions before detailed project planning

Inputs

• Initiative outcomes, measures, scope, constraints, and decision rights
• Capability and value-stream impact assessments
• Stakeholders, business objects, policies, organization, and technology dependencies
• Current initiatives, commitments, funding boundaries, and delivery capacity
• Transition risks, sequencing assumptions, and operating ownership

Moves

1. Restate the initiative as measurable business outcomes and establish the boundary that decomposition must preserve
2. Map the affected value-stream stages, capability changes, stakeholders, information lifecycles, policies, organization, and enabling technology
3. Identify coherent change packages around a distinct business outcome, capability transition, value slice, or reusable prerequisite rather than the current org chart
4. Give each package a purpose, scope, exclusions, accountable business owner, measures, architecture impacts, and completion condition
5. Expose interfaces and dependencies among packages, distinguishing true prerequisites from preferred sequencing and shared constraints
6. Separate foundational and enabling work from value-producing releases while tracing each foundation to the outcomes that justify it
7. Sequence packages using value, dependency, risk, capacity, learning, and reversibility rather than assumed calendar order
8. Test the decomposition for gaps, duplicated scope, stranded dependencies, conflicting ownership, and packages too large to govern
9. Hand the architecture-backed packages to portfolio and delivery authorities for funding, planning, resourcing, and committed dates

Outputs

• Architecture-backed initiative decomposition
• Work-package charters and boundaries
• Outcome and capability coverage matrix
• Dependency and sequencing view
• Ownership, measures, and portfolio decision points

Use when

• Leadership needs an investment sequence across several capability gaps
• A target-state capability assessment exists but lacks a credible transition path
• Initiatives are being scheduled without shared business prerequisites
• Business architecture is expected to guide change without taking ownership of delivery planning

Inputs

• Strategic outcomes, priorities, measures, and planning horizon
• Current and target capability assessments
• Value-stream, stakeholder, information, policy, organization, and technology impacts
• Existing initiatives, constraints, dependencies, and investment commitments
• Capability owners and portfolio decision rights

Moves

1. State the decision, planning horizon, and level of precision the roadmap is authorized to provide
2. Describe the required capability outcomes and target conditions using measurable business terms rather than project completion
3. Identify gaps between current and target conditions and separate foundational, enabling, differentiating, and sustaining changes
4. Map dependencies among capabilities, business objects, policies, organization, skills, decisions, and technology
5. Sequence capability changes into evidence-based horizons or waves using prerequisites, value, risk, capacity, and reversibility
6. Map approved and candidate initiatives as delivery vehicles, then expose capability changes with no initiative and initiatives with no justified capability outcome
7. Assign business accountability, investment decisions, measures, assumptions, and review triggers to each roadmap horizon
8. Hand delivery teams the required outcomes and dependencies while leaving task plans, resource loading, sprint sequencing, and committed dates to accountable delivery governance
9. Review the roadmap when strategy, evidence, funding, or dependency conditions materially change

Outputs

• Capability change roadmap by horizon
• Current-to-target capability transition view
• Dependency and prerequisite map
• Initiative-to-capability coverage view
• Measures, decision points, owners, and review triggers

Use when

• Requirements have accumulated without clear business rationale
• Scope changes cannot be evaluated against intended value
• Delivery teams need business context without receiving another large architecture package
• Audit, governance, testing, or benefit realization requires end-to-end traceability

Inputs

• Requirement statement, source, status, owner, and acceptance criteria
• Initiative outcomes, scope, measures, and decision records
• Stakeholders, value streams, capabilities, business objects, rules, and policies
• Relevant design, implementation, test, and benefit records
• Traceability standards and repository identifiers

Moves

1. Normalize the requirement into a clear statement of need, condition, or constraint without embedding an unjustified solution
2. Identify the originating stakeholder need and measurable business outcome, recording the evidence and decision that authorized it
3. Link the requirement to the affected value-stream stage and capability change at the level needed to explain its business purpose
4. Connect relevant business objects, lifecycle states, rules, policies, controls, and organizational accountabilities
5. Trace the requirement to its initiative or release and classify whether it creates, improves, sustains, complies, mitigates, or retires business behavior
6. Challenge orphan requirements, many-to-everything mappings, duplicate requirements, and design choices presented as immutable business needs
7. Maintain forward links to solution decisions, acceptance tests, and realized measures without making the business architecture repository the system of record for delivery detail
8. Assess change requests by following the trace in both directions to reveal affected outcomes, architecture elements, dependencies, tests, and benefits
9. Record ownership, status, rationale, version, and review triggers for material relationships

Outputs

• Requirement-to-business-architecture trace
• Business rationale and authorization record
• Orphan, duplicate, and overconstrained requirement findings
• Change-impact relationships
• Traceability ownership and maintenance rules

Use when

• A request begins with “we need platform X”
• A vendor demonstration or executive preference is driving scope
• A renewal, consolidation, AI, or modernization decision is framed as a product comparison
• The proposed tool automates activity without addressing the underlying business constraint

Inputs

• Technology request and vendor or product material
• Desired outcomes, stakeholders, and measures
• Capability and value-stream baselines
• Business objects, rules, policies, and decision rights
• Current applications, cost, constraints, and operating ownership

Moves

1. Rewrite the technology request as a business outcome, decision, or observable problem without naming the product
2. Locate the stakeholder-value failure and the capabilities that cannot currently produce the required result
3. Test root causes across organization, policy, process, information, measurement, skills, capacity, and technology
4. Define business requirements, information lifecycles, decision rights, controls, and material quality attributes before assessing products
5. Compare viable responses including policy, organization, process, data, existing-platform, new-technology, staged experiment, and do-nothing options
6. Assess the proposed technology for capability fit, gaps, workarounds, duplication, integration, lock-in, security, total cost, transition risk, reversibility, and retirement impact
7. Define the operating-model and adoption changes required to realize value, including ownership after implementation
8. Make a recommendation with assumptions, measures, decision gates, and an exit condition rather than treating acquisition as success

Outputs

• Solution-neutral problem and outcome frame
• Capability and value-stream impact view
• Root-cause and option matrix
• Business-architecture technology-fit assessment
• Required operating-model changes
• Recommendation, measures, and decision gates

Use when

• The practice is new, virtual, or funded through a lower-level initiative
• Executive interest is absent or too general to constitute sponsorship
• Practitioners can access useful decisions but cannot claim enterprise authority
• Waiting indefinitely for ideal sponsorship would forfeit a credible bounded use case

Inputs

• Actual mandate, reporting line, capacity, and permission boundaries
• Reachable business owners and near-term decision scenarios
• Existing strategy, portfolio, governance, and architecture material
• Available evidence, repositories, and informal stakeholder network
• Risks created by incomplete authority or limited access

Moves

1. State the authority and constraints you actually have, including decisions you cannot make, content you cannot approve, and stakeholders you cannot represent
2. Choose one bounded decision with a reachable owner, visible value, manageable scope, and low dependence on unsupported enterprise mandates
3. Use existing forums, terminology, artifacts, and repositories where possible instead of presenting an unofficial enterprise operating model
4. Build only the minimum capability, value-stream, information, stakeholder, and initiative relationships needed to improve that decision
5. Attach source, confidence, scope, status, and provisional ownership to knowledge that has not received enterprise validation
6. Deliver a useful decision product and ask the accountable business owner to approve the decision, content, or next use rather than asking immediately for broad sponsorship
7. Measure reuse, ambiguity removed, dependency discovery, rework avoided, and decision improvement to create credible evidence for expansion
8. Develop lateral relationships with strategy, portfolio, operations, finance, product, and technology stakeholders while respecting formal channels
9. Define the conditions that justify seeking stronger sponsorship, additional capacity, or enterprise governance, and the conditions that require the work to stop

Outputs

• Bounded BA engagement and authority statement
• Minimum decision-support architecture
• Evidence, confidence, and provisional-ownership record
• Demonstrated-value measures
• Sponsorship case and expansion or stop triggers

Use when

• BA reports through enterprise or technology architecture
• Most engagements begin after a technology solution has already been selected
• Business-owned concepts are treated as temporary inputs to application design
• The BA team needs credibility with both business leaders and technical architects

Inputs

• Architecture mandate, operating model, funding, and reporting relationships
• Existing intake, portfolio, strategy, and design-governance forums
• Roles and decision rights across business, enterprise, solution, data, and technology architecture
• Current BA demand, capacity, artifacts, and stakeholder relationships
• One or more business decisions where BA can demonstrate value

Moves

1. Map the host organization as it actually operates, including formal mandates, funding incentives, intake paths, review gates, and informal influence
2. Define a practical BA service boundary around business outcomes, capabilities, value delivery, information meaning, organization, policy, initiatives, and operating-model choices
3. Clarify handoffs and shared responsibilities with enterprise, solution, data, security, and technology architects instead of relying on title distinctions
4. Select a small set of business decisions where BA can engage before solution framing and name a business sponsor or content owner for each
5. Create business-owned definitions, relationships, decisions, and measures that remain valid beyond the technology initiative that first funded them
6. Translate business architecture into technology implications while preserving the traceability back to stakeholder value and capability change
7. Insert BA evidence into existing strategy, portfolio, investment, and architecture forums rather than constructing a competing governance process
8. Measure decisions improved, reuse achieved, ambiguity removed, and downstream rework avoided, not the volume of diagrams produced
9. Build durable working relationships outside IT and review the mandate when repeated demand demonstrates a broader organizational role

Outputs

• BA mandate and service boundary
• Architecture role and handoff matrix
• Business-led engagement and sponsorship model
• Governed business knowledge separated from solution records
• Adoption measures and mandate review triggers

Use when

• A shared capability crosses product, regional, functional, or legal-entity boundaries
• Competing ownership claims are delaying standards, investment, or performance decisions
• A matrix organization has enterprise and local accountabilities
• The capability map assigns one owner but the operating model distributes real authority

Inputs

• Governed capability definition, boundary, and decomposition
• Relevant value streams, stakeholders, business objects, policies, and measures
• Organization model, charters, delegations, budgets, and governance forums
• Representative enterprise, local, and exception decisions
• Regulatory, fiduciary, contractual, or risk constraints

Moves

1. Name the exact decisions and accountabilities in dispute instead of asking who owns the capability in the abstract
2. Verify that the parties are discussing one enduring capability rather than duplicated definitions, specializations, or locally implemented variations
3. Separate semantic stewardship, strategic direction, investment authority, policy and control, performance accountability, operational execution, and architecture-content maintenance
4. Assign decision rights for each category using the existing operating model and legal obligations, naming one accountable authority where a decision truly requires one
5. Define where enterprise standards are mandatory, where local variation is permitted, and what evidence justifies an exception
6. Map incentives, budgets, measures, and consequences that may cause nominal owners to compete or avoid accountability
7. Use an existing executive or portfolio forum to resolve residual conflicts and record the rationale rather than creating a permanent architecture arbitration body
8. Publish the ownership pattern with escalation paths, review triggers, and the capability relationships affected by the decision
9. Test the arrangement against normal operations, cross-unit change, underperformance, and urgent exception scenarios

Outputs

• Capability decision-rights matrix
• Stewardship, accountability, and execution assignments
• Enterprise-standard and local-variation rules
• Escalation and exception path
• Governed ownership decision record

Use when

• A BA practice needs access to investment and prioritization decisions
• Portfolio intake is dominated by project, financial, or technology fields
• Leaders resist another governance forum or mandatory artifact
• Architecture findings arrive after funding and solution commitments have already been made

Inputs

• Current portfolio lifecycle, gates, calendars, roles, and decision rights
• Existing intake forms, business cases, scoring models, and required evidence
• Portfolio pain points, rework, delays, overlaps, and decision-quality measures
• BA capacity, governed knowledge, and priority decision scenarios
• Portfolio, finance, strategy, product, delivery, and architecture stakeholders

Moves

1. Map how portfolio decisions are actually made, including formal gates, pre-meetings, funding cycles, data sources, incentives, and informal veto points
2. Identify the smallest set of recurring decisions where capability, value-stream, stakeholder, information, or initiative-linkage evidence would materially improve the outcome
3. Embed that evidence into existing intake fields, business cases, scoring, and review materials using links to governed architecture rather than duplicate attachments
4. Define proportionate engagement thresholds so BA supports material cross-enterprise, high-risk, or strategically ambiguous changes without reviewing every request
5. Assign BA advisory, content-stewardship, and escalation responsibilities while preserving formal investment authority in the existing portfolio bodies
6. Move the engagement point upstream enough to influence problem framing, options, dependencies, and scope before solution and funding commitments harden
7. Pilot the approach with one decision forum and track cycle time, rework, overlap found, unsupported outcomes, dependency discovery, and decision traceability
8. Remove redundant BA checkpoints and parallel spreadsheets once the required evidence is reliably available in the portfolio workflow
9. Expand only when demand, capacity, decision improvement, and governance ownership justify broader adoption

Outputs

• Portfolio-to-BA integration map
• Minimum architecture evidence requirements
• Risk-based engagement thresholds
• Updated roles, intake fields, and review materials
• Pilot measures and scale-or-stop decision

Use when

• Selecting, configuring, migrating, or cleaning up an EA tool
• Teams disagree about the repository system of record
• Working files and approved architecture are mixed together
• Licensing, integration, usability, or maintenance capacity requires a defensible boundary

Inputs

• Priority decisions, questions, consumers, and reporting needs
• Current architecture content, repositories, working tools, and authoritative business systems
• Required element types, relationships, metadata, views, and lifecycle states
• Tool capabilities, integrations, licensing, security, retention, and performance constraints
• Content owners, stewards, authors, and maintenance capacity

Moves

1. Begin with the decisions and recurring questions the architecture knowledge must answer rather than the tool metamodel
2. Inventory candidate content and identify its current authority, owner, consumers, change frequency, sensitivity, volume, and retention need
3. Place knowledge in the EA tool when it is durable, reusable, relationship-rich, governed, and needed across more than one decision or initiative
4. Keep transient workshop material, detailed delivery plans, source documents, high-volume operational data, and specialist records in their appropriate working or authoritative systems
5. Classify each connection as native governed content, linked reference, synchronized attribute, derived view, or intentionally excluded material
6. Define the minimum metadata for repository content, including identifier, definition, owner, source, status, effective date, confidence, and review trigger
7. Use stable identifiers and integrations to preserve traceability without copying data that another system already governs
8. Pilot the boundary against representative impact, strategy, portfolio, ownership, and reuse questions, then measure authoring and maintenance effort
9. Migrate only content that meets the boundary rules, archive obsolete material, and assign ownership for continuing quality and retirement

Outputs

• EA repository scope and placement rules
• Content-to-system-of-record matrix
• Integration and linking pattern
• Minimum metadata and lifecycle standard
• Migration, archive, and ownership backlog

Use when

• Leadership is exploring a future business concept or strategic option
• A regulatory, market, acquisition, product, or operating-model possibility needs early analysis
• No initiative, funding, solution, or target organization has been approved
• Stakeholders need to compare options without treating a concept as a commitment

Inputs

• Concept statement, source, owner, decision, scope, and time horizon
• Drivers, intended outcomes, stakeholders, value propositions, and constraints
• Relevant current-state capabilities, value streams, information, organization, policies, and performance
• Known assumptions, uncertainties, scenarios, and disconfirming evidence
• Governance states for proposed, approved, deferred, and rejected content

Moves

1. Label the concept and every resulting element with its actual status so proposed intent cannot be mistaken for approved target state
2. Define the decision and time horizon the model must support, including the option to defer or do nothing
3. Describe intended stakeholder and enterprise outcomes and the value conditions that would justify proceeding
4. Identify the capabilities, value-stream changes, business objects, policies, organization, and measures the concept would require without assigning an implementation prematurely
5. Develop distinct scenarios or operating hypotheses and show which assumptions and dependencies make each viable
6. Relate the concept to current architecture to expose gaps, conflicts, reusable strengths, constraints, and effects on existing commitments
7. Mark uncertainty, confidence, evidence, owner, and validation need directly on consequential statements and relationships
8. Avoid naming target applications, processes, vendors, teams, or structures unless the decision specifically concerns those options
9. Produce the next decision agenda and govern the model through approval, revision, deferral, rejection, or transition into initiative architecture

Outputs

• Status-controlled concept architecture
• Outcome, stakeholder, capability, and value implications
• Scenario and assumption model
• Current-state impact and dependency view
• Evidence plan and next decision agenda

Use when

• An initiative closes without implementation or benefit realization
• A program is merged into another investment
• A repository contains project-created architecture with uncertain authority
• The underlying business problem or capability gap may outlive the initiative

Inputs

• Initiative artifacts, models, decisions, sources, and repository records
• Closure rationale, governance disposition, and effective date
• Validated business definitions, relationships, baselines, and findings
• Proposed target states, requirements, assumptions, options, and unresolved issues
• Enterprise content owners and retention obligations

Moves

1. Record the formal initiative disposition, rationale, authority, date, and relationship to any successor effort
2. Inventory the architecture created and distinguish validated enterprise knowledge from project scope, proposed change, implementation design, working assumptions, and superseded material
3. Promote durable definitions and relationships into governed enterprise records only when their evidence and ownership remain valid beyond the initiative
4. Preserve material decisions, rejected options, constraints, and lessons with provenance so future teams can understand why the path ended
5. Withdraw or clearly mark target states, roadmaps, requirements, scores, and mappings that depended on the cancelled scope or time horizon
6. Retain unresolved capability gaps and stakeholder needs as unfunded or unassigned conditions rather than implying that cancellation solved them
7. Repair links from portfolios, strategies, capabilities, value streams, requirements, and systems so they reflect the closure or successor initiative
8. Assign owners and review dates to retained knowledge and apply legal, regulatory, contractual, and records-retention rules
9. Publish a concise closure note that tells future consumers what remains authoritative, what is historical, and what was retired

Outputs

• Architecture disposition inventory
• Promoted enterprise knowledge
• Historical decision and rationale record
• Retired or superseded target-state content
• Residual gaps, ownership, and closure note

Use when

• A new initiative resembles earlier work
• Leaders want speed and consistency through reuse
• A shared pattern may cross products, regions, business units, or regulatory contexts
• Teams disagree about whether variation is waste or a legitimate business difference

Inputs

• Source architecture with provenance, status, decisions, and outcomes
• Target initiative outcomes, stakeholders, scope, scenarios, and constraints
• Governed enterprise definitions, standards, and variability rules
• Business objects, policies, organization, capabilities, value streams, and technology context
• Evidence about source performance and lessons learned

Moves

1. State the decision reuse is meant to accelerate and identify the source and target contexts explicitly
2. Separate governed enterprise definitions and relationships from source-specific scope, assessments, owners, processes, technology, and transition choices
3. Compare outcomes, stakeholders, value propositions, business-object lifecycles, policies, scale, risk, regulation, and operating conditions across both contexts
4. Classify each candidate element as reusable unchanged, reusable with adaptation, useful only as a reference, or inapplicable
5. Treat differences as legitimate variation when they change value, rules, risk, lifecycle, or accountability, and challenge variation supported only by habit or organizational preference
6. Reuse stable identifiers and relationships where meaning is shared, but reassess current state, performance, ownership, priorities, and dependencies for the target context
7. Validate adapted content with target business owners and affected enterprise stewards rather than relying solely on the source team
8. Record the reuse decision, adaptations, rejected assumptions, provenance, and conditions under which the pattern applies
9. Promote a repeatable enterprise pattern only after multiple contexts demonstrate both a stable core and governed variation points

Outputs

• Source-to-target context comparison
• Adopt, adapt, reference, or reject decisions
• Reusable core and variation rules
• Target-validated architecture
• Pattern provenance and applicability conditions

Use when

• A value stream is accumulating activities and swimlanes
• A capability assessment identifies a problem but not its execution cause
• Requirements depend on handoffs, timing, decisions, controls, or exception paths
• Stakeholders request a process map without stating the decision it must support

Inputs

• Decision, scope, audience, and required level of precision
• Relevant value-stream stages, capabilities, stakeholders, and business objects
• Known events, outcomes, rules, controls, handoffs, roles, measures, and exceptions
• Existing procedures, system behavior, evidence, and process ownership
• Expected consumers in operations, risk, design, requirements, or improvement

Moves

1. State the decision and test whether capability, value-stream, stakeholder, information, or policy views already provide sufficient evidence
2. Use a process model when the answer depends materially on sequence, responsibility, handoff, timing, branching, control, resource flow, or exception handling
3. Define a precise trigger, end outcome, scenario, boundary, level, and process owner before drawing activities
4. Link the process to its enabling capabilities, value-stream stage, participating stakeholders, business objects, rules, and measures
5. Model the normal path first, then add only exceptions and variants that change the decision or control design
6. Show accountable roles and system support without turning organizational units or applications into the business purpose of the process
7. Validate actual practice against documented procedure and record observed variation, evidence, risk, and unresolved ownership
8. Use the model to derive the required operational, policy, information, control, or solution decisions, then keep those decisions traceable
9. Set an owner and review trigger if the process will remain governed; otherwise retain it as time-bounded analysis and archive it after use

Outputs

• Decision-specific process model
• Trigger, outcome, boundary, and scenario definition
• Capability, value, information, rule, and role linkages
• Exception, control, and handoff findings
• Governance or archive disposition

Use when

• An engagement is expanding without a clear completion test
• Stakeholders keep requesting more detail after the decision is supportable
• Architecture deliverables are approaching handoff or publication
• The team needs to distinguish finished analysis from continuing knowledge governance

Inputs

• Decision, scope, audience, measures, and agreed stop condition
• Required architecture questions, artifacts, relationships, and evidence
• Open issues, assumptions, confidence, risks, and ownership
• Approval, publication, repository, and downstream-consumer needs
• Remaining work, expected decision value, capacity, and opportunity cost

Moves

1. Restate the decision and test whether the accountable decision maker has sufficient evidence, options, tradeoffs, and traceability to act
2. Confirm that work remains within the authorized scope and that every material conclusion has a source, status, confidence, and owner
3. Check that affected capabilities, value streams, stakeholders, information, organization, initiatives, policies, measures, and dependencies are linked only to the depth required
4. Disposition open items as resolve now, assign with a due date, accept as residual uncertainty, move to governance, or exclude with rationale
5. Validate that approved knowledge is separated from observations, assumptions, proposals, rejected options, and historical material
6. Confirm content ownership, decision rights, publication status, effective date, review trigger, and repository placement
7. Give downstream consumers the views, identifiers, boundaries, and decisions they need without transferring unnecessary modeling detail
8. Compare the likely decision value of additional work with delay, maintenance burden, and the opportunity cost of other architecture demand
9. Close the engagement with a decision record, handoff, residual-risk statement, and explicit conditions for reopening the architecture

Outputs

• Decision-sufficiency assessment
• Completed architecture package and decision record
• Open-item and residual-risk disposition
• Governed publication and ownership record
• Handoff, closure, and reopening criteria

Use when

• Portfolio leaders need an enterprise view of where change is landing
• Several initiatives claim different outcomes but affect the same capabilities
• Strategically important or underperforming capabilities may have no funded change
• Shared dependencies and organizational capacity are creating hidden portfolio risk

Inputs

• Governed capability map at a consistent level with definitions and owners
• Active and candidate initiatives with outcomes, scope, sponsor, status, timing, and material investment information
• Existing initiative mappings to strategy, value streams, stakeholders, information, organization, policy, and technology
• Capability importance, performance, risk, capacity, and evidence assessments
• Portfolio decision, planning horizon, inclusion rules, and accountable governance forum

Moves

1. State the portfolio decision, time horizon, organizational boundary, and initiative population before creating the matrix
2. Normalize every initiative into the outcome sought and the business change proposed so project names and technology labels do not drive the analysis
3. Select one decision-appropriate capability level and resolve mixed-level mappings before comparing investment concentration
4. Map each initiative to the capabilities it materially creates, improves, sustains, constrains, or retires, distinguishing primary change from supporting dependency
5. Record mapping source, confidence, owner, timing, status, and a proportionate indicator of effort or investment without treating count or spend as proof of importance
6. Aggregate the mappings by capability and overlay strategic importance, observed performance, risk, ownership, capacity, and material dependencies
7. Identify concentration, neglect, collision, sequencing dependency, duplicated enablement, unfunded gaps, and initiatives that do not trace to a justified capability outcome
8. Validate the patterns with capability and initiative owners to distinguish deliberate concentration or resilience from accidental duplication and contention
9. Bring the findings to the existing portfolio forum with explicit questions and options, then record decisions, assumptions, effective date, and review triggers

Outputs

• Capability-to-initiative matrix
• Investment and change-concentration heat map
• Neglected-capability and unsupported-initiative findings
• Overlap, dependency, sequencing, and capacity-contention view
• Portfolio questions, options, and governed decision record

Use when

• A cross-functional problem has no accepted owner or boundary
• Different stakeholders offer competing explanations for the same observed condition
• An initiative or technology has been proposed before the problem has been traced
• Local improvement risks moving cost, delay, risk, or failure somewhere else in the value stream

Inputs

• Observed problem statement with scope, baseline, magnitude, trend, timing, source, and accountable decision owner
• Affected stakeholders, expected value, service or performance measures, and representative scenarios
• Relevant value streams, capability map, business objects, organization, policies, and decision rights
• Process, technology, operational, financial, risk, and customer evidence available for the affected boundary
• Existing initiatives, requirements, prior decisions, assumptions, and competing causal hypotheses

Moves

1. Describe the observed condition without embedding an assumed cause or preferred solution, and establish its magnitude, boundary, timing, evidence, and decision owner
2. Identify who experiences the problem, what value or enterprise outcome is impaired, and which measures distinguish the current condition from the required one
3. Locate the value-stream stages where the condition becomes visible, where value first begins to degrade, and where consequences appear downstream
4. Map the capabilities enabling those stages and distinguish the capability where the symptom is observed from capabilities that may create, transmit, prevent, detect, or recover from it
5. Trace the material business objects, lifecycle states, information quality, policies, decisions, organizational accountabilities, processes, controls, capacity, skills, and technologies across the affected path
6. Develop more than one plausible causal explanation and record supporting evidence, disconfirming evidence, confidence, missing information, and the owner of the next test
7. Relate active initiatives and requirements to the problem trace to expose gaps, duplication, dependencies, displaced consequences, and solution-first work that does not address the observed constraint
8. Identify decision-relevant intervention points and compare policy, organization, information, process, capacity, technology, control, and do-nothing options without presenting architecture relationships as proof of causation
9. Return a concise problem trace to the accountable owner with the current evidence, viable explanations, next diagnostic actions, intervention options, and an explicit decision or escalation request

Outputs

• Evidence-bounded business problem statement
• Stakeholder-to-value-stream-to-capability problem trace
• Information, organization, policy, process, control, and technology relationship view
• Causal hypotheses with evidence, confidence, and disconfirmation tests
• Initiative coverage gaps and decision-ready intervention options

Use when

• Business units, consultants, or architecture teams maintain competing capability baselines
• A merger, reorganization, repository migration, or tool replacement requires a common capability view
• Portfolio or strategy analysis cannot compare work consistently across maps
• One map is more structurally sound while the other contains relationships and terminology the business already uses

Inputs

• Both versioned maps with definitions, levels, identifiers, sources, status, scope, owners, and modeling rules
• The decisions, consumers, reports, repository links, and governance obligations each map currently supports
• Representative value streams, business objects, outcomes, rules, products, policies, and business scenarios
• Organization, process, technology, assessment, initiative, and ownership relationships attached to both maps
• Reconciliation authority, canonical-content rules, decision criteria, migration constraints, and required date

Moves

1. Preserve both baselines and document their original purpose, scope, authority, construction method, consumers, strengths, and known limitations before changing either one
2. Define the reconciliation decision, canonical capability test, level contract, scope, and governance authority so comparison does not become a contest between labels or sponsors
3. Create a source-to-source crosswalk and classify each relationship as equivalent, synonym, broader, narrower, overlapping, specialized, legitimate variation, unmatched, or unresolved
4. Rewrite candidate definitions in neutral business language and compare outcomes, business-object lifecycles, enduring rules, value contribution, and representative scenarios rather than names alone
5. Resolve level differences explicitly when one map treats an element as a parent and the other treats it as a peer or child; do not force a false one-to-one correspondence
6. Separate capability meaning from embedded organization, process, role, product, application, and ownership constructs, then retain those elements as related evidence where useful
7. Select canonical identifiers, names, definitions, parent-child relationships, accepted aliases, and applicability or variation rules while preserving source provenance and rejected alternatives
8. Test the reconciled baseline against representative scenarios and migrate downstream strategy, initiative, assessment, value-stream, information, organization, ownership, and technology relationships deliberately
9. Record unresolved conflicts, decisions, rationale, owners, effective dates, consumer transitions, retirement status, and review triggers through the existing governance authority

Outputs

• Source-to-source capability crosswalk
• Reconciled canonical capability map and level contract
• Aliases, specializations, variations, unmatched elements, and governed conflicts
• Downstream relationship and identifier migration plan
• Reconciliation decision record, publication status, and retirement plan

Use when

• An architecture review, portfolio forum, or business owner makes a consequential choice
• A capability definition, ownership pattern, target state, exception, scope boundary, or investment implication is disputed
• Approval includes conditions, assumptions, residual risk, or required follow-through
• A prior decision may need to be reviewed, superseded, expired, or traced into downstream work

Inputs

• Exact decision request, accountable decision owner, formal authority, required date, and current status
• Business context, intended outcomes, scope, constraints, and affected stakeholders
• Architecture evidence with source, version, status, effective date, owner, and confidence
• Viable options, tradeoffs, recommendation, assumptions, dissent, risks, and disconfirming conditions
• Affected architecture elements, initiatives, requirements, repositories, downstream consumers, and applicable retention or access rules

Moves

1. State the decision as a choice or disposition rather than a discussion topic, and identify the accountable authority, decision forum, date, effective date, and status
2. Capture the minimum context needed to understand the problem, intended outcome, scope, boundary, constraints, and consequence of taking no action
3. Reference the specific architecture evidence used, preserving source, version, ownership, status, confidence, and material gaps instead of copying unsupported conclusions
4. Record the viable options and tradeoffs, including defer or do nothing where credible, and separate the architect’s recommendation from the accountable owner’s decision
5. Capture the disposition, rationale, conditions, dissent, accepted residual risk, assumptions, exceptions, and matters explicitly left unresolved
6. Link the decision to affected capabilities, value streams, stakeholders, information, organization, policies, initiatives, requirements, measures, and prior decisions at the depth needed for traceability
7. Assign required actions, owners, and due dates while keeping the decision record distinct from project plans, meeting minutes, and operational issue logs
8. Define the review, expiration, withdrawal, or supersession triggers and preserve prior versions so a changed decision does not erase its institutional history
9. Publish the record in its authoritative location, notify affected consumers, update governed relationships, and verify that conditions and downstream changes are tracked

Outputs

• Authoritative business architecture decision record
• Evidence, option, rationale, assumption, and dissent trail
• Conditions, actions, owners, and residual-risk register
• Affected-architecture and downstream-consumer traceability
• Review, expiration, supersession, and historical-version controls

Use when

• A connected architecture baseline includes capability, value, and information but lacks organization
• An initiative or operating-model decision crosses business units, legal entities, shared services, channels, or partners
• Ownership discussions confuse organizational participation, capability stewardship, investment authority, policy control, and operational execution
• Reorganization, outsourcing, acquisition, or ecosystem change requires a stable organization-to-architecture view

Inputs

• Decision, scope, scenarios, time horizon, and authoritative organization sources
• Current organization chart, legal-entity structure, business units, functions, shared services, channels, locations, partners, and contractual relationships
• Governed capabilities, value streams, stakeholders, business objects, products, policies, and measures
• Charters, delegations, budgets, decision rights, service agreements, and regulatory or fiduciary constraints
• Organization owners, capability stewards, value owners, and subject-matter experts

Moves

1. State the decision and define which organization types and relationships are relevant; do not import the entire HR structure by default
2. Create a governed organization catalog with stable identifiers, type, purpose, parent or affiliation, status, effective dates, authoritative source, and owner
3. Separate organizations from people, roles, teams, locations, channels, products, capabilities, processes, systems, and stakeholder categories while retaining necessary relationships
4. Model material structural, legal, service, funding, contractual, oversight, supplier, partner, and escalation relationships without treating one reporting hierarchy as the complete operating model
5. Map organization participation to value-stream stages and distinguish value owner, participant, provider, consumer, regulator, partner, and affected party where those distinctions change the decision
6. Map organizations to capabilities using explicit relationship types such as performs, governs, funds, sets policy, stewards content, supplies capacity, or consumes service instead of one ambiguous “owner” field
7. Add relevant business-object stewardship, policy authority, performance accountability, decision rights, capacity, location, product, and technology dependencies
8. Test the model against normal operations, cross-unit change, exception handling, reorganization, outsourcing, and external-partner scenarios to expose unstable or missing relationships
9. Validate the decision-relevant view, record conflicts and distributed authority, and publish the organization relationships with source, status, applicability, and review triggers

Outputs

• Governed organization catalog and relationship view
• Organization-to-capability participation and decision-rights matrix
• Organization-to-value-stream-stage map
• External-party, service, funding, policy, information, and capacity dependencies
• Accountability gaps, conflicts, provenance, and review triggers

Use when

• Recipe 19 or performance evidence identifies a capability that requires attention
• Leaders know a capability matters but disagree about the source of the gap
• A proposed initiative or technology is being treated as the improvement before operating constraints are understood
• Investment choices require a defensible comparison of intervention options rather than a generic maturity target

Inputs

• Named capability, definition, boundary, owner, required outcome, and decision
• Current and target performance measures, stakeholder and value-stream evidence, and time horizon
• People, skills, capacity, process, information, technology, policy, governance, organization, control, cost, risk, and dependency evidence
• Relevant business objects, value stages, products, initiatives, requirements, incidents, and prior decisions
• Assessment criteria, sources, confidence rules, subject-matter experts, and disconfirming evidence

Moves

1. Define the required capability outcome and observable gap without assuming that low maturity, technology, process, or organization is the cause
2. Bound the assessment to the scenarios, value stages, products, organizations, information states, and time horizon that matter to the decision
3. Establish a baseline using performance, demand, capacity, quality, cost, risk, customer, workforce, control, and dependency evidence rather than opinion alone
4. Assess people and skills, process and coordination, information and decision quality, technology enablement, policy and controls, governance and ownership, organization and incentives, capacity and resilience, and external dependencies as separate dimensions
5. Identify the current limiting constraints and test whether other observed weaknesses would still block the required outcome if the leading constraint were removed
6. Distinguish evidence from hypothesis, record confidence and disagreement, and specify what observation would disconfirm each material causal explanation
7. Develop intervention options across policy, organization, information, process, capacity, skills, governance, measurement, technology, sourcing, partnership, and do-nothing responses
8. Compare options using outcome contribution, dependency, adoption burden, risk, cost, timing, reversibility, operating ownership, and evidence strength without collapsing them into an unexplained composite score
9. Present the assessment to the accountable capability or investment authority and record the selected intervention, evidence plan, owner, measures, and review trigger

Outputs

• Capability outcome and gap definition
• Multidimensional capability constraint assessment
• Evidence, confidence, disagreement, and disconfirmation register
• Prioritized intervention options and dependency implications
• Improvement decision, measures, owners, and reassessment trigger

Use when

• Initiative impact is understood but the post-change operating responsibilities are not
• A technology or process design assumes that adoption and ownership will be resolved later
• Several organizations must coordinate new capability behavior, decision rights, information, or controls
• Delivery planning needs a business-owned target condition without asking business architecture to create the project plan

Inputs

• Approved outcomes, initiative impact, capability changes, value-stream effects, and measures
• Current operating model, organization map, capability ownership, value participation, and decision rights
• Required process, information, policy, control, product, technology, skill, capacity, service, and support changes
• Transition constraints, dependencies, sourcing or partner arrangements, regulatory obligations, and delivery assumptions
• Accountable business owner, operating leaders, content stewards, delivery authorities, and affected stakeholders

Moves

1. Restate the approved business outcome and identify the capabilities and value-stream stages whose enduring operation must change
2. Describe the current and required operating conditions for organization participation, accountability, decision rights, funding, incentives, skills, capacity, location, sourcing, and partner relationships
3. Define required business-object states, information quality, stewardship, access, timing, retention, and decision support
4. Identify the processes, handoffs, policies, controls, measures, products, services, channels, and technologies necessary to sustain the target capability behavior
5. Separate enterprise standards from legitimate local variation and state the authority, evidence, and exception path for each
6. Assign one accountable operating owner for the outcome and explicit stewardship, performance, policy, execution, support, and escalation responsibilities without forcing false single ownership
7. Assess transition obligations including workforce change, training, communications, data migration, control approval, service management, support, capacity ramp, parallel operation, and retirement
8. Compare credible operating-model options using value, cost, risk, resilience, scalability, adoption burden, reversibility, and dependency evidence
9. Publish the selected operating-model delta, unresolved decisions, readiness obligations, measures, owners, and review triggers for portfolio and delivery planning

Outputs

• Current-to-target operating-model delta
• Organization, decision-rights, capability, value, information, policy, process, product, and technology relationships
• Operating ownership, stewardship, support, and escalation model
• Transition, adoption, control, capacity, and retirement obligations
• Option decision, measures, unresolved issues, and review triggers

Use when

• An initiative claims benefits that are not traceable beyond delivery outputs
• Leaders need to decide whether to scale, adapt, continue, pause, or stop a released change
• Operational adoption and benefit ownership are separated from project governance
• Architecture and portfolio records must be updated using observed post-release evidence

Inputs

• Approved initiative outcomes, benefit assumptions, scope, release, and decision records
• Delivery outputs, adoption evidence, operating-model changes, and accountable operating owners
• Affected stakeholders, value-stream stages, capabilities, business objects, organization, policies, products, processes, and technologies
• Baseline, leading, operational, lagging, risk, cost, and customer measures with authoritative sources
• Expected timing, attribution assumptions, external influences, comparison conditions, and review authority

Moves

1. Separate delivery output, user or operational adoption, changed capability performance, value-stream effect, stakeholder outcome, and enterprise benefit as distinct claims
2. Build a trace from each material output through the required operating behavior and capability change to the value-stream stage and stakeholder outcome where value should become observable
3. Identify the information, policy, organization, process, capacity, skill, control, product, technology, and dependency conditions required for the chain to hold
4. Assign an accountable operating owner to each enduring outcome and distinguish project delivery accountability from adoption, performance, and benefit ownership
5. Establish baselines, leading adoption indicators, capability measures, value-stage measures, lagging outcomes, evidence sources, expected time lags, and disconfirming thresholds
6. Record attribution limits, competing explanations, external changes, displaced cost or risk, and downstream consequences so architecture linkage is not presented as proof of causation
7. Collect evidence at the agreed review points and compare observed adoption, performance, value, cost, risk, and stakeholder effects with the original hypothesis
8. Develop options to scale, adapt, remediate, resequence, preserve, retire, or stop the change and update expected benefits, dependencies, scope, and operating obligations
9. Record the decision and update strategy, portfolio, capability assessments, value streams, operating models, requirements, initiative status, and governed architecture knowledge

Outputs

• Delivery-to-adoption-to-capability-to-value realization trace
• Outcome, measure, baseline, timing, source, and ownership plan
• Operating conditions, dependencies, attribution limits, and disconfirmation tests
• Observed realization findings and displaced-consequence analysis
• Scale, adapt, remediate, retire, or stop decision with architecture updates

Use when

• A release or transition requires a business readiness decision
• Technical go-live criteria are complete but operating obligations remain fragmented
• The change crosses organizations, partners, policies, controls, information, products, or value-stream stages
• Leaders need an evidence-based release, limit, remediate, defer, or stop disposition

Inputs

• Release outcome, scope, operating-model delta, measures, and accountable decision authority
• Required capabilities, value stages, organizations, roles, skills, capacity, business objects, policies, controls, processes, products, and technologies
• Training, communications, staffing, support, service management, data migration, cutover, continuity, and retirement plans
• Test results, unresolved defects, exceptions, dependencies, risk acceptances, and evidence confidence
• Adoption, performance, control, customer, cost, risk, and escalation measures with owners and thresholds

Moves

1. State the business outcome, release boundary, readiness decision, authority, date, and permitted dispositions before reviewing checklists
2. Translate the operating-model delta into explicit readiness conditions for organization, accountability, skills, capacity, process, information, policy, control, product, partner, technology, support, continuity, and retirement
3. Assign an owner, evidence source, threshold, status, due date, and consequence to every material condition
4. Test end-to-end normal, exception, failure, peak-demand, cross-unit, partner, control, and recovery scenarios rather than accepting component readiness as enterprise readiness
5. Distinguish must-be-ready conditions from bounded post-release actions, and identify which exceptions require formal risk or authority outside business architecture
6. Assess adoption readiness, operating support, decision rights, data quality, monitoring, escalation, rollback, reversibility, and the ability to protect stakeholder value during transition
7. Expose dependency and capacity assumptions that delivery teams cannot control and obtain explicit commitments or contingency dispositions from their owners
8. Present release, limited release, remediate, defer, or stop options with residual risk, conditions, owners, timing, and expected effect on value
9. Record the disposition, update the decision record and operating model, and establish post-release adoption and value-realization reviews through recipe 43

Outputs

• Decision-specific business readiness assessment
• Readiness conditions, evidence, thresholds, owners, and status
• End-to-end scenario, dependency, exception, and residual-risk findings
• Release, limit, remediate, defer, or stop options
• Governed readiness disposition and post-release review plan

Use when

• A regulatory, legal, contractual, policy, audit, or control change crosses organizational or initiative boundaries
• Compliance work is framed as a system update without a business-impact model
• Several business units interpret the same obligation differently
• Leaders need to decide scope, ownership, sequencing, evidence, and operating readiness before the effective date

Inputs

• Authoritative obligation, source, jurisdiction or applicability, effective date, interpretation owner, and formal decision authority
• Current policies, controls, procedures, products, services, contracts, organization, capabilities, value streams, and business objects
• Affected stakeholders, legal entities, partners, channels, locations, systems, initiatives, and evidence repositories
• Known interpretations, assumptions, exceptions, penalties, risks, dependencies, and implementation constraints
• Legal, compliance, risk, operations, product, information, technology, delivery, and business content owners

Moves

1. Preserve the authoritative source and separate the obligation, internal interpretation, policy choice, implementation proposal, and evidence requirement
2. Confirm applicability by jurisdiction, legal entity, product, stakeholder, channel, scenario, and effective date with the authorized legal or policy owner
3. Translate each material obligation into observable business behavior, outcome, prohibition, decision, control, information, retention, reporting, or evidence condition
4. Trace affected value-stream stages, capabilities, business objects and lifecycle states, organizations, stakeholders, products, processes, technologies, and external parties
5. Compare the required condition with current policy, control, performance, ownership, and evidence to identify gaps, conflicts, duplication, and legitimate variation
6. Assign policy authority, capability and operating accountability, content stewardship, control ownership, execution, monitoring, escalation, and exception decision rights
7. Develop implementation options and change packages across policy, organization, information, process, capacity, skills, product, contract, technology, control, and partner arrangements
8. Sequence decisions and changes using effective dates, prerequisites, risk exposure, testing, operating readiness, evidence production, and reversibility
9. Record interpretations, scope, decisions, exceptions, residual risk, measures, evidence, owners, review triggers, and downstream architecture updates without presenting architecture advice as legal counsel

Outputs

• Obligation-to-business-behavior interpretation trace
• Policy, capability, value-stream, information, organization, product, process, control, partner, and technology impact view
• Applicability, gap, exception, ownership, and evidence register
• Implementation options, change packages, dependencies, and readiness decisions
• Governed interpretation, decision, measure, and review record