White Paper
Why TOGAF is Now the De Facto
Enterprise Architecture Framework
WP0009 | August 2011
When I started my formal architecture career in the early 2000’s
I was asked by the CTO of a previous employer of mine to
investigate a series of architecture frameworks and to select a
framework that we could use in our organization to help with the
maturity of our architecture projects and also the formalisation
of our architecture function. After three months of work sessions
with vendors (at that time every consulting house had a propriety
Architecture framework) we adopted TOGAF. I must admit that it
was not ‘love at first sight’ when I first tried to read through the
TOGAF version 8 document. However, when I now think back to
the process, and all the mistakes we made in getting started, the
best choice we made was the selection of the TOGAF framework
Louw Labuschagne CBPA® as the basis for our architecture practice.
Louw is a Managing Partner at CS
I can honestly say we did not select it based on the completeness or
Interactive Training, a specialist IT
consultancy focused on providing
superiority of the framework, there were other propriety frameworks that
methodology consulting, training were more advanced and more complete with betterguidance, but none
and systems to organizations who of them had the crucial element that we wanted, a community. That
need to build internal capacity within single fact, an active community or eco-system, has since made TOGAF
their Analysis, Architecture, Design, the undisputed industry standard used by architecture practitioners as
and Requirements Management
highlighted by the survey results below that was conducted in 2009, a
environments. Louw is passionate about
few months after TOGAF 9 was released.
all aspects of information management
and has had the opportunity to act as
strategist, architect, speaker, trainer,
analyst, modeler and developer within
this field over the past 20 years.
Access our free, extensive library at
www.orbussoftware.com/community
Figure 1: Survey results released 2009 at Open Group Toronto EAPC
https://opengroup.org/tech/arch_newsletter/nl_aug09.pdf
I will justify my claim that TOGAF is the industry standard by first
highlighting the size and diversity of the community that created TOGAF
and which continues to support and grow the standard. Secondly I will
use ISO 15704 (Requirements for enterprise-reference architectures
and methodologies) as a generalised framework for describing the
components needed by an enterprise architecture framework.
The active TOGAF Eco-system
My claim that TOGAF is a truly global standard is based on the following
three factors:
1. The diversity of the global Open Group membership that
participates in the development of the TOGAF standard
2. The localisation of TOGAF is making the standard available to a
significant community of non-English speaking architects around
the globe
3. The growth in the certification of architects on the TOGAF
standard
Diverse global participation in TOGAF
development
The TOGAF standard is a product of The Open Group, a global
consortium with more than 350 members. This diverse membership
consists of client organizations (including multi-national organizations,
SME’s, public sector organizations) and suppliers of products and
services that span all sectors of the economy.
2 © Orbus Software 2011
All these member organizations participate in conferences and
workgroups co-ordinated by The Open Group and participants involved
in developing and evolving TOGAF come from a variety of backgrounds,
including; customer organizations, government, systems and solutions
suppliers, tool vendors, integrators and consultants, as well as
academics and researchers.
The geographical distribution of the Open Group offices in a number
of key countries across the globe makes it practical for architecture
professionals to participate in the development of TOGAF and also
ensures that TOGAF is truly a global standard.
TIP: Participate in improving the quality of TOGAF by becoming a member
of the Open Group, either directly or through a partner in your country.
Open Group Offices http://www.opengroup.org/
United Kingdom (Reading, Berkshire, UK Office)
United States – West (San Francisco, CA, USA Office)
United States – East (Boston, MA, USA Office)
Brazil (São Paulo, Brazil Office)
Open Group Partner Offices
Arabia http://www.opengroup.org/arabia/
China http://www.opengroup.org.cn/
France http://www.architecture-forum.org/
India http://www.opengroup.org/india/
Japan http://www.opengroup.or.jp/
South Africa http://www.realirm.com/tog/open-group
Sweden http://www.opengroup.org/sweden/
TOGAF Localisation
The Open Group members are also very active in translating TOGAF
into different languages to enable global participation. The work includes
the translation of glossaries, pocket guides, the TOGAF 9 book, and
examinations into different languages.
The availability of the TOGAF 9 book in Chinese and Japanese is creating a
common architecture language between worlds that were previously were
very difficult to bridge. Also the availability of the TOGAF 9 Pocket Guide
in French, Dutch, German, Japanese, and Chinese just makes it easier for
non-architects to get access to TOGAF methods and techniques.
3 © Orbus Software 2011
The localisation teams in the Open Group (remember that all activities in
the Open Group are member driven, so this means that there are non-
English speaking architecture demand for the translations) are busy with
initiatives to further translate TOGAF into Portuguese and Spanish (with
variations for Portuguese and Brazilian Portuguese, Catalan Spanish and
Latin-American Spanish).
Certified Individuals
As of 31 July 2011, the number of Architects that have been TOGAF
certified has reached more than 16000 individuals globally.
(See Table below)
TOGAF 9 Certified 5672 Registered Individuals
TOGAF 9 Foundation 2396 Registered Individuals
TOGAF 8 Certified 8211 Registered Individuals + 57 confidential
Table 1: Summary of Register of Certified TOGAF Architects as on 31 July 2011
The TOGAF 9 certification is currently one of the most recognised
certifications within the Enterprise Architecture discipline and the
availability of certification exams in multiple languages is also growing the
adoption of TOGAF by non-English speaking architects.
Lastly, the acceptance of TOGAF as a standard can be confirmed when
searching through recruitment agency listings for architecture positions.
Most of the agencies indicate TOGAF certification as a pre-requisite for
job applicants.
Requirements of a good Architecture
Framework
Is TOGAF 9 a good architecture framework? Is it good enough to support
the diverse group of organizations that need architectural support?
If you ask this question to The Open Group, the answer will be yes, of
course. So I did not even bother to ask the question, as I wanted an
honest and independent answer. I did ask consulting firms for advice,
but found that they would say yes or no, but would always want to
encourage me to adopt their framework or enhance TOGAF with their
special secret source (and at a ridiculous price of course!).
The result was that I conducted my own research and experiments (I
will give more detail about this in a later white paper for those who are
interested) and decided to use the Generalized Enterprise Reference
Architecture and Methodology (GERAM) as a benchmark. GERAM is an
annex to ISO 15704 Requirements for enterprise-reference architectures
and methodologies and describes the methods, models and tools which
are needed to build and maintain an integrated enterprise.
4 © Orbus Software 2011
The conceptual model in Figure 2 below, highlight the main components
defined in the Generalized Enterprise Reference Architecture and
Methodology (GERAM) overlaid with the TOGAF 9 Components. In
the following sections each of the components defined by GERAM are
discussed together with a brief overview on how TOGAF 9 supports that
component. Where TOGAF 9 components do not support a GERAM
requirement, an alternative, TOGAF 9 solution is discussed instead.
Figure 2: GERAM Conceptual Model – adapted from GERAM
(http://www.ict.griffith.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html#_Toc447291705)
All definitions used below were extracted from the GERAM standard that
is available here: http://www.ict.griffith.edu.au/~bernus/taskforce/geram/
versions/geram1-6-3/v1.6.3.html#_Toc447291705
Generic Enterprise Reference
Architecture (GERA)
The Generic Enterprise Reference Architecture component defines the
enterprise related generic concepts recommended for use in enterprise
architecture / engineering and integration projects. These concepts are
categorized as; Human Oriented, Process Oriented and Technology
Oriented concepts. The complexity of representing these concepts in a
single model is overcome by the use of views where only certain aspects of
the enterprise model is visualized, depending on the perspective required.
TOGAF 9 uses a viewpoint library to hide complexity from stakeholders
when creating integrated enterprise models. The views defined in TOGAF 9
are based on an integrated meta-model and the change to a single model
or view is reflected throughout the integrated model.
5 © Orbus Software 2011
Enterprise
Engineering
Methodology
(EEMs)
EEMs describe the processes
that must be followed when
performing the enterprise
engineering or enterprise
architecture activity. According to
GERAM an enterprise engineering
methodology may be expressed
in the form of a process model or
structured procedure with detailed
instructions for each enterprise Figure 3: TOGAF ADM
engineering and integration activity.
The TOGAF 9 Architecture Development Method is the core of the
TOGAF standard and detailed process steps are described and
explained in the standard.
Enterprise Modeling Languages (EMLs)
EMLs define the generic modeling constructs for enterprise modeling
adapted to the needs of architects who are creating and stakeholders
who are using enterprise models.
In particular enterprise modeling languages will provide constructs to
describe all the concepts defined within the Generic Enterprise Reference
Architecture, including Human, Process and Technology concepts.
TOGAF do provide a meta-model for use in defining these concepts, but
are modeling notation agnostic.
Alternative compatible Solution: The Open Group ArchiMate Forum
developed and is maintaining an Enterprise Modeling Language that
adheres to the requirements of this component. The Architecture Forum
and ArchiMate forum are working closely together to ensure that the
ArchiMate language is tightly aligned and integrated into the TOGAF 9
Architecture Development Method, allowing seamless integration for
architects using these standards together.
6 © Orbus Software 2011
Figure 4: A diagram drawn according to the ArchiMate notation, which is increasingly aligned with TOGAF
Enterprise Engineering Tools (EETs)
EETs support the processes of enterprise engineering and integration
by implementing an enterprise engineering methodology and supporting
modeling languages. Engineering tools should provide for analysis,
design and use of enterprise models
TOGAF is an architecture framework and not a physical product;
however there are architecture tool vendors that do support the TOGAF
9 implementation natively in their products. (See my white paper on the
Top 10 factors to consider when selecting a TOGAF 9 Repository)
Generic Enterprise Modeling Concepts
(GEMCs)
GEMCs define and formalize the most generic concepts of enterprise
modeling. Generic Enterprise modeling concepts may be defined in
various ways. In increasing order of formality generic enterprise modeling
concepts may be defined as:
• Glossaries
• Meta-models
• Semantic-meanings (typically, built inside the engineering tools).
The TOGAF 9 meta-model is available to use to when defining views and
to assist with the definition of domain specific modeling languages. The
best approach is to ensure that the meta-model is implemented in an
architecture repository.
Tip: If you are using the Zachman Framework, this is where to place it in
the GERAM conceptual map
7 © Orbus Software 2011
Figure 5: The TOGAF 9 Meta-model defines different EA views
Partial Enterprise Models (PEMs)
PEMs capture characteristics common to many enterprises within or
across one or more industry or sector. Thus these models capitalize on
previous knowledge by allowing model libraries to be developed and
reused in a ‘plug-and-play’ manner rather than developing the models
from scratch. Partial Enterprise Models make the modeling process more
efficient.
The Enterprise Continuum and more specifically the Architecture
Continuum is used within TOGAF to classify Partial Enterprise Models
that are made available for re-use. These models reside in the
architecture repository within the reference architecture area.
Figure 6: A process modelled in accordance with ITIL, an example of a PEM
8 © Orbus Software 2011
Enterprise Modules (EMOs)
Enterprise Modules are implemented building blocks or systems
(products, or families of products), that can be utilised as common
resources in enterprise engineering and enterprise integration
The Enterprise Continuum, and more specifically the Solutions
Continuum is used within TOGAF to classify Enterprise Modules that are
made available for re-use. These models reside in the Definitive Software
Library and are linked to the repository by using a reference.
Particular Enterprise Models (EMs)
EMs represents the particular enterprise. Enterprise models can be
expressed using enterprise modeling languages. EMs includes various
designs, models prepared for analysis, executable models to support
the operation of the enterprise, etc. They may consist of several models
describing various aspects (or views) of the enterprise.
The TOGAF 9 Content Framework describes the deliverables produced
when applying the Architecture Development Method. The Architecture
Requirements Specification and Architecture Definition Document are two
examples of how the architecture models and views are packaged for use
by the implementation teams to construct the actual product or service,
based on the architecture defined during the previous processes.
Figure 7: A Physical Application Landscape or ‘view’
9 © Orbus Software 2011
Conclusion
In conclusion, I believe that TOGAF is the de facto Enterprise Architecture
standard because:
1. T
he Architecture framework market share is more than 50%, with no
real competing framework even close to that level of penetration.
2. N
o single organization is dictating the direction that TOFAF must take,
The Open Group consortium is member driven (350+ organizations)
and the membership working on TOGAF is collaborative and inclusive.
3. T
OGAF is accessible by non-English speaking architects through
translations that is setting TOGAF apart from any other EA framework
and linked to local offices across the world, an integrated Architecture
Community is being nurtured.
4. 1
6000+ Architects are TOGAF certified and are using or adapting the
standard for use in their organizations.
5. T
OGAF is freely available to members and non-members, royalty free,
to use to build their own architectures.
© Copyright 2011 Orbus Software. All rights reserved.
No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means,
electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner.
Such requests for permission or any other comments relating to the material contained in this document may be submitted
to: marketing@orbussoftware.com
Orbus Software
3rd Floor
111 Buckingham Palace Road
London +44 (0) 870 991 1851
SW1W 0SR enquiries@orbussoftware.com
United Kingdom www.orbussoftware.com
