A comparison of the top four enterprise architecture frameworks

These frameworks allegedly offer the necessary guidance for practicing enterprise architecture and addressing the problem of business and IT alignment in organisations.

Existing EA frameworks are covered in many mainstream sources. These sources include, among others, a pretty well-known article of Roger Sessions presenting four leading EA frameworks, Zachman, TOGAF, FEA and Gartner, whose influence can be noticed even in the latest industry publications, as well as a rather famous book ‘How to Survive in the Jungle of Enterprise Architecture Frameworks’ discussing 14 EA frameworks¹.

Furthermore, the very genre of musing on frameworks is extremely popular among various EA writers. For example, the academic literature offers tens of papers devoted to analysing, comparing and formulating selection criteria for EA frameworks². Gartner alone issued nearly a dozen of several hundred dollars-worth reports with its advice on how to analyse, choose and deal with EA frameworks properly³. Local consulting companies and software tool vendors offer their own comparisons and framework selection guidelines as well.

At first glance, the current literature offers an exhaustive analysis of all existing EA frameworks from all imaginable perspectives. However, despite the abundance and variety of the available frameworks analyses, these analyses have one critically important feature in common: all these analyses are perfectly speculative in nature. Specifically, all of them assume that whatever is ‘promised’ by EA frameworks is true, i.e. represents genuine best practices and valid reference models that proved helpful in some organisations and can be beneficial to other companies willing to practice enterprise architecture. For this reason, all the extant analyses of EA frameworks essentially concentrate only on ample promises given by these frameworks and take their promises for granted, but never question them or analyse whether, or to what extent, these promises have actually been delivered.

So, what do we know about popular EA frameworks besides these speculations? While all the previous analyses compared only the claims and promises of EA frameworks (e.g. which frameworks propose more guidance on which aspects of an EA practice), this article compares their practical consequences and outcomes (e.g. whether EA frameworks in fact delivered on their promises and what their real value is). In particular, the article focuses on the four most widely known EA frameworks: the Zachman Framework, FEAF, DoDAF and TOGAF.

Zachman Framework

The Zachman Framework initially emerged in the 1980s as a two-dimensional 30-cell taxonomy for architectural descriptions⁴. Today, it is widely advertised as the fundamental structure or even ‘ontology’ for enterprise architecture, whose role in the EA discipline is equivalent to the role of the periodic table of elements in chemistry.

The framework was proposed by John Zachman, at that time a marketing specialist at IBM, as part of his attempts ‘merely to improve on the planning methodologies to follow BSP’^{5 (page xvi)} (BSP was one of the earlier IBM’s information systems planning methodologies that he promoted since the 1970s). The framework resulted from Zachman’s observations of similarities allegedly existing between architectural representations utilised in the manufacturing and construction industries. Namely, Zachman speculated that ‘an analogous set of architectural representations is likely to be produced during the process of building any complex engineering product, including an information system’^{4 (page 281)}. Although originally the framework was conceived for individual information systems, in the late 1990s it was readily ‘elevated’ to the enterprise level and repositioned as the framework for enterprise architecture, even without any noticeable modifications of its structure⁶.

The fundamental flaw in the underlying analogy between engineering products and information systems exploited by Zachman was spotted long ago, besides many other people, even by his colleagues from IBM⁷. Yet, Zachman continued to emphatically promote his framework and insistently inquired: ‘Why would anyone think that the descriptive representations for enterprises are going to be any different from the descriptive representations of anything else that has ever been created?’^{8 (page 41)} Moreover, he relentlessly argued for producing ‘excruciatingly’ detailed descriptions and even went further to guarantee that such formal, engineering-style drawings are necessary for organisations:

‘Some day, I guarantee you, you are going to wish you had every one of the models identified by the [Zachman Framework] made explicit, every one of them made explicit enterprise-wide, all the models integrated horizontally across every row, all the models integrated vertically down every column and all the models made explicit at excruciating levels of detail’^{9 (page 9)}

Of course, Zachman did not specify where his guarantees can be redeemed and did not risk his own dollars while disseminating these ideas. It is difficult to estimate now how many people have been perplexed by his prescriptions and how much money has been spent in vain in organisations globally in the attempts to develop ‘all the models made explicit at excruciating levels of detail’, as Zachman recommended. However, research reports from some organisations that acted in line with his advice indicate that their EA practices resulted in dramatic failures ‘with multimillion dollar consequences’^{10 (page 85)} and anecdotal evidence suggests that similar experiences were rather typical across the industry:

‘Most of us have heard John Zachman’s often-quoted remark: ‘Someday you are going to wish you had all these models made explicit, enterprise-wide, horizontally and vertically integrated, at an excruciating level of detail’. Taking this remark too literally has caused too many EA teams to lock themselves in their ivory towers, snowed under by hundreds of models that no one is able to keep up to date’^{11 (page 10)}

As a result of Zachman’s brilliant and persistent promotional efforts, what we have today is a purely symbolic taxonomy, which is claimed to be fundamental, but is apparently based on inappropriate and confusing assumptions, cannot classify real EA artifacts, has no demonstrated examples of its practical application, no use cases in organisations, no implications for EA practitioners and does not add any theoretical or practical value to the EA discipline, as discussed earlier. Besides that, contrary to the widespread beliefs, historically the Zachman Framework did not introduce the notion of architecture, was not the first architectural taxonomy and even did not coin the term ‘enterprise architecture’, as also reported earlier.

At the present moment, it would arguably be fair to say that the broad interest in the Zachman Framework has already faded away and within the next few years it is likely to be forgotten by the EA community due to its inexplicable practical utility. However, some architects still like the Zachman Framework because, unlike other EA frameworks, it is easy to use – ‘using it’ does not require studying extensive materials and does not imply doing anything in particular.

Federal Enterprise Architecture Framework (FEAF)

The Federal Enterprise Architecture Framework (FEAF) is a rather comprehensive EA guidance developed specifically for the U.S. Federal Government in the end of the 1990s¹². Rhetorically, FEAF was based on the pioneering ideas of John Zachman and Steven Spewak, who were regarded as ‘two of many recognised leaders in architecture conceptualisation and enterprise architecture planning’^{12 (page 19)}.

In reality, however, FEAF descends directly from the ancient information systems planning methodologies of the 1960s-1970s. For instance, FEAF leverages Spewak’s Enterprise Architecture Planning (EAP) methodology, which in turn ‘has its roots in IBM’s BSP’, as explicitly acknowledged by its author^{5 (page 53)}. Consequently, similarly to early architecture planning methodologies, FEAF is based on the naïve assumption that the long-term target state for the whole organisation can be defined by a dedicated group of planners, described in detail via numerous formal diagrams and relationship matrices and then implemented as planned.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

BSP and similar mechanistic planning methodologies proved impractical long before the development of FEAF¹³, ¹⁴, ¹⁵. Furthermore, even Steven Spewak himself admitted that ‘the vast majority of enterprises that undertake Enterprise Architecture Planning are not successful’^{5 (page 19)}. Unsurprisingly, FEAF failed as well, and failed spectacularly:

‘Enterprise architecture within the Federal Government hasn’t been working, and far more often than not hasn’t delivered useful results. Moreover, significant parts of the federal EA program have been complete and utter failures’^{16 (page 6)}

The outright fiasco of FEAF can be fairly considered to be the single most expensive documented failure of an EA initiative in the history:

‘Literally more than a billion dollars have been spent so far on enterprise architecture by the Federal Government, and much, if not most of it has been wasted’^{16 (page 52)}

Even worse, the very emergence of FEAF also represents an evident failure of logic and common sense: the planning approach that consistently proved ineffective earlier in multiple companies has been ‘scaled up’ to the federal level only to fail again with much greater losses. In light of the abundant previous negative research findings regarding formal architecture methodologies¹³, ¹⁴, ¹⁵, the failure of FEAF can be viewed as a natural, perfectly predictable and even the only possible outcome.

Today, FEAF arguably does not deserve any attention from the community of EA practitioners. It offers no reasonable guidance that can help anyone establish an EA practice, nothing of practical value, only some obscure pictures and a bunch of curious reference models the meaning of which was not really understood even by architects working for the U.S. Government¹⁶.

Department of Defense Architecture Framework (DoDAF)

The Department of Defense Architecture Framework (DoDAF) emerged in the mid-2000s as a common approach to architecture for the U.S. Department of Defense (DoD) and represents an evolution of the earlier C4ISR framework born in the 1990s¹⁷. DoDAF defines the views that should be covered in architecture, specific products that should be created to describe them and the steps that should be followed to develop these deliverables.

Conceptually, DoDAF embodies essentially the same ideas and beliefs as FEAF inspired by early architecture planning methodologies, e.g. once you produce a comprehensive architecture depicting the desired future, it will naturally help you make better decisions (somehow). However, besides analogous findings regarding other architecture methodologies¹³, ¹⁴, ¹⁵, the naivety of these beliefs was noticed previously even specifically in relation to the C4ISR framework, DoDAF’s direct predecessor:

‘The prevailing belief was that if one built the architecture, the owners and operators would come. History has shown, however, that few organisations actually ‘operationalised’ the architecture – and the owners and operators did not come. The inherent flaw from the beginning was the lack of a standard framework or methodology that allows the architecture to be inserted into the decision making process’^{18 (page 2)}

As in the case of FEAF discussed above, these earlier observations regarding the pitfalls of architecture methodologies did not stop DoD from repeating exactly the same mistakes again on a wider scale. In particular, DoD intended to create a comprehensive architecture for its business mission area consisting of almost the full set of 26 products prescribed by DoDAF^{19 (pages 40-41)} (this case, by the way, clearly demonstrates that EA frameworks were originally designed to be implemented literally ‘as is’, not merely as flexible toolkits for architecture, as many people would argue today). However, the official report to congressional committees concluded that the developed architecture deliverables turned out largely useless:

‘The products that it has produced do not provide sufficient content and utility to effectively guide and constrain ongoing and planned systems investments. As a result, despite spending almost 4 years and about $318 million, DoD does not have an effective architecture program’^{19 (page ii)}

Precisely the same conclusions have also been echoed several years later in another official report:

‘Even though DoD has spent more than 10 years and at least $379 million on its business enterprise architecture, its ability to use the architecture to guide and constrain investments has been limited’^{20 (page ii)}

Therefore, instead of establishing a successful EA program in DoD, DoDAF consumed nearly $400 million and generated only the heaps of arcane documents unsuitable for decision-making purposes, in a way similar to FEAF¹⁶. As one of the DoD reports neatly summarised, ‘hundreds of millions of dollars had been spent on a business enterprise architecture (BEA) that had limited use’^{21 (pages 1-2)}.

Currently, DoDAF can arguably be helpful, at best, as a loose catalogue of diverse models some of which occasionally might be found useful or inspiring by experienced architects, and predominantly in the realm of solution architecture. No sane human beings should ever consider the prescriptions of DoDAF seriously as an actionable guidance for their EA practice, as DoD did.

The Open Group Architecture Framework (TOGAF)

The Open Group Architecture Framework (TOGAF) was created by The Open Group in the mid-1990s from the materials of the earlier TAFIM framework²², which itself was based on some earlier models initiated in the mid-1980s. TOGAF provides an end-to-end, holistic guidance for an EA practice including the steps and sub-steps required to develop architecture (ADM), a comprehensive collection of artifacts and deliverables necessary to describe architecture (ACF), governance and maturity models, as well as many other diverse recommendations²². Presently, TOGAF has achieved the status of the most popular EA framework and is regarded by many as a de facto industry standard in enterprise architecture.

Similarly to FEAF and DoDAF, TOGAF follows fundamentally the same mechanistic step-by-step logic as all the previous architecture planning methodologies (e.g. BSP, Method/1 and Information Engineering) that discredited themselves long ago and, therefore, offers essentially nothing new and simply cannot work successfully in practice²³. For instance, exactly the same well-known problems associated with all formal architecture methodologies had been reported earlier regarding TAFIM and ultimately led to its retirement (and thus to the emergence of TOGAF):

‘TAFIM most certainly required a large investment of both time and money. [...] The elapsed time required to produce the architecture makes it close to obsolete before completion. [...] The end result is normally incomprehensible to a business-oriented audience and is harder to trace to the business strategy. [...] Perhaps in part due to some of these flaws, the TAFIM was abruptly cancelled’^{24 (page 79)}

Those architects following ADM steps more or less closely and developing at least half of all the deliverables prescribed by ACF will inevitably face analogous problems, experience disappointment and eventually abandon TOGAF as a practical guidance:

‘After an intensive phase of familiarisation and an initial workshop, where TOGAF was presented to the involved stakeholders, we decided: Thanks, too complicated for us’^{25 (page 14)}

However, as reported earlier²³, ²⁶, currently the absurdness of TOGAF is already widely acknowledged among seasoned EA practitioners. Now, in virtually all cases, TOGAF is viewed merely as a label and ‘used’ purely declaratively - its prescriptions are simply ignored and other, more reasonable planning approaches are followed instead.

It is arguably impossible to assess with any precision how much money had been wasted in the past by organisations trying to adopt TOGAF’s ‘best practices’, but the stories of EA teams that aligned their activities with TOGAF, produced heaps of shelfware and have been eliminated or reorganised are plentiful in every corner of the planet. Taking into account that TOGAF is aggressively promoted worldwide with varying intensity for at least two decades as a proven EA standard and buttressed by the global infrastructure of consultancies, experts and other commercially motivated supporters, these expenditures can be truly daunting and vastly outnumber the aggregate toll of all other EA frameworks. Besides that, a standalone multimillion-dollar industry has also formed around TOGAF courses, training and certifications that yields nothing but symbolic badges.

Although the overall step-wise planning approach recommended by TOGAF is unfit for real organisations, it would be fair to say that some separate terms, notions, ideas and artifacts mentioned in the 500-pages-long TOGAF manual can certainly be found helpful in practice. However, to be able to ‘decipher’ this manual, distinguish a few good ideas from numerous not-so-​good ones and determine their applicability in concrete situations, architects should fully realise how EA practices actually work. From this perspective, TOGAF can be ironical viewed as a ‘trash can’ of random EA-related ideas, where something useful can occasionally be found, but only by mature EA practitioners who already know all of that, understand what to look for and how to interpret it properly.

Summary of the top enterprise architecture frameworks

The discussion above presented a realistic view and analysis of the four most prominent EA frameworks from a pragmatic, practical standpoint. A comparison of the top four EA frameworks is briefly summarised in Figure 1.

Figure 1. A Comparison of the Top Four Enterprise Architecture Frameworks (click to view larger image)

So, which one of them is worse? As it is evident from the comparison provided in Figure 1, none of the top four EA frameworks is substantiated by anyone’s genuine best practices; all of them represent merely renovated replicas of some earlier architecture planning methodologies that were once advertised by consultancies but proved impractical and vanished, except for the Zachman Framework, which represents a superficial attempt to improve on one of those methodologies. All these frameworks also advocate simplistic ideas inspired by classic engineering-style thinking manifested in formalised documentation or step-by-step processes unsuitable for real organisations with their dynamism, social nature and enormous complexity. Each of the famous EA frameworks also caused noticeable damage to organisations trying to use them in the form of wasted money and efforts, even when these frameworks were tailored specifically for concrete organisations, as in the case of FEAF and DoDAF. Needless to say, each of them promised infinitely more than it has actually delivered, if anything at all. For this reason, it would be fair to conclude that these EA frameworks are all worse.

Even though none of the top four EA frameworks proved useful, each of them is still actively advertised as some form of ‘best practice’ by its salesmen: the Zachman Framework has ‘profound significance in putting definition around enterprise architecture’, FEAF and DoDAF have ‘proven to have immediate applicability’ and ‘are very powerful frameworks’, while TOGAF is ‘a proven enterprise architecture methodology’ and ‘the most prominent and reliable enterprise architecture standard’. Generally, the entire stream of EA frameworks is driven by commercial interests, rather than common sense. Numerous consultancies, vendors and gurus tout EA frameworks for their own pecuniary purposes, regardless of their detrimental effects on the EA discipline.

Overall, the phenomenon of EA frameworks most certainly is a grand management fad that was shamefully swallowed by the EA community. Moreover, it arguably represents one of the most ridiculous fads in the history of management, or ‘the fad of the century’, which proposed so few new ideas relative to the previously existing approaches, wasted so much money in organisations globally, brought so little value to practice and, taking all that into account, is still not unanimously acknowledged as a fad. Even worse, instead of being rejected outright as impractical and forgotten, EA frameworks slowly get institutionalised into the fabric of society in the form of university courses and prerequisite certifications for architects, perpetuating themselves and causing permanent cognitive dissonance between rhetoric and reality throughout the EA community.

As it requires a rich imagination, unshakeable faith or strong commercial motivation to find any resemblance between how successful EA practices actually work and what popular EA frameworks prescribe, these frameworks do not deserve to be discussed seriously, but only to be derided and thrown out. Do not try to implement EA frameworks and, please, beware of the next fads!