In this post Andrew McAfee at Harvard Business School has a detailed discussion about the impact of IT. He concludes with the following question:

What’s the correct way to think about IT’s effects going forward: diminished competitive significance because the technology innovations are being absorbed, or sustained significance because IT has moved industries into permanently higher rates of process innovation and replication?

Our research for the book provides strong evidence for the latter and that’s ultimately why we set out to write it in the first place.

Once the IT organisation has got its own house in order and gained the trust of the business, the route to effective IT-business alignment – understand and reflect the business; engage the business; and drive the business – and the enterprise architecture process that supports it is all about harnessing IT capabilities (people, technologies and practices) to support process innovation. That’s why, as we explain, the concept of business processes offers the most appropriate basis for analysing business activities and informing technology, investment and sourcing decisions.


McKinsey has just published the results of a survey of 72 senior IT executives in the US (free subscription required for the full article) which investigated IT strategy maturity. The majority of respondents believe that they are successfully aligning IT strategy with business needs. What’s particularly gratifying, in light of the principles we outline in the book, is that 83% agree that their IT strategy is developed through collaboration with the business, with 79% saying that their IT plans are shaped by close integration of their IT and business strategies.

The research also shows that almost 90% are at least somewhat effective when it comes to getting the basics right and managing IT infrastructure and 85% when it comes to managing IT as a business-driven portfolio and focusing IT where it can add most business value, further endorsing our principles.

All in the garden (sorry!) isn’t quite so rosey when it comes to harnessing technology innovation. This isn’t too surprising. In the book we outline a chain of four goals for sustainable IT-business alignment and it’s only in the last link in that chain where IT is in a position to drive the business “through business innovation based on understanding of IT and business capabilities and constraints and how they relate to one another

Excuse the blatant promotional post but I thought I would mention that you can now purchase The Technology Garden at

I was talking earlier on to one of the people we interviewed for the book, outlining the main findings and getting some feedback. One of the main topics we focused on was the nature of Enterprise Architecture, and what characterises EA work “done right”.

The person I was talking to relayed a conversation they had with a client recently that was interested in becoming “Zachman compliant”. The client was under the impression that if they could do this, it would be a stamp of approval that they were “doing EA well”.

I’ve seen things like this myself from time to time, and it’s worrying. Organisations set up EA teams that are naturally inclined to focus on modelling technology landscapes and so on, and that focus more on the outputs (models) than on how they arrive at those outputs.

The problem here is that the process of EA is at least as important as the outputs. “EA done right” is as much about how you conduct EA work, as it is about what you produce. EA done right involves architects engaging in truly two-way discussions with stakeholders in IT and business – sharing ideas, learning and also communicating what’s been learned so far, so everyone understands more. EA done wrong involves architects sucking ideas from the brains of “users” and not giving anything back. The architects learn more but very quickly you end up with a fundamental disconnection between business and IT and you’re no closer to developing a common language.

And this brings us back to Zachman – because although ZIFA goes further than just promoting the Zachman framework (it’s starting to promote the importance of developing a good process) there are an awful lot of people out there who just focus on the framework. And although the framework is  a great way of categorizing models and knowledge, it says nothing about how that knowledge is arrived at.

If you just focus on getting good at filling in the cells in the Zachman framework, that’s no guarantee at all you will be doing EA in a way that helps IT or the business.

A couple of weeks ago I was party to another event, this time hosted by IBM. At short notice I was asked to facilitate a session on defining services, which was interesting in the extreme as it very quickly became clear in the earlier sessions that there was no clear definition of what a service was – particularly as there were two types of people in the room – business analysts and technical architects.

So, I decided to take a different tack. Rather than trying to fix a definition of service, I thought we would go round the room and ask what characterised a “good” service. Here’s what we came up with:

• Value – the benefits of accessing a service should outweigh its costs
• Reusability – it should be possible to access the service repeatedly, with the same level of interaction and service quality
• Meaningfulness – it should be possible to describe the service in clear, relevant terms
• Autonomy – the service should be cohesive, i.e. clearly bounded
• Independence – the service should also minimise dependencies with other services
• Contract – the service should offer its own guarantees in terms of what it delivers, and how: such terms should be subject to prior acceptance by the service user.
• Uniqueness – the service should minimise overlaps with other services

With hindsight, there is possibly some honing that could be done with the above list – the difference between “Autonomy” and “Independence” for example, is not all that clear. What was interesting however, was that even as the debate raged around what a service should look like, there was relatively little controversy about what separated the wheat from the chaff. For organisations looking to develop their own service strategies, this would appear to be a good place to start.

Here is the audio of what we hope will be a series of podcasts with CIOs who’ve instigated work to improve IT-business alignment in their organisations. The interview is between us two Neils (me and Macehiter) and New Zealand-resident Peter Burggraaff, until recently the CIO of NZ retail chain Farmers Trading Company. Peter talks to us in this 31’34” podcast episode about his initiative at Farmers and the outcomes he achieved.

In the podcast Peter explains that Farmers was in a situation where IT cost was way too high, and although the IT organisation was doing some things well (particularly managing operational services) it wasn’t seen as a real contributor of business value as Farmers looked to put some big business changes in place. He goes on to explain how he started to turn this situation around and built a solid and trusted relationship with Farmers business management. Thanks Peter!

If you’d like to get involved in this programme of podcasts don’t hesitate to let us know.

Nick Malik (who we interviewed for the book) and Michael Platt, who are both coincidentally from Microsoft, have recently posted some thoughts on enterprise architecture, which align well with our research into the topic for the book.

First to Nick, who discusses the extent to which stakeholders understand the value of EA. You should read the whole thing but I wanted to call out this:

Some may feel that the value of architecture is to design the solutions that the company needs to consume (build the solutions right!). The real value, in my mind, is to help make sure that the money spent on IT is building agility and not complexity (build the right solutions).

I cannot emphasize this enough, and as we share the message with our friends and collegues, we need to be clear about this point.

Enterprise Architecture is not about “building solutions right”

Enterprise Architecture is about “building the right solutions”

Absolutely! EA is first and foremost about understanding the business, as he goes on to point out:

The real value for IT is in providing strategic information, opportunities, and success to the company as a whole. That means that IT figures out what projects need to be worked on, in partnership with the business. IT works not as a servant but as a knowledgable and capable business partner, suggesting business opportunities that the business may not have thought of, and taking it to the business and executive management for funding.

Which leads me on too Michael’s post commenting on a paper assessing the applicability of existing EA frameworks (Zachman, TOGAF et al) to two common scenarios:

a company which had a fixed and inflexible set of stovepiped application that were stopping progress (IT is a problem scenario) and a company that wanted to expand its business using IT (IT is an enabler).

The upshot of the paper is that the existing EA frameworks didn’t really address either scenario, which is interesting in its own right. However, what resonated with me particularly in the light of Nick’s post was Michael’s comment (and he may be overstating the case) on why in the second scenario:

In the “IT is an enabler” scenario none of the EA methodologies even started to look at what the company wanted to archive [achieve] and so failed at the first post.

If enterprise architecture processes and teams aren’t considering what the organisation is trying to achieve, how can they move beyond “building solutions right” to “building the right solutions”?