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.
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.
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.
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.
# | 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.
Project | April 2020/2021 | April 2021/2022 | April 2022/2023 | Comments |
---|---|---|---|---|
Transitional Architecture 1: |
Transitional Architecture 2: |
Transitional Architecture 3: |
||
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.
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.
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.
Applying the ADM
This document provides guidelines for adapting the TOGAF ADM to deal with a number of usage scenarios.
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.
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.
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.
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.
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.
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.
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.
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.
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