So you think you can predict the future? Future proof. Future proof. Future proof. It's almost a mantra in the IT world. Everyone is preaching it. Everyone is doing it.
And hardware manufacturers love it. It guarantees larger sales, right now. And as long as customers continue to do it, it will guarantee larger sales tomorrow, too.
The thing is, while it works like a dream as a sales improvement tool for the hardware manufacturers, it doesn't generally work for the customer, except over the short term. In fact, I'd go so far as to say it's usually throwing money away on scalability that will never be used.
Part of Go Communications' work is in the decommissioning of existing network infrastructure, usually to make way for new systems. A while back I was involved in the decommissioning of a truly enormous network in a secret underground bunker somewhere in the South of England.
It was all a bit James Bond. There were metal detectors and a personal search on the way in, and a truly enormous switch and server farm inside. I had never seen an installation of such a size, before or since.
The decommissioning was required because the hosting company had overspent and gone out of business as a result. The customer it was designed for had required that the specification be future proof not just for a couple of years but for ten.
The waste was horrifying. Rack upon rack of slots sat empty in every single chassis and the cabinets were twice the height they needed to be.
The crippling cost of the over-specified hardware and the ongoing costs of wasted electricity – larger cabinets need larger power supplies and more cooling – must have been contributors to the hosting company's cash-flow problems. They could even have been the issues that brought it down.
Future proofing sounds good. And I'm the first to agree that, over the short term – a year or two – it is a vitally important issue in most network designs. Trying to cater for a future more than a couple of years away, though, is almost guaranteed to fail, because it's virtually certain that the network will have been replaced before the expansion space has been used.
Coming back to the secret bunker switch and server farm, specifying for ten years ahead seems, on the face of it, to be prudent – especially with a large, mission-critical network. Let's give it a moment's cold, hard thought, though.
Ten years ago, we were all using Windows 98. The original iPod was still more than two years away. Digital cameras were an exciting new thing. And the average desktop PC was less powerful than today's iPhones.
With technological advancement accelerating, the changes over the next ten years are likely to be even more dramatic than those over the last. Predicting developments in technology is a bit like forecasting the weather: if you know what you're doing, you can make reasonable guesses as to what's around the corner, but try doing it any distance into the future and you're setting yourself up for a fall.
When you're specifying network systems, a fall means expense, and usually a lot of it.
Specifying one or two extra slots for extra cards in the next few months or year is usually prudent, but it's almost always wasteful going any further. While there is always the chance that additional slots over and above those one or two may be needed, designing for that small possibility is rarely wise: it ties up money that could be much more effectively deployed elsewhere on the network today.
Specify what you need today, with a little expansion room for the immediate future. If you do find at some point in the future that you need extra network resources over and above those for which you've allowed space, then re-specifying the appropriate parts of the network to cater for those resources can usually be done economically, especially as the general trend of hardware prices is always downwards rather than upwards.