This comes from Leo de Sousa, an EA in Australian Higher Education who asked the Shared Insights EA Network to provide ideas about what EA trends they were seeing.

My take: leading organisations get EA and are figuring out how to link it to other important IT governance-related practices, but this is still a sparse community with demand for skills outstripping supply and not enough consistent “good practice” guidance out there. Grass-roots communities (like the aforementioned EA Network) are starting to help EA practitioners build a critical mass of “stuff that works”, though.

If I had any more time, I’d think about writing a followup to The Technology Garden, focused specifically on Enterprise Architecture practice in the real world…


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”.

I just came across Steve Jones’ post, Nodding dog alignment – the perils of aligning to people not business, in which he points out the sad reality that many IT organisations which believe they are aligned with the business aren’t actually delivering value. Why? Because they are aligning with the wrong things. Instead of focusing on business goals they focus on the individuals who have those goals with the result that:

the IT department just turns into a nodding dog and says yes to all requests made by anyone who can claim to be a business person. This is what leads to hideously configured packages because “the business said so” and to a fragmented IT estate and ever increasing IT spend for ever decreasing business value.

This issue is something that came out strongly in the research for our book (the perfect Christmas gift 😉 )and is reflected in two of our principles for effective IT-business alignment.

First, the IT organisation must establish a peer relationship with the business, rather than a supplier-customer relationship which Steve flags. It’s about shared accountability and responsibility and, in much the same way as a P2P network, involves dynamic interactions controlled through a set of protocols (or governance policies and procedures) in accordance with objectives and constraints (business goals, budgets, people in the IT-business alignment case; file downloads, network bandwidth and latency in the P2P case).

Second, it’s not about working on the basis of “he who shouts loudest”. Rather it’s about working towards a set of goals and objectives that are coordinated and agreed by the combined business and IT team.

As Steve so aptly puts it:

Business alignment isn’t about people alignment.

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.