Refactoring the Future….

Most of my career has been spent in infrastructure and I guess infrastructure related technologies is the thing which really interests me professionally but I have spent time working as a developer, leading a development team managing the transition to agile development and more recently, as well as running a storage team, I also manage an Integration and Test team; this has hopefully led me into becoming more rounded professionally. And I think we as Infrastructure techies have a lot to learn from our colleagues in development; they’ve probably got more to learn from us but we can learn something from them.

Recently I’ve been wondering if Infrastructure could be treated more as an application; something that is more dynamic and less static than it is traditionally. Can an Infrastructure be Agile? And can it be managed in an Agile manner? The received wisdom is almost certainly, no! More outages are caused by change in infrastructure than any other cause;’  ‘if aint broke, don’t fix it’ is not actually a bad way to go but is that necessarily the case?

One of the big changes that Cloud brings should be that applications are engineered to cater for failure and change; an application should be able to move, replicate, grow, shrink and be resilient in spite of infrastructure.

Now this could mean that we could deploy, change and improve infrastructure a lot more rapidly; refresh becomes a constant task and not something which needs a special project to do, tuning and maintenance become routine and not scary. We have an infrastructure that is being constantly refactored in the same way that good developers refactor code; we fix kludges and workarounds, no longer living with them because we are fearful of the consequences of changing them.

Yet we also need discipline not to change for change’s sake; anyone who has run an Agile team will tell you about the importance of eg0-less developers (an oxymoron if there ever was) but you can run into the problem where more time is spent refactoring than adding value. I am not convinced that we will have this problem initially in Infrastructure, the culture of  ‘if aint broke, don’t fix it’ is heavily ingrained.

Refactoring is a small part of Agile but it is something that we can learn from in our Infrastructure domains. However there is a big problem; vendors don’t really like change and they throw all kinds of obstacles in your way, like interoperability matrices and the like. They really don’t like the idea of incremental change; they want big change where they can bill big tickets and big services.

I think that vendors and service providers who are going to win big are those who can deal with incremental change and improvements; those who are reliant on big changes and refresh cycles may well struggle as we move to a more dynamic model. I include internal IT suppliers in  this as well; the big change is a cultural change to accept that change is constant and good.