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.

The Enterprise Operating Model

The Enterprise Operating Model is a technique that is used in phases A through to E in the TOGAF Architecture Development Method.

The main ingredient to establishing interoperability is to determine the Corporate Operating Model.

The Corporate Operating Model will determine what type of interoperability approach will be appropriate.

The Operating Model is the necessary level of business process integration and standardisation for delivering services and goods to customers. The Operating Model will describe how a company wants to grow by providing a more actionable and stable view of the company.

There are four operating models each based on the level of business process, standardisation and integration. It is using these models that architects are able to decide the level of detail and complexity of solution and architecture building blocks.

The four operating models are:

  1. Coordination
  2. Unification
  3. Diversification
  4. Replication

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.

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.

Architectural Activities – Restraining the Scope

For various reasons it may be necessary to restrain the scope of an architectural activity which usually pertains to:

  • The stakeholder concerns and objectives that need to be addressed within the architecture
  • The availability of resources such as people or money
  • The authority within the organisation of the people producing the architecture.

It is important to understand that the proposed scope should allow the work of all the architects within the organisation or enterprise to be integrated and effectively governed. Doing this will require that a set of aligned “Architecture Partitions” are created which will ensure that different architects are not all working on conflicting or the same activities. It will also require that any definitions of compliance relationships are established between the architecture partitions as well as how they may be re-used.