Making Strategy Work with Enterprise Architecture

23 December 2010

If you want to execute a business strategy then you’ll need an Enterprise Architecture function.

Enterprise architecture (EA) is about change – strategic change in an enterprise.

But not exogenous change – reactive change forced on the enterprise by outside exigencies – although that sort of change and those external forces may be taken into account. No, enterprise architecture is about endogenous change – directed, planned, strategy-driven change within the enterprise.

Enterprise architecture is about describing the desired future state of the enterprise and plotting a course towards that position in enterprise ‘state space’ known as the Target Architecture.

Recently there was a long and fruitful discussion on LinkedIn, between practitioners, of the proposition that “EA is not the glue between IT and “The Business”. EA is the glue between Strategy and Execution.”. Aside from the questions of whether “glue” is the right metaphor and the possible mereological fallacy of considering IT and “The Business” as separate entities in need of glueing, the proposition is also something of a false dichotomy.

The two aspects – Business-IT Alignment and Strategy Formulation-Strategy Execution are neither mutually exclusive nor independent from each other. So, as with many false dichotomies, the ‘correct’ answer is “both and neither”. But in terms of importance to the business or enterprise, being the glue between strategy formulation and its (presumably) successful execution is critical whereas getting IT aligned to the business needs is only a very useful and desirable outcome.

But the question this immediately raises is what exactly it means to be the glue between strategy formulation and strategy execution – which despite the lengthy discussion was not really answered.

How exactly does EA help strategies get executed – and executed well?

The standard ‘authorities’  [like “Enterprise Architecture as Strategy” by Ross, Weill and Robertson] actually don’t help all that much – offering general aphorisms like “First build your foundation for execution” and “Define your operating model”. Well, yes – but what does that mean and how does that get your strategy off the drawing board and put into effect?

In recent weeks I’ve been reading a somewhat ‘non-standard’ EA textbook, by a professor at Wharton Business School which addresses exactly this problem.

That book is “Making Strategy Work – Leading Effective Execution and Change” – and even though Dr. Hrebiniak never mentions the term, I would contend it is a book about Enterprise Architecture because it is about change, strategic change, in an enterprise.

Towards the end of chapter six he provides a very plausible answer to the question of how strategy execution is glued to strategy formulation in the form of a “Strategy Review Process – Planning, Execution, and Controls” [Figure 6.2]. See

In essence the process is an adaptive closed-loop feedback control (socio-technical) system that seeks to bring actual business performance towards that demanded by the ‘control’ input of strategic objectives through the following six steps:

1) Strategy Formulation – including resource capabilities and constraints, strategy and goals, industry forces and competitor analysis

2) Strategy Planning and Execution – including meeting the demands of strategy, [changing] organisational structure, Integration Requirements and Methods, Information Requirements, Hiring and Training People [Developing organisational skills and knowledge] and Appropriate Incentives

3) Review of Actual Business Performance – including emergent deviations from the planned strategy

4) Cause-Effect Analysis and Learning

5) Feedback / Change – including changes in strategy and changes in the capabilities of the organisation

6) Continuation and Follow-Through – including integration and review of strategy changes, resource (re)allocations and agreement on business performance objectives and measures

Where step 6 feeds back and leads back into step 1, closing the loop. Dr. Hrebiniak asserts “Every organisation must fashion its own strategy review process. It’s not a luxury but a necessity. It’s that important. …It supports execution”. I’m not sure how much the professor is hyping his own process – but if the strategy review process is the enterprise’s only formal link between formulation and execution, I‘d say there is little hyperbole – it really is that important. Execution is delivery, formulation is just structured aspiration.

So what has this to do with Enterprise Architecture?

Step 1 is strategy formulation – and it is the usual process of matching internal and external analyses of the enterprise for the future. Enterprise Architecture is *the* key contributor to the internal analysis – the resource capabilities and constraints are (should be) described by the EA model, the strategy and goals are the EA (model) Motivation Decomposition.

Step 2 is essentially the strategic planning of change – including people, processes and technology wrapped up as  organisational ‘capabilities’, or business architecture, information architecture, functionality (or ‘applications’) architecture and technology architecture. Many would regard this as definitively Enterprise Architecture. Not only that, the changes are described by the Target and Current Enterprise Architectures (models) and a number of intermediate Transitional Architectures and the differences between them. The planning process is the EA gap analysis process.

This is EA as a strategic planning for change function for the enterprise.

In step 3 – the intended target or transitional enterprise architecture (model) provides the baseline against which actual achievement can be objectively measured.

In step 4 – well, correlation is not causation; it is actually remarkably difficult to determine the contributory causative factors to any particular outcome or effect. EA has a role in assessing how much of the (change in) business performance achieved is down to what changes in the enterprise.

This is EA as the basis for impact analysis of change. Did investing in that software development really cause the increase in sales of snow-shovels or was it that the weather was more inclement than most people anticipated this year?

Step 5 brings in capabilities again. EA should describe the relationship between the organisational capabilities and the resulting business performance. EA is there to help assess what returns investing in particular capabilities is likely to achieve – and therefore find the optimum investment pattern.

And step 6 is again into describing the architecture of the enterprise as it is now and how we want it to be – and how we are going to measure the progress towards the ‘to-be’.

From this perspective, Enterprise Architecture can be seen to suffuse the entire Strategy Review Process, making it systematic, rigorous and cohesive – like a resin glue.

So if you are the CEO of a company that does not have an Enterprise Architecture function or a Strategy Review Process, presumably you think all you need do is formulate and promulgate a strategy and the execution will take care of itself?


Me neither – I think you need some glue.

by Ian Glossop, Enterprise Architect.


4 Responses to “Making Strategy Work with Enterprise Architecture”

  1. […] Making Strategy Work with Enterprise Architecture « on Enterprise … […]

  2. wikitect Says:

    I agree with the sentiment in terms of EA needing to be glueware but struggle with an ‘EA Function’ as the last thing we need is a new functional silo.

    In essence EA is one of several tools or techniques that can be used to integrate parts of an enterprise. In order for it to be successful, however, you need collaboration and all parts of the organisation should play a part in populating the architecture description of the enterprise. Done this way the parts of the architecture description are owned by the information sources / experts and will therefore likely be more accurate, more timely and importantly, maintained.

    For all the above reasons EA is a disruptive technology – perhaps all the more so because it is currently controlled and run typically by the IT parts of an enterprise.

    The articulation of the enterprise goals and enduring capabilities to support these ought to be being done by that part of the company – commercial folks not the current priesthood with ‘architect’ in the job title.

    How do you get these people to want to collaborate and to add their part of the architecture description? As importantly how do you get the current architects in the IT function to let others contribute (they might see it as a loss of control or ‘turf’) such that it isn’t run as an over-the-wall post box?

    If EA is for everyone’s benefit then everyone has to have an equal part and equal access. This doesn’t seem to happen and I suspect it’s as much the problem with people inside the current discipline as those outside. For it to be able to integrate disparate disciplines you need to start breaking down some of the traditional barriers.

    • The mission of Enterprise Architecture is to break down silos not to perpetuate them. Enterprise Architecture by definition should be working for the benefit of the enterprise as a whole, which means it should not be part of IT or conversely part of the other business areas but ideally should be working directly for the CEO and the executive team.

      Often people get hung up on word such as ‘architect’ and deliberately misunderstand the role of an Enterprise Architect as a purely IT role which it isn’t. Enterprise Architecture isn’t the same as IT Architecture, so it’s not a matter of getting IT architects to let the business ‘contribute’ – that’s the wrong way of thinking.
      It is important to think of Enterprise Architecture as to do with making business strategy work and not as something to do with software design.

  3. Ian Glossop Says:


    EA is a disruptive technology – ‘technology’ in the little-used sense of ‘know-how’ or ‘knowledge’ or ‘way-of-thinking’. It is disruptive in at least two ways 1) it changes the relationships between the ‘traditional’ functional divisions in a company and 2)it changes the way people think about their organisational units’ roles in the enterprise.

    As Adrian says – an holistic, open, collaborative, cross-functional, anti-silo approach is a key feature of effective EA efforts. As you say collaboration is key and the last thing we need is another ‘priesthood’. It is important that the EA model is widely shared and bought into across the enterprise – something ownership of parts of the model can foster. Two big challenges are 1) changing the mode of thinking, prevalent in IT, that IT is somehow separate from the business and 2) overcoming the distrust of IT in the business that as built up over the years.

    This may be a culture change for the enterprise and is much more difficult to do than any technological change or organisational re-design. Chapter 8 of Larry Hrebiniak’s book is entitled “Managing Culture and Culture Change”. The introduction of a collaborative, extended EA function into the enterprise (one not confined to the remit of the IT Department or the technical aspects of the enterprise) may be a part of that change agenda – and may feature in the strategy.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: