… but maybe some parts of the network should be.

What the heck am I talking about? Actually, when you remove the fluff, I’m talking about optimizing the network – striking a long term, cost-advantaged balance between CapEx and OpEx. Which is another way of saying that, sometimes, spending a little more money now saves you lots more money over time.

Here’s an example I’ve been working with for an SP lately. They have multiple data centers, where their subscriber traffic is supported. Subscriber numbers are growing, and the use per subscriber is also growing. They need to add capacity, but not necessarily evenly.

Some subscribers still use older network access devices, and need more supporting services from the operators’ network. Most newer network access devices, however, use very little from the SP and simply want to get to the Internet. The result of the subscriber growth plus subscriber usage growth plus device evolution means the SP needs to both add capacity – lots of capacity – and rethink the network design at the same time.

A problem with adding capacity in the network is that, unless proportionate capacity is incremented everywhere, the design has now changed – maybe a little, maybe a lot, most likely somewhere between those two extremes. As a result, every capacity add must be engineered from scratch, because things keep changing. Of course, if keeping the current proportionality of resources is important (so your design doesn’t fundamentally change), you’d have to create unnecessary capacity in those network elements which users are evolving away from, but hey – your design would stay the same.

Unfortunately, that’s like hitting every golf shot with a driver, when maybe sometimes you need a wedge – or a putter. The problem, to continue the metaphor, is when you’ve put yourself in the game with only one club in your bag. Suppose you could have a bag with – what an idea!! – different clubs for different sizes of golf problems?

How about different “modules” of network capacity for different network needs? Isn’t that sort of like having a driver for long shots, a wedge for lifted shots, and a putter for those close-controlled shots on the green? It’s true you’d winding up spending more money for three clubs than you spent for only one … but your golf game would be a lot better.

If your network needs to grow faster than you can keep redesigning it, maybe it’s time to accept a little higher CapEx to create modules/zones/sectors which are designed as drop-in units. It’s not quite plug-and-play, but pre-engineered, standardized modules will be faster to deploy. The savings in design, review, redesign, catching up with what’s changed since the last design, and now fitting in a custom addition … just may add up to an OpEx reduction that exceeds the CapEx increment.

Not to mention that increasing capacity as fast as you need just might reduce churn. Wouldn’t that be nice?