Home The TOGAF® Standard
Search
Word Search | Search Index


Advanced Search
Provide feedback on this page

TOGAF® Fundamental Content

Extended Guidance

General How-To

Establishing an EA Team

Domains
Agile Methods
Business Architecture
Data/Information Architecture
Sustainability
Security Architecture

Reference Models & Method

1. Introduction

This chapter provides an introduction to the guidance provided in the TOGAF Standard — Architecture Content (this document).

1.1 Overview

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, or project compliance assessments. 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 Content Framework provided here is intended to allow the TOGAF framework to be used as a stand-alone framework for architecture within an enterprise. However, other Content Frameworks exist (such as the Zachman® Framework) and it is anticipated that some enterprises may opt to use an external framework in conjunction with the TOGAF framework. In these cases, the TOGAF Content Framework provides a useful reference and starting point for TOGAF content to be mapped to other Content Frameworks.

The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:

The relationships between deliverables, artifacts, and building blocks are shown in Figure 1-1 .

Figure 1-1: Relationships between Deliverables, Artifacts, and Building Blocks

For example, an Architecture Definition Document is a deliverable that documents an Architecture Description. This document will contain a number of complementary artifacts that are architecture views of the building blocks relevant to the architecture. For example, a process flow diagram (an artifact) may be created to describe the target call handling process (a building block). This artifact may also describe other building blocks, such as the actors involved in the process (e.g., a Customer Services Representative). An example of the relationships between deliverables, artifacts, and building blocks is illustrated in Figure 1-2 .

Figure 1-2: Example — Architecture Definition Document

1.2 TOGAF Content Framework and Enterprise Metamodel

1.2.1 Overview

The TOGAF ADM provides lifecycle management to create and manage architectures within an enterprise. At each phase within the ADM, a discussion of inputs, outputs, and steps describes a number of architecture work products.

An essential task when establishing the enterprise-specific Enterprise Architecture Capability in the Preliminary Phase of the ADM is to define:

The Content Framework chosen is likely to be influenced by:

1.2.2 Content Framework

The Content Framework defines a categorization framework to be used to structure the Architecture Description, the work product used to express an architecture, and the collection of models that describe the architecture.

The Architecture Repository, which is explained in 4.2.5 Architecture Repository , is structured to store the artifacts and work products identified in the Content Framework. The Content Framework is one element of the Enterprise-Specific Architecture Framework.

1.2.3 Enterprise Metamodel

The TOGAF Standard encourages development of an Enterprise Metamodel, which defines the types of entity to appear in the models that describe the enterprise, together with the relationships between these entities.

An Enterprise Metamodel provides value in several ways:

Note that the TOGAF Standard does not aim to constrain an enterprise's:

The types of entity within an enterprise and the relationships between them are specific to the individual enterprise. Developing a high-quality metamodel is an important aspect of establishing the Enterprise Architecture Capability.

1.2.4 The TOGAF Content Framework

The TOGAF Content Framework defines a categorization framework to be used to structure the Architecture Description, the work products used to express an architecture, and the collection of models that describe the architecture.

There are many alternative Content Frameworks (e.g., the TOGAF Content Framework, the Zachman Framework, DoDAF, NAF, etc.). Selecting a Content Framework is essential even though the choice of Content Framework is less important. The final Content Framework is usually adapted to fit specific organization needs.

The TOGAF Content Framework is intended to:

At the highest level, the TOGAF Content Framework (see Figure 1-3) is structured in line with the phases of the ADM.

Figure 1-3: Content Framework by ADM Phase

Figure 1-4: Content Framework Overview

1.3 Content Framework and the TOGAF ADM

The TOGAF ADM describes the process of moving from a baseline state of the enterprise to a target state of the enterprise. The ADM will address a business need through a process of visioning, architecture definition, transformation planning, and Architecture Governance. At each stage in this process, the ADM requires information as inputs and will create outputs as a result of executing a number of steps. The Content Framework provides an underlying structure for the ADM that defines inputs and outputs in more detail and puts each deliverable into the context of the holistic architecture view of the enterprise.

The Content Framework should therefore be used as a companion to the ADM. The ADM describes what needs to be done to create an architecture and the Content Framework describes what the architecture should look like once it is done.

1.4 The Enterprise Continuum

It is usually impossible to create a single unified architecture that meets all the requirements of all stakeholders for all time. Therefore, the Enterprise Architect will need to deal not just with a single Enterprise Architecture, but with many related Enterprise Architectures.

Each architecture may have a different purpose and architectures may relate to one another. Effectively bounding the scope of an architecture is therefore a Critical Success Factor (CSF) in allowing architects to break down a complex problem space into manageable components that can be individually addressed.

The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.

6. Enterprise Continuum discusses the Enterprise Continuum; including the Architecture Continuum and the Solutions Continuum.

1.5 The Architecture Repository

Operating a mature Architecture Capability within a large enterprise creates a huge volume of architectural output. Effective management and leverage of these architectural work products require a formal taxonomy for different types of architectural asset alongside dedicated processes and tools for architectural content storage.

7. Architecture Repository provides a structural framework for an Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization.

return to top of page