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

The Architecture Capability Framework

The Architecture Capability Framework is used to examine and discuss the roles, skills, processes and responsibilities that are needed to operate and create an Architecture function inside an Enterprise. In addition the Architecture Capability Framework also provides assets and resources that are required when creating an Enterprise Architecture Capability.

According to TOGAF the recommended capabilities are:

  • Supplier Management
  • Risk Management
  • Configuration Management
  • Resource Management
  • Financial Management
  • Service Management
  • Quality Management
  • Performance Management
  • Stakeholder Management
  • Communications Management
  • Environmental Management

The Architecture Repository

The Architecture Repository is a model used for storing the different types of output produced by the architecture and is conceptually linked to the Enterprise Continuum. The Architecture Repository consists of the following main components:

  • Architecture Meta-model
  • Architecture Landscape
  • Reference Library
  • Standards Information Base (SIB)
  • Governance Log
  • Architecture Capability

Architecture Meta-model
The Architecture Meta-model is used to describe the content meta-model in the form of a architecture method that is specific to the organisation

Architecture Landscape
The Architecture Landscape provides an architectural depiction of the assets being planned or that are currently in use by the architecture at specific points in time (e.g. Past, Present and Future)

Reference Library
The Reference Library contains any architecture work products that are able to be re-used

Standards Information Base (SIB)
The Standards Information Base (SIB) is a directory or database of standards which are able to be used to define a set of specific services and components for the specific architecture of an organisation

Governance Log
The Governance Log is use to capture the result of any activity produced by the governance (e.g. Compliance assessment)

Artifacts, Deliverables and Building Blocks

What is the difference between Artifacts, Deliverables and Building blocks?

An Artifact is a smaller work product that is used to describe an architecture via a specific viewpoint (E.g. A matrix or diagram).

Think of a Deliverable as a product of work that can be reviewed and then signed off on by a stakeholder or stakeholders.

A Building Block is used to represent the capability of a component of IT, business / organisation or architecture capability. It is therefore possible that a Artifact can contain multiple Building Blocks and a Deliverable can contain multiple Artifacts.

The Enterprise Continuum

The Enterprise Continuum as related to TOGAF is used to describe how generic solutions can be specalised and leveraged in order to support the individual requirements of an organisation. Specifically the Enterprise Continuum sets the broader context for an architect.

Think of the Enterprise Continuum as a virtual repository of all the assets that make up the architecture; for example:

  • Patterns
  • Architecture descriptions
  • Models

The Enterprise Continuum is also able to aid communication as it provides a consistent language with which to categorise and classify artifacts.

The Enterprise Continuum consists of two core concepts:

  1. Solutions Continuum
  2. Architecture Continuum

Solutions Continuum
The Solutions Continuum provides a way to consistently understand and describe the implementation of the assets which are defined within the Architecture Continuum. The Solutions Continuum also defines the Solution Building Blocks (SBBs) that are able to be reused within the organisational environment.

Architecture Continuum
The Architecture Continuum provides a way to consistently understand and refine the generic representations, rules and relationships within the Architecture. This representation includes the derivation and trace-ability relationships.