Monday, November 15, 2010

I've been thinking more and more about why Simplicity is hard and I've come up with a few key things that Simple IT needs to be and how you judge Simple IT. Part of this links back to the SOA anti-patterns and it comes down to a few key questions

Can your IT estate be described as a series of discreet elements

Can each of these elements be easily maintained within their business context

Can each of these elements be simply described

This comes down to that old principle of "one thing well", in IT this doesn't mean low level services, it can be very high-level services, for instance putting in an HR system which does everything that the business wants in a vanilla package solution would meet all of these requirements. HR is in fact a single discreet element and its delivered via a single package, this matches how the business wants to manage that area.

So the building blocks of a simple IT strategy are not all of the same size, they are of the size that makes sense within the context of the business architecture

In a simple IT approach the focus is always on the on going evolution of the IT estate in line with business strategy and not based on a single project delivery. The way IT is set up tends to focus on the The Ivory Tower of Implementation Optimism v Long term viability which drives against simplicity and towards complexity.

So the focus of simple IT is to value

Long term evolution over short term expediency

Architectural clarity over coding efficiency

Business Strategy over IT strategy

Simple IT is also to

Drive IT costs in-line with their business value

Drive IT technology selection in-line with the business value

Create clear upgrade boundaries between different business value areas

Manage IT based on the different business value areas

The point here is that simple IT is not actually about making a single project faster, its about making the 2nd project and its support faster and more efficient. This means having control and direction into which the right approaches can be used, Agile where its about value creation and reaction, package where its about standardisation and SaaS where its about utility.

This is about having the business architecture, having the heatmap, and then aligning IT clearly into those areas.

Simple IT is hard, it requires control, it requires vision and it requires focus.