TOGAF ADM and Architecture Content Framework

The Architecture Content Framework (also known as the “TOGAF Content Framework”) is defined as

“The TOGAF content framework provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the architectural building blocks that artifacts represent. The intention of including a content framework within TOGAF is to drive greater consistency in the outputs that are created when following an Architecture Development Method (ADM)”.

TOGAF ADM and Content Framework

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, project compliance assessments, etc. 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 TOGAF 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 TOGAF. In these cases, the content framework provides a useful reference and starting point for TOGAF content to be mapped to other 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, agreed, 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 the 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, business interaction matrix, and a use-case 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.

TOGAF Content Metamodel

The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another. For example, when creating an architecture, an architect will identify applications, “data entities” held within applications, and technologies that implement those applications. These applications will, in turn, support particular groups of business users or actors, and will be used to fulfill “business services”.

The content metamodel identifies all of these concerns (i.e., application, data entity, technology, actor, and business service), shows the relationships that are possible between them (e.g., actors consume business services), and finally identifies artifacts that can be used to represent them.

Summary

• 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.