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 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 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":

• Specific, by defining what needs to be done in the business
• Measurable, through clear metrics for success
• Actionable, by:
  • Clearly segmenting the problem
  • Providing the basis for determining elements and plans for the solution
• Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints
• Time-bound, in that there is a clear statement of when the solution opportunity expires

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:

• There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description, and that can therefore misguide architecture work.
• The business value of solving the problem is unclear.
• The relevance of potential solutions is unclear.

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

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 .

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:

• Constituencies
• Human Actors
• Computer Actors
• Issues
• Objectives

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.

• 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.

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 .

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 .

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:

• Take time, observe, and record how they are working today
• Structure information in such a way that it can be used later
• Uncover critical business rules from domain experts
• Stay focused on what needs to be accomplished, and how it is to be accomplished

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":

• 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 to identify where and when the problem exists:

• Where are you experiencing this particular problem? In what business process?
• When do you encounter these issues? During the beginning of the process, the middle, the end?

Ask questions that help to 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 & 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?

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:

• Return on investment
• Scalability
• Performance needs
• Compliance to standards
• Ease-of-use measures

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:

• 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 viewpoints, such as:

• Developer
• Maintainer
• Operator
• Administrator
• User

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:

• What are the main tasks of the actor?
• 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?

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:

• Capture all the important details about a business scenario:
  • Situation description and rationale
  • All measurements
  • All actor roles and sub-measurements
  • All services required
• Capture the critical steps between actors that address the situation, and sequence the interactions
• Declare relevant information about all actors:
  • Partition the responsibility of the actors
  • List pre-conditions that have to be met prior to proper system functionality
  • Provide technical requirements for the service to be of acceptable quality

In the main body of the business scenario:

• Generalize all the relevant data from the detail in the appendices

26.8.2 Business Scenario Models

• Remember the purpose of using models:
  • Capture business and technology views in a graphical form
  • Help comprehension
  • Give a starting point to confirm requirements
  • Relate actors and interactions
• Keep drawings clear and neat:
  • Do not put too much into one diagram
  • Simpler diagrams are easier to understand
• Number diagrams for easy reference:
  • Maintain a catalog of the numbers to avoid duplicates

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:

• Specific: The objective of providing "a consistent user interface that will ensure all user accessible functions and services will appear and behave in a similar, predictable fashion regardless of application or site". is pretty specific. However, the measures listed in the second sentence could be more specific ...
• Measurable: As stated above, the objective is measurable, but could be more specific. The second sentence could be amended to read (for example): "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".
• Actionable: The objective does appear to be actionable. It seems clear that consistency of the user interface must be provided, and that could be handled by whoever is responsible for providing the user interface to the user device.
• Realistic: The objective of providing "a consistent user interface that will ensure all user accessible functions and services will appear and behave in a similar, predictable fashion regardless of application or site" might not be realistic. Considering the use today of PDAs at the user end might lead us to augment this objective to ensure that the downstream developers don't unduly create designs that hinder the use of new technologies. The objective could be re-stated as "a consistent user interface, across user interface devices that provide similar functionality, that will ensure ..." etc.
• Time-bound: The objective as stated is not time-bound. To be time-bound the objective could be re-stated as "By the end of Q3, provide a consistent ...".

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:

• Increased process throughput
• Consistent output quality
• Predictable process costs
• Increased re-use of existing processes
• Reduced time of sending business information from one process to another process

Goal: Decrease Costs

Cost improvements can be realized through the following objectives:

• Lower levels of redundancy and duplication in assets throughout the enterprise
• Decreased reliance on external IT service providers for integration and customization
• Lower costs of maintenance

Goal: Improve Business Operations

Business operations improvements can be realized through the following objectives:

• Increased budget available to new business features
• Decreased costs of running the business
• Decreased time-to-market for products or services
• Increased quality of services to customers
• Improved quality of business information

Goal: Improve Management Efficacy

Management efficacy improvements can be realized through the following objectives:

• Increased flexibility of business
• Shorter time to make decisions
• Higher quality decisions

Goal: Reduce Risk

Risk improvements can be realized through the following objectives:

• Ease of implementing new processes
• Decreased errors introduced into business processes through complex and faulty systems
• Decreased real-world safety hazards (including hazards that cause loss of life)

Goal: Improve Effectiveness of IT Organization

IT organization effectiveness can be realized through the following objectives:

• Increased rollout of new projects
• Decreased time to rollout new projects
• Lower cost in rolling out new projects
• Decreased loss of service continuity when rolling out new projects
• Common development: applications that are common to multiple business areas will be developed or acquired once and re-used rather than separately developed by each business area.
• Open systems environment: a standards-based common operating environment, which accommodates the injection of new standards, technologies, and applications on an organization-wide basis, will be established. This standards-based environment will provide the basis for development of common applications and facilitate software re-use.
• Use of products: as far as possible, hardware-independent, off-the-shelf items should be used to satisfy requirements in order to reduce dependence on custom developments and to reduce development and maintenance costs.
• Software re-use: for those applications that must be custom developed, development of portable applications will reduce the amount of software developed and add to the inventory of software suitable for re-use by other systems.
• Resource sharing: data processing resources (hardware, software, and data) will be shared by all users requiring the services of those resources. Resource sharing will be accomplished in the context of security and operational considerations.

Goal: Improve User Productivity

User productivity improvements can be realized through the following objectives:

• Consistent user interface: 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.
• Integrated applications: applications available to the user will behave in a logically consistent manner across user environments, which will lead to the same benefits as a consistent user interface.
• Data sharing: databases will be shared across the organization in the context of security and operational considerations, leading to increased ease-of-access to required data.

Goal: Improve Portability and Scalability

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

• Portability: applications that adhere to open systems standards will be portable, leading to increased ease-of-movement across heterogeneous computing platforms. Portable applications can allow sites to upgrade their platforms as technological improvements occur, with minimal impact on operations.
• Scalability: applications that conform to the model will be configurable, allowing operation on the full spectrum of platforms required.

Goal: Improve Interoperability

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

• Common infrastructure: the architecture should promote a communications and computing infrastructure based on open systems and systems transparency including, but not limited to, operating systems, database management, data interchange, network services, network management, and user interfaces.
• Standardization: by implementing standards-based platforms, applications will be provided with and will be able to use a common set of services that improve the opportunities for interoperability.

Goal: Increase Vendor Independence

Vendor independence will be increased through the following objectives:

• Interchangeable components: only hardware and software that have standards-based interfaces will be selected, so that upgrades or the insertion of new products will result in minimal disruption to the user's environment.
• Non-proprietary specifications: capabilities will be defined in terms of non-proprietary specifications that support full and open competition and are available to any vendor for use in developing commercial products.

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:

• Reduced duplication: replacement of isolated systems and islands of automation with interconnected open systems will lead to reductions in overlapping functionality, data duplication, and unneeded redundancy because open systems can share data and other resources.
• Reduced software maintenance costs: reductions in the quantity and variety of software used in the organization will lead to reductions in the amount and cost of software maintenance. Use of standard off-the-shelf software will lead to further reductions in costs since vendors of such software distribute their product maintenance costs across a much larger user base.
• Incremental replacement: common interfaces to shared infrastructure components allow for phased replacement or upgrade with minimal operational disturbance.
• Reduced training costs: common systems and consistent Human Computer Interfaces (HCIs) will lead to reduced training costs.

Goal: Improve Security

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

• Consistent security interfaces for applications: consistent security interfaces and procedures will lead to fewer errors when developing applications and increased application portability. Not all applications will need the same suite of security features, but any features used will be consistent across applications.
• Consistent security interfaces for users: a common user interface to security features will lead to reduced learning time when moving from system to system.
• Security independence: application deployment can use the security policy and mechanisms appropriate to the particular environment if there is good layering in the architecture.
• A 25% reduction in calls to the help desk relating to security issues.
• A 20% reduction in "false positives" detected in the network (a false positive is an event that appears to be an actionable security event, but in fact is a false alarm).

Goal: Improve Manageability

Management improvement can be realized through the following objectives:

• Consistent management interface: consistent management practices and procedures will facilitate management across all applications and their underlying support structures. A consistent interface can simplify the management burden, leading to increased user efficiency.
• Reduced operation, administration, and maintenance costs: operation, administration, and maintenance costs may be reduced through the availability of improved management products and increased standardization of the objects being managed.

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