26.3.1 Overall Process
Creating a business scenario involves the following, as illustrated in Figure 26-1 :
Identifying, documenting, and ranking the problem driving the scenario
Identifying the business and technical environment of the scenario and documenting it in scenario models
Identifying and documenting desired objectives (the results of handling the problems successfully); get "SMART"
Identifying the human actors (participants) and their place in the business model
Identifying computer actors (computing elements) and their place in the technology model
Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required
scripts per actor, and the results of handling the situation
Checking for "fitness-for-purpose" and refining only if necessary
Figure 26-1: Creating a Business
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
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.
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.
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
This phase is extremely important, as the absence of shared expectations is in many cases the root cause of project