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
The Enterprise Repository structure
The Architecture and Solutions Continua
Chopping up the architecture landscape
How many architecture dimensions are there?
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
·
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 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, 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 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!
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).”
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 |
TOGAF suggests various ways to chop up the architecture landscape
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 |
|
|||
Level and
Timeframe |
Architecture
Domain |
|
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:
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