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.

Interoperability

In the context of TOGAF the term Interoperability is defined as:

“The ability to share information and services”

The key element is being able to define the degree to which crucial services and information are to be shared. Within the TOGAF Architecture Development Method interoperability occurs in phases A through to F (From the Architecture Vision Phase through to the Migration Planning Phase).

Phase A – The Architecture Vision Phase

In Phase A Business Scenarios are used to discover the nature and security considerations of any information and security exchanges.

Phase B – Business Architecture Phase

During Phase B Business Terms are used to define information and service exchanges.

Phase C – Information Systems Architecture Phase

During Phase C The Information Exchange Model sometimes in association with Corporate Data is used to detail the content of information exchanges. It is during this phase that the way applications are to share information is specified.

Phase D – Technology Architecture Phase

In Phase D the appropriate technical mechanisms to allow information and service exchanges are detailed.

Phase E – Opportunities and Solutions Phase

In Phase E the actual solutions that will be implemented are chosen.

Phase F – Migration and Planning Phase

During Phase F interoperability is logically implemented.

Capability Based Planning

The objective of Capability Based Planning to focus on the planning, engineering and delivery of strategic business capabilities to the enterprise.

Capability Based Planning is both business-led and business-driven and combines the efforts if all lines of the business or organisation to achieve the required capability. Most corporate business models are catered for with Capability Based Planning.

Capability Based Planning links the IT Vision, architectures and the Implementation and Migration plans with the corporate business, strategic and line of business plans.

Capabilities are parallel and go against the grain of normal vertical corporate governance. Oftentimes, the management direction and also the corporate management accountability framework are based on the line of business metrics and not the enterprise metrics.

Risk Management

With any business transformation or architecture there will always be a degree of risk involved. The key is to determine, classify and reduce any risks as much as possible before starting. This is so that any risks identified are able to be tracked for the duration of the transformation process.

Levels of risk

TOGAF identifies two levels of risk:

  1. Initial Level of Risk
  2. Residual Level of Risk

Initial Level of Risk

The Initial Level of Risk is where any risks are categorised prior to determining and implementing mitigating actions

Residual Level of Risk

The Residual Level of Risk is where any risks are categorised after the implementation of mitigating actions.

The Risk Management Process

The Risk Management Process is comprised of the following steps:

  1. Risk classification
  2. Risk identification
  3. Initial risk assessment
  4. Risk mitigation and residual risk assessment
  5. Risk monitoring

Risk Identification

During Phase A or the Architecture Vision Phase any risks are identified a part of the initial Business Transformation Readiness Assessment.

In Phase G or the Implementation Governance Phase a risk identification worksheet is maintained as a governance artifact; an example of a Risk Identification Worksheet is shown below (Courtesy of the opengroup.org).

Risk Identification Worksheet

When maintaining the Risk Identification Worksheet Table ensure that ‘Unlikely’ and ‘Likely’ pertain to the probability or risk and not the frequency of risk.

Risk Mitigation Assessment

In Phase G (The Implementation Governance Phase) a Risk Mitigation Assessment worksheet is maintained as an governance artifact. It is in Phase G where risk monitoring is conducted. The purpose of Risk Mitigation is to identify, plan and conduct specific actions which will limit any risks to an acceptable level.

Preparing a business for change

Enterprise Architecture is a major project within an enterprise / organisations and as such it is important to understand if a business is ready for change.

One method to detect any issues and determine if a business is ready for change is to use what is known as the Business Transformation Readiness Assessment

Business Transformation Readiness Assessment

The Business Transformation Readiness Assessment is an assessment used to determine the readiness of an enterprise or organisation to:

  • Accept change
  • Identify any issues pertaining to change
  • Deal with issues during both the migration and implementation phases via the respective phases plans

The Business Transformation Readiness Assessment is comprised of the following steps:

  1. Determine what factors will impact the business transformation based on the migration from baseline to target architectures.
  2. Create maturity models based on the factors determined in the previous step.
  3. Based on the readiness factors discovered in step 1, rate the factors based on: Readiness Status, Urgency, Degree of difficulty
  4. Assess the risks associated with each readiness factor and create a set of actions to mitigate the risk; Don’t forget to use the Risk Management Technique
  5. Incorporate the actions into the ADM phases E (Opportunities and Solutions) and F (Migration Planning) as well as then migration and implementation plan.

Developing Architecture Principles

An Architecture Principle is a method for providing support during the decision making process. In addition they provide guidance on using and deploying assets and resources pertaining to the architecture work.

When developing an Architecture Principle the following should be taken into account:

  • What are the characteristics of the enterprise or organisation? i.e. Perform a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats)
  • What are the goals of the enterprise or organisation?
  • How is the enterprise or organisation structured?
  • What external constraints might come into play? i.e. Customer expectations, current or proposed legislation etc.
  • Technology and Systems across the enterprise or organisation which includes policies and procedures, documentation and Information Systems.
  • Trends (Technical, Economic, Political) which may be emerging within the enterprise or organisations industry which may impact the enterprise or organisation.

Principles should be linked to Standards, Policies, Guidelines and Procedures. The reason for linking principles is so that they are able to be supported inside the repository and can be shared with architects providing a full understanding pertaining to the structure.

Architecture Principles are usually established during the Preliminary Phase and can be thought of as a general set of guidelines and rules. Architecture Principles apply directly to the Architecture which is being developed and are usually a subset of the broader Enterprise Principles.

Architecture Principles should be created in such as way that each Principle is:

  • Robust
  • Understandable
  • Consistent
  • Stable
  • Complete

Why the need for Architecture Principles?

An Architecture Principle provides support and information in the way that an enterprise or organisation fulfills its objective. They should be specified as statements of intent which can be quantified and can be carried out by the architecture.

Standards, Policies, Procedures and Guidelines

It is important to understand the difference between the following definitions:

  • Standards
  • Policies
  • Procedures
  • Guidelines

Standards

A Standard is a set of rules which is usually set by an authority on a subject. Standards are able to be repeated and are usually mandated by a set policy. In addition, Standards specify at a low level compulsory controls which will support and impose policies and also provide a way to establish consistency across the enterprise or organisation.

Policies

A Policy references any procedures, standards and guidelines that provide support to it and are typically internal to the enterprise or organisation. The scope of a Policy is very narrow meaning that it is extremely specific dealing with a well-defined, specific area. Policies are dictated from the very top level of an organisation and are adhered to by organisational levels under the top level. A policy is used to determine who is liable for implementing and enforcing the policy and the reason the policy is needed. Finally, a policy is used to dictate set rules and requirements that must be followed.

Procedures

Procedures sometimes called Standard Operating Procedures (SOPS) describe in a logical, step by step manner how to implement standards, guidelines and policies. Each step in the procedure should be specific explaining the individual step in detail.

Guidelines

Think of Guidelines as a recommendation which is not mandatory but rather a best practice where there is no set standard available. Guidelines may provide additional information in order to support a Standard where there is no other information available for the standard.

Requirements Management Process

The Requirements Management Process is used throughout the entire Architecture Development Methodology life-cycle in all phases.

It’s key objective is to address the requirements of the enterprise or organisation, store the requirements and then pass the requirements to and from each ADM phase when required.

The Requirements Management Process is what drives the ADM and this is why the Requirements Management Process is at the center of the ADM life-cycle as shown below.

It is imperative that an architecture is able to handle changes in requirements as by its very nature an architecture is subject to changes such as:

  • Stakeholder uncertainty regarding requirements and solutions
  • What was proposed and what can actually be delivered (e.g. Constraints may force a change in deliverables)
  • Drivers and constraints outside of the control of the ADM or enterprise, such as changes in technology, new legislation for example

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