TOGAF Fundamental Content

This chapter describes the TOGAF Fundamental Content documents provided in the TOGAF Standard.

Introduction and Core Concepts

This document introduces the TOGAF Standard. It provides an executive overview of Enterprise Architecture and the TOGAF Standard; it describes the structure of the TOGAF documentation set, the core concepts of the framework, together with terminology and definitions that apply to the Fundamental Content. It consists of the chapters as shown in Table 1.

Table 1. Introduction and Core Concepts Summary
Chapter	Description
Introduction	A general introduction to Enterprise Architecture and the TOGAF Standard, including an executive overview.
The TOGAF Documentation Set	A description of the scope and structure of the materials that make up the TOGAF Standard, and the scope and structure of the TOGAF Library.
Core Concepts	A description of the core concepts that are used across the components of the TOGAF Standard.
Definitions	Definitions of terms that are used consistently across the components of the TOGAF Standard.
Appendices	The list of documents referenced in the TOGAF Standard, a supplementary list of definitions of terms, and commonly used abbreviations.

Core concepts in this document include high-level descriptions of the following:

The Architecture Development Method
Enterprise Architecture Services
Deliverables, Artifacts, and Building Blocks
Architecture Abstraction
Architecture Principles
Interoperability
Enterprise Continuum
Architecture Repository
TOGAF Content Framework and Enterprise Metamodel
Establishing and Maintaining an Enterprise Architecture Capability
Establishing the Architecture Capability as an Operational Entity
Using the TOGAF Standard with Other Frameworks
Using the TOGAF Framework with Different Architecture Styles
Architecture Views and Viewpoints
Enterprise Agility
Risk Management

The Architecture Development Method (ADM)

This document describes the TOGAF ADM, which is an iterative approach to developing an Enterprise Architecture. This document is described in the Architecture Development Method.

ADM Techniques

This document provides a collection of techniques to support the application of the TOGAF approach and the TOGAF ADM.

Table 2. ADM Techniques Summary
Chapter	Description
Architecture Principles	Describes principles for the use and deployment of resources across the enterprise, and how to develop the set of general rules and guidelines for the architecture being developed. See Architecture Principles.
Stakeholder Management	Describes stakeholder management, an important discipline that successful architecture practitioners can use to win support for their projects.
Architecture Patterns	Provides guidance on using architectural patterns.
Gap Analysis	Describes the technique used in the TOGAF ADM to validate an architecture that is being developed.
Migration Planning Techniques	Describes a number of techniques to support migration planning in Phases E and F. See Migration Planning Techniques.
Interoperability Requirements	Describes a technique for determining interoperability requirements.
Business Transformation Readiness Assessment	Describes a technique for identifying business transformation issues.
Risk Management	Describes a technique for managing risk during an architecture/business transformation project.^[1]
Architecture Alternatives and Trade-Offs	Describes a technique to identify alternative Target Architectures and perform trade-offs between the alternatives.

Stakeholder Management

Stakeholder management is an important discipline that successful architects can use to win support from others. It helps them ensure that their projects succeed where others fail. The technique should be used during Phase A to identify the key players in the engagement, and also be updated throughout each phase. The output of this process forms the start of the Communications Plan (see Communications Plan).

The benefits of successful stakeholder management are that:

The most powerful stakeholders can be identified early and their input can then be used to shape the architecture; this ensures their support and improves the quality of the models produced
Support from the more powerful stakeholders will help the engagement win more resources, thus making the architecture engagement more likely to succeed
By communicating with stakeholders early and frequently, the architecture team can ensure that they fully understand the architecture process, and the benefits of Enterprise Architecture; this means they can support the architecture team more actively when necessary
The architecture team can more effectively anticipate likely reactions to the architecture models and reports, and can build into the plan the actions that will be needed to capitalize on positive reactions while avoiding or addressing any negative reactions
The architecture team can identify conflicting or competing objectives among stakeholders early and develop a strategy to resolve the issues arising from them

Gap Analysis

The Gap Analysis technique is usually the final step within a phase. The basic premise is to highlight a shortfall between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately omitted, accidentally left out, or not yet defined.

The steps are as follows:

Draw up a matrix with all the Architecture Building Blocks (ABBs) of the Baseline Architecture on the vertical axis, and all the ABBs of the Target Architecture on the horizontal axis
Add to the Baseline Architecture axis a final row labeled “New”, and to the Target Architecture axis a final column labeled “Eliminated”
Where an ABB is available in both the Baseline and Target Architectures, record this with “Included” at the intersecting cell
Where an ABB from the Baseline Architecture is missing in the Target Architecture, each must be reviewed

If it was correctly eliminated, mark it as such in the appropriate “Eliminated” cell. If it was not, you have uncovered an accidental omission in your Target Architecture that must be addressed by reinstating the ABB in the next iteration of the architecture design – mark it as such in the appropriate “Eliminated” cell.
Where an ABB from the Target Architecture cannot be found in the Baseline Architecture, mark it at the intersection with the “New” row as a gap that needs to filled, either by developing or procuring the building block

When the exercise is complete, anything under “Eliminated” or “New” is a gap, which should either be explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function.

Migration Planning Techniques

The TOGAF Standard defines a number of techniques to support migration planning in Phases E and F. These are described in the following sections.

Implementation Factor Catalog

The Implementation Factor Catalog is used to document factors having an impact on the architecture Implementation and Migration Plan. The catalog should include a list of the factors to consider, their descriptions, and the deductions (conclusions) that indicate the actions or constraints that have to be taken into consideration when formulating the plans. Typical factors include risks, issues, assumptions, dependencies, actions, and impacts. An example catalog is shown in Table 3.

Table 3. Implementation Factor Catalog
Factor	Description	Deduction
<Name of the Factor>	<Description of the Factor>	<Impact on the Migration Plan>
Change in Technology	Reduction in staff in the call centers, saving 500 personnel, and have them replaced by AI systems.	Need for personnel training, re-assignment AI technology has major personnel savings and should be given priority.
Consolidation of Services	…	…
Introduction of New Customer Service	…	…

Consolidated Gaps, Solutions, and Dependencies Matrix

The Consolidated Gaps, Solutions, and Dependencies Matrix is used by the architect to group the gaps identified in the domain architecture gap analysis results and assess potential solutions and dependencies to one or more gaps. An example is shown in Table 4. This matrix can be used as a planning tool when creating work packages. The identified dependencies drive the creation of projects and migration planning in Phases E and F.

Table 4. Consolidated Gaps, Solutions, and Dependencies Matrix
#	Architecture	Gap	Potential Solutions	Dependencies
1	Business	New Order Processing Process	Use COTS software tool process Implement custom solution	Drives Application #2
2	Application	New Order Processing Application	COTS software tool X Develop in-house
3	Data	Consolidated Customer Database	Use COTS customer database Develop customer data mart

Architecture Definition Increments Table

The Architecture Definition Increments Table is used by the architect to plan a series of Transition Architectures outlining the status of the Enterprise Architecture at specified times. A table should be drawn up, as shown in Table 5, listing the projects and then assigning their incremental deliverables across the Transition Architectures.

Table 5. Example Architecture Definition Increments Table
Project	April 2020/2021	April 2021/2022	April 2022/2023	Comments
	Transitional Architecture 1: Preparation	Transitional Architecture 2: Initial Operational Capability	Transitional Architecture 3: Benefits
Enterprise e‑Services Capability	Training and Business Process	e-licensing Capability	e-employment Benefits
IT e-Forms	Design and Build
IT e-Information Environment	Design and Build Information Environment	Client Common Data Web Content Design and Build	Enterprise Common Data Document Management Design and Build
…	…	…	…	…

Transition Architecture State Evolution Table

The Transition Architecture State Evolution Table is used by the architect to show the proposed state of the architectures at various levels using the defined taxonomy for the enterprise.

Table 6. Example Transition Architecture State Evolution Table
Sub-Domain	Service	Transition Architecture 1	Transition Architecture 2	Transition Architecture 3
Infrastructure Applications	Information Exchange Services	Solution System A (replace)	Solution System B-1 (transition)	Solution System B-2 (new)
	Data Management Services	Solution System D (retain)	Solution System D (retain)	Solution System D (retain)
…	…

A table should be drawn, listing the services from the taxonomy used in the enterprise, the Transition Architectures, and proposed transformations, as shown in Table 6. All SBBs should be described with respect to their delivery and impact on these services. They should also be marked to show the progression of the Enterprise Architecture. In the example, where target capability has been reached, this is shown as “new” or “retain”; where capability is transitioned to a new solution, this is marked as “transition”; and where a capability is to be replaced, this is marked as “replace”.

Business Value Assessment Matrix

The business value assessment matrix is a matrix based on a value index dimension and a risk index dimension. It is used to assess the business value of a project.

An example is shown in Figure 1, showing Projects A through H. The value index should include criteria such as compliance to principles, financial contribution, strategic alignment, and competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure. Each criterion should be assigned an individual weight.

Figure 1. Example Business Value Assessment Matrix

Risk Management

Identification of business transformation risks and mitigation activities is first determined in Phase A. Risk management is a technique used to mitigate risk when implementing an architecture project.

It includes a process for managing risk consisting of the following activities:

Risk classification
Risk identification
Initial risk assessment
Risk mitigation and residual risk assessment
Risk monitoring

It is recommended that risk mitigation activities be included within the Statement of Architecture Work (see [desc-Statement-of-Architecture-Work]).

Architecture Alternatives and Trade-Offs

There is often more than one possible Target Architecture that would conform to the Architecture Vision, Architecture Principles, and Requirements. It is important to identify alternative Target Architectures and build understanding of different possibilities and identify trade-offs between the alternatives. Creating an architecture normally requires trade-offs among competing forces. Presenting different alternatives and trade-offs to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final Target Architecture. Figure 2 illustrates the architecture trade-off method.

Figure 2. Architecture Trade-Off Method

Applying the ADM

This document provides guidelines for adapting the TOGAF ADM to deal with a number of usage scenarios.

Table 7. Applying the ADM Summary
Chapter	Description
Using the TOGAF Framework with Different Architecture Styles	Discusses how the framework can be adapted to different architectural styles.
Applying Iteration to the ADM	Discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM.
Applying the ADM Across the Architecture Landscape	Discusses the different types of architecture engagement that may occur at different levels of the enterprise – this section then also discusses how the ADM process can be focused to support different types of engagement.
Architecture Partitioning	Discusses how partitions are used to simplify the development and management of the Enterprise Architecture.

Architecture Styles

The Architecture Development Method (ADM) process can be adapted to deal with many different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (such as security). Architectural styles differ in terms of focus, form, techniques, materials, subject, and time period. The TOGAF Standard is a generic framework intended to be used in a wide variety of environments. It is a flexible and extensible framework that can be readily adapted to a number of architectural styles.

An organization’s Architecture Landscape can be expected to contain architecture work that is developed in many architectural styles. The TOGAF Standard ensures that the needs of each stakeholder are appropriately addressed in the context of other stakeholders and the Baseline Architecture.

When using the TOGAF Standard to support a specific architectural style the practitioner must take into account the combination of distinctive features in which architecture is performed or expressed. As a first step, the distinctive features of a style must be identified.

The second step is determining how these distinctive features will be addressed. Addressing a distinctive style should not call for significant changes to the TOGAF framework; instead it should adjust the models, viewpoints, and tools used by the practitioner.

In Phase B, Phase C, and Phase D the practitioner is expected to select the relevant architecture resources, including models, viewpoints, and tools, to properly describe the architecture domain and demonstrate that stakeholder concerns are addressed. Depending upon the distinctive features, different architectural styles will add new elements that must be described, highlight existing elements, adjust the notation used to describe the architecture, and focus the architect on some stakeholders or stakeholder concerns.

Addressing the distinctive features will usually include extensions to the Architecture Content Metamodel and the use of specific notation or modeling techniques and the identification of viewpoints. Dominance of a particular architectural style can direct the practitioner to revisit the Preliminary Phase to make changes to the Architecture Capability or to address a distinctive feature in the expected scope of a single ADM cycle. Style-specific reference models and maturity models are commonly used tools that support a practitioner.

Iteration and the ADM

The graphical representation of the TOGAF ADM and the description of the ADM phases discretely in order can be read to imply a deterministic waterfall methodology. This method of presentation is provided for the purpose of quickly communicating the basics of architecture development and the architecture development cycle. In practice, two key concepts are used to manage the complexity of developing an Enterprise Architecture and managing its lifecycle — iteration and levels. The two concepts are tightly linked.

The ADM supports a number of concepts that are characterized as iteration.

Iteration to develop a comprehensive Architecture Landscape:

Projects will iterate through the entire ADM cycle, commencing with Phase A

Each cycle of the ADM will be bound by a Request for Architecture Work. The architecture output will populate the Architecture Landscape, either extending the landscape described, or changing the landscape where required.
Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects
One project may trigger the initiation of another project

Typically, this is used when higher-level architecture initiatives identify opportunities or solutions that require more detailed architecture, or when a project identifies landscape impacts outside the scope of its Request for Architecture Work.

Iteration within an ADM cycle (Architecture Development Iteration):

Projects may operate multiple ADM phases concurrently

Typically, this is used to manage the inter-relationship between Business Architecture, Information Systems Architecture, and Technology Architecture.
Projects may cycle between ADM phases, in planned cycles covering multiple phases

Typically, this is used to converge on a detailed Target Architecture when higher-level architecture does not exist to provide context and constraint.
Projects may return to previous phases in order to circle back and update work products with new information

Typically, this is used to converge on an executable Architecture Roadmap or Implementation and Migration Plan, when the implementation details and scope of change trigger a change or re-prioritization of stakeholder requirements.

Iteration to manage the Architecture Capability (Architecture Capability Iteration):

The result of addressing a Request for Architecture Work in Phase A may require a new iteration of the Preliminary Phase to adjust the Architecture Capability for the organization
Changes identified in Phase H may require a new iteration of the Preliminary Phase to adjust the Architecture Capability for the organization

The suggested iteration cycles for the TOGAF ADM are shown in Figure 3. These can be used to effectively group related architectural activities to achieve a specific purpose.

Figure 3. Iteration Cycles

The iteration cycles are as follows:

Architecture Capability iterations support the creation and evolution of the required Architecture Capability

These iterations include the initial mobilization of the architecture activity for a given purpose or architecture engagement type by establishing or adjusting the architecture approach, principles, scope, vision, and governance.
Architecture Development iterations allow creation of content by cycling through, or integrating, Business, Information Systems, and Technology Architecture phases

These iterations ensure that the architecture is considered as a whole. In this type of iteration stakeholder reviews are typically broader. As the iterations converge on a target, extensions into the Opportunities and Solutions and Migration Planning phases ensure that the architecture’s implementability is considered as the architecture is finalized.
Transition Planning iterations support the creation of formal change roadmaps for a defined architecture
Architecture Governance iterations support governance of change activity progressing towards a defined Target Architecture

A number of techniques can be employed to use the ADM as a process that supports hierarchies of architectures, referred to as levels. Essentially there are two strategies that can be applied:

Architectures at different levels can be developed through iterations within a single cycle of the ADM process
Architectures at different levels can be developed through a hierarchy of ADM processes, executed concurrently (see a Hierarchy of ADM Processes Example)

Applying the ADM Across the Architecture Landscape

In a typical enterprise, many architectures will be described in the Architecture Landscape at any point in time. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. To address this complexity the TOGAF Standard uses the concepts of levels.

Levels provide a framework for dividing and organizing the Architecture Landscape into three levels of granularity as summarized in Figure 4:

Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.

Figure 4. Summary Classification Model for Architecture Landscape

Architecture Partitioning

Partitions are used to simplify the development and management of the Enterprise Architecture. Architectures are partitioned because:

Organizational unit architectures conflict with one another
Different teams need to work on different elements of architecture at the same time and partitions allow for specific groups of architects to own and develop specific segments of the architecture
Effective architecture re-use requires modular architecture segments that can be taken and incorporated into broader architectures and solutions

It is impractical to present a definitive partitioning model for architecture. Each enterprise needs to adopt a partitioning model that reflects its own operating model. The TOGAF Standard includes classification criteria that can be applied when partitioning architectures, and guidance for activities within the Preliminary Phase for establishing a partition.

Architecture Content

This document describes the TOGAF Content Framework, a structured metamodel for architectural artifacts, and an overview of typical architecture deliverables, artifacts within deliverables, and the ABBs that artifacts represent.

Table 8. Architecture Content Summary
Chapter	Description
Introduction	An overview of the Architecture Content document introducing the key concepts, including categories for architectural work products, the TOGAF Content Framework, the Enterprise Metamodel, the Enterprise Continuum, and the Enterprise Repository.
TOGAF Content Framework and Enterprise Metamodel	Describes the Content Framework, a categorization framework used to structure the Architecture Description and the models that describe an architecture. The Enterprise Metamodel defines the types of entities that appear in the models that describe the architecture, and the relationships between these entities.
Architectural Artifacts	Discusses the concepts surrounding architecture artifacts and then describes the artifacts that are recommended to be created for each phase within the ADM.
Architecture Deliverables	Provides descriptions of deliverables referenced in the ADM.
Building Blocks	Explains the concept of building blocks and their use in the ADM.
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.
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.

Content Framework Overview

Architects executing the 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 TOGAF Content Framework is intended to:

Provide a detailed model of architectural work products
Drive consistency in the outputs created when following the ADM
Provide a comprehensive checklist of architecture output that could be created
Reduce the risk of gaps within the final architecture deliverable set
Help an enterprise mandate standard architecture concepts, terms, and deliverables

The Content Framework provided supports the use of the TOGAF framework as a stand-alone framework for architecture within an enterprise. However, other Content Frameworks exist (for example, that provided by the ArchiMate Specification) and it is expected that some enterprises will use an external framework in conjunction with the ADM instead. In such cases, the TOGAF Content Framework provides a useful reference and starting point for TOGAF content to be mapped to the metamodels of other frameworks.

Figure 5. Content Framework Overview

Architectural Work Products

In order to assist with the classification of new work products and the potential need to correlate with other content frameworks (including any existing classified architecture work products), the Content Framework uses the following three categories to describe the type of architectural work product within its context of use:

A deliverable is a work product that is contractually specified, and would normally be reviewed, agreed, and signed off by its stakeholders – deliverables often represent the output of projects
An artifact is an architectural work product that describes an aspect of the architecture

Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, application interaction matrix, and a value chain diagram. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository.
A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions

The Enterprise Continuum

The Enterprise Continuum, shown in Figure 6, is a categorization for artifacts held in the Enterprise Repositories that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

Figure 6. The Enterprise Continuum

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.

The TOGAF Standard 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. This Architecture Repository is one part of the wider Enterprise Repository, which provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories.

Figure 7. Overview of Architecture Repository

Enterprise Architecture Capability and Governance

This document is a set of resources, guidelines, templates, background information, etc. provided to help establish an architecture practice and governance framework within an organization. It describes the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise and describes an Enterprise Architecture governance framework.

Table 9. Enterprise Architecture Capability and Governance Summary
Chapter	Description
Establishing an Architecture Capability	Guidelines on how to use the ADM to establish an Architecture Capability within an organization.
Architecture Governance	Framework and guidelines for Architecture Governance.
Architecture Board	Guidelines for establishing and operating an Enterprise Architecture Board.
Architecture Contracts	Guidelines for defining and using Architecture Contracts.
Architecture Compliance	Guidelines for ensuring project compliance to the architecture.

Architecture Capability

An overview of the TOGAF Architecture Capability is shown in Figure 8.

Figure 8. Architecture Capability Overview

Architecture Governance

The TOGAF Standard contains a framework and guidelines for Architecture Governance. Architecture Governance is the practice by which Enterprise Architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the following:

Implementing a system of controls over the creation and monitoring of all architecture components and activities, to ensure the effective introduction, implementation, and evolution of architectures 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
Establishing and documenting decision structures that influence the Enterprise Architecture; this includes stakeholders that provide input to decisions
Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization

Architecture Board

An Enterprise Architecture is more than just the artifacts produced by the application of the ADM process. Making the organization act according to the principles laid down in the architecture requires a decision-making framework. The TOGAF Standard provides a set of guidelines for establishing and operating an Enterprise Architecture Board.

An Architecture Board is responsible for operational items and must be capable of making decisions in situations of possible conflict and be accountable for taking those decisions. It should therefore be a representation of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture. It is important that the members of the Architecture Board cover architecture, business, and program management areas.

Issues for which the Architecture Board can be made responsible and accountable are:

Providing the basis for all decision-making with regard to changes to the architectures
Consistency between sub-architectures
Identifying re-usable components
Flexibility of Enterprise Architecture; to meet business needs and utilize new technologies
Enforcement of architecture compliance
Improving the maturity level of architecture discipline within the organization
Ensuring that the discipline of architecture-based development is adopted
Supporting a visible escalation capability for out-of-bounds decisions

The Architecture Board is also responsible for operational items, such as the monitoring and control of Architecture Contracts, and for governance items, such as producing usable governance materials. Important tasks are:

Assigning architectural tasks
Formally approving architectural products
Resolving architectural conflicts

1. For expanded guidance on Risk Management see the TOGAF Series Guide: Integrating Risk and Security within a TOGAF^® Enterprise Architecture.