Gartner Blog Network

Hype about the EA Hype Cycle

by Philip Allega  |  August 11, 2010  |  5 Comments

Personally and professionally, it’s very exciting to see the blogosphere and twitterverse abuzz about the findings from Gartner’s Enterprise Architecture Hype Cycle, 2010I’m certain my excitement over this topic just adds to my credibility as a geek (if not, have a look at this video from Norway about .net vs. java development: 

Mike Walker chose to blog about this (see as did a a couple of others, including:

 I’ve also seen this picked up on other “news services” as well, including, &

Further recounts of the news that the Hype Cycle is in existence were also find in the morning’s scan:

The last one is in Dutch.  I love it when I see my name in print in languages I can’t read fluently.  I still have a copy of an article with my picture from Slovenia that quotes something I was talking about when I addressed every CIO in the country during a conference in 2003.  I don’t read Slovenian and can’t recall if I said anything worth remembering.  I do hope it all sounds good in Dutch.

Enterprise architecture “news” doesn’t always happen that quickly, so it’s interesting to see how, like the phone game I played as a child, the facts in our research can quickly become garbled in translation.  For those of you not familiar with the phone game, I quote wikipedia:

…the first player whispers a phrase or sentence to the next player. Each player successively whispers what that player believes he or she heard to the next. The last player announces the statement to the entire group. Errors typically accumulate in the retellings, so the statement announced by the last player differs significantly, and often amusingly, from the one uttered by the first.

To be fair, it’s not that terrible, but there are a few interesting observations about some different interpretations of key points.

EA and Strategy.  First off, I think it’s only fair to point out to a number of practitioners that, from the perspective of Gartner analysts, the META Group analysts Gartner acquired in 2005, and leaders in this field such as Larry DeBoever (most recently at EADirections) and Richard Buchanan (today at Gartner) – EA is the bridge between strategy and implementation.  As such, when strategy is absent or when EA value is proven, EA practitioners do find themselves engaged in the development of strategy and have done so for many years (see some of the examples I mentioned in a recent blog: 

It is, partially, for this lack of clarity as to the relationships between EA and Strategy (recognizing that, sometimes, EA is Strategy) that we placed EA coming just out the trough of disillusionment.   Furthermore, when we look at the extended value proposition of leaders in IT and EA we see that their roles take on more than we have traditionally assumed that they would be capable of doing for their organization.

This continued misunderstanding that EA programs have little to do with business strategy was echoed in Adraina Grigoriu’s critique of Gartner’s EA Hype Cycle, 2010 (see, when he expressed some surprise that EA architects might be involved in developing strategy for their company.

If you don’t believe Gartner when we say that this happens, perhaps the 2006 book by Ross, Weill, and Robertson may help show further instances where this has been happening since 2006, and earlier: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.

The Overall Positioning of EA.  EA as a concept has been around for more than 20 years, since John Zachmann introduced it in the “IBM Systems Journal,” vol. 26, no. 3, 1987. IBM Publication G321-5298, but the discipline is not yet mature. At the time the concept was introduced, many organizations were experiencing difficulty managing their IT plants, as technology began to evolve from a back-office support function to a business-critical capability. Starting in the 1990s, enterprises began to introduce EA disciplines into their IT organizations as they tried to come to grips with the increased complexity of IT and the changing nature of the IT organization’s relationship to the business. EA has had a rocky ride. As we point out in “So You Think You’re Doing Enterprise Architecture?“, many EA teams are doing things, under the banner of EA, which are really not EA. Common examples of this include:

  • Omitting the business context step
  • Starting with comprehensive documentation of the current state
  • Adopting a framework, then producing every artifact in the framework without analyzing which artifacts will deliver business value and address the strategic needs of the organization.
  • Focusing on solving tactical problems and never having time to devote to the strategic issues

The overall maturity of EA by practitioners is adolescent.  Strong examples of successful practitioners do exist, delivering value to their business with EA; however, many more struggle with the basic steps to delivering a successful EA program.  As market hype concerning alternatives to EA continues (see Business-Driven EA), we see EA practitioners focusing more upon EA value realization than upon creation of artifacts for their own sake. Market hype will begin to abate as a common understanding of enterprise architecture is attained (see EA Frameworks entry in our research). The winners will be the practitioners themselves and the organizations they serve as EA reaches the plateau of productivity in the next five to 10 years.

As a result of immaturity and misapplications of EA, compounded by the market of “my way to do EA is better than your way to do EA”, we still see EA just coming out of the trough of disillusionment (see

Isf EA business-driven or is “business-driven EA” something different? Going back to my comments on EA and Strategy, I think that it’s important to reflect upon the hype of the entry we entitled “business-driven EA”.  We noted that this will be obsolete before it ever hits the plateau (see the graphic here: 

Gartner’s definition for many years, and that of META Group’s before, begins with:

Enterprise architecture is the process of translating business vision and strategy into effective enterprise change…

As we stated in our research,  “Business-driven EA” is a term used by pundits, vendors, consultancies and practitioners who seek to differentiate themselves by redefining enterprise architecture as a new discipline that is more aligned with the business and to differentiate themselves from misperceptions of the long-held definition of EA.  Many advocate the development of a “business architecture” as if it were a new concept and thus struggle to clarify their distinction beyond a desire to add fear, uncertainty and doubt concerning the work of enterprise architects.

Enterprise architects have been observed to use the term “business-driven EA” as a way to:

  • Garner business interest in EA
  • Relaunch limited enterprise technical architecture (ETA) efforts to focus more broadly on the business context, enterprise information architecture (EIA), enterprise solution architecture (ESA) and enterprise business architecture (EBA)
  • Relaunch a failed EA program that had not translated business vision and strategy into effective enterprise change

 Enterprise architecture (when properly practiced) has always been “business-driven.” As organizations mature in their understanding of EA, realizing that it has always been based on business context, enterprise architecture will evolve out of the Trough of Disillusionment. As this happens, we believe the use of the term “business-driven EA” will wain into obsolescence.

Tom Graves recent blog (see seems to believe that Gartner”…‘discovered’ business-oriented architecture somewhen in the past couple of years”; this just shows that we must not have been that good in communicating our message about what EA is, and has been, to Tom (sorry, Tom). 

Tom  noted that Gabriel Mortno, of Microsoft’s internal Enterprise Strategic Planning unit, posted a blog (see on what Gabriel described as a ‘breakthrough’ in enterprise-architecture, “A Breakthrough: Maturing EA to be a Catalyst to Transform the Company“.   As Tom noted, this should have been no surprise to those who have always known that EA must be linked to the business; but, Tom missed the point that we see “business-driven EA” as not making it to the plateau of productivity because, to be curt, savvy practitioners are already recognizing the EA has ALWAYS BEEN business-driven and didn’t need a new qualifier.  He makes that point that he sees EA coming up the slope of enlightenment and we, too, see EA coming out of the trough (see 

As I have seen it over my past 20 years in EA, I see the following progression of EA that our Hype Cycle confirmed and exposed the following progression:

1980-1990s: Architecting for IT
2000s: Architecting for the Business
2010s: Architecting for the Extended Enterprise

So, leaders have been seeing EA applied to the four walls of the business for some time and those further out in front are applying this to the extended enterprise of their business ecosystem.  This is beyond where most are and why some of those profiles just entering the hype cycle seem foreign, and out of place, to many practitiioners.  There’s more of this to be explored in our research over the coming year. 

I hope that this further engages discussions in the “hype” over the “hype cycle” for EA in 2010.  Overall, it has been very exciting to engage in this online dialogue concerning Gartner’s EA Hype Cycle, 2010.

Category: enterprise-architecture  hype-cycle  

Philip Allega
Research VP
12 years at Gartner
27 years IT industry

Philip Allega is a research vice president responsible for teaching, coaching and critiquing Gartner's clients to help them realize the value of enterprise architecture as a strategic discipline. Read Full Bio

Thoughts on Hype about the EA Hype Cycle

  1. Tom Graves says:

    Hi Philip – many thanks for the links to my posts on the Microsoft ‘breakthrough’ and ‘hoist by their own petard’ – much appreciated. 🙂

    Okay, so I’m probably just Obtuse Mr Grumpy, but I must admit I hadn’t seen much from Gartner before about business-oriented architecture. I’d seen plenty in much the same vein as TOGAF – i.e. a ‘business-architecture’ which in essence is ‘anything not-IT that might affect IT’, but nothing much that talked about ‘the architecture of the business as business’, which might in some cases not touch IT at all. But then I’m not a Gartner subscriber as yet – sorry, I’s just a working-grunt, I can’t afford it! 🙂 – so I guess I haven’t seen it because it’s in the subscriber-only material?

    I was most interested to see that your progression:

    1980-1990s: Architecting for IT
    2000s: Architecting for the Business
    2010s: Architecting for the Extended Enterprise

    I suspect that may be a bit optimistic, though, because it’s been clear that most of the folks at the various EA conferences I’ve been to over the past few years (including the recent Gartner one in London) are still firmly in the ‘Architecting for IT’ phase. The Open Group only just started explicitly adding the ‘Architecting for the Business’ theme to their conferences late last year, but it’s still very much focused on EA as “the enabler to IT as the enabler to the business” – in other words, still IT-oriented rather than business-oriented. And I’ve yet to find more than a handful of EA people who even _understand_ the difference between ‘the business’ and ‘the enterprise’, let alone build it into their practice.

    So at a guess I’d say that although the periods in your progression are correct for the very earliest adopters, for the mainstream they’re perhaps at least a decade too early in each case? I must admit I hope not, because all of my own work is focussed on the ‘extended-enterprise’ scope – but it does still feel that there’s a long way still to go before we can break EA free at last from the dead weight of IT-centrism.

    Thanks again, anyway.

  2. Philip Allega says:


    I am very appreciative of your comments because they are making me seriously look back at our research, our events, and our years of (possibly) missing the mark with our messaging. As an analyst at META Group, acquired by Gartner in 2005, I recall the transition from what we once called EWTA (enterprisewide technical architecture) to EA (enterprise architecture) that encompassed business, information, technical and (then) application, maturing to solution by 2001, viewpoints. Even under EWTA we made a lot of noise, perhaps mostly unheeded, about the fact that this is all about the business. As we transitioned to EA, the EBA (enterprise business architecture) viewpoint was codified from observations of leading clients. From that day forward, we have seen the business the critical element moving forward. From my vantage point, it’s just now being much more well known; yet, also from my viewpoint, sometimes conflated and misunderstood as to which part is driving which part. Let me share the Gartner definition (source: 2005) that’s been around for awhile:

    Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution. The scope of the EA includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.

    Nowhere in there do we (Gartner) advocate only “Architecting for IT”. I will concede, however, that this is only what many CAN ACHIEVE at this moment in time. It’s not to say that it’s wrong, but that it’s a reality for the majority of practitioners. I will go further and concur that many practitioners wonder why they should even care about the business, let alone what comprises the enterprise. Those that are in this state of wonder typically fail. I’m fortunate to hold the corporate memory of a number of organizations who started, stopped, and started EA efforts many times for just these reasons.

    Could we be early, and optimistic, with such a progression? Most likely. The start of a new generation isn’t always well recognized until you’re steeped in it. When we began publishing work around EBA in the late 1990’s many thought we had lost our mind. Still, years later, I continue to run across many EA programs who have yet to make that explcit connection to their business strategy and future direction (we call this the “business context”), let alone do any work on “business architecture” as part of an overall EA effort.

    In short, our long standing position is that every viewpoint of EA should be preceded by, and dependent upon, a “business context” package (vision, anchor model, principles). “Business architeture” is just a viewpoint of EA. “Technical architecture” is also a viewpoint of EA. Viewpoints can be done independently, but we advice that all be linked to “business context”.

    Should EA “lose its IT-centricism”? There are 2 large camps with different opinions. Let’s look at 2 very public camps:

    CAEAP (Center for the Advancement of the Enterprise Architecture Profession). This group is very clear that EA is its own thing, separate from IT. There are, and I’m just guesstimating (note: for those not familiar with this english word, it’s a guess + estimating mashup) here, around 2 or 3,000 members.

    IASA The International Association of Software Architects. For this group, EA is strongly rooted in IT. There are, again I’m guesstimating here, about 70,000 members.

    This is instructive because there are some strong polar belief systems about what EA is, and for whom it is done. I, like you, have seen this applied to solve a myriad of challenges. In a call this morning, the challenge concerned providing consistent advice to an outsourced application development team in order to maintain future agility in light of a desired future state described by the business. In a call one week ago, the use of EA was upon business operating model integration. In the former example, EA is applied by IT professionals for a specific IT situation. In the latter, this use of EA was by people outside the IT function who wouldn’t consider themselves as “IT people” but as “business people”. Both used EA for different aims. Both were right.

    Let me return to your concern that you’re early days because of your focus on the extended enterprise. I say GOOD. And, I say “welcome to the club”. When such things are in infancy you probably won’t be too surprised to discover that there are a lot of serious people who can pay for other serious people to engage in these activities. Indeed, if we look at our London EA Summit that you mentioned, roughly 50% were “newbies”, 25% were “intermediates” and another 25% were “advanced” (note: these are my own labels and not Gartner labels) who are already focusing upon the extended enterprise. I’m certain you’ll recall Rene Doursat’s (see talk about complex systems as well. There’s a lot to do in the emerging areas of EA and, although not everyone, a lot of serious folks already there.

    I wouldn’t be discouraged by IT-centrism. I, personally, feel it’s more important to recognize how one will apply EA, for what purpose, and for whom. There’s a lot on offer. It’s not, in my humble estimation, inevitable that EA will leave IT behind forever. It is more likely that its uses will become more diverse, as will its practitioners. It will be fun to observe and share the changes as they come.

  3. Tom Graves says:


    Many thanks for the clarification re the history of Gartner’s/META’s engagement with business-architecture – I sit corrected, and duly apologise. 🙂

    Thanks also for the reiteration of Gartner’s definition of EA. I would have a few quibbles (of course!) but would otherwise strongly concur: the scope of ‘enterprise architecture’ must literally cover the whole of the enterprise (including where it extends beyond the organisation itself), and it must be able to cover everything and everything within that scope. We may well work in only one area at a time (such as IT), but need to be aware of the implications across the whole (i.e. ‘holistic’).

    There’s a crucial difference, though, between IT-orientation and IT-centrism. I have no qualms or concerns about EA being IT-oriented – in other words placing much if not most of its focus on IT issues – and as you say, that’s where most people start (and need to start), because that’s where their most urgent architectural issues reside. But IT-centrism is a different matter: it places IT _as the centre_ of the architecture, its sole reason to exist – and that attitude will all but guarantee architectural failure, especially in the longer term. TOGAF, for example, is still IT-centric: the actual end-focus of its ADM (Architecture Development Method) is technology-infrastructure (Phase D), and all of its descriptions of implementations (Phases E-G) presume an IT-based project. (FEAF is similar in its IT-centrism; DoDAF/MoDAF are not, but to me start too low, taking enterprise-strategy as a ‘given’ rather than something in which EA should and must be actively engaged.)

    As people at last start to break out of IT, I’m seeing exactly the same mistake being repeated at the business-level: where before we had IT-centrism, we now start to have business-centrism. The problem is not the area of focus (IT or business or security or process or whatever); the problem is the assumption that there is a single centre around which everything else revolves. Creating a single centre also inherently creates opposition between that centre and ‘everything else’ – hence TOGAF’s usage of ‘business-architecture’ as a near-random dumping-ground for ‘everything not-IT that might impact on IT’. Hence also the dreaded ‘IT/business alignment’ chasm, which is largely _caused_ by IT-centrism.

    In short, _there can be no single centre in an enterprise-architecture_: everywhere and nowhere is ‘the centre’, all at the same time.

    “When such things are in infancy you probably won’t be too surprised to discover that there are a lot of serious people who can pay for other serious people to engage in these activities”, you say. I don’t know if you’re being sarcastic there, but that’s not been my experience… 🙁 (Or did you accidentally miss a “not” there, as in “there are _not_ a lot of serious people who can [or will] pay” for this kind of early-stage work?) To be frank, I would be very surprised indeed, because in the past half-decade I’ve seen very little evidence that many ‘serious people’ are taking this seriously at all, and certainly not to the level of paying for it (though I have had one group who’ve repeatedly asked _me_ to pay _them_ serious money for the ‘privilege’ of correcting the fundamental flaws in their proprietary architecture-models…). Most of my EA colleagues who work at the whole-enterprise level are in much the same boat: we can get by well enough, tidying up the mess after the usual IT-centric architecture-disasters, but it doesn’t allow us to do the work that would _prevent_ those disasters in the first place – and down at the coalface, to be honest, it’s _not_ “fun to observe and share the changes as they come”, because mostly they don’t. Anything that you-plural can do to help those much-needed changes to come along sooner would be much appreciated… 😐

    Thanks again, anyway – definitely do appreciate that you at least do treat these issues with the serious concern that they deserve.

  4. […] This post was mentioned on Twitter by Tom Graves, Philip Allega. Philip Allega said: Blog: Hype about the EA Hype Cycle #entarch #enterprisearchitecture #GartnerEA […]

  5. Philip Allega says:

    Thanks, Tom. I appreciate your delineation between orientation and centrism. It’s a fine, but important, distinction. I agree with the points you make about some of the other well-known EA approaches/frameworks.

    Perhaps it is due to my current role at Gartner that I am priveleged to speak with a lot of companies engaged in extended enterprise efforts and that I recognize that these are household names in the Global 500. Aerospace and defence are typical entities engaged in extended enterprise work as are a lot of large financial services related companies. As operation technology and information technology (OT and IT) blend in telecommunications and other industries, the need for extended enterprise understanding, and undertakings, increases. Kristian Steenstrup (see is a colleague from Brisbane who leads our research concerning the OT and IT combination and resulting implications.

    I do agree that your observations about the world of EA, at large, does not change that rapidly; yet, change is happening. From my perspective as an analyst, my “fun” does come from working with and observing those who are the leading and bleeding edge as well as the maturation of such practices over time. If we mark the “birth” of EA at Zachman’s 1987 article, we’re only 23 years old. How good does it feel to be 23 again?

    How did it feel to be 23? I will not name and shame a particular soon-to-turn 22 year old, but my observations are that he has had successes and setbacks and is still rooted in some ways of looking at the world that are not to his advantage or helpful to others around him who want to help him. Yet, there are other young adults at his age who are much more mature and are already making their mark on the world. He may take a little more time, and it may be later rather than sooner by the looks of things, but I have faith that it will come out well in the end. At times, I look at the state of EA in much the same way.

    All said, I feel that I am a pragmatist, a realist if you will, with a tweak more of optimism than pessimism. Perhaps I should put that as a disclaimer?

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.