8.2 Business Scenarios

8.2 Business Scenarios

The Foundation syllabus asks you to briefly explain business scenarios. A business scenario is a technique for discovering and documenting business requirements, and for articulating an Architecture Vision that responds to them. In the 10th Edition it is described in the TOGAF Series Guide: Business Scenarios.

---

Why Business Scenarios Matter

A key factor in the success of any architecture is the extent to which it is linked to business requirements and demonstrably supports the enterprise in achieving its business objectives. Business scenarios help identify and understand business needs and thereby derive the business requirements the architecture must address. They are an important technique that may be used prior to, and as a key input to, the development of the Business Architecture.

A business scenario describes:

• A business process, application, or set of applications that can be enabled by the architecture
• The business and technology environment
• The people and computing components — called actors — who execute the scenario
• The desired outcome of proper execution

A good business scenario is also SMART:

The glossary's definition of an Objective uses the same wording: an organizational aim declared in a Specific, Measurable, Actionable, Realistic, and Time-bound way.

---

Creating a Business Scenario

TOGAF describes the technique as a set of activities:

1. Identify, document, and rank the problem driving the scenario
2. Identify the business and technical environment of the scenario and document it in scenario models
3. Identify and document desired objectives — the results of handling the problem successfully — and make them SMART
4. Identify the human actors (participants) and their place in the business model
5. Identify the computer actors (computing elements) and their place in the technology model
6. Identify and document roles, responsibilities, and measures of success per actor; document the required scripts per actor and the results of handling the situation
7. Check for fitness-for-purpose and refine only if necessary

Developing a business scenario is iterative: information is gathered, then analyzed, then reviewed with the business, and the cycle repeats until the scenario is good enough. A business scenario typically contains business scenario models (for example, business process, information flow, and actor interaction models) and descriptive text.

---

Where Business Scenarios Are Used in the ADM

Business scenarios also reveal early the nature and security considerations of information and service exchanges, which later drive interoperability requirements.

---

Business Scenarios Versus Use Cases

A business scenario works at the level of a business problem: the environment, human and computer actors, their roles and responsibilities, and SMART objectives for the business. A software use case or user story describes interactions with a particular system. Business scenarios come first, so the architecture is driven by business need rather than by a proposed technology solution.

Worked Enterprise Scenario: Omnichannel Retail Banking Loan Origination

To see how the Business Scenarios technique functions in practice, examine this enterprise case study from the financial services sector:

1. Context & Business Problem

A regional commercial bank is hemorrhaging retail loan customers to agile digital fintech lenders. The bank's current loan origination process requires an average of 14 business days from application intake to loan approval, resulting in a 45% application abandonment rate. Customers who start applications online are forced to visit physical branches with paper documentation, leading to widespread dissatisfaction and lost revenue.

2. Environment & Constraints

• Regulatory Mandates: Strict adherence to Fair Credit Reporting Act (FCRA), Anti-Money Laundering (AML), Know Your Customer (KYC), and Equal Credit Opportunity Act (ECOA) regulations.
• Technical Constraints: Core banking customer accounts reside on a legacy 1980s mainframe system accessible only via batch queues and terminal emulation interfaces.
• Channels: Mobile application, public web portal, and 240 physical branch offices.

3. Actors & Roles

• Retail Applicant (Customer): Wants rapid loan pre-qualification on mobile without branch visits.
• Branch Lending Officer: Spends 60% of work hours manually re-keying paper documents into internal systems.
• Credit Risk Underwriter: Requires aggregated credit scores, debt-to-income (DTI) calculations, and fraud indicators to approve non-standard loans.
• Automated Underwriting Engine: Software service responsible for algorithmic credit decisioning.
• Core Banking Mainframe: Authoritative system of record for account balances and customer master data.

4. Process & Action Analysis

1. Intake: Customer submits loan application via mobile app; system auto-fills identity data using biometric verification.
2. Verification: Automated integration calls external credit bureaus (Equifax/Experian) and internal fraud detection services.
3. Decisioning: Automated Underwriting Engine applies credit risk policy algorithms:
   • Tier 1 (Low Risk): Instant approval without human intervention.
   • Tier 2 (Moderate Risk): Routed to Credit Underwriter with pre-calculated DTI and risk highlights.
   • Tier 3 (High Risk): Automated rejection with FCRA-compliant adverse action documentation.
4. Fulfillment: Approved applicants execute electronic digital signatures (e-Sign) and funds are disbursed via the core banking API.

5. Desired Business Outcomes

• Reduce end-to-end loan approval turnaround from 14 days to under 10 minutes for 80% of applicants.
• Reduce application abandonment rate from 45% to below 15% within 12 months of deployment.
• Lower per-loan origination operational cost by 40%.

6. Derived SMART Architecture Requirements

---

Common Exam Pitfalls

• Misremembering SMART. In TOGAF the "A" is Actionable and the "R" is Realistic.
• Forgetting computer actors. Actors include both people and computing components.
• Treating business scenarios as technology designs. They document business requirements and desired outcomes first.
• Placing business scenarios only in Phase B. They are used especially in Phase A to articulate the Architecture Vision, and can support other phases and Requirements Management.