Alignment may well be a process - a journey rather than a destination. But Neil still hasn't explained why it's a good thing. He merely provides a number of reformulations, apparently in the hope that I might understand one of them:
"bringing IT closer to how the business works ... synchronise movement ... minimise latency between movement ... synchronise the process of change management ... bringing these two timetables closer together"I understand this agenda perfectly well; I just don't agree with it. If two processes have a different natural timetable, I believe it is usually better to manage them asynchronously than synchronously. Much of the work I've done in SOA and the service-based business is about the structural implications of loose coupling, and the opportunities for business transformation. (Perhaps some people haven't got this yet.)
I take my cue from the notion of Shearing Layers (>Wikipedia) pioneered in architecture by Frank Duffy and Stewart Brand. The basic insight here is that tightly coupled artefacts (and this includes such socio-technical systems as the Business-IT relationship) cannot cope flexibly with change - they shear themselves apart.
Clearly the CIO has to be able to respond to events in the business world (for example, a major take-over) as well as events in the IT world (for example, a major platform upgrade). But with a properly decoupled and layered IT architecture, these responses can be mobilized independently of one another. Surely that's better than being forced to align?