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:

• A deliverable is a work product that is contractually specified and in turn formally reviewed, approved, and signed off by the stakeholders

  Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.

• 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 enterprise capability that can be combined with other building blocks to deliver architectures and solutions

  Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".

  • Architecture Building Blocks (ABBs) typically describe what is required of SBBs at a more logical or supplier-independent level; those requirements may include services to be performed, data resources, and capabilities needed. ABBs include logical business, application, and technology components
  • Solution Building Blocks (SBBs) represent physical or supplier-specific components that have the capability to realize part or all of a more logical ABB. There are business, application, and technology SBBs.

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

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 .

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:

• A categorization framework to be used to structure the Architecture Descriptions, the work products used to express an architecture, and the collection of models that describe the architecture; this is referred to as the Content Framework
• An understanding of the types of entities within the enterprise and the relationships between them that need to be captured, stored, and analyzed in order to create the Architecture Description; this Enterprise Metamodel depicts this information in the form of a formal model
• The specific artifacts to be developed (see 4. Architecture Deliverables)

The Content Framework chosen is likely to be influenced by:

• The Architecture Framework selected as the basis for the Enterprise Architecture Capability
• The chosen software tool used to support the Enterprise Architecture Capability

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:

• It gives architects a starter set of the types of thing to investigate and to cover in their models
• It provides a form of completeness-check for any architecture modeling language, or architecture metamodel, that is proposed for use in an enterprise

  Namely, how completely does it handle the types of entity in the Enterprise Metamodel, and manage required facts about them such as their attributes and relationships?

• It can help ensure:
  • Consistency
  • Completeness
  • Traceability

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

• Selection of artifacts
• Modeling notation

  The TOGAF Standard may use the ArchiMate® modeling language, Business Process Modeling Notation^TM (BPMN^TM), Unified Modeling Language^TM (UML®), entity relationship diagramming, flowcharting, or any other notation that can express some TOGAF ideas.

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:

• 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

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

• Architecture Principles, Vision, Motivation, and Requirements models are intended to capture the surrounding context of formal architecture models, including general Architecture Principles, strategic context that forms input for architecture modeling, and requirements generated from the architecture

  The relevant aspects of the business context that have given rise to the Request for Architecture work are typically investigated, refined, validated, and recorded in the Preliminary and Architecture Vision phases.

• Business Architecture captures architecture models of the business, looking specifically at factors that motivate the enterprise, its structure, and its capabilities
• Information Systems Architecture models capture architecture models of IT systems, looking at applications and data in line with the TOGAF ADM phases
• Technology Architecture models capture technology assets that are used to implement and realize information system solutions
• Architecture Realization/Transformation models capture change roadmaps showing transition between architecture states and binding statements that are used to steer and govern an implementation of the architecture
• Architecture Change Management models capture value realization management events, internal and external, that impact the Enterprise Architecture and the generation of requirements for action

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.

---

---