Monday, July 10, 2006

Business IT Alignment 2

Neil Ward-Dutton thinks I've missed something fundamental in my previous post on Business IT Alignment, and tells me "It's the Process Stupid".

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?


  1. I think this difference of opinion has to do with two things, Richard:

    1) the definition you choose to use. My (admittedly not very big) dictionary offers a range of options for "to align": among which is "to move or be adjusted into proper relationship or orientation"; and "to ally with an argument or cause". That's what we think about;

    2) the level of abstraction that you focus on. For us, the main focus is at the level of organisational, cultural and managerial concerns. From reading your blog entries, your view seems to be more at the level of software/solution architecture.

    With those differences in mind, hopefully you'll see how I can absolutely agree with you about dealing with "shearing layers". Business and technology do change at different rates - so from our perspective, a "business aligned" (ugh) solution architecture approach is absolutely reliant on isolating domains which change at different rates.

  2. The notion of alignment is a trap. Thanks for keeping the blogosphere honest...