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)

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)

Deliverables

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.

Artifacts

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.

The core of the Architecture Development Method – ADM

The diagram below displays the core of the TOGAF Architecture Development Method otherwise known as the TOGAF ADM. The TOGAF ADM provides a step by step approach to Enterprise Architecture

TOGAF Architecture Development Method

It is important to understand that TOGAF consists of six different components – The six components are:

  1. The TOGAF ADM (As shown above)
  2. An Architecture Content Framework – This framework is used to model the work products that will form the architecture. The Architecture Content Framework contains artifacts, deliverables and the building blocks (Otherwise known as Architecture Building Blocks or ABBs) that the deliverables will represent.
  3. Techniques and guidelines that are able to be used by an organisation when following the Architecture Development Method process.
  4. The Architecture Capability Framework that can be used to define roles, skills, responsibilities and other reference and guideline materials needed to create and operate an Enterprise Architecture within an organisation
  5. The Enterprise Continuum – A model that provides a way for an organisation to structure an Architecture Repository. The Enterprise Continuum also provides a way for classifying solution and architecture artifacts.
  6. The TOGAF library – The TOGAF library is a supporting reference library that contains templates, guidelines and other reference material to help expedite the creation of Enterprise Architectures.

The four Architecture Domains within Enterprise Architecture

The are four Architecture Domains that form Enterprise Architecture

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

It is suggested by TOGAF that a complete Enterprise Architecture should address all of the four architecture domains specified above. Each of the Enterprise Architecture domains are detailed below.

Business Architecture
Think of Business Architecture as a way of defining the business organisation, the business strategy and the key processes that form the business

Application Architecture
Application Architecture is a way to develop a template or blueprint for the deployment of the systems within the Application. Application Architecture also describes the relationships between the business processes and how they interact.

Data Architecture
Data Architecture details the definition and structure of an organisations physical and logical assets as well as the data management resources and assets

Technology Architecture
Technology Architecture provides a method to describe the software and hardware necessary to support the release of the organisations main applications

How can Enterprise Architecture benefit businesses?

There are many ways that Enterprise Architecture can benefit organisations – some of these are:

  • Helping a business or organisation achieve its business strategy
  • Allow new capabilities or innovations to get to market faster
  • A more consistent and streamlined business process with better information across organisational units
  • Better security and reliability
  • Less risk
  • Streamlining IT and business operations
  • Reduced risk in terms of future investment and a better return for existing investments
  • Easier and more streamlined procurement at reduced cost

Describe an Architecture

In its simplest form, think of an Architecture in terms of TOGAF as the central properties or concepts in a system; specifically:

  • The individual elements that form the system
  • The fundamental principles that govern the systems evolution and design
  • How the elements in the system relate to each other

Describe an Enterprise

Think of an Enterprise in the terms of Architecture as a set of business or organisations that share a set of common goals. Examples of an Enterprise may be:

  • A large multinational company that spans multiple countries
  • A single company or corporation
  • A subset or part of a company or corporation

It is important to understand that a large company or corporation may consist of multiple enterprises. An enterprise may even extend out to other businesses such as a companies customers, suppliers and any other business partners.

Essentially, an Enterprise in terms of Architecture can be summarised as a set of entities that are working together to reach a common goal.

What does “Architecture” mean?

People often ask, what is the meaning of “Architecture” when talking about the TOGAF standard?

Whilst TOGAF does embrace the IEEE Standard 1471 it does not strictly adhere to it.

Briefly, the term Architecture in the context of TOGAF has two different meanings and these two meanings are different depending on the context. In terms of TOGAF Architecture can be defined as:

  • A plan or formal description detailing a system broken down into components to help guide the implementation – Or
  • The structure and relationships between components as well as the principles and guidelines that govern the evolution and design of a system over a period of time