The State Of EA In 2009 – A Disconnect Between Goals And Activities?

In September-October Forrester conducted its State of Enterprise Architecture survey – a broad look at EA in the context of the IT & business organization. We asked respondents questions ranging from where does the architecture function report, to the state of completeness of various architecture domains, the key technologies firms will be making significant architecture decisions about, and the degree of support for EA by various constituencies ranging from application developers to corporate business management. An upcoming series of reports from Forrester will discuss the survey results.

Last week, I conducted a webinar for the survey respondents – highlighting the results and discussing ‘what it means’. Webinar participants were very engaged in the discussion of the results – and with the broader question of the relationship and impact of EA to the larger business organization it is part of. 

Two figures that really stood out and generated discussion: 

We asked survey respondents – who were primarily architects in large enterprises – to identify the drivers for the EA program – essentially the mission and charter for the architecture organization.

 1 graphic

(Click the graphic for a full scale view)

The interesting thing about this is that the top drivers are predominately strategic and business-focused ones: enable better planning, improve business agility, enable better Business-IT alignment.  The more technical and tactical ones were generally lower in priority. This is a switch from architecture as it has been practiced, which focused on technology and application consolidation and application delivery projects. This data is supported by another question on ‘where does EA report?’ where the most common reporting relationships are to the CIO and to the head of strategy and planning, and a second question on ‘where does the architecture team spend its time’. 

But it is also clear that EA teams are struggling with how to act on these drivers. When asked about themes for the EA program for 2010, the results clustered around greater involvement with projects and project governance – which are good themes but not very related to the drivers of ‘Better strategic planning’,’ improved business agility’ or ‘improved business-IT alignment’.  And when we asked about the state of completeness of various architecture viewpoints, it’s clear that EA has made the most progress on the more technical and less business-focused architectures:

2 graphic
(Click the graphic for a full scale view)

The webinar participants saw this as an indicator of the gap between business-focused architecture, and ‘architecture for IT’. The preponderance of the webinar discussion was around the relationship between Business architecture and ‘the rest of Enterprise Architecture’. We all know that, if you take the word ‘enterprise’ for what it means, business architecture is part of the scope of EA – and should be the primary point of reference for all architecture activities. It’s a mystery how EA can  promote better strategic planning, business agility or improved alignment without a business architecture – you can only do a very imperfect job of connecting business and IT ‘pieces’ and likely a worse job of communicating the rationale and value of the connection.  

How would you interpret this information – does it indicate a gap between goals and activities? A reluctance of architects to move out of their technology roots? Or simply a factor of the ‘newness’ of this business focus?


Broken Link

The link does not work. Please provide a working one.

"Leveraging Architecture For Business Impact"

Link does not work

Hi Bob,
Please email me at and I will send you the webinar materials.

Senior Research Associate
Enterprise Architecture|Forrester Research

re: The State Of EA In 2009 – A Disconnect Between Goals And Ac

I'm of the belief that it's rather a lack of skill and savviness than a lack of resolve to bridge the business strategy - IT architecture gap.As architect-practitioners, we've always known that business architecture defines IT architecture and its minion. But we haven't done a very good job at defining, for example, what a "business capability architecture" for a bank (or high-tech company, government, non-profit, car manufacturing, etc.) looks like. This makes it more difficult to create a traceability between business strategy & business models to capability to processes all the way to use cases, test cases and IT product procurement and vendor management.What needs to be done first is recognize the urgency in ramping up our "business architecture" skills and savviness. This must obviously include active executive awareness & support for resources. Success or failure in this first step will either mean getting ahead of competition and assuredly reap the financial rewards or continuing in the "same old, same old" path of workarounds that oftentimes fail to produce the desired results. It's your choice.