The Gap Analysis

The technique known as Gap Analysis is used throughout the TOGAF Architecture Development Method to validate an architecture under development. The main step to understand when undertaking a gap analysis is to consider any facets which may have been forgotten.

The purpose of a gap analysts is to show any shortcomings between the Baseline Architecture and the Target Architecture meaning any items which may have been accidentally or deliberately left out or not yet defined.

Crucial source of gaps which should be actively considered are any concerns of the stakeholders which may have not been addresses in prior architectural work.

A gap analysis occurs during phases B, C, D and E of the architectural development method.

How to perform a gap analysis

The first step is to draw a matrix with a list of all the Target Architecture Building Blocks (ABBs) across the top.

Next, create a new column listing all the Baseline Architecture Building Blocks (ABBs vertically)

At the end of the last horizontal row create a new column and call this column Eliminated.

Create a new row at the very bottom of the matrix and call this row New.

When an ABB appears in both the horizontal row at the top and the first column indicating that the ABB appears in both the target and baseline architectures, mark the cell as Included.

When an ABB in the baseline architecture is not included in the target architecture the ABB should be reviewed. In the scenario where the ABB is correctly eliminated mark it as Intentionally Eliminated in the associated cell in the Eliminated column.

When an ABB was found to be accidentally eliminated and must be addressed by reinstating it during the next iteration of the architecture design mark the ABB as Unintentionally Eliminated in the associated cell in the Eliminated column.

When an ABB from the target architecture is not included mark it as a gap which needs to be developed in the row marked New.

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.

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

The ADM Process

The ADM is a process which is iterative:

  • Over the whole process
  • Between phases
  • Within phases.

For each iteration a decision must be made to determine:

  • The coverage and breadth of the Enterprise to be defined
  • The level of detail that will be defined
  • The extent of time horizon

Decisions will need to be made in terms of the architectural assets that will need to be used including:

  • Assets that have been created during previous iterations
  • Industry assets that are available elsewhere (These assets may include systems models, vertical industry models and other frameworks etc)

It is important to understand that the decisions made will need to based on a practical appraisal of the resource capability and if the decision will add value to the enterprise.

The TOGAF ADM explained; briefly

The ADM (Architecture Development Method) is the main framework as dictated by TOGAF and is a way of extracting organisation-specific Enterprise Architecture.

TOGAF as a framework emerged from the contributions of countless Enterprise Architecture professionals and provides a process for developing Architectures that are:

  • Able to be easily repeated
  • Stable and tested

The TOGAF ADM provides a set of activities that are able to be performed with an iterative approach which constantly refines the architecture definition. This iterative approach is designed to address the business (and IT) needs by providing:

  • A set of guidelines for tools that can be used for the development of architecture
  • A method for managing the requirements
  • A recommended set of deliverables
  • A set of Architecture Views such as: Data, Application, Technology and Business.

The main activities within the iterative TOGAF ADM cycle are:

  • Establishing an Architecture Framework
  • Developing Architecture Content
  • Transitioning architectures
  • Governing the architecture into realisation