A significant event in the world of enterprise architecture (EA) is the recent release of the version 9.2 of the well-known TOGAF standard1. The new version was officially announced on 16 April 2018 and already engendered some discussions in the EA community. This is the first update of the widely promoted ‘proven enterprise architecture methodology and framework’, as declared on The Open Group website, since the previous version 9.1, released back in 2011.
How did TOGAF change? What does the new release of TOGAF bring to the EA community? Are there any major improvements in the new version? Did this version address the existing problems of the earlier versions? Did TOGAF ascend to the higher level of its evolution and maturity with the recent release? Below I will discuss the ‘fresh’ changes in the TOGAF standard and analyse these changes in the broader context of the EA discipline.
What has changed?
Arguably the single most significant change in version 9.2 of TOGAF is the introduction of the so-called TOGAF Library, ‘a reference library containing guidelines, templates, patterns, and other forms of reference material to accelerate the creation of new architectures for the enterprise’1. Essentially, the TOGAF Library simply encompasses and organises various TOGAF-related publications that were already available earlier on The Open Group website. However, the planned addition of some new reference materials to the TOGAF Library in future is also announced.
Several modifications can be noticed in the core body of TOGAF as well. Firstly, the TOGAF Library is now positioned as an integral part of TOGAF and some former TOGAF chapters, e.g. chapter 21 (Security Architecture and the ADM) and chapter 22 (Using TOGAF to Define and Govern SOAs), and even the entire previous part VI (TOGAF Reference Models) have been moved from the main body text into the TOGAF Library.
Secondly, the core TOGAF text has been somewhat cleaned up. In particular, chapter 4 (Release Notes) has been removed altogether, while some other chapters have been moved to the TOGAF Library, as mentioned above. However, most of the existing chapters remain in place with only insignificant changes, e.g. reordering of subsections, minor updates, or small editorial improvements. As a result of this cleanup, the overall volume of the TOGAF documentation in the version 9.2 has been reduced to 532 pages from 692 pages in the previous version 9.1.
Finally, it is declared that the new version of TOGAF puts more emphasis on business architecture. Practically, this emphasis is manifested mostly in the addition of ten new EA artifacts to the list of outputs in phase B (Business Architecture) supplemented by shallow one-sentence descriptions of each of these artifacts in part IV (Architecture Content Framework).
In summary, the changes made in TOGAF 9.2 look pretty superficial and can be considered at best only as a ‘refactoring’, rather than as a substantial enhancement. Although TOGAF has extended its ‘dictionary’ with some new titles of EA artifacts, its fundamental approach to planning stayed the same. The purely ‘cosmetic’ nature of the recent changes suggests that the overlap between current TOGAF prescriptions and actual EA best practices existing in industry remains negligibly small.
TOGAF and genuine EA best practices
The key components of TOGAF defining various aspects of an EA practice include the architecture development method (ADM), architecture content framework (ACF) and enterprise continuum. However, my extensive empirical research in organisations with established EA practices shows that none of these components proved useful in any real sense. Moreover, genuine industry best practices in various aspects of an EA practice hardly resemble corresponding TOGAF recommendations2,3,4.
For example, no organisations follow ADM steps, even if the use of TOGAF is declared. Instead, successful EA practices consist of multiple independent but related continuous decision-making processes involving different stakeholders at different organisational levels. The practical inapplicability of ADM for an organisation-wide planning is widely acknowledged among experienced architects and even engendered some curious and paradoxical opinions regarding TOGAF, e.g. that TOGAF is actually a solution architecture framework.
Likewise, no organisations align their EA artifacts to the architecture deliverables prescribed by ACF. Since ACF includes almost all imaginable types of EA artifacts, some of these EA artifacts can be certainly found in established EA practices and indeed proved useful in organisations, e.g. principles, but the overall correlation between the recommended set of ACF deliverables and the set of useful EA artifacts is arguably still close to zero. Put it simply, ACF at best provides only some vague resemblance of useful EA artifacts5,6.
Regarding the enterprise continuum the practical situation is much worse. I have never met an architect who even pronounced the phrase ‘enterprise continuum’, let alone actually used it in practice. Moreover, even the general idea of understanding enterprise architecture as the set of separate business, data, application, and technology architectures, as suggested by TOGAF, proved impractical since most helpful EA artifacts tend to cover multiple architecture domains simultaneously. Therefore, the fact of life is that successful EA practices differ from the TOGAF prescriptions in almost every aspect with the exception of general trivialities, e.g. some EA artifacts are indeed developed and used.
In summary, it can be fairly said that what is written in TOGAF and positioned as ‘best practices’ by The Open Group hardly overlaps with the genuine EA best practices that proved effective and work in leading organisations, even when they formally work under the TOGAF ‘signboard’2,3,4. This painfully obvious inconsistency between promoted and actual EA best practices naturally results from a more fundamental underlying problem.
The deeper underlying problem
The very planning approach embodied in TOGAF, where the planning of an entire organisation is conducted in a formal step-by-step manner and each step produces certain architectural deliverables which are later ‘consumed’ in subsequent steps, is actually 50-years-old. This approach was seemingly pioneered by the business systems planning (BSP) methodology in the end of the 1960s and since then repeated in different forms and variations in numerous derivative architecture planning methodologies including, among others, Method/1, information engineering, strategic data planning, enterprise architecture planning (EAP) and FEAF7,8,9.
All these methodologies advocated essentially the same rigid step-wise planning approach imitating traditional engineering methods. All these methodologies in some or the other form implied analysing an organisation and its business strategy, studying the current IT landscape, developing an ideal target architecture, and then producing a transition plan. All these methodologies required too much time and effort to produce the heaps of cryptic architectural diagrams that in most cases were eventually shelved as useless. All these methodologies enriched their consultants but impoverished their clients and discredited the very word ‘architecture’ in many organisations. All these methodologies were once very actively promoted, but then proved their historical ineffectiveness and rapidly disappeared without a trace. All these methodologies were unsuitable for an organisation-wide planning8,9.
Unfortunately, TOGAF can be considered only as yet another attempt to promote exactly the same planning approach that consistently proved ineffective over the last decades. For example, the recent announcement explicitly states that ‘a key part of the TOGAF standard is the method - the TOGAF Architecture Development Method (ADM) - for developing an enterprise architecture that addresses business needs’1. The entire long history of information systems planning efforts in organisations has clearly shown, however, that such a ‘wonderful’ enterprise architecture is simply impossible to create with any formal step-wise methods, while more organic, flexible, pragmatic and participative planning approaches should be followed instead10. In other words, a minutely planned, comprehensive architecture defining the whole organisation assumed by TOGAF is only an unachievable utopia.
Seemingly these expensive historical lessons still have not been learnt by the proponents of TOGAF. At the same time, the perseverance in promoting the planning approach that consistently proved impractical for decades and, as it is now absolutely clear, is flawed in principle and demonstrates that TOGAF is essentially trying to evolve against the common sense.
Evolving against the common sense
For many years by now we hear the same endless proclamations of The Open Group that TOGAF ‘is a proven enterprise architecture methodology and framework used by the world’s leading organisations’1, while all the actual evidence from these organisations clearly suggests otherwise. This fact essentially means that TOGAF is somehow evolving on its own for almost a quarter of a century without taking into account the empirical realities of information systems planning in any form. No learning happens at all, the feedback from practice is ignored, only the terminology is modernised to accommodate with the recent trends and buzzwords.
In its ‘improvements’ TOGAF simply neglects the reality altogether instead of adapting to it. It seems to exist inside its own parallel imaginary world completely disconnected from the real world of practice11. Even worse, TOGAF is actively trying to standardise the terminology for describing non-existing activities and documents, impose the planning approach that simply cannot work successfully and institutionalise proven worst practices through various EA courses and certifications. Such counterproductive efforts of The Open Group, which I consider to be at least unethical, naturally result in a substantial harm for the entire EA discipline and profession.
Here it is important to notice that The Open Group is seemingly in the business of selling certifications, rather than in the business of analysing actual best practices. This ‘business strategy’ of The Open Group partially explains the evident absurdness of the TOGAF phenomenon. On the one hand, the authors of TOGAF might not know genuine EA best practices since they apparently do not study and analyse them intentionally, but seem to only guess and speculate about them. On the other hand, The Open Group, in my view, even might not care about the critical gaps between TOGAF and these best practices since its primary goal is only to sell more certificates, rather than benefit the EA discipline. At the same time, The Open Group does a wonderful marketing job in promoting its standards, which seems to be the ‘core capability’ for its strategy.
The new version of the TOGAF standard has been released, but nothing has changed in the EA discipline for the better. For numerous trainers, many of which seemingly know little about enterprise architecture in a practical sense, TOGAF will remain a very good source of low-risk income, while for EA practitioners the value of TOGAF will probably remain purely symbolic, as it always was before.
Therefore, go spend around $3,000 on your TOGAF 9.2 training and certification, get your ‘TOGAF-certified’ badge, put it in your CV, then listen to elusive explanations and precautions of trainers and experts that TOGAF should not be ‘taken too literally’, and finally learn genuine EA best practices from experienced architects or some other limited evidence-based sources on enterprise architecture12, as if TOGAF never existed.
