This page is published under the terms of the licence summarized in the footnote.
The paper introduces the terms, concepts, processes and
deliverables of TOGAF.
TOGAF is about enterprise architecture. You might use TOGAF for tactical solution architecture projects, but it is primarily for strategic enterprise architecture efforts. Notice how many times the word strategy is used in the quotes from TOGAF 8 below.
“The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy.
“This in turn makes IT a responsive asset for a successful modern business strategy.
“An enterprise architecture provides a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
“A good enterprise architecture:
· enables you to achieve the right balance between IT efficiency and business innovation,
· allows individual business units to innovate safely in their pursuit of competitive advantage,
· assures the needs of the organization for an integrated IT strategy,
· permits the closest possible synergy across the extended enterprise.”
TOGAF is focused on concerns that can be addressed by IT systems. TOGAF does embraces business analysis and business change, but it is primarily intended to improve IT operations, infrastructure and ownership, to improve software development, system and network management. The result should be more efficient IT operations, a better return on existing IT investment, and faster, simpler, and cheaper IT procurement. TOGAF says of defining business goals and business strategy “this may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A.”
TOGAF should help you improve:
TOGAF is comprehensive, well-known and makes a good common reference point. TOGAF contains much that is useful to the enterprise architect. It provides processes and deliverables to help you design, evaluate, and build the architecture for your enterprise. It is a structure for thinking and documentation, a guide, a friend. It contains contributions from many practitioners. Many use it as a touchstone because it is both “open” and widely read.
TOGAF has its limitations. It must work for all: public sector and private sector, manufacturing and services industries, enterprises and service providers. It is rather abstract and wordy. It is not entirely consistent in its level of abstraction. It is not a modelling language, a quality management system, or a substitute for architect skills. But think of it as a friend or partner: it does such a lot of good, helps you so much that, you can and will learn to live with any imperfections.
TOGAF is published on the Open Group web site. There are several reference books, but the web site is the one true version. See http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html. Of course, if you want to study or use TOGAF on the web site, you should respect the conditions of use. It is freely available for viewing online without a license. It may be downloaded and stored under license, as explained on the web site. It may be used freely by any organization wishing to do so to develop an architecture for use within that organization. If you use TOGAF, then we recommend you customise it using ideas and advice in our guides and associated training, especially if you want to use it for solution architecture.
This paper introduces the main features of TOGAF:
An architecture describes the structure and behavior of a system. TOGAF presents the architecture of an enterprise in four top-level views – or domains – called business, data, applications and technology. These domains can be represented as a hierarchically layered architecture in which the components in a lower layer provide services to the components in the layer above.
|
The architecture
domains as layers |
|
Business architecture |
|
Information systems architecture (data and applications) |
|
Technology architecture |
The core of TOGAF is the process called ADM. It is a step-by-step process for developing an enterprise architecture. People use ADM to record the benefits and constraints of the “baseline architecture”, develop a "target architecture" to meet requirements for change, and plan and govern the transformation from baseline to target.
This table shows the TOGAF Phases, including the preliminary Phase, and the parallel maintenance of requirements.
|
TOGAF Phases |
|
|
Architecture framework and principles |
|
|
Requirements Management |
A Architecture Vision |
|
B Business Architecture |
|
|
C Information System Architecture |
|
|
D Technology Architecture |
|
|
E Opportunities and Solutions |
|
|
F Migration Planning |
|
|
G Implementation Governance |
|
|
H Architecture Change Management |
|
We’ll come back to this process later.
This table shows the main inputs and outputs of ADM
|
Artifacts
and information sets in TOGAF |
|
|
Inputs |
|
|
Framework Definition |
Architecture Principles |
|
Re-usable Architecture Building Blocks |
Re-usable Solution Building Blocks |
|
Product Information |
New Technology Report |
|
Outputs |
|
|
Business Principles, Goals, and Drivers |
IT Governance Strategy |
|
Request for Architecture Work |
Statement of Architecture Work |
|
Architecture Vision |
|
|
Business Architecture |
Business Architecture Report |
|
Business Requirements |
Technical Requirements |
|
Data Architecture |
Data Architecture Report |
|
Applications Architecture |
Applications Architecture Report |
|
Technical Architecture |
Technical Architecture Report |
|
Architecture Viewpoints |
Architecture Views |
|
Gap analysis |
Impact Analysis - Project list |
|
Impact Analysis - Migration Plan |
Impact Analysis - Implementation recommendations |
|
Architecture Contracts |
Request for Architecture Change |
|
Requirements Impact Statement |
|
For more on ADM, read our paper TOGAF process framework at ref 1.
There is a misconception that TOGAF tells architects how but not what - provides processes but not deliverables. This common misconception is encouraged by those who want to continue using another deliverable framework and use TOGAF only for its process. In fact, TOGAF comes with wide set of architecture deliverables.
The primary (not only) deliverable framework is called the Enterprise Continuum. For more, read our paper TOGAF description framework at ref 1.
This section introduces concepts that are fundamental to any reading of TOGAF.
TOGAF very roughly follows the ANSI 1471 standard. (See ‘What’s wrong with 1471’ at ref. 1.) So TOGAF adopts the following standard definition of architecture as:
TOGAF defines the structure of a system in terms of components, but it uses the term building block rather than component. The general idea is that any system can be described as a composition of building blocks, each of which may be further decomposed into small building blocks. These building blocks are related in a structure or configuration. The three key building blocks in TOGAF are
TOGAF proposes that building blocks are defined at two levels - logical and physical:
Note that TOGAF authors use the term building block in two ways:
TOGAF defines the behavior of a system in the form of business scenarios. Scenarios are like use cases, or instances of use cases. A business scenario maps a business process to the actors, applications and technologies it involves. TOGAF uses business scenario in two phases: Phase A: Vision and Phase B: Business Architecture.
Q) Why doesn’t TOGAF include analysis and design techniques (other than Business Scenarios)?
A) TOGAF assumes its users know Information Engineering principles and techniques. E.g. Use of hierarchical structures and tables, cluster or affinity analysis, top-down decomposition of business functions, business-wide data model and local data models, and mapping of business functions to data.
A reference model is a generalized structure of building blocks of services that can be used as starter or template for more specific models. It can be a hierarchical structure, a data model, a process model, whatever.
TOGAF encourages architects to define and work with abstractions. To logicalise technology specifications to the point where then are vendor-neutral. To generalize applications specifications to the point they are platform-independent. To factor out common components for reuse. To use standard infrastructure services, so as to increase application portability.
Reference models are logical/generic/standard descriptions of business functions, data entities, processes and technical services that are common to, can be reused by, many enterprises.
There is a misconception that TOGAF tells architects how but not what - provides processes but not deliverables. This common misconception is encouraged by those who want to continue using another deliverable framework and use TOGAF only for its process. In fact, TOGAF comes with wide set of architecture deliverables.
This table shows the fundamental building blocks are business functions, applications and technologies.
|
This architecture domain |
is composed of building blocks |
that provide services to each other and to |
|
Business architecture |
Business functions |
Customers |
|
Information systems architecture |
Applications |
Business functions |
|
Technology architecture |
Technologies |
Applications |
TOGAF provides detailed templates for Applications and Technologies (see below), and suggests mapping Business Functions to Applications and to Data, using CRUD matrices.
There are templates for documents, ranging from a Request for Work to Gap Analysis Reports and Requirements Impact Statements.
And there is much more. There are at least 25 architecture description views and models, ranging from business goals to technology descriptions. There are two or three classification schemes for these architecture views and models.
TOGAF describes architecture views and models only lightly. It leaves room for interpretation regarding the level of granularity, the particulars and the style of documentation. But even though some document templates are light and some deliverables are not described clearly, it is possible to derive from them a meta model. See ref. 1 for a TOGAF meta model.
The lists below identify the key objects, models and views that make up the business architecture descriptions produced in Phase B of ADM.
Business Architecture models and views
See ref. 1 for a TOGAF meta model that draws from the above.
The lists below identify the key objects, models and views that make up the data architecture descriptions produced in Phases C of ADM.
Data architecture models
Data architecture views
See ref. 1 for a TOGAF meta model that draws from the above.
The lists below identify the key objects, models and views that make up the applications architecture descriptions produced in Phase C of ADM.
Application Artifact Template
Models (safe to assume here that System is a synonym for Application).
Applications architecture views
See ref. 1 for a TOGAF meta model that draws from the above.
The lists below identify the key objects, models and views that make up the technology architecture descriptions produced in Phase D of ADM.
Technology Artifact Template
Technology Architecture Views
See ref. 1 for a TOGAF meta model that draws from the above.
TOGAF provides various classification
frameworks for architecture views and models. In their place, we have drawn a
simple table that contains key TOGAF deliverables – the main architecture
models and views produced during phases A to D of ADM.
|
Business Architecture |
Data Architecture |
|
Organization structure -
identifying business locations and relating them to organizational units Business goals and objectives -
for the enterprise and each organizational unit Business functions - successive decomposition
of major functional areas into sub-functions Business services - the services
that the enterprise and each enterprise unit provides to its customers,
internal and external Business processes, including
measures and deliverables Business roles, including
development and modification of skills requirements Business data model Correlation of organization and
functions - relate business functions to organizational units in the form of
a matrix report |
Models
Views
|
|
Applications Architecture |
Technology Architecture |
|
Application Name (short and
long) Who maintains Owner(s)/business unit(s)
responsible for requirements Other users Plain language description of
what the application does (not how it does it) Status (planned, operational, obsolete)
Business functions supported Organizational units supported Hardware/software platform(s) on
which it runs Networks used Precedent and successor
applications |
Technology Name (short and long)
Physical location Owner(s) Other users Plain language description of
what the hardware/software platform is and what it is used for Business functions supported Organizational units supported Networks accessed Applications and data supported System inter-dependencies (for
example, fall-back configurations) |
|
Models
Views
|
Technology Architecture Model
|
TOGAF also includes some views that span two or more architecture domains. This section mentions two of them.
The Software Engineering View is about structuring software into flexible, location-independent components. Here, TOGAF suggests you define the use of:
The System Engineering View is about assembling software and hardware components into a working system. Here, TOGAF suggests you define the use of four models:
No comprehensive or perfect classification architectural styles and patterns has yet been devised. There is overlap and potential for confusion between logical software structures and physical platform structures. Also between design-time structure and run-time behavior. And it is difficult to address database transaction processing systems and web/network-based systems in one scheme. Having said that, see our guide to system/software engineering views for a wider classification that includes all the software/system architecture styles and patterns found in TOGAF.
See ref. 1 for a meta model that is based on analysis of the text describing TOGAF models and views. In Avancier training this meta model compared with others ArchiMate and with SAM (the EA method published by the NCC).
The IT industry continually finds new ways to mangle ordinary language. TOGAF is an amalgam of contributions from more than a hundred authors. It grows rather like an open source operating system, except that there are no test cases for contributions, and no regression test pack. Inevitably, different authors use some different words and write in different styles. The official TOGAF glossary is thin. You have to read TOGAF with a degree of caution about the wording and be relaxed about that.
Students on training courses usually find the following helpful.
Ref 1: other papers at http://avancier.co.uk
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