The four dimensions of scope

There are four main dimensions that are typically used to limit and define the scope of an Architecture.

  1. Breadth
  2. Depth
  3. Time Period
  4. Architecture Domains


Determine the extent of the enterprise or organisation and how much of that extent should the architecture effort focus on. It is important to understand that many organisations are large and are comprised of separate business units. These separate business units can be thought of as enterprises in their own right. Modern businesses further blur this distinction as many businesses embrace a combination of traditional business enterprise as well as partners, customers and suppliers.


Depth describes to what level of detail an architect should go to when creating an architecture. The challenge here is deciding on how much architecture is enough and when to stop and the delineation between other related activities or systems.

Time Period

Specifies the time period for the initial phase – Architectural Vision and is the specified amount of time realistic based on resources available.

Architecture Domains

Typically when creating an Architecture Description the description should contain information pertaining to all four domains:

  1. Business
  2. Data
  3. Application
  4. Technology

Sometimes, due to constraints such as time and resources there often not enough resources available to create an all inclusive architecture description that covers all four domains.

Typically when creating the scope of an Architecture the scope is expressed in:

  • Breadth
  • Depth
  • Time

Once the scope of the organisation is understood then a suitable combination of architectural domains is selected based on the problem being addressed.

The Architecture Capability Framework

The Architecture Capability Framework is used to examine and discuss the roles, skills, processes and responsibilities that are needed to operate and create an Architecture function inside an Enterprise. In addition the Architecture Capability Framework also provides assets and resources that are required when creating an Enterprise Architecture Capability.

According to TOGAF the recommended capabilities are:

  • Supplier Management
  • Risk Management
  • Configuration Management
  • Resource Management
  • Financial Management
  • Service Management
  • Quality Management
  • Performance Management
  • Stakeholder Management
  • Communications Management
  • Environmental Management

The Architecture Repository

The Architecture Repository is a model used for storing the different types of output produced by the architecture and is conceptually linked to the Enterprise Continuum. The Architecture Repository consists of the following main components:

  • Architecture Meta-model
  • Architecture Landscape
  • Reference Library
  • Standards Information Base (SIB)
  • Governance Log
  • Architecture Capability

Architecture Meta-model
The Architecture Meta-model is used to describe the content meta-model in the form of a architecture method that is specific to the organisation

Architecture Landscape
The Architecture Landscape provides an architectural depiction of the assets being planned or that are currently in use by the architecture at specific points in time (e.g. Past, Present and Future)

Reference Library
The Reference Library contains any architecture work products that are able to be re-used

Standards Information Base (SIB)
The Standards Information Base (SIB) is a directory or database of standards which are able to be used to define a set of specific services and components for the specific architecture of an organisation

Governance Log
The Governance Log is use to capture the result of any activity produced by the governance (e.g. Compliance assessment)

Artifacts, Deliverables and Building Blocks

What is the difference between Artifacts, Deliverables and Building blocks?

An Artifact is a smaller work product that is used to describe an architecture via a specific viewpoint (E.g. A matrix or diagram).

Think of a Deliverable as a product of work that can be reviewed and then signed off on by a stakeholder or stakeholders.

A Building Block is used to represent the capability of a component of IT, business / organisation or architecture capability. It is therefore possible that a Artifact can contain multiple Building Blocks and a Deliverable can contain multiple Artifacts.

The Enterprise Continuum

The Enterprise Continuum as related to TOGAF is used to describe how generic solutions can be specalised and leveraged in order to support the individual requirements of an organisation. Specifically the Enterprise Continuum sets the broader context for an architect.

Think of the Enterprise Continuum as a virtual repository of all the assets that make up the architecture; for example:

  • Patterns
  • Architecture descriptions
  • Models

The Enterprise Continuum is also able to aid communication as it provides a consistent language with which to categorise and classify artifacts.

The Enterprise Continuum consists of two core concepts:

  1. Solutions Continuum
  2. Architecture Continuum

Solutions Continuum
The Solutions Continuum provides a way to consistently understand and describe the implementation of the assets which are defined within the Architecture Continuum. The Solutions Continuum also defines the Solution Building Blocks (SBBs) that are able to be reused within the organisational environment.

Architecture Continuum
The Architecture Continuum provides a way to consistently understand and refine the generic representations, rules and relationships within the Architecture. This representation includes the derivation and trace-ability relationships.

The Architecture Content Framework

The TOGAF Architecture Framework is comprised of the following main components

  • Building Blocks
  • Artifacts
  • Deliverables
  • An Architecture Repository

Before detailing the main components in the TOGAF Architecture Content Framework lets understand why an Enterprise would want to leverage the Content Framework.

Leveraging the TOGAF Content Framework provides the following benefits:

  • Detailed meta model
  • A detailed open standard for how architectures should be described
  • Comprehensive checklist of the architecture outputs
  • Greater consistency in terms of the outputs of the ADM
  • Promotes better integration of work products

The TOGAF Architecture Content Framework provides a specific and detailed model of work products that form the architecture. These models include:

  • Deliverables (Including the artifacts that fall within the deliverables)
  • The building blocks that form the architecture (Otherwise known as ABBs)


In terms of the TOGAF ADM a deliverable is defined as a formal work product(s) or a specified output(s) where the output is based on a specified contract. It is important to understand that a deliverable many contain one or more artifacts.

Further, a deliverable or work product is based on a contract and because of this will be formally agreed upon, reviewed and then signed off by the relevant stakeholders within the enterprise.

At the completion of a project any deliverables that form any type of documentation will be archived and may be placed into the Architecture Repository for future use as a standard, reference model or architecture snapshot at a set point in time.


TOGAF describes an artifact as a much smaller work product that is used to describe an architecture from as set view point.

An artifact falls into one of three categories:

  1. Lists or catalogs – (A list of things)
  2. Diagrams – Images of things
  3. Matrices – Relationships between things

As an example, an artifact may include items such as:

  • Network diagram
  • A use case specification
  • Server specification
  • A set of requirements for the architecture
  • A business interaction matrix

An architectural deliverable is able to contain more than a single artifact and these artifacts will be the content of the Architecture Repository.

Building Blocks

Simply put a building block is a component of Information Technology, Organisation (Business) or architectural capability that can be combined with other building blocks to deliver the Solutions or Architectures. It is worth noting that a building block may be able to be re-used.

There are two different types of building blocks:

  1. Solution Building Blocks otherwise known as SBBs
  2. Architecture Building Blocks otherwise known as ABBs

A Solution Building Block (SBB) is the implementation of the designs as specified by the Architecture Building Blocks.

An Architecture Building Block is the output of the design.

Architecture Repository

The Architecture Repository is a model which is used for storing the different Architectural output types as produced by the ADM.

Techniques and Guidelines

TOGAF provides a set of techniques and guidelines that will assist the architect when following the Architecture Design Method (ADM)

Techniques are a way to provide support for tasks that fall inside the ADM; for example, risk management, gap analysis, planning for migration

Guidelines provide a way to adapt the ADM when dealing with a variety of differing scenarios which may include various process styles and also set requirements