TOGAF 10 Business Scenarios: 5-Step Creation Guide with SMART Example

What Is a Business Scenario in TOGAF 10?

In the TOGAF 10 Series Guide, a business scenario is defined as a complete description of a business problem , covering both business and architecture aspects. This allows individual requirements to be viewed in relation to each other within the context of the problem.

The technique requires business line managers and other stakeholders to participate early in the architecture project, securing their buy-in. Business scenarios also facilitate communication with vendors, especially since most implementations now rely on commercial off-the-shelf (COTS) solutions from multiple suppliers; customers can use scenarios to help vendors deliver appropriate solutions.

How to Create a Business Scenario: The Five-Step Model

TOGAF 10's business scenario creation model consists of five parts, differing slightly from the seven steps in TOGAF 9.2.

Step 1: Identify, Document, and Categorize the Driving Problem – Pinpoint the problem that motivates the scenario, write it down, and classify its priority.

Step 2: Identify and Document the Business and Technical Environment – Capture the relevant business context and technical landscape in the scenario model.

Step 3: Identify and Document the Desired Outcome (Result of Solving the Problem) – Define what success looks like; the outcome must meet SMART criteria (Specific, Measurable, Actionable, Realistic, Time-bound).

Step 4: Identify Human Actors (Participants) and Their Place in the Business Model – List the people involved and show where they fit in the business model.

Step 5: Identify Computer Actors (Computational Elements) and Their Place in the Technical Model – List the system components and show their positions in the technical model.

SMART Refinement Example: Consistent User Interface

The article provides a worked example where the initial goal is "provide a consistent user interface" described as: "A consistent user interface will ensure that all user-accessible functions and services appear and operate in a similar, predictable manner regardless of application or site. This will bring higher efficiency and fewer user errors, thereby reducing recovery costs."

To make this goal SMART, each criterion is examined and the goal is progressively refined:

1. Specific: The goal is already specific, but the listed measures can be made more concrete.

2. Measurable: The goal is measurable but vague; it is revised to: "This will result in a 10% increase in user efficiency, a 20% reduction in order-entry user errors, which in turn may lead to a 5% reduction in order-entry costs."

3. Actionable: The goal appears achievable; it is clear that UI consistency must be provided and can be handled by whoever delivers the user interface to user devices.

4. Realistic: The original goal may be unrealistic given today's use of PDAs at the user end. The goal is rephrased to "consistent user interface across user-interface devices providing similar functionality to ensure…" to avoid designs that hinder new technology adoption.

5. Time-bound: The original goal lacks a deadline. It is restated as "By the end of Q3, provide a consistent…"

The final SMART goal reads: "By the end of Q3, provide a consistent user interface on user-interface devices that provide similar functionality to ensure that all user-accessible functions and services appear and behave in a similar manner when using these devices in a predictable way, regardless of application or site. This will increase user efficiency by 10%, reduce order-entry user errors by 20%, thereby reducing order-entry costs by 5%."

Reference: TOGAF Series Guide