Svyatoslav Kotusev, a researcher at RMIT University, Melbourne, Australia, questions whether the Open Group Architecture Framework (TOGAF) is the industry standard framework that enterprise architects really deserve.
The Open Group Architecture Framework (TOGAF) is currently promoted as an industry consensus framework for enterprise architecture (EA) representing the best practice of numerous EA practitioners.
However, my observations of successful companies using TOGAF as a basis for their EA efforts suggest that most TOGAF recommendations are usually found inapplicable, while the most critical parts of EA practice are usually established from scratch in company-specific ways.
Therefore, my findings question the value of TOGAF as a standard for EA practice since successful TOGAF-based EA initiatives hardly overlap with the actual TOGAF prescriptions. More realistic and evidence-based sources on EA are needed.
In the recent years The Open Group Architecture Framework (TOGAF 2011) has gained prominence as the best-known framework for EA practice. It is positioned as an ‘open, industry consensus framework for enterprise architecture’ (TOGAF 2011, p. xxiii) representing the best practice of multiple companies practicing EA.
Its core feature, Architecture Development Method (ADM), is ‘the result of continuous contributions from a large number of architecture practitioners’ (TOGAF 2011, p. 45). Unsurprisingly, TOGAF is heavily promoted by various consultancies, experts and trainers. Is it really so valuable for organisations? Does it really reflect the best practice of successful organisations using EA?
My observations of leading Australian companies (who wished to remain anonymous) suggest negative answers to these questions. Although these companies use TOGAF as the key EA framework (one of them is even included in the ‘official’ list of TOGAF users on The Open Group website, (see TOGAF (2015)), their actual activities hardly resemble TOGAF prescriptions.
For instance, ADM - the core of TOGAF - is found inapplicable in practice and its steps are not followed by any of these companies. Similarly, other essential TOGAF features, including the Architecture Content Framework and Enterprise Continuum, are also not used in companies ‘using’ TOGAF.
Instead of following the step-wise and iterative ADM they established idiosyncratic sets of continuous EA-related processes. Instead of developing heaps of EA artifacts recommended by the Architecture Content Framework they established small pragmatic sets of value-adding documents with clearly defined aims, stakeholders and purpose. Consequently, the most critical parts of TOGAF-based EA initiatives were essentially ‘invented’ from scratch in unique company-specific ways.
On the other hand, useful TOGAF features adopted in these companies, such as four EA domains or architecture principles, are not really TOGAF-specific but rather conventional and have been used for decades (Davenport et al. 1989; PRISM 1986; Richardson et al. 1990). Therefore, the core parts of TOGAF were found largely useless, useful parts of TOGAF were not TOGAF-specific, while the most critical parts of EA practice were established from scratch.
In light of these findings the growing popularity of TOGAF can hardly be attributed to the real usefulness of its advice, but rather to a lack of any better alternative sources on EA. This conclusion supports the opinion of Bloomberg (2014a, p. 1) that ‘TOGAF’s accelerating success is simply because it’s the only game in town’ and that ‘TOGAF has gained traction simply because it’s better than doing nothing’.
Despite the fact that many TOGAF recommendations are considered as overly complex and largely unrealistic, it still remains the most comprehensive available source on EA where some useful ideas can be found, while other EA frameworks are even less helpful. Consequently, the choice between TOGAF and other EA frameworks is essentially the choice between something and nothing, bad and very bad, largely useless and totally useless.
Although TOGAF is briskly discussed, heavily promoted and its certifications are required for enterprise architects at many companies, my findings suggest that successful EA efforts, even TOGAF-based, are built on pragmatic common sense ideas and rarely resemble the actual TOGAF recommendations.
Therefore, TOGAF is used, arguably, more as a symbol than as a realistic actionable guidance. Following TOGAF does not guarantee a successful EA practice to an organisation and getting TOGAF-certified does not guarantee a successful career to an EA practitioner. In short, TOGAF does not define EA practice, and successful EA is not TOGAF.
Despite the promise that ‘TOGAF provides a best practice framework for adding value’ (TOGAF 2011, p. 7), the analysis of its usage shows that this best practice can be hardly applicable and TOGAF can be hardly used in any real sense: only as a ‘dictionary’ where some useful information can occasionally be found or as a ‘horoscope’ from which vague recommendations can be adapted and interpreted to fit all organisations, but, not providing any real practicable guidance to any of them. Though positioned as a comprehensive end-to-end EA framework covering most parts of EA practice, TOGAF rarely provides useful advice on its most critical aspects.
Surprisingly, my conclusions are not innovative and far from new, but rather old and widely known. They are supported by numerous previous empirical studies (Ahlemann et al. 2012; Buckl et al. 2009; Haki et al. 2012; Holst and Steensen 2011; Ross et al. 2006; Smith et al. 2012) that consistently demonstrate that EA frameworks, including TOGAF, have only a minor value at best or are even detrimental at worst.
Consequently, this article is not a breakthrough, but yet another reminder that successful EA initiatives have not much to do with the popular EA frameworks that are, arguably, no more than a typical management fad since their value is more than questionable. ‘Frameworks are cocaine for executives - they give them a huge rush and then they move to the next framework’ (Bloomberg 2014b, p. 1).
Therefore, I argue that the EA community should take a sober realistic look at existing EA literature, critically revise and rethink its idealistic ideas that are presently very distant from the real-world EA practice in organisations. New evidence-based comprehensive sources on EA are desperately needed as a substitute for largely useless, but aggressively promoted, EA frameworks.
The bottom line is that there is no substitute for competent analytical capability, which seeks to learn from others, but applies intelligence, experience, perception, common-sense, and good communication skill to each unique context. One size does NOT fit all, and many of the criticisms expressed here might be directed at other brands, such as PRINCE2 and ITIL, where inexperienced practitioners try to apply them without broad understanding and a degree of pragmatism. There is no golden bullet!
It feels like you had some negative experience(s) with either the TOGAF framework or more generally Enterprise Architecture or maybe both. Maybe you should explain where and why you believe TOGAF didn't help (people and company names can be changed to sthg that doesn't identify them too obviously if you can't disclose those details). I believe TOGAF and the ADM are not rigid and can be tailored to specific needs (like with most frameworks). Are you TOGAF certified yourself ?
An interesting and thought provoking article. I am still relatively new to EA and maybe got too bogged down in TOGAF and I would agree with your conclusions. Whilst retaining some elements and guidelines from TOGAF, we moved to a more dynamic and agile form of enterprise architecture focussed on business outcomes, heavily promoted by organisations such as Gartner, alongside a sound business capability model. At present it is not clear how TOGAF fully supports that approach. We were also driven by projects and the ADM as it stands was rejected as it was too architecture driven.
I would be keen to hear of more practical experience from organisations who successfully adopted TOGAF while maintaining business agility.
It will be interesting to see what happens with the next revision of TOGAF and whether it improves alongside a more integrated update to Archimate.
This seems an overly negative piece based on an un quantified number of observations. As mentioned in the first comment, if you use any framework "to the letter" it will be overly restrictive and be viewed as not delivering value. That is where TOGAF, in my opinion, does add value. In the first phase of the ADM cycle, the architect has the option to tailor the approach to best fit the situation at hand. This flexibility, and the common language employed in its execution, rather than the "better than nothing" approach cited in this piece, are more likely the reason that TOGAF is so widely used.
This article cannot even refer to the versions 8 and 9 of TOGAF correctly. However I can agree with some the authors core ideas. That is that EA is not TOGAF. Indeed TOGAF is a framework, a structure a gathering of lots of practical real world experience on how an Enterprise Architect can work.
Enterprise Architecture is a wide ranging product that requires skill and experience to develop. TOGAF never claims to be Enterprise Architecture.
So the title of the article is true and I support it. However very little that follows has any real evidence other than unquoted sources.
I can quote many of the organisations that I have worked for using TOGAF for clients all very successfully. Why? Because they accept what TOGAF is... a guide... not a prescription.
The power of TOGAF is its flexibility based on real experience.
Like any framework it is a toolset to achieve a goal, and if the tool doesn't work for you then you modify it. One of the first elements of TOGAF is to adapt it to fit in with the company model that it is to work within. Too many people take the methodology as the goal, when the goal is the results they provide.
This article reflects my field experience with clients, though I do not fully endorse the conclusions drawn. In an organisation with no framework TOGAF provides a toolbox from which relevant elements can be adopted and adapted. In each case the stakeholders need to see sufficient benefit to justify the effort for each process and work product. Often this requires tayloring to existing culture, practices and terminology. The specific architecture method used ends up as a variant. But a better one than would have been reached if starting without a reference framework.
Surely you are not so naïve as to suggest that the IT industry be a slave to any framework, be it TOGAF or any other? Your article suggests blind obedience and reflects a lack of understanding of how organisations use frameworks in the real world. Any framework should be treated as a reference tool for an organisation to pick and choose from to pragmatically befit their needs, maturity, and capabilty.
This idiot don't no what is EA what is the definition of EA practice completely no idea and experience about TOGAF i don't no what kinda research he doing in RMIT
If you bother to read TOGAF, it tells you that the best practices for any organisation is the one they adapt and that TOGAF is merely indicative. TOGAF itself claims that it provides guidelines and references. There is no TOGAF police out there that names and shames non-compliant EA practitioners. TOGAF is unique in many ways and has been found to be very useful by thousands of organisations. There is no prescribed method for following ADM and it is up to the organisation itself to find the best ADM cycle that suits its needs. TOGAF does refer to several documents but these are like a library from which a User can pick the most appropriate.
I am not sure what the reason is behind this rant tirade. It is advised that you read up and try to understand the object of your criticism first.
Perhaps you expect too much from a framework or a methodology. Studying and getting certified in TOGAF will not make you an Enterprise Architect. It will however, give you a language to communicate with other EAs. TOGAF itself is not revolutionary, indeed one could say that it has taken 15 years to catch up with proprietary methodologies such as Information Engineering and IBM's SDM (and all the other names it was known by), although it did add a little around ongoing governance and maintenance which were lacking in the original methods.
TOGAF is far from perfect, but it does provide a reasonable reference for many architectural techniques, but then it needs to be tailored to what is useful in your context.
In the end, it is like everything else. There is no substitute for knowledge and experience. A method gives you a common framework which you can adapt and tailor to need, where it is useful.
TOGAF does not position itself to be adhered to wholesale, and tailoring TOGAF (as with any other such framework) is recommended. So to quest an alternative for TOGAF, simply it is not being followed to the letter, may be premature. Note that there are other valid EA frameworks out there (e.g., Zachman), and organisations are not bound to only use TOGAF.
I fully agree with you findings. To "Enterprise architecture is not TOGAF" I would add, and vice versa. In the last 15 years I have seen either:
a) decent EA not using TOGAF;
b) decent EA pretending to use TOGAF;
c) TOGAF fans actually using TIGAF, but not doing EA.
Even more, if one or more of the following questions is answered positively, the chance is, IMO you are not doing EA:
1. Are you reporting to the CIO?
2. Your artefacts make sense only if there is electricity in your organisation?
3. Is your EA only reactionary and only to requirements (the centre of ADM)?
(and so on...)
4. You consider diagrams an important part of the EA deliveries?
5. You are not allowed to work on changing the structure of your organisation (outside IT)?
Re: "On the other hand, useful TOGAF features adopted in these companies, such as four EA domains or architecture principles". Agree about principles, disagree about domains. Indeed they are widely used and indeed it wasn't a TOGAF invention. But I personally find them useless and a frame for bad decisions. Whenever there is some strong case to use them, they should at least not be considered disjoint (see https://storify.com/kvistgaard/is-it-architecture-subset-of-business-architecture)
Yes & No, you have already answered the No and Yes as well....
No framework can sustain longer in this changing world....the way we do business is changing, expectations are changing, frameworks will change to...
I've been saying this for years.
PEAF has been an alternative for many years but since everyone gos on a TOGAF course because everyone goes on a TOGAF course, getting traction is difficult.
PEAF stops people making 90% of the mistakes that kill 90% of EA initiatives. It concentrates on getting the fundamentals right, providing the 20% that will provide 80% of the benefits.
POET is similar but covers the whole of the transformation domain (from strategy to deployment) rather than just the EA domain, and could be viewed as a super-class of PEAF since PEAF inherits from POET.
If you think your enterprise would like to increase it’s maturity (effectiveness, efficiency, agility, durability) of how it does change/transformation or any part of it (such as EA – Strategising and Roadmapping), I’d be happy to have a chat.
Of course, if your Enterprise is happy with how it runs Transformation (from Strategy to Deployment) in terms of its effectiveness, efficiency, agility, durability, then it would have no need to mature it.
From a personal point of view, we also run a Pragmatic Associate Programme (PAP) where you can self study and get certified for free (£450 fee refunded over 3 stages as you progress) in exchange for helping us spread the word about PEAF and POET.
An interesting article and I agree with many of the points made; especially Togaf exists because nothing else does !
The primary element missing from all architectural approaches / methodologies / frameworks is prior Knowledge of the business - knowledge of end-to-end performance, knowledge and appreciation of the importance of Perspective and Proof - tangible evidence that the 'problem' being solved actually exists. and then evidence (+ or -) of the impact the proposed solution is having on the problem.
Until we further merge the worlds of IT and Business - the various camps will continue to operate in silos - like villages - collaborating when required to ensure their survival - but incapable of really achieving more.
Interesting article but the framework is meant to be adapted in its entirity or just a component. The point is, there has to be structured methodology from an enterprise perspective. There's no limit on the extent that one can or should tailor the TOGAF as long there's some alignment between Business and IT.
TOGAF provides a dictionary for an Enterprise Architecture practice. One can fine most of the relevant aspects that might be necessary when reasoning about an enterprise in terms of "developing", "constructing" and "sustaining". If you remove the TOGAF out of the game, what you get is islands of whatever-works-for-whomever. As mentioned in the previous comments, TOGAF is a toolbox, and provides a common frame of reference. Now how you apply it, is completely up to the enterprise. Also, important to mention, TOGAF does not provide a solution, and every enterprise is unique in terms of its structure, culture, etc.