Introduction Benefits Creation Contents Contributions ADM Guidelines on Developing Business Scenarios Guidelines on Business Scenario Documentation Guidelines on Goals and Objectives Summary
A key factor in the success of an IT 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 prior to, and as a key input to, the development of the architecture, to derive the characteristics of the Technical 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":
The section below entitled Guidelines on Goals provides detailed examples on objectives that could be considered. Whatever objectives you use the idea is to make those objectives SMART.
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 IT 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 software (COTS) 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.
Creating a business scenario involves the following, as illustrated in Figure 1:
1 - Identifying, documenting and ranking the problem driving the scenario
2 - Identify 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 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 Figure 2.
Figure 2: Phases of Developing Business Scenarios
The Gathering phase is where information is collected on each of the areas in Figure 1.
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.
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.
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.
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 analysis 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.
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.
This phase is extremely important, as the absence of shared expectations is in many cases the root cause of project failures.
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 on content: graphics (models), and descriptive text. Both have a part to play.
Business Scenario Models capture business and technology views in a graphical form, to aid comprehension. Specifically, they relate actors and interactions, and give a starting point to confirm specific requirements.
Business Scenario Descriptions capture details in a textual form. A typical contents list for a business scenario is given below.
Table of Contents
Business Scenario Problem Description
Environment and Process Models
Actors and Their Roles and Responsibilities
Resulting Technology Architecture Model
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, 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 Figure 3.
Figure 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 Figure 3.
Business Scenarios figure most prominently in the initial phase of the ADM, Initiation and Framework, 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 life cycle, as illustrated in Figure 4.
Figure 4: Relevance of Requirements Throughout the ADM
Because business requirements are important throughout all phases of the ADM life 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.
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.
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:
Raise a red flag
Ask "why do you need to do it that way?" questions
If the problem is too vague or unactionable:
Raise a red flag
Ask "what is it you need to do, or will be able to do if this problem is solved?" questions
Ask questions that help identify where and when the problem exists:
Where are you experiencing this particular problem? In what business process?
When do encounter these issues? During the beginning of the process, the middle, the end?
Ask questions that help identify the costs of the problem:
Do you account for the costs associated with this problem? If so, what are they?
Are there hidden costs? If so, what are they?
Is the cost of this problem covered in the cost of something else? If so, what and how much?
Is the problem manifested in terms of poor quality or a perception of an ineffective organization?
Identifying the business and technical environment, and documenting in models
Questions to ask about the business environment:
What key process suffers from the issues? What are the major steps that need to be processed?
Location/scale of internal business departments?
Location/scale of external business partners?
Any specific business rules and regulations related to the situation?
Questions to ask about the current technology environment:
What technology components are already presupposed to be related to this problem?
Are there any technology constraints?
Are there any technology principles that apply?
Is the "what" sufficiently backed up with the rationale for "why"? If not, ask for measurable rationale in the following areas:
Return on investment
Compliance to standards
Ease of use measures
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, e.g.:
Computer user with the computer
Phone user with the telephone
Payroll clerk with the Payroll System
Internet subscriber with the web browser
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 view points, such as:
Ask about the computer components likely to be involved, again from different points of view. What must they do?
When defining roles, ask questions like:
Will the actor have to read/write/change any information?
Will the actor have to inform the system about outside changes?
Does the actor wish to be informed about unexpected changes?
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.
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 Information Technology 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.
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 architecture development method 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.
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, one asks whether the objective is specific, measurable, actionable, realistic, and time-bound, and then augments 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 quarter 3 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 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.
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 will be realized through the following objectives:
Goal: Decrease Costs
Cost improvements will be realized through the following objectives:
Goal: Improve Business Operations
Business operations improvements will be realized through the following objectives:
Goal: Improve Management Efficacy
Management efficacy improvements will be realized through the following objectives:
Goal: Reduce Risk
Risk improvements will be realized through the following objectives:
Goal: Improve Effectiveness of IT Organization
IT organization effectiveness will be realized through the following objectives:
Goal: Improve User Productivity
User productivity improvements will be realized through the following objectives:
Goal: Improve Interoperability
Interoperability improvements across applications and business areas can be realized through the following objectives:
Goal: Reduce Life-Cycle Costs
Life-cycle costs can be reduced through most of the objectives discussed above. In addition, the following objectives directly address reduction of life-cycle costs:
Goal: Improve Security
Security will be improved in the organization's information through the following objectives:
Goal: Improve Manageability
Management improvement can be realized through the following objectives:
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 it 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.
Copyright © The Open Group, 1999, 2001