Business scenarios and problem framing

A business scenario is a TOGAF technique for discovering and documenting architecture requirements by telling a structured story about a real business problem. The technique is described in detail in TOGAF Series Guide G176.

A business scenario is not a user story. User stories describe a feature from the perspective of a single user. Business scenarios describe an enterprise situation involving multiple actors, environmental conditions, and systemic constraints.

A business scenario is not a strategy statement. Strategy statements describe where the organisation wants to go. Business scenarios describe the specific situation that makes change necessary, including the pain points, constraints, and actors involved.

A business scenario is not a requirements document. Requirements documents list what a system must do. Business scenarios describe the enterprise context from which requirements will later be derived. The scenario comes first; the requirements come later.

G176 describes a structured process for developing business scenarios. Here is the full set of steps, with a plain-language explanation of what each one produces.

Step 1: Identify, document, and rank the problem. Start by capturing the business problem or opportunity that the architecture must address. This is not a technology problem. It is a business situation that creates pain, risk, or missed opportunity. Rank it against other problems to establish whether it deserves architecture attention now.

Step 2: Identify the business and technical environment. Describe the current state of the enterprise as it relates to the problem. What systems exist? What processes are in place? What data flows occur? What regulations apply? The environment description anchors the scenario in reality rather than aspiration.

Step 3: Identify and document the desired objectives. What does "better" look like? The objectives must be specific enough that a governance body could later assess whether they have been achieved. "Improve digitalisation" is not an objective. "Reduce average connections response time from 90 days to 65 days by eliminating manual data re-entry at three handoff points" is an objective.

Step 4: Identify the human actors and their roles. Who experiences the problem? Who influences the outcome? Who controls the relevant decisions? Who is constrained by the current state? Actors are not limited to internal staff. They include regulators, customers, partners, and system operators. Notice how this connects directly to the stakeholder work from Module 9.

Step 5: Identify the computer actors and their roles. What systems, platforms, and data stores are involved in the current problem? What role does each one play? Where do systems create constraints, handoffs, or data-quality issues? This step captures the technical context that shapes architecture options.

Step 6: Identify and document the roles, responsibilities, and measures of success. For each actor (human and computer), document what they are responsible for, what authority they have, and how success is measured. This step prevents the scenario from becoming a narrative without accountability.

Step 7: Check for fitness for purpose and refine. Review the scenario with stakeholders to test whether it accurately represents the problem. Is anything missing? Are the actors correctly identified? Are the objectives realistic and measurable? Are the constraints accurate? Refine until the scenario is specific enough to design against.

The output of this process is not a requirements document. It is a shared, validated description of the enterprise situation that the architecture must address. That description becomes the foundation for scope decisions (Module 12), the Architecture Vision (Module 14), and the requirements that feed into every later ADM phase.

A surprising amount of weak architecture starts with a sentence that sounds strategic but explains very little. The business scenario technique helps by forcing the team to separate symptoms from root causes and root causes from actionable problem descriptions.

A symptom is what people complain about. "Our connections process is too slow." Symptoms are useful starting points but dangerous foundations for architecture because they do not explain why the problem exists or what causes it.

A root cause explains why the symptom exists. "Data is re-entered manually at three handoff points because the upstream system does not publish structured output." Root causes are more useful than symptoms but still do not provide enough context for architecture work.

A business scenario provides the full enterprise context: who experiences the problem, under what operating conditions, with which constraints, involving which actors and systems, and what better looks like. The scenario is the foundation the architecture team can design against.

Consider the difference in practice:

• Symptom: "Our connections process is too slow."
• Root cause: "Manual data re-entry at three handoff points."
• Scenario: "Applicants for new electricity connections in central London submit requests that pass through five handoff points between planning, network design, commercial assessment, and works scheduling. At two of those handoffs, data is re-entered manually from PDF attachments because the upstream system does not publish structured output. Average response time is 90 days against a regulatory target of 65 days. The planning team, network designers, commercial assessors, and works schedulers each depend on data quality at the previous stage but have no visibility of whether that data has been validated. Ofgem monitors connections performance and publishes league tables that affect the distributor's public reputation and regulatory standing."

The symptom gives you a complaint. The root cause gives you a clue. The scenario gives you actors, handoffs, data gaps, regulatory pressure, and a measurable threshold. That is enough to shape architecture scope.

Bad scenario work falls into two common patterns, and both fail for the same reason: they do not produce architecture-relevant reality.

Fiction-writing scenarios. The team produces a compelling narrative about a future state without grounding it in current actors, systems, constraints, or measurable outcomes. The scenario reads well but gives the architecture team nothing to design against. You can spot fiction-writing scenarios because they contain no specific system names, no specific process handoffs, and no measurable thresholds.

Slogan-recycling scenarios. The team rewrites the strategy document in scenario format without adding any new specificity. The scenario says "improve digitalisation" instead of describing which processes break, where data quality fails, and who is affected. You can spot slogan-recycling scenarios because they could apply to any organisation in the same sector without modification.

A sound scenario does not need to be cinematic. It needs to be disciplined. It must reveal who does what, under what pressure, with which constraints, and why the current arrangement is not good enough. The test is simple: could an architect read this scenario and explain what scope decisions follow from it? If the answer is no, the scenario is not ready.

Let us walk through the G176 steps using London Grid's connections modernisation as the worked example.

Step 1: The problem. London Grid's connections process takes an average of 90 days to respond to new connection requests, against an Ofgem performance target of 65 days. Performance has been declining for three consecutive quarters. The distributor is in the lower half of the regulatory league table for connections responsiveness, which affects its public reputation and regulatory standing.

Step 2: The environment. The connections process passes through five internal handoff points: initial application receipt, planning assessment, network design, commercial assessment, and works scheduling. Three separate systems are involved: the customer-facing application portal, the network planning tool, and the works management system. At two of the five handoffs, data is re-entered manually from PDF attachments because the upstream system does not publish structured output. The planning tool uses a legacy data format that pre-dates the current CIM standard. Ofgem publishes quarterly connections performance data that is visible to applicants, local authorities, and the general public.

Step 3: The objectives. Reduce average connections response time to 65 days or below within 18 months. Eliminate manual data re-entry at the two identified handoff points. Ensure all published connections performance data is accurate, timely, and traceable to a single authoritative source. Maintain network safety and operational continuity throughout the transition.

Step 4: Human actors.

• Connection applicants (developers, homeowners, businesses) who submit requests and experience the delay.
• Planning assessors who evaluate network capacity and determine whether a connection can be accommodated.
• Network designers who specify the physical works required.
• Commercial assessors who determine the cost and terms of the connection.
• Works schedulers who coordinate physical installation with field teams and contractors.
• Data stewards who are responsible for the quality of published performance data.
• Ofgem (the regulator) which monitors performance, publishes league tables, and can take enforcement action.
• NESO which requires planning data from London Grid for national network coordination.

Step 5: Computer actors.

• The customer application portal which receives connection requests and presents status information.
• The network planning tool which models network capacity but uses a legacy data format.
• The works management system which schedules physical installation work.
• The regulatory reporting system which compiles and publishes performance data for Ofgem.
• The GIS which holds the geographic location of network assets.

Step 6: Roles, responsibilities, and measures of success. The planning team is responsible for assessing capacity within five working days. Network design must produce specifications within ten working days. Commercial assessment must confirm terms within five working days. Works scheduling must allocate a delivery window within ten working days. The data steward is responsible for ensuring published performance data matches the authoritative source. Success is measured by the 65-day response-time target, the elimination of manual data re-entry, and the accuracy of published data.

Step 7: Refinement. The scenario was reviewed with the planning team, the operations director, the regulatory affairs lead, and the customer services manager. The review revealed an additional constraint: the works management system is shared with another programme that has a conflicting upgrade timeline. That constraint was added to the scenario.

This complete scenario now provides everything the architecture team needs to begin scope, stakeholder, and vision work. It names specific actors with specific responsibilities. It identifies concrete system limitations. It sets measurable objectives. It surfaces constraints that would otherwise be discovered too late.