Frameworks & Practices

Business Scenarios

3 min read

TL;DR

Business Scenarios are a TOGAF technique used to identify, structure, and validate business requirements. In Phase A, they help shape the Architecture Vision from business outcomes, actors, and constraints instead of jumping too quickly into technical design.

Why this matters in Phase A

Phase A depends on clear business requirements.

Business Scenarios give teams a structured way to capture those requirements and tie them to architecture direction.

That’s why TOGAF practice often uses this technique early in the ADM cycle.

What a business scenario is

A business scenario can be seen as:

  • a technique for discovering and agreeing business requirements
  • a deliverable artifact that documents the scenario clearly

The technique helps derive architecture characteristics from high-level business needs.

Core elements of a scenario

A strong scenario usually describes:

  • the underlying business problem
  • business and technology context where the problem occurs
  • desired business outcomes
  • human actors (people/roles)
  • computer or system actors that support those capabilities

If any part is weak, the resulting architecture direction tends to be incomplete.

SMART outcomes (practical quality rule)

TOGAF guidance often applies SMART thinking to scenario outcomes:

  • Specific: clearly states what must improve
  • Measurable: defines how success is measured
  • Actionable: supports concrete actions and planning
  • Realistic: feasible within real constraints
  • Time-bound: clear deadline or decision window

Typical development cycle

Business scenarios are usually built iteratively:

  1. plan
  2. gather information
  3. analyze
  4. document
  5. review with stakeholders
flowchart LR
    P["Plan"] --> G["Gather info"]
    G --> A["Analyze"]
    A --> D["Document"]
    D --> R["Review with stakeholders"]
    R -->|"refine until aligned"| P
    R -->|"good enough"| DONE["Use in Architecture Vision"]

Repeat until stakeholder understanding is good enough for decision-making.

Since context changes, scenarios should be reviewed and refreshed over time.

Where scenarios are used in ADM

Most commonly:

  • Phase A: frame Architecture Vision from business requirements
  • Phase B: deepen business architecture analysis
  • Requirements Management: keep requirement alignment current

In some engagements, the technique is also used in Preliminary work to shape architecture capability setup.

  • Use case: detailed interaction behavior, often software-focused
  • Business scenario: earlier, broader business-context framing
  • Business case: financial/value justification
  • Scenario planning: macro futures exploration

They can complement each other, but don’t confuse them — each serves a different purpose.

Benefits

  • creates a common language between business and architecture
  • keeps requirements connected to value outcomes
  • improves stakeholder buy-in by making intent explicit
  • reduces risk of solving the wrong problem

Exam note

  • Business Scenarios are a key TOGAF technique for capturing business requirements.
  • They are especially relevant in Phase A and Phase B.
  • The quality of outcomes (often using SMART criteria) strongly affects architecture quality.

Sources

Graph View

Backlinks