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?

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.