Where should the Enterprise Architecture function ‘sit’ in the Org Chart?

I was thinking about this after reading a Linkedin thread “Where should The Enterprise Architecture Practice within the corporate structure reside?” which discussed an article about the topic.

<UPDATE: I recently checked and found these old links were dead but found some similar discussion here, here, here and here

Summary and Proposition

A short but concise article by Vance King Saxbe explores how EA typically sits in either location 1) or 2) in the diagram below. Aspects of EA also sit in locations 3) – 6).

My commentary below on the article which is below the diagram suggests that where EA sits has moved between 1) and 2) and offers some reasons and also suggests that 3) – 6) are where Agile Enterprise Architecture is emerging.

Its taken a while but evolved and mature thinking on EA is now pretty universal that within IT is not really the right place. The linked article above by Paulo Falcao above gives some good reasons for why EA should not be viewed as a ‘function’ within IT

• Overemphasis on Technology, Not Strategy When EA reports to IT, the focus often shifts disproportionately toward technology rather than aligning technology with business objectives. This approach risks neglecting EA’s core mission: bridging the gap between strategy and execution.

• Conflict of Interests IT departments typically prioritize operational needs and delivery timelines. This short-term focus can clash with EA’s broader mandate of creating sustainable, long-term architectural strategies.

• Reduced Business Influence Sitting under IT often minimizes EA’s visibility and influence within other business units, limiting its ability to shape cross-functional strategies effectively.

• Risk of Becoming “Order Takers” An EA team under IT leadership can sometimes be relegated to a support role, responding to technical needs rather than proactively driving organizational transformation.

I think where EA ‘sits’ is a real dilemma and does not have a single correct answer and changes over time – I have seen this

Its also a reflection of the changing role of EA, in particular within large enterprises, and increasing mainstream/corporate acceptance of previously ‘niche’ IT practices such as Agile that challenge the fabric of traditional EA ‘top-down’ views and ‘waterfall’ and ‘gate’ based project and transformation methods. We all accept now that ‘fail fast’ can drive innovation and time to market. Tell that two an Architect who is working on version 25 of his ArchiMate diagrams to document the POC or MVP and calling out ‘compromise’ and ‘risk’ in every design forum and status meeting.

To me in a number of large organisations I have worked at the trajectory of where EA ‘sits’ within the Org Chart tends to follow a path very similar to the Gartner Hype Cycle. During the ‘peak of inflated expectations’ EA is positioned with corporate strategy as understanding and managing an organisation’s Enterprise Architecture is seen as a key enabler for achieving its business vision (i.e. use EA frameworks to ensure business plans are understood and their execution is managed concurrently across all domains). In reality in most of the larger enterprises I have worked in EA simply just moved up the food chain and became a ‘strategy support’ activity. With its most visible face into IT as ‘governance’ and policing of ‘adherence’ to published largely conceptual models. Over time the prominence of Solution Architecture then re-emerges as it is really the vehicle for execution, and is a devolved activity largely IT focused and ‘within’ projects where the only interaction across projects, or with ‘Corporate’ EA are the obligatory and largely under-valued ‘EA review and EA compliance steps’. And this view does not even reflect the C-level staff count issues if EA if EA is positioned higher up the chain highlighted in the post already where EA is seen as an expensive staff overhead – and where the EA budget is an even more visible aspect of the where does EA sit challenge.

So where should EA sit?

For organisations that have been through this journey reaching the ‘plateau of productivity’ means striking a balance – Solution Architecture within and across projects evolves to be more like ‘Agile Enterprise Architecture’ (see Scott Ambler etc) working with a reduced sized corporate EA function that primarily assists the strategic planning group by adding value on ‘what’ to document and model to best ensure the vision can be executed and then measured. The Corporate EA role needs to work with rather than ‘govern’ the devolved ‘Agile Enterprise Architecture’ function.