Guideline: Creating the Business Scenario
Main Description

26.3.1 Overall Process

Creating a business scenario involves the following, as illustrated in Figure 26-1 :

  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 Figure 26-2.


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 Figure 26-1. 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.