The Architecture Continuum provides a consistent way to describe and understand the implementation of the assets

A Foundation Architecture supports the complete enterprise operating environment.

Common Systems Architectures guide the creation of an architecture useful for building common solutions across a wide number of relevant domains

Industry Architectures guide the integration of common systems components with industry specific components.

Organization-Specific Architectures describe and guide the final deployment of user-written or third-party components that constitute effective solutions for particular enterprises

At relevant places throughout the ADM, there are reminders to consider which architecture assets from the Architecture Repository the architect should use

The practical implementation of the Enterprise Continuum will typically take the form of an Architecture Repository that includes reference architectures, models, and patterns mandated in TOGAF

In executing the ADM, the architect is only developing a snapshot of the enterprise at particular points in time, and populating the organization’s own Architecture Repository is outside the scope of ADM

The first execution of the ADM is simplified because of the re-use potential of the standard architecture assets available for re-use in TOGAF Architecture Repository

Architecture Repository is only accessed in the Requirement Management phase

Fundamental organization of the IT system

The principles governing its design and evolution IT system

Hardware, software, and communications technology and their relationships to each other and the environment

Technical implementation architecture

Target Technology Architecture that will form the basis of the subsequent implementation and migration planning

Architecture Landscape

Standards Information Base

Architecture Metamodel

Architecture Capability

E. Compliance Log

Implementing a system of controls over the creation and monitoring of all architectural components and activities

Improving the maturity level of architecture discipline within the organization

Implementing a system to ensure compliance with internal and external standards and regulatory obligations

Establishing processes that support effective management of the above processes within agreed parameters

Developing practices that ensure accountability to a clearly identified stakeholder community

Preliminary phase

Phase A

Phase B

Phase C

Phase D

To improve the maturity level of architecture discipline within the organization

To identify where the standards themselves may require modification

To identify services that are currently application-specific but might be provided as part of the enterprise infrastructure

To document strategies for collaboration, resource sharing, and other synergies across multiple architecture teams

To take advantage of advances in technology

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution

A rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them

An architecture is the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales about the overall structure (i.e., essential elements and their relationships) and associated characteristics and behavior

Architecture is the use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting

A formal description of a system, or a detailed plan of the system at a component level to guide its implementation or the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

Enterprise Continuum is a virtual repository where as the Architecture Repository is a physical repository

Enterprise Continuum can be thought of as a view of the Architecture Repository

The Architecture Repository defines six classes for architectural information held in the repository

TOGAF recognizes the need to manage the content of the Enterprise Continuum using tools but does not provide any guidance on tool selection

The Solutions Continuum is a population of the architecture with reference building blocks – either purchased products or built components – that represent a solution to the enterprise’s business needs

Preliminary phase

Phase A

Phase B

Phase C

Phase D

Architecture Principles

Use case Modeling

Architecture Patterns

Interoperability Requirements

Capability-Based Planning

Architecture Vision, Architecture Requirements Specification and Architecture Roadmap

Source Architecture, Target Architecture and Gap Analysis

Architecture Vision, Architecture Design Document and Transition Architecture

Building Block, Artifact and Deliverable

Request for Architecture Work, Statement of Architecture Work and Architecture Contract

Phase A

Phase E

Phase F

Phase G

Phase H

It is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository

It is an important aid to communication and understanding, both within individual enterprises, and between customer enterprises and vendor organizations

It also represents an aid to organizing re-usable architecture and solution assets

It is a physical repository of all architecture assets models, patterns, architecture descriptions, and other artifacts produced during application of the ADM

It represents an aid to communication

ADM Guidelines and Techniques

Architecture Content Framework

Architecture Governance

TOGAF Reference Models

Architecture Capability Framework

Gap Analysis

Architecture Patterns

Interoperability Requirements

Business Scenario

Business Transformation Readiness Assessment

They define how the functionality will be realized through products and components

They capture architecture requirements

They define the implementation

They fulfill business requirements

They are product or vendor-aware

Requirement Management

Migration Planning

Implementation Governance

Architecture Change Management

Opportunities and Solutions

Yes, you can only cycle around the ADM

Yes, you can cycle around all single individual phase

Yes, you can cycle around any combination of phases

Yes, you can cycle around ADM, iterate across specific phases or cycle through some of the phases

No, ADM is not iterative

It will make certain that the architecture selected allows for future growth in response to the needs of the business

It will ensure more complete coverage of the designed solution

It will speed up and simplify architecture development

Its use may be mandated by federal agencies

It will ensure compliance and protect the interest of stakeholders

Refer to any existing libraries of viewpoints

Select key stakeholders

Analyze their requirement and document them

Select appropriate viewpoints

Generate views of the system using the selected viewpoints as templates

Preliminary phase

Phase A

Phase B

Phase E

Requirement Management Phase

Preliminary Phase

Phase A

Phase B

Phase E

Phase F

Concerns determine the acceptability of the system

The terms “concern” and “requirement” are synonymous

Concerns are the root of the process of decomposition into requirements

Concerns are represented in the architecture by these requirements

Each stakeholder typically has interests in, or concerns relative to, that system

Information consumer application

Management utilities

Brokering application

Communication infrastructure interface

Information provider application

Continuous monitoring to check integrity

Adherence to the principles and standards

Facilitate re-usablility

Identification of risks

Ensuring accountability, responsibility, and discipline

A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain

Business Architecture is often necessary as a means of demonstrating the business value of subsequent architecture work

Business Architecture looks at the Enterprise in abstraction and does not look at the relationship between people and process

Business Architecture should support the agreed Architecture Vision

Business Architecture should demonstrate how stakeholder concerns are addressed

Compliance, Business Control , Monitoring and Reporting

Process, Content, Monitoring and Reporting

Process, Content, Repository and Process Flow Control

Content, Context, Process and Reporting

Business Control, Content, Monitoring and Reporting

Increased visibility supporting internal processes and external parties’ requirements

Greater shareholder value

Improved software development productivity

Protection of the existing asset base through maximizing re-use

Controlled risk management

A business process, application, or set of applications

The business and technology environment

The people and computing components who execute the scenario

The underlying business vision

The desired outcome of proper execution

It is established in Phase A and operated on Phase F to H

It is established in Preliminary Phase, refined in Phase A and operated on Phase F to H

It is established in Phase A and operated on Phase E to G

It is established in Preliminary Phase and operated on Phase G and H

It is established in Preliminary Phase and operated on all subsequent phases

It considers implementation and usage, and evolves to exploit technology and standards

It may be assembled from other building blocks

It may be a sub assembly of other building blocks

Ideally, a building block is re-usable and replaceable, and well specified with stable interfaces

It may specify implementation details

It is a reference model that focuses on the Application Software space

It is fundamentally an Application Architecture reference model – a model of the application components and application services software essential for an integrated information infrastructure

It enables each individual department to operate at maximum efficiency was for a long time accepted as the best approach to managing a large enterprise

It describes a fundamental architecture upon which other, more specific, architectures can be based

It points to rules and standards to assist in leveraging solutions and products within the value chain

Technology Architecture

Migration Planning

Implementation Governance

Architecture Change Management

Opportunities and Solutions

It is first carried out in Phase A and updated in Phase E

It is first carried out in Preliminary Phase and updated in Phase A to E

It is first carried out in Phase A, updated in Phase E and finalized in Phase F

It is first carried out in Preliminary Phase, updated in Phase A to E and finalized in Phase F

It is first carried out in Phase A and updated in Phase B to E

People gaps

Process gaps

Tools gaps

Information gaps

Data relationship gaps

It emerges through phase B to D and is finalized in phase E

It is first formulated in phase E and gets refined in phase F and G

It is formulated in phase E and then split into implementation projects

Based on the implementation projects selected in phase E, Transition Architectures is arrived at in phase F

In Phase E major implementation projects grouped into Transition Architectures and they are confirmed with relevant stakeholders in phase F

The organizationally tailored application of an architecture framework, including a meta-model for architecture content

The parameters, structures, and processes that support governance of the Architecture Repository

An architectural view of the building blocks that are in use within the organization today

A Stakeholder analysis and map

A record of governance activity across the enterprise

An important consideration is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise concerned

An enterprise may wish to use or tailor the ADM in conjunction with the security best practices in use in the enterprise

The ADM is one of many corporate processes that make up the corporate governance model for an enterprise

The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation, and needs to be tailored to achieve a suitable compromise between the contractor’s existing practices and the contracting enterprise’s requirements

The enterprise is a small-to-medium enterprise, and wishes to use a “cut-down” version of the ADM

It holds guidelines, templates, patterns

It holds a set of specifications, to which architectures must conform

It describes the organizationally tailored application of an architecture framework

It defines the parameters, structures, and processes that support governance

It holds view of the building blocks that are in use within the organization today