Business Scenario

A Business Scenario is a technique that is used during the various stages of the Enterprise architecture. The most common phases where Business Scenarios are implemented are during Phase A (Architecture Vision) and Phase B (Business Architecture). A Business Scenario is used to derive the characteristics of the architecture straight from the high-level requirements of the business or organisation.

Business Scenarios are helpful in identifying and understanding the needs of the business and therefore create the requirements of the business that the architecture development needs to address.

What is a Business Scenario?

A Business Scenario is able to be used at any stage of the Architecture Development Method if it is required. In TOGAF a Business Scenario is used to define the requirements of a customer. A Business Scenario should describe:

  • The environment of the business and technology
  • Business Processes and application(s)
  • The components pertaining to people and comping (Otherwise known as Actors) who will execute the scenario
  • The required outcome of proper execution

A Business Scenario should represent a significant problem or business requirement and allow vendors to understand the value of a solution to the customer.

In addition a Business Scenario should also be SMART.

  • S – Specific by defining the exact requirements
  • M – Measurable via clear metrics for success
  • A – Actionable by clearly breaking down the issue and providing a clear basis for the solution
  • R – Realistic in so far as that the issue can actually be solved given the constraints of time, physical reality and cost
  • T – Timed meaning that the Business Scenario should have a clear statement of when the opportunity expires.

Phase H – Architecture Change Management

The main objectives of Phase H or the Architecture Change Management Phase are:

  • To appraise the efficiency and performance of the architecture and provide proposals for when the architecture may need to be altered.
  • To ensure that the proposed architecture is able to achieve the specified business values.
  • To ensure that any baseline architectures can continue to evolve e.g. Changes in the business or technology may force baseline architecture(s) to be altered.
  • Determine the circumstances and provide a process which will allow the architecture to be modified after the deployment.
  • Assess any changes to the principles and framework which have been created in the previous phases of the Architecture Development Method.
  • To use and administer the Governance Framework.

It is worth understanding that Phase H or the Architecture Change Management Phase is extremely pertinent to the processes pertaining to architecture governance and management of the Architecture Contract.

Phase G – Implementation Governance

The main objective of Phase G or the Implementation Governance Phase is to bring together all of the relevant information pertaining to the various implementation projects – specifically:

  • Ensure that the deployed architecture conforms with the implementation projects
  • Ensure that the actual solution is deployed successfully
  • Generate suggestions for each of the implementation projects
  • Manage and govern an Architecture Contract for the actual implementation and deployment
  • Implement the appropriate governance functions pertaining to the system while it is being deployed and implemented
  • Ensure that any future supporting operations are started.

Phase G or the Implementation Governance Phase is where the association between the architecture and the implementation organisation occurs; this connection is via the Architecture Contract.

To make certain that the Architecture Contract is both competent and effective there are five main aspects of the Governance Framework which should be introduced during Phase G; they are:

  1. Communication
  2. Ensuring processes are as straight forward as necessary
  3. Authority is centered around people
  4. Any responses should be timely with an effective and efficient escalation process.
  5. Aspects should support the organisation structures

Phase E – Opportunities and Solutions

The objective of Phase E or the Opportunities and Solutions Phase is to:

  • Identify the important phases of change
  • Any known parameters
  • High-level projects / Work packages
  • Any new business opportunities that arise from architecture work during previous phases

That will need to be undertaken when moving from the current environment to the new environment. Any outputs from the Opportunities and Solutions phase will be the initial step in modelling the implementation plan for the target architecture.

Other objectives during the Opportunities and Solutions phase are to perform a gap analysis between phase B (Business Architecture Phase) through to phase D (Technology Phase). In addition, during this phase it is important for the architect to review the capabilities and objectives of the business.

A full review (And confirmation) of the organisation or enterprises current parameters should be taken in order to see the effect of any proposed changes.

The definition of the solution building blocks should also be done and a set of transition architectures should also be derived.

Finally, an overall strategy outlining the Migration and Implementation should be generated and agreed upon with the relevant stakeholders.

When implementing Phase E or the Opportunities and Solutions Phase it is important to understand that this phase is the first phase which is directly concerned with the actual implementation.

On occasion, when identifying any new implementation opportunities a new application may be identified. If and when this occurs, it may be necessary for an architect to revisit and iterate over the previous phases.

Phase D – Technology Architecture

The objective of Phase D or the Technology Architecture Phase is to define and develop the Technology Architecture that will:

  • Identify any candidate Architecture Road-map components using a gap analysis based on differences between Baseline and Target technology architectures.
  • Enable any physical and logical data and application components as well as the Architecture Vision
  • Address any stakeholder concerns and requests for architecture work

Specifically, the Technology Architecture should be able to describe the current and target views of the technology portfolio. These views should identify the key work components and build a road-map toward the proposed Target Architecture.

When implementing Phase D or the Technology Architecture Phase the architecture team will need to acknowledge any Technology Architecture Resources that are available via the Architecture repository and most importantly, are these resources relevant?

There are a vast array of existing Information Technology Services resources already available – these resources include:

Finally, it is important to understand that new emerging technologies can be a major catalyst for organisations or enterprises seeking to improve their business operations.

Any Technology Architecture should be able to understand and implement any new opportunities that may arise via the adoption of new technology.

Phase C – Information Systems Architecture

The main objective of Phase C or the Information Systems Architecture is to develop the target architecture for any Information Systems.

The Information Systems Architecture can be broken down into two separate architectures:

  1. Data Architecture
  2. Application Architecture

The Information Systems Architecture should be able to describe in detail how the enterprise or organisations Information Systems Architecture will facilitate:

  • The Identification of any Architecture Road-map Components based on a gap analysis
  • The Business Architecture
  • The Architecture Vision

Data Architecutre

The main objective of the Data Architecture is to determine the sources and types of data that will be required to support the organisation or business. It is imperative that the Data Architecture should be able to be easily understood by any stakeholders.

Application Architecture

The main objective of the Application Architecture is to determine the specific types of systems that will be required to process any data and to support the organisation or business.

Phase B – Business Architecture

The main objective of Phase B or the Business Architecture Phase is to develop the business architecture that will describe how the enterprise or organisation will need to function in order to reach the business goals that have been specified.

In addition, another objective is to identify the candidate architecture road-map components which are based on any gaps between the target business architectures and the baseline business architectures.

Other key objectives pertaining to Phase B or the Business Architecture Phase are:

  • Elicit any business requirements and identify any existing material that may be able to be reused.
  • To demonstrate to stakeholders the business value of any subsequent work and what return on investment they should expect to see.
  • Describe the baseline Business Architecture
  • Analyse any gaps between the Target Business Architecture and the Baseline Business Architecture.
  • Identify and develop the architecture viewpoints that are relevant.
  • Demonstrate how end stakeholder requirements and concerns are addressed in the Business Architecture
  • Identify and select any techniques and tools that are relevant and can be utilised within the selected viewpoints
  • Identify any existing architecture definitions that may be able to be used as a starting point when creating the architecture

The key aspects when approaching the Business Architecture Phase are:

Approach one -The most common approach

  • An architect must understand that the extent of work in the Business Architecture Phase will directly depend on the the enterprise environment. It is important to be aware that in some instances important elements pertaining to the Business Architecture may be completed within other activities
  • Where the key element may be completed in other activities the architect may be required to verify and update any current or ongoing business plans and strategies. In addition there may be the requirement for the architect to connect between business strategies, business drivers (At a high level) and goals on one-hand and the specific requirements of the business on the other.
  • Where none or a small amount of Business Architecture work has been completed the architect must analyse and research, verify and achieve buy-in to the main business objectives and processes that the architecture must support.

A secondary approach

Establishing the Baseline Description

Where the business has existing descriptions of the architecture. In this scenario, then these descriptions should form the basis for the Baseline Description. Where no architecture descriptions exists, then information should be obtained and the relevant Business Architecture Models developed.

Implementing Business Capabilities

Use the the business capability map that was either found or developed during the Architecture Vision phase. The business capability map should provide a self contained overview of the current business or enterprise organisational structure, IT systems, applications and any other business processes.

A third approach

Using the organisation map – An organisation map displays any key organisational partners, units and stakeholder groups the form the ecosystem of the enterprise or organisation. The organisation map should also display any working relationships between these entities.

Mapping and modelling techniques which may be provided are extensions that will implement the business capabilities, organisational maps and any value streams into actual business practice.

In addition to any value streams, business capabilities and organisational maps a assortment of other techniques may be employed. These techniques may be Class Models, Use-Case Models and Business Process Models (Commonly referred to as Activity Models).

The Preliminary Phase

The main objective of the preliminary phase is to provide the definition of how an organisation will develop its architecture. A key objective within the Preliminary Phase is to get the buy-in of all the relevant stakeholders.

Other objectives within the Preliminary Phase are:

  • Developing an “Architecture Footprint” which consists of the people who will be performing the architectural work, their specific responsibilities and their location.
  • Defining and understanding the scope and any assumptions that are being made
  • Define the method and any frameworks that will be utilised throughout the ADM
  • Confirmation of any support framework that will be used and also to confirm a governance
  • Selection and implementation of any supporting tools that may be used
  • Define any architecture principles that may limit the architecture work.

The Preliminary Phase should be thought of in terms of defining the following in the enterprise:

  • Where
  • What
  • Why
  • Who
  • How

The key aspects when approaching the Preliminary Phase are:

  • Evaluating the architecture maturity of the enterprise
  • Defining any relationships that exist between management frameworks
  • Defining the framework that will be utilised
  • Defining architecture principles that will drive the architecture work
  • Define the actual requirements for the architecture work
  • Defining the Enterprise
  • Identifying key elements and drivers in the context of the organisation.

Overview of the TOGAF Architecture Development Method

The TOGAF ADM Framework is a method for developing an Enterprise Architecture and consists of the following phases. Each phase below is listed in the order that it should be followed through each iteration of the ADM.

Preliminary Phase

The Preliminary Phase is used to describe the initiation and preparation activities that will be required to meet the specific business directives for a new enterprise architecture. The preliminary phase should include the definition of principles as well as the organisation specific architecture framework.

In summary the preliminary phase is used to prepare the organisation for undertaking successful enterprise architecture projects which includes:

  • Understanding the business environment
  • Engaging high-level management commitment
  • Agreeing on the scope of the proposed architecture
  • Establishing principles
  • Establishing a governance structure
  • Agreeing upon the method(s) that will be adopted.

Phase A – Architecture Vision

It is during the Architecture Vision or Phase A where the first iteration of the architecture process is initiated. It is also during Phase A where the scope, expectations and constrains of the project are set.

The Architecture Vision is used as the guide during the beginning of every architecture iteration to assist with the creation of the Architecture Statement of Work Document and Architecture Vision. The Statement of Architecture Work Documents are used to validate the context of the business.

Phase B – Business Architecture

When undertaking architecture work in any domain (Data, Application, Technology) it is prerequisite that there is knowledge pertaining to the Business Architecture. Therefore the first architecture activity that needs to be undertaken is gaining the knowledge of the business architecture.

On occasion, information pertaining to the Business Architecture may already be available in other business / organisational processes such as:

  • Strategic Business Planning
  • Enterprise Planning
  • Business Process re-engineering

Phase C – Information System Architectures

Phase C is associated with two main architectures:

  1. Data Architecture
  2. Applications Architecture

When developing the architecture an architect must decide on which architecture to begin first; Application or Data?

In most instances it is usual to address both the data and applications architectures at the same time; however this may not always hold true depending on the scope of the project and any constraints.

If an architect had to choose which architecture to begin with, based on existing theory it would be wise to begin with the Data Architecture. However(!), due to practical considerations, it may mean that starting with the Application Architecture is more efficient.

Remember, that Phase C encapsulates two separate architecture domains (Data and Application). Therefore there are actually two areas / phases inside Phase C – Data and Application so there will need to be an iteration for both of these.

Phase D – Technology Architecture

The Technology Architecture Phase or Phase D is used to map any application components defined during the Application Architecture phase into a set of technology based components.

These technology components should be able to represent the hardware and software components which are already available on the market or components that are already configured within the organisation into technology platforms.

Phase E – Opportunities and Solutions

The Opportunities and Solutions Phase or Phase E is the first phase in the Architecture Development Methodology which is directly concerned with design and structure of how the target architecture will be achieved.

Phase F – Migration and Planning

During Phase F or the Migration Planning phase of the ADM the main focus is the development of a viable implementation and migration plan. The migration plan should be developed in conjunction with the project and portfolio managers.

Phase G – Implementation and Governance

The Implementation and Governance phase or Phase G is concerned with providing an architectural overview of the proposed implementation activities.

Providing an overview of the proposed implementation activities is to ensure that the activities are compliant with the target architectures.

Phase H – Architecture Change Management

During Phase H or the Architecture Change Management Phase the main goal is to ensure that the proposed architecture is able to achieve the original target as specified by the business.

The Architecture Change Management Phase should:

  • Manage changes to the architecture in an orchestrated and cohesive manner
  • Provide for continual monitoring of any changes in governance requests, new technology developments and any changes in the business environment
  • If any changes do occur then the Change Management Phase should be used to determine if a new formal iteration of the architecture evolution cycle should be initiated.

Requirements Management

Requirements management whilst not technically a phase within the ADM is vitally important. The Requirements Management is a process for the management of requirements throughout all phases of the ADM.

The four dimensions of scope

There are four main dimensions that are typically used to limit and define the scope of an Architecture.

  1. Breadth
  2. Depth
  3. Time Period
  4. Architecture Domains

Breadth

Determine the extent of the enterprise or organisation and how much of that extent should the architecture effort focus on. It is important to understand that many organisations are large and are comprised of separate business units. These separate business units can be thought of as enterprises in their own right. Modern businesses further blur this distinction as many businesses embrace a combination of traditional business enterprise as well as partners, customers and suppliers.

Depth

Depth describes to what level of detail an architect should go to when creating an architecture. The challenge here is deciding on how much architecture is enough and when to stop and the delineation between other related activities or systems.

Time Period

Specifies the time period for the initial phase – Architectural Vision and is the specified amount of time realistic based on resources available.

Architecture Domains

Typically when creating an Architecture Description the description should contain information pertaining to all four domains:

  1. Business
  2. Data
  3. Application
  4. Technology

Sometimes, due to constraints such as time and resources there often not enough resources available to create an all inclusive architecture description that covers all four domains.

Typically when creating the scope of an Architecture the scope is expressed in:

  • Breadth
  • Depth
  • Time

Once the scope of the organisation is understood then a suitable combination of architectural domains is selected based on the problem being addressed.