The Archetypes of EA

This past summer, Forrester conducted a series of in-depth interviews of architects to further our understanding of their roles:  how they saw the role in the context of their organizations, how they are evaluated by senior management, their key success imperatives and their information needs.  We undertook this not just as research to publish, but also to inform how we support individuals in the EA role.

The most interesting realization from these interviews is how architects segment themselves based on the expectations of the larger organization:  how focused they are at a project or strategy scope, and how oriented they are towards business or technology.

Architects, and the architect function are project-focused when their most important value was to project success or technology selection.  When defining, communicating and guiding strategy was the expectation, architects are more strategy-focused.  Similarly, in some organizations, architects are viewed as technology experts or direction-setters, while in other organizations, they are more closely associated with business-oriented planning.  When you combine these two dimensions of scope and orientation, you get four types of enterprise architecture functions – which we labeled as “the Archetypes of EA”.


This is similar to the “Archetypes of IT” which Forrester described in 2006 in a series of reports: the ‘Solid Utility’, ‘Trusted Supplier’ and ‘Partner Player’ archetypes.  The significance of these IT archetypes is that they are based on the expectations of IT by the larger business organization – not on how IT chose to view itself.  IT is successful only in the context of these expectations.  An IT organization can’t be a ‘Partner Player’ if business expects only a ‘Solid Utility’ – and if business expects a ‘Partner Player’ – IT better execute as a partner or risk marginalization (and probably getting a new CIO).

What’s the significance of these EA archetypes?
First, a lot of EA thought – by analyst firms, other thought leaders and practitioners, is that EA teams must be excellent at all of these quadrants – and it’s the fault of the EA team if they aren’t being strategic or business-focused enough.  The reality is EA teams need to be excellent at the archetype that reflects the IT and business expectations – and they can never be excellent at those archetypes where the larger organization doesn’t want or value their contribution.
Second, for EA teams who wish to contribute more in the strategy and/or business quadrants, they have to change expectations along with changing their practices.  EA teams will be successful at influencing business and IT strategy when the CIO and some business peers start looking for their input.  Changing expectations is a different task from learning strategy mapping or similar techniques.
Third, this archetype model is a great tool for fostering discussion with IT and business leaders.  As one reader of our first report said: ‘this is better than a maturity model because I can ask what the firm needs, instead of just talking about how good we are in an area’.     

We on the EA team at Forrester are also using this model to sharpen our role focus:

  • We’re deepening our research into Business and Information Architectures, and how firms can use them to address issues in strategy, alignment and change.
  • We in the EA team are expanding our focus on best practices for technology strategy and roadmaps.  This complements the coverage of other teams in Forrester on individual technology areas as part of their role focus.
  • Our coverage on the EA function, organization and value will be addressing the steps EA leaders can take to re-set business and IT expectations, and re-position their teams.

Tell me what you think -  Do you agree that this archetype view is valid and useful? Or is there a better model?  Do you have recommendations for our research focus?


re: The Archetypes of EA

I agree with the points made already and that including projects causes some conflict with what some EA's are trying to focus on. I wonder what would happen to your model if you changed your horizontal axis to Assurance and Strategy instead of Projects and Strategy.

re: The Archetypes of EA

I'm glad to see that Forrester's EA focus will look at some new areas of emphasis in 2010-- particularly on Roadmaps and Business Architecture.

I think that one of the major challenges around EA today is a set of mature practices for the Strategy elements-- both business and technology. Roadmaps are only one tool, and frankly they wind up typically being watered down powerpoints.

What's really needed from my perspective is more of a method to adopt product planning types of techniques to mature core business domains. As such, a business and architecture function can define owners of certain product lines (eg Sales & Marketing or Mobile) and further decompose specific products/processes/functions. Typical product maturity around new features, releases aligned to OS/DB versions as well as "beta" for immature or solutions (eg social networking pilots) are all conventions we're considering.

The critical success factor is a business champion to aid in prioritizing and budgeting for the product investments across many different target users (eg lines of business or regions).

Once these practices are in place, the governance aspects of EA ensure that the enterprise converges on common standards and invests in alignment to targeted reuse/simplication strategies becomes straightforward.

re: The Archetypes of EA

Hmm - I think you have sort of got some good points, but there is clarity that your diagram and words do not show.EA is all about strategic planning and then governance of change. As soon as you get into projects (the left half of your diagram) you are into solution and technical architecture. EA does exist in the left part but only from the point of view of governance.

re: The Archetypes of EA

I agree with Kevin. The EA community is struggling with how to really be relevant to the enterprise, and main question is how far this extends into business. There doesn't seem to be debate about whether EA should be enterprise-wide. An issue with that is how far EA should extend into understanding the ecosystem of the firm, which from can be seen as the sources and sinks of information from the enterprise viewpoint. I think an introduction of projects into this fundamental definition of scope will create a lot more heat than light.

re: The Archetypes of EA

I agree with both Kevin and Doug's viewpoints on this article. I think in this context it is important to define what a project really mean as it could imply different things to different people. The example provided in the top left quadrant is surely a solution architect's realm. but interestingly, the example in the bottom left quadrant is something I feel fits in EA's realms (and may not necessarily be done in project mode). The technology selection should be a job that typically should be an accountability of Enterprise Architects and I don't think it is necessarily done in a project mode but as part of technology standards management at an enterprise level.