TOGAF 9.1 Series — Architecture Content Framework

Have you ever heard of TOGAF and never really understood it? In my TOGAF 9.1 series of articles, I will give you summary points what TOGAF is and what you will learn in TOGAF.

I have written the TOGAF exam a while back. I thought that writing this series will let me review the TOGAF content and believe that it would be valuable to others. It is always a good practice to regularly review the contents of a topic that you have learned.

I’m not going to rewrite the official TOGAF books content in my article series. Some sections will only contain bullet points of key terms used in TOGAF. Always reference the official TOGAF book for more details.

Legal Points

TOGAF is a trademark of The Open Group. They maintain the TOGAF standard and release new versions of the framework. I highly recommend that you read the official website and content of TOGAF on the official site:

The contents in my article series are my opinions and in no way reflects the views of The Open Group.

If you are interested in learning all the finer details of TOGAF or want to write the exam then buy the official book:

Figure 1: TOGAF Version 9.1 book

Architecture Content Framework

Content Metamodel

The Content Metamodel identifies all of these concerns, shows the relationships that are possible between them and finally identifies artifacts that can be used to represent them.

Content Metamodel Overview

Architecture Principles, Vision and Requirements:


  • Architecture Principles

Architecture Vision

  • Business Strategy
  • Technology Strategy
  • Business Principles, Objectives and Drivers
  • Architecture Vision
  • Stakeholders

Architecture Requirements

  • Requirements
  • Constraints
  • Assumptions
  • Gaps

Business Architecture

  • Motivation: Drivers, Goals, Objectives, Measures
  • Organization: Organizational Units, Locations, Actors, Roles


  • Business Services, Contracts, Service Qualities
  • Processes, Events, Controls, Products
  • Functions

Information Systems Architecture

  • Data: Data Entities, Logical Data Components, Physical Data Components
  • Application: Information System Services, Logical Application Components, Physical Application Components

Technology Architecture

  • Platform Service
  • Logical Technology Components
  • Physical Technology Components

Architecture Realization

  • Opportunities, Solutions and Migration Planning: Capabilities, Work Packages, Architecture Contracts
  • Implementation Governance
  • Standards
  • Guidelines
  • Specifications

Core Content Metamodel Concepts

Core Concepts

Core and Extension Content

  • Employs a basic core Metamodel and then applies a number of extension modules.

Core Metamodel Entities

  • Showing the purpose of each entity and the key relationships that support architectural traceability.

Catalog, Matrix and Diagram Concept

  • Describes the concept of catalogs, matrices and diagrams.

Core Metamodel and its Extensions

Core Content Metamodel

  • Governance Extensions
  • Services Extensions
  • Process Modeling Extensions
  • Data Extensions
  • Infrastructure Consolidation Extensions
  • Motivation Extensions

Core Metamodel Entities

  • Actor
  • Application Component
  • Business Service
  • Data Entity
  • Function
  • Information System Service
  • Organization Unit
  • Platform Service
  • Role
  • Technology Component

Key Relationship Concepts

  • Process should normally be used to describe flow
  • Function describes units of business capability at all levels of granularity
  • Business services support organizational objectives and are defined at a level of granularity consistent with the level of governance needed
  • Business services are deployed onto application components
  • Application components are deployed onto technology components

Architectural Artifacts

Basic Concept

Architectural artifacts are created in order to describe a system, solution or state of the enterprise.


  • A view is what you see.
  • A view is always specific to the architecture for which it is created.


  • A viewpoint is where you are looking from — the vantage point or perspective that determines what you see.
  • Viewpoints are generic and can be stored in libraries for re-use.

View Creation Process


  • Refer to an existing library of viewpoints
  • Select the appropriate viewpoints
  • Generate views of the system by using the selected viewpoints as templates

Approach Benefits

  • Less work for the architects
  • Better comprehensibility for stakeholders
  • Greater confidence in the validity of the views

Classes of Artifacts


  • Are logs lists of building blocks


  • Show the relationships between building blocks of specific types


  • Present building blocks plus their relationships and interconnections in a graphical way that supports effective stakeholder communication.

Recommended Artifacts for ADM Phases


  • Principles Catalog

Phase A — Architecture Vision

  • Stakeholder Map Matrix
  • Value Chain Diagram
  • Solution Concept Diagram

Phase B — Business Architecture

  • Organization/Actor Catalog
  • Driver/Goal/Objective Catalog
  • Role Catalog
  • Business Service/Function Catalog
  • Location Catalog
  • Process/Event/Control/Product Catalog
  • Contract/Measure Catalog
  • Business Interaction Matrix
  • Actor/Role Matrix
  • Business Footprint Diagram
  • Business Service/Information Diagram
  • Functional Decomposition Diagram
  • Product Lifecycle Diagram
  • Goal/Objective/Service Diagram
  • Business Use-Case Diagram
  • Organization Decomposition Diagram
  • Process Flow Diagram
  • Event Diagram

Phase C — Data Architecture

  • Data Entity/Data Component Catalog
  • Data Entity/Business Function Matrix
  • Application/Data Matrix
  • Conceptual Data Diagram
  • Logical Data Diagram
  • Data Dissemination Diagram
  • Data Security Diagram
  • Data Migration Diagram
  • Data Lifecycle Diagram

Phase C — Application Architecture

  • Application Portfolio Catalog
  • Interface Catalog
  • Application/Organization Matrix
  • Role/Application Matrix
  • Application/Function Matrix
  • Application Interaction Matrix
  • Application Communication Diagram
  • Application and User Location Diagram
  • Application Use-Case Diagram
  • Enterprise Manageability Diagram
  • Process/Application Realization Diagram
  • Software Engineering Diagram
  • Application Migration Diagram
  • Software Distribution Diagram

Phase D — Technology Architecture

  • Technology Standards Catalog
  • Technology Portfolio Catalog
  • Application/Technology Matrix
  • Environment and Location Diagram
  • Platform Decomposition Diagram
  • Processing Diagram
  • Networked Computing/Hardware Diagram
  • Communications Engineering Diagram

Phase E — Opportunities and Solutions

  • Project Context Diagram
  • Benefits Diagram

Requirements Management

  • Requirements Catalog

Architecture Views Categories

Business Architecture Views

  • Address the concerns of the users of the system.

Data Architecture Views

  • Address the concerns of database designers and database administrators.

Application Architecture Views

  • Address the concerns of system and software engineers.

Technology Architecture Views

  • Address the concerns of acquirers, operating staff, system administrators and system managers.

Recommended Architecture Views

Business Architecture View

  • Is concerned with addressing the concerns of users.

Enterprise Security View

  • Is concerned with the security aspects of the system.

Software Engineering View

  • Is concerned with the development of new software systems.
  • Distribution Transparencies:
  • Access Transparency
  • Failure Transparency
  • Location Transparency
  • Migration Transparency
  • Relocation Transparency
  • Replication Transparency
  • Transaction Transparency

System Engineering View

  • Is concerned with assembling software and hardware components into a working system.
  • Computing Models:
  • Client/Server Model
  • Master/Slave and Hierarchic Models
  • Peer-to-Peer Model
  • Distributed Object Management Model

Communications Engineering View

  • Is concerned with structuring communications and networking elements to simplify network planning and design.

Data Flow View

  • Is concerned with storage, retrieval, processing, archiving and security of data.
  • Database Models:
  • Relational Model
  • Hierarchy Model
  • Network Model
  • Object-Oriented Model
  • Flat Files

Enterprise Manageability View

  • Is concerned with operations, administration and management of the system.

Acquirer View

  • Is concerned with acquiring Commercial Off-The-Shelf (COTS) software and hardware.

Architecture Deliverables

Architecture Building Blocks

  • Architecture documentation and models from the enterprise’s Architecture Repository.

Architecture Contract

  • Are the joint agreements between development partners and sponsors on the deliverables, quality and fitness-for-purpose of an architecture.

Architecture Definition Document

  • Is the deliverable container for the core Architectural Artifacts created during the project and for important related information.

Architecture Principles

  • Are general rules and guidelines that inform and support the way in which an organization sets about fulfilling its mission.

Architecture Repository

  • Acts as a holding area for all architecture-related projects within the enterprise.

Architecture Requirements Specification

  • Provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.

Architecture Roadmap

  • List individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture.

Architecture Vision

  • Is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.

Business Principles, Business Goals and Business Drivers

  • Provide context for architecture work by describing the needs and ways of working employed by the enterprise.

Capability Assessment

  • To understand the baseline and target capability level of the enterprise.

Change Request

  • In order to kick-start a further cycle of architecture work.

Communications Plan

  • Effective communication of targeted information to the right stakeholders at the right time is a critical success factor for enterprise architecture.

Compliance Assessment

  • To govern the architecture through implementation to ensure that the original Architecture is realized.

Implementation and Migration Plan

  • Provide a schedule of the projects that will realize the Target Architecture.

Implementation Governance Model

  • Ensure that a project transitioning into implementation also smoothly transitions into appropriate architecture governance.

Organizational Model for Enterprise Architecture

  • Define organization, roles and responsibilities within the enterprise.

Request for Architecture Work

  • This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle.

Requirements Impact Assessment

  • Assesses the current architecture requirements and specifications to identify changes that should be made and the implications of those changes.

Solution Building Blocks

  • Implementation-specific building blocks from the enterprise’s Architecture Repository.

Statement of Architecture Work

  • Defines the scope and approach that will be used to complete and architecture development cycle.

Tailored Architecture Framework

  • Tailoring will select appropriate deliverables and artifacts to meet project and stakeholder needs to fit the enterprise.

Building Blocks

Generic Characteristics

  • A building block is a package of functionality defined to meet the business needs across an organization.
  • A building block has a type that corresponds to the TOGAF Content Metamodel.
  • A building block has a defined boundary and is generally recognizable as “a thing” by domain experts.
  • A building block may interoperate with other, inter-dependent, building blocks.

Architecture Building Blocks

  • Capture architecture requirements (business, data, application and technology)
  • Direct and guide the development of SBBs

Solution Building Blocks

  • Define what products and components will implement the functionality
  • Define the implementation
  • Fulfil business requirements
  • Are product or vendor-aware

Classes of Building Blocks

  • Re-usable building blocks, such as legacy items.
  • Building blocks to be the subject of development, such as new applications.
  • Building blocks to be the subject of purchase, Commercial Off-The-Shelf (COTS)

Originally published at on March 21, 2016.

Like what you read? Give Cecil a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.