TOGAF Enterprise Continuum and Repository

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.co.uk in whichever social media you use.

 

TOGAF is the most popular public domain enterprise architecture framework.

Since it is voluminous, multi-authored and not an easy read; the Avancier web site hosts papers to help you understand it.

Beware that most TOGAF authors take it for granted you know architecture description techniques already.

TOGAF is a specific transformation management framework

If you want to understand enterprise architecture in general and specific architecting practices, then go to avancier.website.

 

Abstract

The Enterprise Continuum is a device for classifying the architecture description contents in an architecture repository

This paper presents some notes relating to these topics in the fifth part of TOGAF.

Contents

The Architecture Content Framework structure. 1

The Enterprise Repository structure. 1

The Enterprise Continuum.. 2

The Architecture and Solutions Continua. 4

The Architecture Repository. 5

Chopping up the architecture landscape. 5

How many architecture dimensions are there?. 7

 

The Architecture Content Framework structure

TOGAF encourages enterprise architects to document and maintain every architectural asset they use and produce.

 

The architecture content framework defines content/products/documentation that architects may produce. It defines:

·        c20 Deliverables (think word processor documents), which contain

·         c50 Artefacts (think tables and diagrams) which describe and relate

·         c30 Building blocks (think discrete architectural entities like business role, application and technology).

 

Architects are expected to store documentation in a repository - using the enterprise’s knowledge management systems, tools and file stores.

Architects are expected to structure and index the repository for ease of access - using structuring and indexing devices such as the enterprise continuum.

The Enterprise Repository structure

The enterprise repository is divided into three repositories; TOGAF is centred on the architecture repository.

ADM Phase

Enterprise repository

A

Requirements repository

B, C and D

Architecture repository

E, F and G

Solutions repository

 

The architecture repository is divided into six sections; TOGAF is centred on populating the architecture landscape.

Architecture repository

Section

Content

Methodology

Architecture meta model

Architecture method: tailored version of TOGAF’s ADM

Content meta model: the structure in which architecture entities are related

Architecture documentation

Architecture landscape

Descriptive artefacts

Reference models

Common structures and patterns

Standards

Open standards, local standards etc.

Organisation and work

Architecture capability

The architecture team, roles, skills, training etc.

Governance log

Record of compliance assessments due and made

 

The Enterprise Continuum

The enterprise continuum, sometimes described as a virtual repository, is nothing more or less than a classification scheme for system description artifacts.

It is a window onto the real repository that reveals only those assets in the repository that can be pigeon-holed into the Enterprise Continuum’s structure.

Each repository above corresponds to a level in the continuum.

 

Enterprise repository

ADM Phase

Enterprise Continuum level

The requirements repository

A

Context and requirements

The architecture repository

B, C and D

Architecture Continuum

The solutions repository

E, F and G

Solutions Continuum

 

The enterprise repository contains many architecture deliverables, artefacts and building blocks.

How to find an artefact or building block you are looking for? There are many ways to classify artefacts and building blocks.

Two-dimensional classification schemes like the ones below suggest some indexes for filing elements of documentation.

 

Indexes to TOGAF’s Enterprise Continuum

 

Indexes to the Zachman Framework

 

Avancier Methods – Architecture Work Space

Generalisation

Idealisation

Universal

Common

Shared

Unique

x

x  

Question

Idealisation

What

How

Where

Who

When

Why

x

Domain/view

Level

Business

Information

Data

Applications

Infrastructure

Platform

Contextual

 

 

 

 

 

Contextual

 

 

 

 

 

 

 

Enterprise 

 

 

 

 

Conceptual/logical

 

 

 

 

 

Conceptual/logical

 

 

 

 

 

 

 

Solution

 

 

 

 

Physical

 

 

 

 

 

Physical

 

 

 

 

 

 

 

Software 

 

 

 

 

Real

 

 

 

 

 

Real

 

 

 

 

 

 

 

Operations

 

 

 

 

 

The enterprise continuum is a device for classifying artefacts found in the Enterprise Repository. Think of it as a bookcase with four shelves.

The second shelf – the architecture continuum - contains logical specifications – services, processes and data entities.

The second and third shelves are divided into four pigeon holes representing a spectrum from generic or universal to specific or unique.

 

ADM Phase

Enterprise repository

Enterprise Continuum

Foundation

Common System

Industry

Organisation

A

Requirements repository

Context and requirements

 

 

 

 

B, C and D

Architecture repository

Architecture Continuum

e.g. JMS

Unix Spec.

e.g. Required

groupware features

e.g. Domain-specific

data and process models

e.g. Unique

data models and use cases

E, F and G

Solutions repository

Solutions Continuum

Web Logic, JBoss

HP-UX, AIX, Solaris, OS X

Groupware product

Domain-specific package

Bespoke applications

 

 

Deployed solutions

 

 

 

 

 

The Enterprise Continuum encourages you to identify and find artefacts that are reusable - because they are generic (to the left) and/or logical (to the top).

 

The Enterprise Continuum serves as a prompt to:

a)      abstract logical architecture description (in phases A,B,C,D) from physical solution description (in phases E,F,G)

b)     help you find (to the left) reusable generic standard services, components and patterns.

 

Thus, the Enterprise Continuum gives you a set of pigeon holes.

You can place in them descriptions of components, services, reference models, and any other reusable items.

In practice, this means attaching meta data to a descriptive artefact to say which class or category it is in.

 

Chapter 39.4 says

‘The Enterprise Continuum is intended to represent the classification of all assets that are available to an enterprise.’

 

TOGAF can be misread here, since some assets are large descriptive artefacts that span several categories.

A large descriptive artefact may contain generic and specific elements, logical and physical elements.

E.g. you might add many purpose-specific services to the generic core set in Unix or Linux.

Such a hybrid composite asset cannot be readily classified in one cell of the Enterprise Continuum.

However, you can make it pigeon-holeable by dividing it into smaller separately classifiable elements.

You can get into arguments about what is foundation or common, what is logical or physical.

But if you are determined to classify every asset in the Enterprise Continuum, then you can of course assign an artefact as you see fit.

The Architecture and Solutions Continua

The Architecture continuum contains descriptive artefacts that logical or vendor-neutral.

The Solutions continuum contains more detailed, vendor and technology-specific artefacts describing physical products that implement the logical specifications.

 

 

Foundation

Common System

Industry

Organisation

 

The infrastructure, the platform, on which systems are built.

Common features, patterns or structures for

building systems on top of the foundation

Business domain/vertical

(e.g. Retail, Banking, Telecoms)

Enterprise-specific

(e.g. Tesco,  HBOS, Orange)

Architecture continuum

Logical / external specifications.

E.g. Technical Reference Model (TRM)

Standards Information Base (SIB).

JMS

Unix Spec.

E.g. Required groupware features

Business intelligence functions

Application integration patterns such as the III-RM

Generic business function, data and process models.

E.g. Tele Management Forum reference models for the business processes, applications and data

Bespoke use cases and data models

Can also contain organisation-specific technology specs.

Solutions continuum

Universal platform products and systems that

implement platform services, such as an http server or operating system.

JMS: Web Logic, JBoss

Unix: HP-UX, AIX, Solaris, OS X

Solutions (built using foundation solutions) that

are common to most business domains. E.g. Email system, Security system.

Solutions common only across businesses in one business domain.

E.g. various COTS Packages

Solutions specific or bespoke to a single enterprise.

 

Q) Does the solution continuum contain real products?

A) No. It contains their specifications, not the things themselves.

The real things are recorded in the deployed solutions row below the Solutions Continuum.

 

Q) How does how abstraction by omission or composition appear in the Enterprise Continuum structure?

A) In several ways!

  • Fine-grained generic entities to the left may be reused as components in specific architectures/solutions to the right.
  • Coarse-grained generic structures to the left can be decomposed and elaborated into specific architectures to the right.
  • Logical descriptions in the architecture continuum may be elaborated with physical details in the solutions continuum.

The Architecture Repository

Remember the enterprise repository is divided into three repositories. TOGAF is centred on the architecture repository.

Remember the architecture repository is divided into six sections. TOGAF is centred on populating the architecture landscape.

 

The architecture repository

Section

Content

Methodology

Architecture meta model

Architecture method: e.g. TOGAF ADM

Content meta model: the structure in which architecture entities are related

Architecture documentation

Architecture landscape

Descriptive artefacts

Reference models

Common structures and patterns

Standards

Open standards, local standards etc.

Organisation and work

Architecture capability

The architecture team, roles, skills, training etc.

Governance log

Record of compliance assessments due and made

 

The Architecture Landscape contains the bulk of the architecture deliverables, artefacts and building blocks.

[It] is the architectural representation of assets deployed within the operating enterprise at a particular point in time.”

“[It] shows an architectural view of the building blocks that are in use within the organization today (e.g. a list of the live applications).”

Chopping up the architecture landscape

TOGAF views the enterprise as a system; a long-term goal is to describe the whole enterprise.

However, TOGAF chapter 5 questions the feasibility of a single enterprise-wide architecture for every business function and purpose:

 

“Current experience does seem to indicate that, in order to cope with the increasingly broad focus and ubiquity of architectures,

it is often necessary to have a number of different architectures existing across an enterprise, focused on particular timeframes, business functions, or business requirements.”

 

So, your aspiration may be to complete the architecture landscape for an entire enterprise in one fully integrated architecture repository.

But TOGAF does not assume you will be able to achieve this; you are allowed to maintain several distinct architectures.

 

Chapter 40 says:

“It is not possible to develop a single architecture that addresses all the needs of all stakeholders.”

“The enterprise must be partitioned into different areas, each of which can be supported by architectures.”

“In a typical enterprise, many architectures will be in existence at any point in time.”

“This chapter discusses the classification criteria that are generally applied to architectures or solutions and how these can be leveraged to partition the enterprise into a set of architectures.”

 

Chapter 40 talks about partitioning the repository (the view of the world, rather than the work) into subject matter, view points and time.

However, these are not additional dimensions, since they strongly correspond to the dimensions for dividing the work in ADM.

Scoping in chapter 20

Partitioning in chapter 40

Segments (or capabilities)

Subject matter

Architecture domains

View points

Architecture states

Time

 

View points certainly map to architecture domains.

Time certainly maps to architecture states.

However, division of the world by subject matter may or may not correspond to and division of the work by segment.

 

Figure 40-1 (Allocation of Teams to Architecture Scope) maps the EA organisation to levels of detail.

 

Teams

Level of Detail

Corporate EA

(strategy)

Segment EA

Portfolio

(programme)

Project

Enterprise

Corporate

Segment

 

 

Segment

Corporate

Segment

Portfolio

 

Capability

 

 

Portfolio

Project

 

Chapter 40 notes that

“Creation of a number of partitioned architectures within an enterprise runs the risk of producing a fragmented and disjointed collection of architectures that cannot be integrated to form overall big picture.”

 

So, Figure 40-2 (Architecture Content Aggregation) suggests the various architecture are indeed joined up into a complete architecture along one of more of the dimensions in a 4-dimensional cube.

Level of Detail

Domain

Time

Organisation scope

Strategic

Business

Baseline

Org unit 1

x Segments

Data

Transition 1

Org unit 2

x * y Capabilities

Applications

Transition 2

Org unit 3

 

Technologies

Target

Org unit 4

 

How many architecture dimensions are there?

TOGAF suggests various ways to chop up the architecture landscape

  • Index the content of an architecture repository (chapters 2, 39 and 40)
  • Divide the work addressed by a cycle of ADM (chapters 5, 19 and 20).

 

This table shows the five architecture dimensions discussed in these TOGAF chapters.

Five dimensions of architecture scope (which run at right angles to each other)

Architecture Development Method

Enterprise Continuum

Level and Timeframe

Architecture Domain

Architecture State

Ideal to Real

Generic to Specific

Strategic

Business

Baseline

Requirements

Foundation

x Segments

Data

Transition 1

Architecture BBs (conceptual/logical)

Common System

x * y Capabilities

Applications

Transition n

Solution BBs (physical)

Industry

 

Technologies

Target

Deployed Solutions (real)

Organisation-specific

 

TOGAF does not tell you to complete every section in each dimension of an enterprise architecture.

But suppose you try to do this for an enterprise with 9 capabilities, 3 segments, and 2 transition states in each migration plan.

And suppose you use all 5 dimensions to systematically index every item in the architecture repository.

Then you will end up with several thousand logical partitions.

That is a good thing, since you have to be able to find items in the repository, and manage small chunks of work.

 

Q) Is the end result easy to manage?

A) No.

 

Q) For example, where will we find a reference to the Customer Entity in our Architecture Repository?

A) The Customer Entity could potentially appear in:

  • Several Architectures at different levels of granularity and subject matter: Enterprise + Segments + Capabilities.
  • And for each of those, in 3 Architectures at different states in time: Baseline + Transition + Target.
  • And for each of those, perhaps 2 of the 4 Architectures for different architecture domains: Business + Data + Apps + Technology.
  • And for each of those, in 3 Architectures at different levels of abstraction by idealisation: Requirements & Context, Architecture, Solution
  • And for each of those, perhaps 2 of the 4 Architectures at different levels of abstraction by generalisation: Foundation, Common System, Industry, Organisation Specific.

 

That really does reflect the complexity of the problem space and documentation architects are trying to maintain!

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see  http://creativecommons.org