TOGAF Series #29 | ATL002:29

The Fundamental Factors in EA

a Meta Framework
by Roger Evernden

Several times in this blog Ive talked about

TOGAF being more a body of knowledge than
a framework; and Ive also said that TOGAF
isnt just one framework, but that it is really a
framework of frameworks.
Certainly the concept of an architecture
framework can be confusing because EA
practitioners often use the term carelessly.
TOGAF, for example, defines an architecture
framework quite simply as a conceptual structure
used to develop, implement, and sustain an
architecture (Definitions 3.13). But the TOGAF
documentation is more a body of knowledge
describing some of core practices in Enterprise
Architecture. And while TOGAF includes several
more detailed and specific frameworks - such
as the Capability Framework, Skills Framework,
Content Framework, and even the ADM the
overall framework in TOGAF is designed to
show the structure of the TOGAF documentation
as much as develop, implement and sustain an
architecture (this is the diagram shown as Figure
1-1 in the TOGAF documentation).

So what can we do about this? What is the true

role of an architecture framework? And what
can we do to create really practical and useful
architecture frameworks?
The true role of an architecture framework
is very simple and we can refer back to the
TOGAF definition: a conceptual structure used to
develop, implement, and sustain an architecture
(Definitions 3.13). Usually a framework is shown
as a diagram, and the most common architecture
frameworks are represented as tables or
matrices. A popular example is the Zachman
Framework, which is depicted as a 6 x 6 matrix.
But things are not quite that simple! Enterprise
Architecture is a complex discipline: it covers
a wide range of diverse domains, it deals with
large numbers of stakeholders with different
needs and viewpoints, it deals with complex
architectural landscapes, it spans short-term
change and long-term transformation, and
it handles many simultaneous and parallel
initiatives! Because of all this, EA is multidimensional.
Now the problem with a simple, conceptual
structure like a matrix or table is that it cant cope
with more than three dimensions at a time. Even
that is stretching the capacity of a matrix. So a
framework depicted as a matrix or table is
good at handling one, or two dimensions of EA,
but after that it struggles.
So looking at TOGAF, we can now see why it is a
framework of frameworks, rather than a single
framework. Each of its individual frameworks
meets a specific purpose content, capability,
development. And those individual frameworks
are easy to understand because they only cover
one or two of the dimensions in EA.

Figure 1: The Structure of the TOGAF Documentation

Copyright 2015 Good e-Learning. 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: [email protected]. Good e-Learning is a trading name used by
Educational Systems Ltd. The Open Group and TOGAF are registered trademarks of the Open Group in the United States and other countries

Now we are getting somewhere. A framework is

really useful and practical when it focuses on just
one or two dimensions. For example, we might
have a framework that shows the Phases of the
ADM on one axis, and the key deliverables on
the other axis; and now the intersection of the
two can show us which deliverables are input or
output from each Phase. This might help us to
keep track of what we produce during an iteration
of the ADM. Useful. Practical.
If we tried to also add information about another
130 separate projects, and tried to show their
evolution over the next five years, together with
the responsibilities of everyone involved in each
project, and details of the various viewpoints
and views we were producing, and all of the
artifacts that we produced, and their versions,
and whether they were compliant or not.... If we
tried to add too much information to our simple,
practical framework, then it would become
overwhelming, confusing and useless.
TOGAF as a framework of frameworks is more
a body of knowledge than a practical tool that you
would use in your day-to-day architectural work
- which is one reason why the documentation
emphasizes that you must customize it before
you use it. In other words, you need to take from
the TOGAF body of knowledge, and create a set
of frameworks that are tailored and adapted to
meet your specific needs.
The only snag is that TOGAF doesnt really explain
how you go about creating or using architecture
frameworks. Which is ironic considering that it
describes itself as an architecture framework.
What can we do to create really practical and
useful architecture frameworks? Here is a simple
overview of the key steps:
1. Start by examining the fundamental factors
in EA to see which ones are relevant to your
needs. My research shows that there are
eight fundamental factors that are used
in every architecture framework, including
TOGAF. These eight factors provide a meta
framework a framework for creating and
using frameworks. For example, you might
decide that the architecture development
process, the architecture domains and subdomains, and the metamodel are central to
your needs.

2. Then you need to decide which particular

elements are required for each of these
factors. For example, TOGAF describes
four high-level domains (business, data,
application and technology); you might need
all four of these domains, or you might need
to focus on business and data. Then you
might need to decide which sub-domains you
needed; for example, in business you might
need to cover processes, events, products
and business rules.
3. Now think about how you are going to use
each of the eight fundamental factors. You
might need to use the ADM Phases and
Steps to manage the development process,
and the domains, sub-domains and detailed
constructs in the metamodel to identify
the information you need to gather at each
stage in the process. A good framework
might therefore matrix Process and Domain/
Content so that you get a good overview of
this and can manage the work effectively.
4. Once you have created the relevant
frameworks using the previous three
steps use them to help you think about
the architecture, or to help manage the
architecture. Nearly every framework can be
RAG rated or can include metrics to show
how well things are going.
Obviously this is a simplified take on architecture
frameworks. The key takeaways are that
architecture frameworks are one of the most
useful tools available to architects; that TOGAF,
and every other pre-defined framework, needs
to be customized to your needs; and that the
starting point for creating a set of multiple,
integrated architecture frameworks are the eight
fundamental factors (or dimension) to EA.
If you have found this interesting, and wish to know more
about the eight fundamental factors, please check out
Enterprise Architecture the Eight Fundamental Factors
(2nd Edition, 2015), by Roger and Elaine Evernden.

Copyright 2015 Good e-Learning. 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: [email protected]. Good e-Learning is a trading name used by
Educational Systems Ltd. The Open Group and TOGAF are registered trademarks of the Open Group in the United States and other countries