Positioning EA in the enterprise

[A great LinkedIn conversation with Bala Somasundaram came back to the question of how we describe the role of enterprise-architecture – especially in large organisations – and how we differentiate it from other enterprise-wide disciplines such as strategy, quality, change-management, knowledge-management and the like. Bala seemed to like my reply 🙂 so it seems it might be worth making it more publicly available here, as follows…]

The real justification for EA is its role in enhancing enterprise effectiveness, and in managing intended and unintended consequences of opportunity and risk. We do this through that specific combination of ‘enterprise‘ and ‘architecture‘.

‘Enterprise‘ is about maintaining a whole-of-enterprise perspective: being able to switch from big-picture (extended-horizontal, such as whole-of-supply-chain, or extended-vertical, such as whole-of-market, including prospects, non-clients and anti-clients) to fine-detail (interconnections between individual systems or individual services/processes).

‘Architecture‘ is about mapping and understanding interdependencies (what connects with what, what needs to connect with what, and so on) at every level and every domain of the enterprise, and linking each of those parts back to the purpose of the whole. Architecture faces towards the big-picture view, design faces towards the fine-detail view; everyone will do some of both, but enterprise-architects would, or should, emphasise especially the whole-of-enterprise view.

This gives us a knowledge-base about the dynamic interplay of structure and purpose within the enterprise, and tools and techniques to use (or help others use) that knowledge-base in system-design, process-design and the like.

We don’t do much strategy as such, but strategy won’t work without us. Part of our work also looks at future change in market, technology, culture and so on, hence much of that will.also feed into strategy and investment-decisions and the like.

We don’t do much risk-assessment or disaster-recovery planning as such, but they’ll depend on our knowledge-base and our disciplines of ‘follow the connections’.

We probably shouldn’t do much design as such: design is often best left to detail-specialists, whereas architects’ work is more about linking those specialists together to create a unified design that integrates with the whole.

We don’t implement change ourselves – that’s the role of projects and programme/portfolio-management – but we help ensure that each change contributes to overall effectiveness.

In a sense, enterprise-architecture is a special-case of knowledge-management: it deals with a specific class of knowledge (enterprise-wide interdependencies and choices), but also takes active steps to put that knowledge to practical use.

So overall, EA has a specific business role with specific boundaries to its authority and responsibilities. Like many other ‘pervasive services’ such as quality, security and knowledge-management, its business-value can be hard to measure, because much of the value shows up only at the level of the whole – but it’s also clear that it does have real business value. One of the best ways to describe that value is through the lens of ‘enterprise effectiveness’ – an emphasis on the balance between efficiency, reliability, ‘elegance’, appropriateness (‘on purpose’) and whole-of-enterprise integration.

Hope this helps, anyway. 🙂

(Many thanks again to Bala Somasundaram for the conversation that started this thread.)