26. Business Scenarios

Chapter Contents
26.1 Introduction | 26.2 Benefits of Business Scenarios | 26.3 Creating the Business Scenario | 26.4 Contents of a Business Scenario | 26.5 Contributions to the Business Scenario | 26.6 Business Scenarios and the TOGAF ADM | 26.7 Guidelines on Developing Business Scenarios | 26.8 Guidelines on Business Scenario Documentation | 26.9 Guidelines on Goals and Objectives | 26.10 Summary

This chapter describes a method for deriving business requirements for architecture and the implied technical requirements.

26.1 Introduction

A key factor in the success of an enterprise architecture is the extent to which it is linked to business requirements, and demonstrably supporting and enabling the enterprise to achieve its business objectives.

Business scenarios are an important technique that may be used at various stages of the enterprise architecture, principally the Architecture Vision and the Business Architecture, but in other architecture domains as well, if required, to derive the characteristics of the architecture directly from the high-level requirements of the business. They are used to help identify and understand business needs, and thereby to derive the business requirements that the architecture development has to address.

A business scenario describes:

A good business scenario is representative of a significant business need or problem, and enables vendors to understand the value to the customer organization of a developed solution.

A good business scenario is also "SMART":

26.9 Guidelines on Goals and Objectives provides detailed examples on objectives that could be considered. Whatever objectives you use, the idea is to make those objectives SMART.

26.2 Benefits of Business Scenarios

A business scenario is essentially a complete description of a business problem, both in business and in architectural terms, which enables individual requirements to be viewed in relation to one another in the context of the overall problem. Without such a complete description to serve as context:

Also, because the technique requires the involvement of business line management and other stakeholders at an early stage in the architecture project, it also plays an important role in gaining the buy-in of these key personnel to the overall project and its end-product - the enterprise architecture.

An additional advantage of business scenarios is in communication with vendors. Most architecture nowadays is implemented by making maximum use of Commercial Off-The-Shelf (COTS) software solutions, often from multiple vendors, procured in the open market. The use of business scenarios by an IT customer can be an important aid to IT vendors in delivering appropriate solutions. Vendors need to ensure that their solution components add value to an open solution and are marketable. Business scenarios provide a language with which the vendor community can link customer problems and technical solutions. Besides making obvious what is needed, and why, they allow vendors to solve problems optimally, using open standards and leveraging each other's skills.

26.3 Creating the Business Scenario

26.3.1 Overall Process

Creating a business scenario involves the following, as illustrated in Creating a Business Scenario :

  1. Identifying, documenting, and ranking the problem driving the scenario
  2. Identifying the business and technical environment of the scenario and documenting it in scenario models
  3. Identifying and documenting desired objectives (the results of handling the problems successfully); get "SMART"
  4. Identifying the human actors (participants) and their place in the business model
  5. Identifying computer actors (computing elements) and their place in the technology model
  6. Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation
  7. Checking for "fitness-for-purpose" and refining only if necessary


Figure 26-1: Creating a Business Scenario

A business scenario is developed over a number of iterative phases of Gathering, Analyzing, and Reviewing the information in the business scenario.

In each phase, each of the areas above is successively improved. The refinement step involves deciding whether to consider the scenario complete and go to the next phase, or whether further refinement is necessary. This is accomplished by asking whether the current state of the business scenario is fit for the purpose of carrying requirements downstream in the architecture process.

The three phases of developing a business scenario are described in detail below, and depicted in Phases of Developing Business Scenarios .


Figure 26-2: Phases of Developing Business Scenarios

26.3.2 Gathering

The Gathering phase is where information is collected on each of the areas in Creating a Business Scenario . If information gathering procedures and practices are already in place in an organization - for example, to gather information for strategic planning - they should be used as appropriate, either during business scenario workshops or in place of business scenario workshops.

Multiple techniques may be used in this phase, such as information research, qualitative analysis, quantitative analysis, surveys, requests for information, etc. As much information as possible should be gathered and preprocessed "off-line" prior to any face-to-face workshops (described below). For example, a request for information may include a request for strategic and operational plans. Such documents typically provide great insights, but the information that they contain usually requires significant preprocessing. The information may be used to generate an initial draft of the business scenario prior to the workshop, if possible. This will increase the understanding and confidence of the architect, and the value of the workshop to its participants.

A very useful way to gather information is to hold business scenario workshops, whereby a business scenario consultant leads a select and small group of business representatives through a number of questions to elicit the information surrounding the problem being addressed by the architecture effort. The workshop attendees must be carefully selected from high levels in the business and technical sides of the organization. It is important to get people that can and will provide information openly and honestly. Where a draft of the business scenario already exists - for example, as a result of preprocessing information gathered during this phase, as described above - the workshop may also be used to review the state of the business scenario draft.

Sometimes it is necessary to have multiple workshops: in some cases, to separate the gathering of information on the business side from the gathering of information on the technical side; and in other cases simply to get more information from more people.

When gathering information, the architect can greatly strengthen the business scenario by obtaining "real-world examples"; i.e., case studies to which the reader can easily relate. When citing real-world examples, it is important to maintain a level of anonymity of the parties involved, to avoid blame.

26.3.3 Analyzing

The Analyzing phase is where a great deal of real Business Architecture work is actually done. This is where the information that is gathered is processed and documented, and where the models are created to represent that information, typically visually.

The Analyzing phase takes advantage of the knowledge and experience of the business scenario consultant using past work and experience to develop the models necessary to depict the information captured. Note that the models and documentation produced are not necessarily reproduced verbatim from interviews, but rather filtered and translated according to the real underlying needs.

In the Analyzing phase it is important to maintain linkages between the key elements of the business scenario. One technique that assists in maintaining such linkages is the creation of matrices that are used to relate business processes to each of:

In this way, the business process becomes the binding focal point, which makes a great deal of sense, since in most cases it is business process improvement that is being sought.

26.3.4 Reviewing

The Reviewing phase is where the results are fed back to the sponsors of the project to ensure that there is a shared understanding of the full scope of the problem, and the potential depth of the technical impact.

Multiple business scenario workshops or "readout" meetings with the sponsors and involved parties are recommended. The meetings should be set up to be open and interactive. It is recommended to have exercises built into meeting agendas, in order to test attendees' understanding and interest levels, as well as to test the architect's own assumptions and results.

This phase is extremely important, as the absence of shared expectations is in many cases the root cause of project failures.

26.4 Contents of a Business Scenario

The documentation of a business scenario should contain all the important details about the scenario. It should capture, and sequence, the critical steps and interactions between actors that address the situation. It should also declare all the relevant information about all actors, specifically: the different responsibilities of the actors; the key pre-conditions that have to be met prior to proper system functionality; and the technical requirements for the service to be of acceptable quality.

There are two main types of content: graphics (models), and descriptive text. Both have a part to play.


Table of Contents

PREFACE

    EXECUTIVE SUMMARY

    DOCUMENT ROADMAP

BUSINESS SCENARIO

    BUSINESS SCENARIO OVERVIEW

        BACKGROUND OF SCENARIO

        PURPOSE OF SCENARIO

        DEFINITIONS/DESCRIPTIONS OF TERMS USED

    VIEWS OF ENVIRONMENTS AND PROCESSES

        BUSINESS ENVIRONMENT

            Constituencies

        PROCESS DESCRIPTIONS

            Process "a"

            etc. ...

        TECHNICAL ENVIRONMENT

            Technical environment "a"

            etc. ...

        ACTORS AND THEIR ROLES AND RESPONSIBILITIES

        COMPUTER ACTORS AND ROLES

        RELATIONSHIP OF COMPONENTS AND PROCESSES

        HUMAN ACTORS AND ROLES

        RELATIONSHIP OF HUMANS AND PROCESSES

        INFORMATION FLOW ANALYSIS

        PRINCIPLES AND CONSTRAINTS

            IT Principles

            Constraints

        REQUIREMENTS

BUSINESS SCENARIO ANALYSIS

    PROBLEM SUMMARY

        Issues

        Objectives

SUMMARY

APPENDIXES

    APPENDIX A: BUSINESS SCENARIOS - ADDITIONAL INFORMATION

    APPENDIX B-n: BUSINESS SCENARIO WORKSHOP NOTES

26.5 Contributions to the Business Scenario

It is important to realize that the creation of a business scenario is not solely the province of the architect. As mentioned previously, business line management and other stakeholders in the enterprise are involved, to ensure that the business goals are accurately captured. In addition, depending on the relationship that an organization has with its IT vendors, the latter also may be involved, to ensure that the roles of technical solutions are also accurately captured, and to ensure communication with the vendors.

Typically, the involvement of the business management is greatest in the early stages, while the business problems are being explored and captured, while the involvement of the architect is greatest in the later stages, and when architectural solutions are being described. Similarly, if vendors are involved in the business scenario process, the involvement of the customer side (business management plus enterprise architects) is greatest in the early stages, while that of the vendors is greatest in the later stages, when the role of specific technical solutions is being explored and captured. This concept is illustrated in Relative Contributions to a Business Scenario .


Figure 26-3: Relative Contributions to a Business Scenario

Vendor IT architects might be able to assist enterprise IT architects with integration of the vendors' products into the enterprise architecture. This assistance most probably falls in the middle of the timeline in Relative Contributions to a Business Scenario .

26.6 Business Scenarios and the TOGAF ADM

Business scenarios figure most prominently in the initial phase of the Architecture Development Method (ADM), Architecture Vision, when they are used to define relevant business requirements, and to build consensus with business management and other stakeholders.

However, the business requirements are referred to throughout all phases of the ADM cycle, as illustrated in Relevance of Requirements Throughout the ADM .


Figure 26-4: Relevance of Requirements Throughout the ADM

Because business requirements are important throughout all phases of the ADM cycle, the business scenario technique has an important role to play in the TOGAF ADM, by ensuring that the business requirements themselves are complete and correct.

26.7 Guidelines on Developing Business Scenarios

26.7.1 General Guidelines

The stakeholders (e.g., business managers, end users) will tell you what they want, but as an architect you must still gain an understanding of the business, so you must know the most important actors in the system. If the stakeholders do not know what they want:

This effort provides the anchor for a chain of reason from business requirements through to technical solutions. It will pay off later to be diligent and critical at the start.

26.7.2 Questions to Ask for Each Area

The business scenario workshops mentioned above in the Gathering phase are really structured interviews. While there is no single set of appropriate questions to ask in all situations, the following provides some guidance to help business scenario consultants in asking questions.

Identifying, Documenting, and Ranking the Problem

Is the problem described as a statement of what needs to be accomplished, like steps in a process, and not how (with technology "push")?

If the problem is too specific or a "how":

If the problem is too vague or unactionable:

Ask questions that help to identify where and when the problem exists:

Ask questions that help to identify the costs of the problem:

Identifying the Business & Technical Environment, and Documenting in Models

Questions to ask about the business environment:

Questions to ask about the current technology environment:

Identifying and Documenting Objectives

Is the "what" sufficiently backed up with the rationale for "why"? If not, ask for measurable rationale in the following areas:

Identifying Human Actors and their Place in the Business Model

An actor represents anything that interacts with or within the system. This can be a human, or a machine, or a computer program. Actors initiate activity with the system, for example:

An actor represents a role that a user plays; i.e., a user is someone playing a role while using the system (e.g., John (user) is a dispatcher (actor)). Each actor uses the system in different ways (otherwise they should be the same actor). Ask about the humans that will be involved, from different viewpoints, such as:

Identifying Computer Actors and their Place in the Technology Model

Ask about the computer components likely to be involved, again from different points of view. What must they do?

Documenting Roles, Responsibilities, Measures of Success, Required Scripts

When defining roles, ask questions like:

Checking for Fitness-for-Purpose, and refining if necessary

Is there enough information to identify who/what could fulfil the requirement? If not, probe more deeply.

Is there a description of when, and how often, the requirement needs to be addressed? If not, ask about timing.

26.8 Guidelines on Business Scenario Documentation

26.8.1 Textual Documentation

Effective business scenario documentation requires a balance between ensuring that the detail is accessible, and preventing it from overshadowing the results and overwhelming the reader. To this end, the business scenario document should have the main findings in the body of the document and the details in appendices.

In the appendices:

In the main body of the business scenario:

26.8.2 Business Scenario Models

26.9 Guidelines on Goals and Objectives

26.9.1 Importance of Goals

One of the first steps in the development of an architecture is to define the overall goals and objectives for the development. The objectives should be derived from the business goals of the organization, and the way in which IT is seen to contribute to meeting those goals.

Every organization behaves differently in this respect, some seeing IT as the driving force for the enterprise and others seeing IT in a supporting role, simply automating the business processes which already exist. The essential thing is that the architectural objectives should be very closely aligned with the business goals and objectives of the organization.

26.9.2 Importance of SMART Objectives

Not only must goals be stated in general terms, but also specific measures need to be attached to them to make them SMART, as described above.

The amount of effort spent in doing this will lead to greater clarity for the sponsors of the architecture evolution cycle. It will pay back by driving proposed solutions much more closely toward the goals at each step of the cycle. It is extremely helpful for the different stakeholders inside the organization, as well as for suppliers and consultants, to have a clear yardstick for measuring fitness-for-purpose. If done well, the ADM can be used to trace specific decisions back to criteria, and thus yield their justification.

The goals below have been adapted from those given in previous versions of TOGAF. These are categories of goals, each with a list of possible objectives. Each of these objectives should be made SMART with specific measures and metrics for the task. However, since the actual work to be done will be specific to the architecture project concerned, it is not possible to provide a list of generic SMART objectives that will relate to any project.

Instead, we provide here some example SMART objectives.

Example of Making Objectives SMART

Under the general goal heading "Improve User Productivity" below, there is an objective to provide a "Consistent User Interface" and it is described as follows:

"A consistent user interface will ensure that all user-accessible functions and services will appear and behave in a similar, predictable fashion regardless of application or site. This will lead to better efficiency and fewer user errors, which in turn may result in lower recovery costs."

To make this objective SMART, we ask whether the objective is specific, measurable, actionable, realistic, and time-bound, and then augment the objective appropriately.

The following captures an analysis of these criteria for the stated objective:

The above results in a SMART objective that looks more like this (again remember this is an example):

"By the end of Q3, provide a consistent user interface across user interface devices that provide similar functionality to ensure all user accessible functions and services appear and behave in a similar way when using those devices in a predictable fashion regardless of application or site. This will lead to 10% greater user efficiency and 20% fewer order entry user errors, which in turn may result in 5% lower order entry costs."

26.9.3 Categories of Goals and Objectives

Although every organization will have its own set of goals, some examples may help in the development of an organization-specific list. The goals given below are categories of goals, each with a list of possible objectives, which have been adapted from the goals given in previous versions of TOGAF.

Each of the objectives given below should be made SMART with specific measures and metrics for the task involved, as illustrated in the example above. However, the actual work to be done will be specific to the architecture project concerned, and it is not possible to provide a list of generic SMART objectives that will relate to any project.

Goal: Improve Business Process Performance

Business process improvements can be realized through the following objectives:

Goal: Decrease Costs

Cost improvements can be realized through the following objectives:

Goal: Improve Business Operations

Business operations improvements can be realized through the following objectives:

Goal: Improve Management Efficacy

Management efficacy improvements can be realized through the following objectives:

Goal: Reduce Risk

Risk improvements can be realized through the following objectives:

Goal: Improve Effectiveness of IT Organization

IT organization effectiveness can be realized through the following objectives:

Goal: Improve User Productivity

User productivity improvements can be realized through the following objectives:

Goal: Improve Portability and Scalability

The portability and scalability of applications will be through the following objectives:

Goal: Improve Interoperability

Interoperability improvements across applications and business areas can be realized through the following objectives:

Goal: Increase Vendor Independence

Vendor independence will be increased through the following objectives:

Goal: Reduce Lifecycle Costs

Lifecycle costs can be reduced through most of the objectives discussed above. In addition, the following objectives directly address reduction of lifecycle costs:

Goal: Improve Security

Security can be improved in the organization's information through the following objectives:

Goal: Improve Manageability

Management improvement can be realized through the following objectives:

26.10 Summary

Business scenarios help address one of the most common issues facing IT executives: aligning IT with the business.

The success of any major IT project is measured by the extent to which it is linked to business requirements, and demonstrably supports and enables the enterprise to achieve its business objectives. Business scenarios are an important technique that may be used at various stages of defining enterprise architecture, or any other major IT project, to derive the characteristics of the architecture directly from the high-level requirements of the business. Business scenarios are used to help identify and understand business needs, and thereby to derive the business requirements that the architecture development, and ultimately the IT, has to address.

However, it is important to remember that business scenarios are just a tool, not the objective. They are a part of, and enable, the larger process of architecture development. The architect should use them, but not get lost in them. The key is to stay focused - watch out for "feature creep", and address the most important issues that tend to return the greatest value.
return to top of page


Navigation

The TOGAF document set is designed for use with frames. To navigate around the document:

return to top of page

Downloads

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.


Copyright © 1999-2009 The Open Group, All Rights Reserved. Not for redistribution.
TOGAF is a registered trademark of The Open Group in the United States and other countries.