Via Steve Jones, here’s another story that perfectly encapsulates the power of realising that a partnership approach between IT and business can drive real improvements in the return that you get from IT investment.

In short: Steve’s associate (working in IT) found that a project he was responsible for wasn’t getting the business buy-in that was required to make the project a success. So he cancelled it.

This “support” thing cuts both ways. We all know about how IT has to support business needs – but when you create a contract, both sides have obligations to fulfil. For too long, IT teams have let business teams get away with not keeping their own implicit obligations.

Perhaps one solution is to formalise business teams’ obligations more explicitly in “service contracts” when IT projects are created, or when big changes are requested. Has anyone done this in an internal IT context, or even an outsourced IT context? What did you find?


One of the the themes that came up time and time again in our interviews for the book was the importance of getting out of the mindset that the IT organisation is in existence to blindly serve requests from the business.

Neil M dealt with this one a little in his last post. And now from Mike Kavis and James Taylor, via the ever-smart Todd Biske, there’s another anecdote that further shores up this argument.

Yes, the IT organisation is there to serve the business. But serving doesn’t imply subservience. Quite often it means asking tough questions and working out the best way to say “no”.

Just saw this story, courtesy of my colleague Martin Atherton (co-worker of book authors Jon Collins and Dale Vile).

Martin asks: are these companies’ IT departments moving from being “suppliers” to “slaves”, or from “suppliers” to “integral parts of the business”?

My hunch is the former, given the retail sector’s on-off successes with IT investments and programmes generally. And if this is the case, it might prove disastrous.

Even if you outsource all your IT provision, you can’t do without a technically-literate IT governance and oversight function that also understands business goals, strategies and priorities. Without that capability in-house you’re opening yourself up to the selfish (and why shouldn’t they be?) agendas of suppliers, whose interests are unlikely to be naturally 100% aligned with yours.

It might be, of course, that the IT Directors in question didn’t fulfil that function – that they were largely IT support managers. In that case, it’s probably fine to outsource their roles. But it only makes sense to do so in the context of a larger picture that involves hiring into a new governance and oversight position.

James Tarbell has this great post, responding to one of the people we’ve interviewed in our research, James McGovern. James T calls out some very insightful similarities between architects and gardeners.

My favourite: “You can get hung up on understanding the big latin words/technical terms or focus on requirements to achieve a result”.

I’ve long been a fan of Nick Malik’s blog – and indeed it was his blog that led me to ask him if he’d be happy to be interviewed for the book.

In this post Nick nails quite a few aspects of IT governance, and explains how they fit in the context of embarking on an SOA initiative.

Nick correctly calls out the dual roles of governance: not only in directing work so that things are “done right”; but also in directing work so that we “do the right things”. The former area is the one where IT departments are most comfortable: you can focus on getting things right while retaining a very internal IT perspective. Doing the latter and focusing on doing the right things requires another set of skills and commitments that are less familiar to most.

It’s easy to look at governance as Nick outlines it (and as many others do too) and say “hmm, this looks like a pretty heavyweight overhead to me. If I’m going to have to make significant extra investment in this governance stuff, how can I make the case for it?”

The key point here is that one of the things that makes IT governance “good” is fitness for purpose. Governance doesn’t have to entail masses of documentation, full-time headcount, onerous processes and big technology investments. As Nick implies, a key feature of governance work is agreeing a strategic destination and a set of navigation charts.

In this context, your focus shouldn’t be securing headcount and defining processes: it should be on securing agreements and commitments from people to work together.

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.

Next Page »