Business Architecture Decision Record: Method & Template

The decision

Create and govern a business architecture decision record

A consequential architecture decision is buried in meeting notes, presentation slides, email, or memory, leaving later teams unable to tell what was decided, by whom, from which evidence, under what conditions, or when the decision should be reconsidered.

Decision supported

How a consequential BA decision, its authority, evidence, options, rationale, conditions, dissent, actions, and review triggers will remain authoritative.

Start with

The exact decision and authority, viable options, recommendation, evidence and confidence, affected architecture, conditions, actions, and retention rules.

Boundary

Preserves the BA decision; it does not replace formal corporate minutes, legal approvals, delegated authority, risk acceptance, or delivery governance.

When to use this method

• 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

Evidence to bring

• 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

The method

Work through the decision.

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

What the work should produce

• 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

Worked example · Northstar v1.1

Keep conditional authorization separate from procurement.

The fictional Northstar v1.1 Investment Council owns the funding decision. At the end of Episode A, the record distinguishes authorization of a bounded release from deferral of the platform purchase. These are the source case’s two initial decision entries.

DEC-001: Conditionally authorize A1/R1 within the $150,000–$300,000 planning band, subject to approved POL-01 and measure definitions, confirmed object owners and source statuses, purposeful branch selection, a readiness decision, and 30/90-day review gates.

DEC-002: Defer A3 enterprise scheduling-platform procurement. Reopen only after R2-quality repeatability evidence identifies material residual automation gaps and a separate business case compares vendor and non-vendor responses.

The release authorization does not silently authorize the platform. Keep conditions and reopening triggers attached to each decision, and preserve unresolved ownership questions as open items with named owners.

Editable template · Version 1.1

Architecture decision, ownership, and open-item record

Keep decisions, rationale, conditions, decision rights, accountable owners, evidence gaps, assumptions, conflicts, review triggers, and closure dispositions in one governed record.

Inside the workbook

• Read me and governance rules
• Decision record
• Ownership and decision-right register
• Open-item log with due-status formulas
• Completed Northstar example

Use it with your own evidence

1. Record the decision request before the meeting.
2. Capture disposition, rationale, conditions, and effective date.
3. Separate accountability, stewardship, contribution, and escalation rights.
4. Close open items with a disposition instead of silently deleting them.

Does not replace formal corporate minutes, legal approvals, records-management policy, delegated-authority schedules, or delivery issue systems.

Continue the work

What knowledge must be updated and when should the decision be reviewed, superseded, expired, or used to close the engagement?

• Recipe 08Turn workshop output into governed architecture knowledge
• Recipe 35Know when the architecture work is finished

Related Field Notes

• The Business Architect as Steward: Servant Leadership Without Surrendering Judgment
• Business Architecture Has a Power Problem

Reference material

• Business Architecture Governance ↗Business Architecture Guild · Account required
• Optimizing Risk Transparency ↗Business Architecture Guild
• Metrics for Evidence-Based Strategy Execution ↗Business Architecture Guild

Find Recipe 39 in the full Cookbook