The phases of TOGAF

The Architecture Development Process (ADM) is a process that is continually improved via feedback from other frameworks, previous iterations and other models based on:

  • Value
  • Competency
  • Availability

The ADM is the core of the TOGAF Framework and is comprised of nine main phases:

  1. Preliminary Phase
  2. Architecture Vision – Phase A
  3. Business Architecture – Phase B
  4. Information System Architectures – Phase C
  5. Technology Architecture – Phase D
  6. Opportunities and Solutions – Phase E
  7. Migration Planning – Phase F
  8. Implementation Governance – Phase G
  9. Architecture Change Management – Phase H

In among all of these phases is Requirements Management which ensures that each phase validates and is based upon the business requirements.

Preliminary Phase

The Preliminary Phase is the phase where an organisation is prepared for a successful architecture project

Architecture Vision – Phase A

The Architecture Vision or Phase A sets the constraints, expectations and scope for a TOGAF project and also creates the vision of the architecture.

Business Architecture – Phase B

The Business Architecture or Phase B is where the business architecture is developed; specifically Target and Baseline architectures as well as any gap analysis.

Information System Architectures – Phase C

The Information System Architectures or Phase C is where the Information Systems architectures are developed; specifically Target and Baseline architectures as well as any gap analysis. The Information System Architecture or Phase C will cover both the Data and Application Domains.

Technology Architecture – Phase D

The Technology Architecture or Phase D is where Technology Architectures are developed; specifically the Target and Baseline architectures as well as any gap analysis.

Opportunities and Solutions – Phase E

Opportunities and Solutions or Phase E is an extremely important phase of TOGAF because:

  • Where an architect starts migration planning and the initial implementation.
  • Decides on if they will be using any Transition Architectures.
  • Helps to Opportunities and Solutions (Phase E) into context

Migration Planning – Phase F

Migration Planning or Phase F is where any potential risks, benefits and costs are analysed to develop a detailed implementation and migration plan.

Implementation Governance – Phase G

Implementation Governance or Phase G is used to provide an oversight of the architectural implementation to ensure that the implementation will confirm to the architecture.

Architecture Change Management – Phase H

The Architecture Change Management or Phase H provides a change management process and continual monitoring of the proposed architecture. This process ensures that the architecture will respond to the needs of the Enterprise.

The Scope of Architectural Activities

How to limit and define the scope of Architectural Activities

It is important to understand that constraining the architecture activities is a vital part of how teams are structured within an organisation.

Within TOGAF there are four main aspects to consider when constraining the scope of an architecture:

  1. Enterprise Scope
  2. Time Period
  3. Architecture Domains
  4. Level of Detail or Vertical Scope

Enterprise Scope

The Enterprise Scope is usually defined by using one of two models:

  1. The publish and subscribe model
  2. Segment Architectures

The publish and subscribe model is the most common way of defining an Enterprise Scope and is most useful where an organisation is decentralised and architectures are developed in parallel.

The success of the publish and subscribe model depends on a functioning architecture governance which may include:

  • Compliance projects and reviews
  • Dispensation process definitions
  • Applications or projects that do not comply but are paramount in order for the business to operate

Segment Architectures are to be used where a business or organisation is divided up into segments. Each of these segments are likely to be functional areas and these segments are directly assigned to architecture teams.

Time Period

Transition Architectures are extremely important where an architecture team needs to stay relevant in organisations that are dynamic and fast paced. Where an organisation or business follows a transition architecture the organisation is able to respond to changes or crisis much more easily.

The ability to adapt to change easily is because the value delivery for the organisation is based upon specific and short transitions that will build up to the final architecture.

Level of Detail or Vertical Scope

When determining the level of detail or “Vertical scope” there are four main factors:

  1. Integration of components
  2. Associated risk
  3. Affordable level of detail
  4. Likelihood of change

Architecture Domains

There are four main domains that fall under the title of “Architecture Domains” – they are:

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

Some organisations or businesses divide their architecture teams up to work on one of the specific architecture domains only. There is an issue with separating the architecture teams up in this way and that is:

All domains rely on the Business Domain to ensure alignment between the business capability requirements and the proposed solutions that will be implemented to fulfill the requirements.

ADM Governance

How and should the Architecture Development Method be managed?

The ADM should be governed and managed. It is important that the management of all processes and artifacts are supported by a Governance Repository. In addition, the Architecture Board should be satisfied that the Architecture Method is being applied correctly throughout all the phases of the ADM iteration. Any proposed architecture should comply with the ADM as compliance is fundamental in terms of the governance of an architecture. Compliance will ensure that all the necessary deliverables are produced and all considerations pertaining to the architecture are made.

What is a Governance Repository?

The Governance Repository is used to manage different types of information for a proposed architecture – specifically:

  • Information about auditing that has occurred – this audit information generally records all completed process actions related to Governance.
  • Any reference information / data – reference data is used for direction and instructions during the implementation phase of the project.
  • Process status – this information pertains to the state of any governance processes

Narrowing the scope of architecture activities

There are many reasons to narrow the scope of an architecture activity; specifically:

  • Taking into account stakeholder and objective concerns that need to be addressed in the architecture
  • Constraints pertaining to the availability of resources (E.g. people or finance)

The specified scope for an architecture activity should allow all the work of all architects working within the enterprise or organisation to be effectively unified and governed. A specified scope will ensure that there is no cross over in terms of work activities being produced. In addition, a scope will also require the definition of reuse and the the way architecture architecture partitions relate.

When limiting the scope of an architecture activity there are four different dimensions that can be utilised:

  1. The Enterprise focus or scope
  2. The four architecture domains (Business, Data, Application and Technology)
  3. The level of detail otherwise known as the “Vertical scope
  4. Project schedule or “Time periods

When first starting to narrow the scope of an architecture it is usual to express the scope in terms of: Enterprise Scope, Time Period and the level of detail.

When the scope of the organisation is known, then an applicable combination of Architecture Domains can be selected which are inline with the problem being solved.

Ensuring integration and consistency across different organisational teams.

It is possible that different teams or people across the enterprise or organisation may be working on the same proposed architecture(s). Therefore there is the need to ensure that there is consistency and that any outputs can be easily integrated. This is where the Integration Framework comes in.

The Integration Framework sits above the individual architectures and can be an Enterprise Framework or a Meta Architecture Framework. The main purpose of the Integration Framework is to:

  • Ensure that architect(s) understand how the various components fit into the proposed architecture.
  • Develop the architecture models that meet the enterprise level capabilities
  • Define the compliance and conformance specifications that will allow the easy integration of the architecture components

The Enterprise Framework is a content framework which is used to position the different artifacts or domains.

A Meta Architecture Framework which may contain items such as standards, guidelines, principles or models) ensures the migration, conformance and interoperability between architectures.

ADM Relationships within TOGAF

How does the ADM relate to other parts of TOGAF?

The ADM is the core of the TOGAF standard and is backed/ supported by other parts of the TOGAF standard and library. The ADM is supported by many approaches (techniques) and guidelines and provides content which will be stored in the repository.

The content produced is then classified by the Enterprise Continuum (Initially this content is populated by the TOGAF Standard reference materials).

Finally the Architecture Capability Framework provides the means to drive the method.

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