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…

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?

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

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.

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.

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

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.

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.

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“