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 (p3).
The TOGAF Architecture Development Method (ADM) is ‘a step-by-step approach to develop and use an enterprise architecture’2 that ‘describes a method for developing and managing the lifecycle of an enterprise architecture’2 (p45), ‘defines a recommended sequence for the various phases and steps involved in developing an architecture’2 (p56) and ‘forms the core of TOGAF’2 (p45). The TOGAF Architecture Content Framework (ACF) is ‘a detailed model of the outputs to be created by the ADM’2 (p37) that provides ‘a detailed open standard for how architectures should be described’2 (p34) 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 (p327). ‘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 (p330).
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 could follow to produce our EA, however this turned out not to be the case’4 (p63). ‘Our views on TOGAF inevitably changed as the project progressed. Working sequentially through the TOGAF [ADM] cycle ceased to make sense’4 (p48).
Consequently, TOGAF was originally designed as ‘a detailed method and a set of supporting tools’2 (p3), 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(p2). Even TOGAF officially defines an architecture framework as ‘a conceptual structure used to develop, implement, and sustain an architecture’2 (p21).
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 organisations’2 (p7) and ‘provides a best practice framework for adding value’2 (P7).
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 organisations 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 organisations 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 (P7) 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 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 organisations suggests that real best practice is hardly included in TOGAF. Probably the most prominent example demonstrating this conclusion is the EA artifact typically called the Business Capability Map/Model (BCM) 14, 15, 16, which is widely used in the vast majority of the studied organisations, but is not even mentioned in TOGAF at all. In fact, the BCM plays a very significant role in EA practices of many organisations 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 organisation-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 (p35) 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 organisations. 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 Categorisation Model’) 17 (p18) 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 (P18), 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 recognisably TOGAF’17 (P18).
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 organisations using any of these elements in any real sense, it can be safely stated that probably nobody on this planet uses TOGAF at all. Unsurprisingly, the release notes of TOGAF Version 9.1 inform readers that ‘the Document Categorisation Model has been removed’2 (p36) 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’.
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 realised if some of its random recommendations accidentally turn out to be 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 organisations. 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 the 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 artifacts22 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 [artifacts]. 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 organisations’. 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). Therefore, the existence of TOGAF only wastes our time and inhibits rather than facilitates our progress in a 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: ‘Organisations start with an open framework like the TOGAF framework, but as it gets customised and tailored, it adapts to an organisation’s culture to become their own ‘personalised’ enterprise architecture model. As enterprise architecture matures in an organisation, the TOGAF framework is still inside and powering their enterprise architecture but no longer very visible’23 (P16). 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 to 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 recognised 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.
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 none of the powerful players on the EA market are 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 a prestigious university27 clearly demonstrates the capitulation of an academic army to marketing aggressors.
An interesting contradiction
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’ve 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 organisation’s culture to become their own “personalised” enterprise architecture model’ and then is ‘powering their enterprise architecture but no longer very visible’23, but all others who are feeling 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.
The views in this article are the views of the author and are his own personal views that should not be associated with any other individuals or organisations.
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.'
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.
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
27 NUS. 2016. 'NICF - Certified Enterprise Architecture Practitioner Course.' Retrieved 13 January, 2016
