The Critical Scrutiny of TOGAF

Svyatoslav Kotusev ([email protected])

Introduction
In my previous article1 I reported that The Open Group Architecture Framework
(TOGAF)2, the most comprehensive and widely known enterprise architecture (EA)
framework, is largely of symbolic value and essentially has nothing to do with a successful
EA practice. Unsurprisingly, the article provoked numerous comments from its readers
ranging from full agreements to total disagreements and even direct insults. Therefore, I feel
obliged to clarify several critically important points regarding TOGAF and its relationship to
real EA practice. Observations in this article are my personal opinions based on an extensive
EA literature analysis as well as on my studies of more than two dozen Australian and
international companies with varying degrees of relationship to TOGAF. Two of these
companies are included in the official TOGAF list3, some of these companies claim to be
TOGAF-based, some of them simply used TOGAF as a source of knowledge on EA, while
others are largely indifferent to TOGAF.
Is TOGAF a Consistent Methodology or Just a Toolkit?
TOGAF community members currently position TOGAF as a useful toolkit for EA
practice where necessary tools can be found. I argue that TOGAF was originally designed as
a consistent methodology, but was subsequently repositioned to a toolkit since de facto it can
be useful at best as a toolkit. For example, its original documentation clearly states that
“[TOGAF] is a framework - a detailed method and a set of supporting tools - for developing
an enterprise architecture”2 (page 3). The TOGAF Architecture Development Method (ADM) is
“a step-by-step approach to develop and use an enterprise architecture”2 (page 21) that
“describes a method for developing and managing the lifecycle of an enterprise architecture”2
(page 45)
, “defines a recommended sequence for the various phases and steps involved in
developing an architecture”2 (page 56) and “forms the core of TOGAF”2 (page 45). The TOGAF
Architecture Content Framework (ACF) is “a detailed model of the outputs to be created by
the ADM”2 (page 37) that provides “a detailed open standard for how architectures should be
described”2 (page 34) and “a structural model for architectural content that allows the major
work products that an architect creates to be consistently defined, structured, and presented”2
(page 327)
. “The ADM describes what needs to be done to create an architecture and the content
framework describes what the architecture should look like once it is done”2 (page 330). At the
same time, the word “toolkit” or similar definitions are never mentioned in the TOGAF
documentation. Therefore, the original TOGAF documentation clearly describes TOGAF as a
consistent methodology for EA practice describing both the processes that should be followed
and the documents that should be produced as an output, not merely as a toolkit.
What is observed in real EA practice? I have never seen or heard of anybody who
followed recommended ADM steps in any real sense or created a significant portion of
documents recommended by the ACF. Architects unanimously complain that these
recommendations are too rigid and impractical. Instead architects typically developed 8-12
different documents hardly overlapping with the ACF and followed no specific iterative
processes resembling the ADM. Similar findings are reported by other authors as well. “Our
initial assumptions about TOGAF were that it would be a sort of ‘methodology’ that we

1
could follow to produce our EA, however this turned out not to be the case”4 (page 63). “Our
views on TOGAF inevitably changed as the project progressed. Working sequentially
through the TOGAF [ADM] cycle ceased to make sense”4 (page 48). Consequently, TOGAF
was originally designed as “a detailed method and a set of supporting tools”2 (page 3), but has
been later repositioned by the TOGAF community to be merely a “set of supporting tools”
since its “detailed method” proved absolutely impractical.
Interestingly, the word “Framework” in its title was also repositioned accordingly
from its original to a new meaning. The notion of EA framework seemingly was originally
introduced by the PRISM framework5, 6 and then widely popularized by the Zachman
Framework7. In these early days an EA framework was defined as “a logical structure for
classifying and organizing the descriptive representations of an Enterprise”8 (page 2). Even
TOGAF officially defines an architecture framework as “a conceptual structure used to
develop, implement, and sustain an architecture”2 (page 21). However, TOGAF-certified EA
practitioners report that their trainers now interpret the word “Framework” in its title as “a set
of reusable components“, in a meaning similar to which it is used in Ruby on Rails, Spring,
CakePHP and other application frameworks, but which is essentially unrelated to its original
meaning. Therefore, not only TOGAF was repositioned from a methodology to a toolkit, but
even the word “Framework” in its title was also re-imbued with a new meaning to denote “a
set of reusable components” instead of “a structure for describing enterprises”.
Is TOGAF Really Based on Best Practice?
EA practitioners often believe that TOGAF is based on an industry best practice in
EA developed by some other successful companies. It is not surprising taking into account
the claims of The Open Group that “TOGAF has been developed through the collaborative
efforts of over 300 Architecture Forum member companies from some of the world's leading
companies and organizations”2 (page 7) and “provides a best practice framework for adding
value”2 (page 7).
However, if nobody follows ADM steps or develops the heaps of recommended EA
documents, then whose best practice is it? I have never seen any architects or organizations
who might have said that the ADM, ACF or Enterprise Continuum represent their actual best
practice. Most EA practitioners I have spoken to agree that these recommendations can
hardly be based on real best practice, while others opine that their organizations are merely
“not mature enough yet” for this best practice. But here I want to notice that TOGAF
appeared in 1995 and its core elements, for instance the ADM, remain virtually unchanged
since then. How can it be that someone’s best practice developed more than 20 years ago still
cannot be implemented anywhere because organizations are “not mature enough yet”?
Moreover, TOGAF is based on the Technical Architecture Framework for Information
Management (TAFIM)9, but TAFIM was reportedly retired as unsuccessful because EA
projects required huge investments of time and money, resulting architectures were often
obsolete before the completion and business stakeholders were usually unable to understand
them10, 11. If TOGAF is based on TAFIM and TAFIM proved unsuccessful, then how can
TOGAF be based on best practice?
In the light of these observations it becomes clear that TOGAF reflect nobody’s actual
best practice, while the real origin of its core recommendations remains largely obscure. At
the same time, the promises of The Open Group that TOGAF “provides a best practice
framework”2 (page 7) can be considered only as typical meaningless marketing statements
aiming to promote the product sales unsurprisingly coming from the TOGAF’s vendor and
the motivation behind them is perfectly clear. For instance, there is currently more than 52
thousand TOGAF-certified individuals worldwide12. It means that The Open Group has
earned at least 23 million dollars on TOGAF certifications only13. If you add various

2
trainings, courses, books, conferences, consulting and other lucrative TOGAF-related
services provided by The Open Group, then this number will probably be much bigger. If you
were The Open Group, would not you claim that TOGAF represents best practice?
Therefore, the conclusion here is pretty unambiguous: core TOGAF recommendations
do not represent (and never represented) anybody’s actual best practice, but rather came from
some other unclear sources.
Is Actual Best Practice Reflected in TOGAF?
Although it is clear that main TOGAF recommendations did not originate from real
best practice, another question from the opposite perspective is to what extent real best
practice is reflected in TOGAF. In other words, is actual best practice at least a subset of
TOGAF?
My analysis of actual EA-related activities in the studied organizations suggests that
real best practice is hardly included in TOGAF. Probably the most prominent example
demonstrating this conclusion is the EA artefact typically called the Business Capability
Map/Model (BCM)14, 15, 16, which is widely used in the vast majority of the studied
organizations, but is not even mentioned in TOGAF at all. In fact, the BCM plays a very
significant role in EA practices of many organizations and has numerous beneficial
applications. For instance: (1) heatmapping – identifying strategically important capabilities
and focusing IT investments there, (2) footprinting – mapping different IT solutions to
capabilities in order to compare their business value, (3) determining impact – mapping an IT
project to capabilities in order to understand how it will affect the business, (4) identifying
stakeholders - mapping an IT project to capabilities in order to identify its stakeholders, (5)
predicting disruption - mapping an IT project to capabilities in order to understand which
activities may be disrupted, (6) scoping - mapping an IT project to capabilities in order to its
overall scope, (7) the BCM provides a common organization-wide vocabulary and a
reference model for various stakeholders to facilitate communication. Therefore, the use of
BCM is evidently a part of actual best practice in EA. However, ~700 pages TOGAF
document describes neither the BCM itself nor its numerous applications. Moreover, a brief
analysis of the release notes of TOGAF Version 9.12 (page 35) suggests that TOGAF is not even
moving towards real industry best practice.
Consequently, real best practice essentially is not included in TOGAF, i.e. TOGAF
hardly overlaps with actual best practice in EA.
Is TOGAF Flexible?
TOGAF community members typically argue that TOGAF should be adapted before
use and often praise TOGAF for its flexibility since it can be tailored to fit numerous
situations and organizations. But where are the limits of this flexibility? In other words, to
what extent can TOGAF be adapted and yet remain TOGAF?
Interestingly, TOGAF used to give an answer to this question. Section 2.11 of
TOGAF Version 9 (“TOGAF Document Categorization Model”)17 (page 18) classified the
content of TOGAF into core, mandated, recommended and supporting sections. Core sections
are “the fundamental concepts that form the essence of TOGAF”17 (page 18), while mandated
sections are “the normative parts of the TOGAF specification” that “are central to its usage
and without them the framework would not be recognizably TOGAF”17 (page 18). All the key
elements of TOGAF, including ADM phases, Architecture Deliverables and Enterprise
Continuum, are classified as either core or mandated meaning that the officially-defined use
of TOGAF implies using ADM phases and Architecture Deliverables and Enterprise
Continuum. Since I have never seen or heard of any organizations using any of these
elements in any real sense, it can be safely stated that probably nobody on this planet uses

3
TOGAF at all. Unsurprisingly, the release notes of TOGAF Version 9.1 inform readers that
“the Document Categorization Model has been removed”2 (page 36) and, therefore, now any
EA-related activities can be interpreted as “using adapted TOGAF” and described as
“TOGAF-based” regardless of their relationship to the actual TOGAF recommendations.
Whatever you do, you use TOGAF.
However, what is much more important is that nobody I am aware of is able to
articulate clearly how exactly TOGAF should be adapted. TOGAF’s ~700 pages
documentation mentions the need for adaptation, but does not answer the question “How
exactly?” either. I argue that the recommendation to adapt TOGAF without specifying how
exactly is an evident logical trick, “catch-22”.
Consider the following recommendation clearly illustrating the typical deceitful
TOGAF-style pattern: “To eat your soup you should use (1) a fork or (2) any other
instrument”. This recommendation looks utterly nonsensical because (1) eating soup with a
fork is obviously impractical but (2) the advice to use any other instrument does not convey
any information at all. Consequently, the value of this recommendation is negative or nil.
Looking through the TOGAF lenses this recommendation can be read as: “To practice EA
you should follow (1) ADM steps or (2) any other processes”. Here again (1) following ADM
steps is obviously impractical but (2) the advice to follow any other processes does not
convey any information at all. In fact, TOGAF is abundant in similar recommendations
where (1) doing what is recommended is obviously impractical but (2) the suggestion to
adapt this recommendation into something else is uninformative. Therefore, for most aspects
of EA practice TOGAF is indeed flexible, i.e. does not prescribe anything in particular. As a
result, TOGAF-certified EA practitioners are free to do whatever they find reasonable and
praise TOGAF for its flexibility since TOGAF generously allows them to adapt (actually
ignore) its own unreasonable advice. Unreasonableness of TOGAF’s advice is compensated
by optionality of its execution.
This situation puts The Open Group in an extremely beneficial position, while the
position of EA practitioners seems desperate. The position of The Open Group is essentially a
“lossless lottery”: any failures of TOGAF-based EA practices can be attributed to the
improper adaptation of TOGAF’s best practice recommendations by unqualified architects,
while any successes of TOGAF-unrelated EA practices can be “appropriated” as TOGAF-
based because TOGAF is very flexible and allows any behaviour. Since TOGAF allows any
arbitrary adaptations, all successful EA practices can be considered TOGAF-based. This
deceptive “flexibility trick” puts TOGAF beyond any critique: TOGAF is always good, you
just need to adapt it properly (somehow). At the same time, EA practitioners have no one to
blame but themselves: they are given “industry consensus EA best practice” by The Open
Group and now it is their turn to adapt and use it properly.
Taking into account the previous conclusions that the TOGAF’s advice is not best
practice and that actual best practice is not included in TOGAF at all, very impressive
flexibility is required in order to transform TOGAF into a working EA practice. Adapting
TOGAF implies not only throwing away ADM, ACF and Enterprise Continuum, but also
inventing something reasonable instead of them. From this perspective “using TOGAF” can
be best explained as “studying TOGAF and then doing something else instead”, and this is
praised as TOGAF’s flexibility.
Therefore, the conclusion here is again unequivocal: the admired flexibility of
TOGAF is nothing more than a simple trick helping (1) conceal impracticality of the actual
TOGAF’s recommendations, (2) put the burden of responsibility for improper adaptation on
EA practitioners, (3) avoid any potential criticism and (4) interpret successes and failures
“properly”.

4
 What is TOGAF?
Since TOGAF consists of ~700 pages of strange optional prescriptions of an unknown
origin hardly overlapping with actual best practice in EA, it can be best described as a toolkit
of random EA-related recommendations. Unsurprisingly, the value of TOGAF is also
haphazard. It can only be realized if some of its random recommendations accidentally turn
out useful, maybe yes, maybe no. For instance, EA practitioners, though unanimously opine
that TOGAF cannot be used as a consistent EA methodology, still admit that TOGAF can
have some value. However, different EA practitioners find different random fragments of
TOGAF valuable and these fragments are typically of secondary importance: some people
find the idea of building blocks useful, some the idea of a viewpoint, technical reference
model or some deliverables from some phases. Moreover, since TOGAF offers nothing in
particular except the flexibility to “pick whatever you want, adapt it as you wish and use it
any way you like”, it is fundamentally unable to provide any meaningful, systematic and
consistent description of EA and EA practice. As a result, regardless of how well you know
TOGAF, it is arguably impossible to establish a successful EA practice from scratch if you
have never seen previously how successful EA practices look like and work in other
organizations. For instance, one interviewee compared the EA profession to a craftsmen’s
guild where the only way to acquire the necessary skills is to become an apprentice and learn
from your master.
TOGAF can be also described as a distractor of attention because it draws the
discourse in the EA community away from real EA-related questions. In other words, people
discuss TOGAF instead of discussing EA (with this article being the brightest illustration of
this statement). Instead of EA education we get TOGAF certification. Instead of asking right
questions, for instance “What works?” and “What does not work?”, many EA practitioners
tend to ask artificial questions, for instance “How should TOGAF be properly applied?”,
“What are the advantages of TOGAF?” or “What is better, TOGAF or Zachman?”. All these
TOGAF-inspired questions do not make much sense and cannot advance our understanding
of EA. Unfortunately, the academic EA community is fascinated with TOGAF as well.
Significant efforts are put into the scientific analysis of TOGAF18, 19, 20, 21 instead of empirical
EA practice. Moreover, the situation in academe from this perspective is probably much
worse than among EA practitioners, since many “paper” researchers live in their theoretical
ivory towers and hardly understand the existence of a gap between EA theory and practice.
For instance, the first version of my paper intended to study the practical usage of EA
artefacts22 was rejected by an anonymous reviewer with the following comment (among
others): “Frameworks such as TOGAF provide very detailed instructions for their users in
terms of methodology and [artefacts]. I do not see the value of redefining these”. More
interestingly, the presence of TOGAF in the EA discourse generates the phenomenon of
“doublethink” - simultaneous acceptance of two mutually contradictory beliefs as correct. For
instance, the question “Do we know something about EA practice?” typically gets answered
with “Yes, TOGAF is a widely-accepted comprehensive industry standard defining EA
practice”, but the question “Can TOGAF be interpreted literally and followed step-by-step to
practice EA?” typically gets answered with “No, TOGAF is only a framework, it should be
modified (somehow) for specific organizations”. In this situation we supposedly know much
about EA practice because TOGAF exists, but at the same time we also do not know anything
about EA practice because nobody can specify how exactly TOGAF should be used.
Consequently, the existence of TOGAF suggests that we know much and do not know
anything about EA practice at the same time. This doublethink essentially leads to a dead end
in the EA discipline because EA studies neither can be started from scratch (because TOGAF
exists), nor can be based on TOGAF (because it is not clear how exactly it is used).

5
Therefore, the existence of TOGAF only wastes our time and inhibits rather than facilitates
our progress in real understanding of EA.
What is more surprising, TOGAF can be considered essentially as a religious text due
to the following properties: (1) its real origin and authorship are disputable, (2) it offers the
wisdom of a mythical origin, (3) it cannot be understood literally, but needs to be properly
interpreted, (4) it is promoted by enlightened gurus who know how to construe it, (5) when
properly interpreted, it has answers to all questions, (6) its original text does not change,
while its interpretations evolve and (7) it is vague enough to be universal. Consider the
following supernatural description of TOGAF at work by a well-known TOGAF guru:
“Organizations start with an open framework like the TOGAF framework, but as it gets
customized and tailored, it adapts to an organization’s culture to become their own
“personalized” enterprise architecture model. As enterprise architecture matures in an
organization, the TOGAF framework is still inside and powering their enterprise architecture
but no longer very visible”23 (page 16). If it is not a sermon, then what is it?
This religious nature of TOGAF has very important implications for the discourse
around it. Firstly, EA practitioners converted in TOGAF faith will be always convinced that
they use TOGAF whatever they do regardless of any logical arguments against it, even if they
actually do not follow a single recommendation out of it. Secondly, whether to be or not to be
TOGAF-based is only a matter of a personal conviction. For instance, I have met some
faithful TOGAF believers who seemingly never read its original text, but only visited some
courses where gurus explained them how to interpret and use TOGAF “properly”. Therefore,
many people believe they use TOGAF without being aware of what exactly the original
TOGAF text says. As a result, many people are convinced that EA practice is TOGAF, which
is not so1. This fact that many people learn TOGAF only from gurus, but never read its
original text explains how TOGAF could be effortlessly reinterpreted and repositioned from a
methodology to merely a toolkit even without modifying its original text. Thirdly, arguments
around TOGAF might be interesting and might even spark “religious wars”, but they are
utterly useless and make no difference at all. Fourthly, TOGAF lives in people’s hearts, not
brains. Therefore, regardless of any future evidence-based scientific progress in our
understanding of EA, TOGAF’s text will not change (but its interpretations still may change)
and TOGAF’s congregation will not decline. As world religions can exist in parallel with
physics, chemistry and biology, TOGAF can also exist in parallel with evidence-based
sources on EA24, 25, which are typically inconsistent with TOGAF. Regardless of any possible
criticism, no matter how substantiated, TOGAF will stay with us and remain a curious
phenomenon of the EA world.
Why TOGAF is So Popular?
I argue that the popularity of TOGAF can be attributed to three main factors. The first
factor is the aggressive promotion of TOGAF. Numerous gurus, trainers, instructors, experts,
consultants, certification centres etc. make their fortunes “selling” TOGAF. Unsurprisingly,
all these parties are interested in promoting TOGAF and avoiding any criticism towards it.
They are all working hard to support the image of TOGAF as a globally recognized de facto
industry standard in EA based on best practice of world-leading companies. What is
interesting here is that EA consultancies can sell their services under the TOGAF brand
perfectly understanding its symbolic value. For instance, one of the few available evidence-
based sources on EA24 co-authored by PricewaterhouseCoopers (PwC) experts clearly
suggests that successful EA practice has not much to do with TOGAF or any other EA
frameworks, but yet PwC’s website promises to provide “advice consistent with industry
leading frameworks such as TOGAF and Zachman”26.

6
 The second factor is a lack of any serious alternatives to TOGAF. On the one hand,
other promoted and well-known EA frameworks are even more useless for real EA practice
than TOGAF and do not deserve any attention at all. On the other hand, other available
reasonably good sources on EA24, 25 are (1) not promoted and therefore are not well-known to
“mass-readership”, (2) not distributed for free, (3) not frameworks, while EA is strongly
associated with frameworks and (4) not comprehensive. Consequently, for many EA
practitioners the only visible alternative to TOGAF is the Zachman Framework and TOGAF
turns out to be the lesser of two evils. Moreover, the situation here looks hopeless since
probably nobody of powerful players on the EA market is motivated to propose any
alternatives to TOGAF: if people willingly pay for TOGAF, then why invent something else?
The third factor is the shameful (or even criminal) inertness of the EA research
community, which I belong to. Unfortunately, EA researchers generally do not provide any
objective analysis of the situation in the EA discipline. As a result, trustworthy and evidence-
based information on EA can hardly be found. In this atmosphere of ignorance numerous EA-
related myths, legends and superstitions propagate very quickly. Due to a number of pretty
complex reasons academic EA researchers are typically obsessed with producing “scientific”
theories instead of answering real practical questions. Consequently, EA research rarely goes
beyond paltry questions, like comparing EA frameworks or speculating on theoretical
benefits of EA. There are more than a thousand of academic publications on EA, but this
impressive heap of “knowledge” cannot answer even the simplest relevant questions, for
instance which documents are typically used in EA practice and how. Therefore, the
academic EA research community is essentially powerless and unable not only to propose
some comprehensive alternatives to TOGAF, but even to restrain the propagation of
dangerous TOGAF-related superstitions. The fact that TOGAF is now taught at the
prestigious university27 clearly demonstrates the capitulation of an academic army to
marketing aggressors.
Conclusion
TOGAF is definitely an interesting phenomenon of the EA world because: (1) it is
based on a methodology previously rejected as ineffective (TAFIM9), (2) it claims to be
based on best practice, but is unable to provide any examples of successful implementation,
(3) it gained enormous popularity, but brings only a minor random value, (4) it is closely
associated with the notion of EA, but is unable to explain how EA works and even what EA
is, (5) everybody knows that TOGAF should be adapted, but nobody can say how exactly, (6)
it is successfully sold to very intelligent people with simplistic tricks, (7) people question its
value, but are eager to get certified (I got my TOGAF certificate as well), (8) it claims to
disseminate best practice, but actually inhibits its dissemination and (9) it acquired faithful
believers.
Essentially, TOGAF is a toolkit of random EA-related recommendations which is
unable to describe what EA practice is and even what EA is, but still can bring some
accidental marginal value. To “use TOGAF” actually means to “study TOGAF and then do
whatever you find reasonable” and, therefore, means nothing at all. The existence of TOGAF
only distracts our attention and impedes our understanding of EA.
However, since TOGAF can be considered as a religious text and a freedom of
religion is guaranteed by the constitution, everyone is free to believe in TOGAF, use TOGAF
and find TOGAF valuable or even essential for EA practice. TOGAF faith cannot be
prohibited, ridiculed or even condemned. Therefore, faithful TOGAF believers are free to
stay content with metaphysical explanations of how TOGAF “adapts to an organization’s
culture to become their own “personalized” enterprise architecture model” and then is
“powering their enterprise architecture but no longer very visible”23, but all others feeling

7
sceptical about vague TOGAF babble should forget TOGAF and study evidence-based
sources on EA, of which two most important probably are “Enterprise Architecture as
Strategy: Creating a Foundation for Business Execution”25 and “Strategic Enterprise
Architecture Management: Challenges, Best Practices, and Future Developments”24.
References
1
Kotusev, S. 2016. "Enterprise Architecture Is Not TOGAF." Retrieved 21 January, 2016,
from http://www.bcs.org/content/conWebDoc/55547
2
TOGAF. 2011. "TOGAF Version 9.1," G116, The Open Group.
3
TOGAF. 2016. "TOGAF Users by Market Sector." Retrieved 23 June, 2016, from
http://web.archive.org/web/20151121161238/http://www.opengroup.org/togaf/users-
by-market-sector
4
Anderson, P., Backhouse, G., Townsend, J., Hedges, M., and Hobson, P. 2009. "Doing
Enterprise Architecture: Enabling the Agile Institution," 533, Joint Information
Systems Committee (JISC), Bristol, United Kingdom, pp. 1-82.
5
PRISM. 1986. "PRISM: Dispersion and Interconnection: Approaches to Distributed
Systems Architecture," CSC Index, Cambridge, MA.
6
Rivera, R. 2013. "The PRISM Architecture Framework - Was It the Very First Enterprise
Architecture Framework?," Journal of Enterprise Architecture (9:4), pp. 14-18.
7
Zachman, J.A. 1987. "A Framework for Information Systems Architecture," IBM Systems
Journal (26:3), pp. 276-292.
8
Zachman, J.A. 1996. "Concepts of the Framework for Enterprise Architecture: Background,
Description and Utility," Zachman International, Monument, CO.
9
TAFIM. 1996. "Department of Defense Technical Architecture Framework for Information
Management, Volume 4: DoD Standards-Based Architecture Planning Guide
(Version 3.0)," Defense Information Systems Agency, Arlington County, VA.
10
Goikoetxea, A. 2007. Enterprise Architectures and Digital Administration: Planning,
Design, and Assessment. Singapore: World Scientific Publishing.
11
Perks, C., and Beveridge, T. 2003. Guide to Enterprise IT Architecture. New York, NY:
Springer.
12
TOGAF. 2016. "Directory of Certified People." Retrieved 13 January, 2016, from
https://togaf9-cert.opengroup.org/certified-individuals
13
TOGAF. 2016. "TOGAF Examination Fees." Retrieved 16 February, 2016, from
https://togaf9-cert.opengroup.org/examination-fees
14
Scott, J. 2009. "Business Capability Maps: The Missing Link Between Business Strategy
and IT Action," Architecture and Governance Magazine (5:9), pp. 1-4.
15
Swindell, A. 2014. "Business Capability Models: Why You Might Be Missing Out on
Better Business Outcomes," Architecture and Governance Magazine (10:2), pp. 3-7.
16
Keller, W. 2015. "Using Capability Models for Strategic Alignment," in Business
Architecture Management: Architecting the Business for Consistency and Alignment,
D. Simon and C. Schmidt (eds.). Berlin: Springer, pp. 107-122.
17
TOGAF. 2009. "TOGAF Version 9," G091, The Open Group.
18
Dietz, J.L., and Hoogervorst, J.A. 2011. "A Critical Investigation of TOGAF - Based on the
Enterprise Engineering Theory and Practice," in Advances in Enterprise Engineering
V, A. Albani, J.L. Dietz and J. Verelst (eds.). Berlin: Springer, pp. 76-90.
19
Zadeh, M.E., Millar, G., and Lewis, E. 2012. "Mapping the Enterprise Architecture
Principles in TOGAF to the Cybernetic Concepts - An Exploratory Study," in
Proceedings of the 45th Hawaii International Conference on System Sciences, R.H.
Sprague (ed.), Maui, HI: IEEE, pp. 4270-4276.

8
20
Mueller, T., Schuldt, D., Sewald, B., Morisse, M., and Petrikina, J. 2013. "Towards Inter-
Organizational Enterprise Architecture Management - Applicability of TOGAF 9.1
for Network Organizations," in Proceedings of the 19th Americas Conference on
Information Systems, J.P. Shim, Y. Hwang and S. Petter (eds.), Chicago, IL:
Association for Information Systems, pp. 1-13.
21
Alm, R., and Wißotzki, M. 2013. "TOGAF Adaption for Small and Medium Enterprises,"
in Proceedings of the 16th International Conference on Business Information Systems
Workshops, W. Abramowicz (ed.), Poznan, Poland: Springer, pp. 112-123.
22
Kotusev, S., Singh, M., and Storey, I. 2015. "Investigating the Usage of Enterprise
Architecture Artifacts," in Proceedings of the 23rd European Conference on
Information Systems, J. Becker, J. vom Brocke and M. de Marco (eds.), Munster,
Germany: Association for Information Systems, pp. 1-12.
23
Viswanathan, V. 2015. "Four Questions: Vish Viswanathan," Journal of Enterprise
Architecture (11:2), pp. 15-17.
24
Ahlemann, F., Stettiner, E., Messerschmidt, M., and Legner, C. (eds.). 2012. Strategic
Enterprise Architecture Management: Challenges, Best Practices, and Future
Developments. Berlin: Springer.
25
Ross, J.W., Weill, P., and Robertson, D.C. 2006. Enterprise Architecture as Strategy:
Creating a Foundation for Business Execution. Boston, MA: Harvard Business
School Press.
26
PwC. 2016. "Enterprise Architecture." Retrieved 18 February, 2016, from
http://www.pwc.com/ca/en/services/consulting/technology/advisory/enterprise-
architecture-governance.html
27
NUS. 2016. "NICF - Certified Enterprise Architecture Practitioner Course." Retrieved 13
January, 2016, from
https://www.iss.nus.edu.sg/ProfessionalCourses/SearchCourse/CourseDetail/tabid/267
/cid/1/cname/nicf-certified-enterprise-architecture-practitioner-course/Default.aspx