TOGAF 9.1 Framework – A Comprehensive Guide

The Open Group Architecture Framework (TOGAF) is a framework – a detailed method and a set of supporting tools for planning, developing, maintaining and gaining value from an Enterprise Architecture. It may be used freely by any organization wishing to develop enterprise architecture for use within that organization.

TOGAF 9 encompasses the entire enterprise architecture life cycle, which is important as architecture is a never ending journey, always changing and evolving. The figure below depicts the TOGAF Architecture Development Method(ADM) which covers the entire architecture life cycle.

Architecture Development Method (ADM)

The ADM central to TOGAF which describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF described in this document as well as other available architectural assets, to meet the business and IT needs of an organization.

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. Each phase of ADM below contains iterative (Continuous) sequence of steps to develop an enterprise-wide Architecture and the possible iterations:

Getting the organization committed and involved

• Preliminary Phase
• Phase A: Architecture Vision

Getting the Architecture right

• Phase B: Business Architecture
• Phase C: Information Systems Architectures
• Phase D: Technology Architecture

Making the Architecture work

• Phase E: Opportunities & Solutions
• Phase F: Migration Planning
• Phase G: Implementation Governance

Keeping the Process running

• Phase H: Architecture Change Management
• Requirement Phase: Requirements Management

ADM Guidelines and Techniques

TOGAF 9 ADM contains a collection of guidelines and techniques for use in applying TOGAF and the ADM. The guidelines document how to adapt the ADM process, whereas the techniques are used when applying the ADM process. Here are some examples of Guidelines and Techniques to support the application and adoption of the ADM:

Guidelines

• Applying Iteration to the ADM – Discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM
  
  
• Applying the ADM at Different Enterprise Levels – Discusses the different types of architecture engagement that may occur at different levels of the enterprise.
  
  

Other Guidelines

• Security Architecture and the ADM -Provides an overview of specific security considerations that should be considered during different phases of the ADM
• Using TOGAF to Define & Govern SOAs – Shows how SOA concepts can be supported by the TOGAF framework

Techniques

• Gap Analysis – A technique used in the TOGAF ADM to validate an architecture that is being developed

Architecture Content Framework

Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc. The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented.

The TOGAF Content Framework defines a set of entities that allow architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability

Enterprise Continuum

A view of the Architecture Repository that provides methods for classifying architectures and solution artifacts in a structured way. The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.

• The Enterprise Continuum enables the architect to articulate the broad perspective of what, why, and how the enterprise architecture has been designed with the factors and drivers considered.
• The Enterprise Continuum is an important aid to communication and understanding, both within individual enterprises, and between customer enterprises and vendor organizations.

Example of Architecture Continuum

Architecture Continuum is composed of four states. The underlying process is to discover architectural requirements, analyze and understand architectures that are already in place in the organization, from foundation architectures (i.e. TRM), through common systems architectures III-RM), industry standard architectures, (i.e. SOA), and to an organization’s own architecture. The Figure below is an illustration of an architectural process based on four states:

• Foundation architectures (TRM)
• Common system architectures (III-RM)
• Industry architectures
• Organization architectures

Architectural changes made to states at the left will migrate to states at the right. The left-to-right direction implies a logical progression in organizing an enterprise architecture implementation.

TOGAF Reference Models

This part provides two architectural reference models, namely the TOGAF Technical Reference Model (TRM), and the Integrated Information Infrastructure Reference Model (III-RM).

TOGAF Technical Reference Model (TRM)

The TOGAF TRM describes a fundamental architecture upon which other, more specific, architectures can be based. In other words, it is an architecture of building blocks and corresponding standards that supports all the Common Systems Architectures, and, therefore, the complete computing environment. The TOGAF TRM describes a fundamental architecture upon which other, more specific, architectures can be based. The TRM has two main components:

1. A taxonomy that defines terminology, and provides a coherent description of the components and conceptual structure of an information system
2. A model, with an associated TRM graphic, that provides a visual representation of the taxonomy, as an aid to understanding

Integrated Information Infrastructure Reference Model (III-RM)

The III-RM is a reference model that focuses on the Application Software space, and is a “Common Systems Architecture” in Enterprise Continuum terms.

• The TRM focuses on the Application Platform space, III-RM main focus is the Applications space particularly the “Common Systems Architecture”
• Like the TRM it is a reference model with a taxonomy and a graphic however it is a subset of the scope of TRM but expands on certain parts

Architecture Capability Framework

An enterprise architecture development involve the generation of business capability, planning and managing architecture in the organization on all levels through different development phases. The enterprise needs to identify of the governance bodies which is responsible to make architecture decisions as shown on the top of the Figure below.

In the middle of the right-hand side, TOGAF specifies the architecture pool of skills which records the definition of the maturity of the organization and its improvement. Therefore, it contains the architecture professionals’ skills, knowledge and professional development strategies. These knowledge enables the definition of the roles and responsibilities for the architecture work, in other words, who is responsible for what?

On the right of the skilled pool, the Project/Portfolio Governance send contracts of architecture work to the Project/Portfolio, which should in sync with priority and focus of the business operations.

Deliverables, Artifacts, logs or policy papers can be drawn from the enterprise continuum and architecture repository

The general idea is to evolve the capability of the organization to develop architecture which will result of increasing business capability.

Components of Capability Framework

• Architecture Board – The Board oversees implementation of the governance strategy, which comprises of representative stakeholders responsible for review and maintenance of architecture
• Architecture Compliant – A key relationship between the architecture and the implementation lies in the definitions of the terms compliant for ensuring the compliance of individual projects with the enterprise architecture.
• Architecture Contracts – Joint agreements between development partners and sponsors on the deliverables, qualify and fitness-for-purpose of an architecture
• Architecture Maturity models – they are employed as a means for businesses to evaluate their current position, and therefore, better understand when it’s the right time to move forward and how to do so
• Architecture Skills frameworks – provide a view of the competency levels required for specific roles.