Without a doubt, telecom’s biggest hot potato is network functions virtualization (NFV) and the software-defined network (SDN). Despite its promise, there are more questions than answers when it comes to NFV, and only a handful of leaders are stepping up to mould the concept into reality.

NFV, of course, represents a shift away from networks built on physical servers, cabled-together connections, and manual configurations. These static environments are limited by the capacity of each physical server, and enhancements are made slowly and at a substantial cost. NFV’s key benefit is drastically reduced costs that result from the replacement of physical boxes with software-only images run on common, shared compute platforms. Capacity that is free within the shared platform can be allocated dynamically to any of those “virtual boxes” per need, enabling scalable, cost-effective networks. In addition, you can chain virtual boxes together without physical wiring, making network changes easier to configure.

So, what’s missing from NFV deployments? One current shortcoming of NFV is its inability to deliver truly complete business elasticity. While NFV is undoubtedly a good thing for telecommunications and offers the potential for profound disruption within the industry, implementations must be supported by a few key capabilities so that operators can achieve full business elasticity.

The time and effort needed to change any system defines its elasticity. Truly elastic systems are easy to deploy, configure, run, upgrade, and change. Most operator configurations today are, at best, fairly rigid and require monumental effort to change, ultimately due to the design of the products, solutions, and systems deployed.

In most large systems, each integration forms a potential rigidity point, as specific requirements define exactly how each end of the integration interacts. Current telecom networks are a spaghetti of integrations, and thus rigidity constrains many NFV deployments. If changing your network means hours of programmatic coding, your design is not very elastic.

In addition, anyone who has done benchmarking or process improvements knows that many system changes simply move a bottleneck or cost benefit to a new place, creating minimal overall improvement. The key challenge in process re-engineering efforts is that, if you're not careful, you can speed a process in one place only to slow it elsewhere.

A complete model for business elasticity requires three dimensions: elastic scalability, elastic configuration, and elastic discovery/insight. NFV partly supports the model by enabling elastic scalability and, to a degree, elastic configuration in the form of dynamic chaining (although those boxes could still be rigidly configured, so NFV is only a partial solution for configuration).

With elastic scalability, you ensure the capacity to grow as needed. More often than not, opportunities to scale start small, are local, and may not be addressable when scaling capacity to the masses. A niche may later turn into something bigger, but elasticity offers the opportunity to address niches while they’re still small. Natural disasters, for example, demand a lot of network capacity and scalability in hard-hit areas, but not necessarily in less-affected ones.

With elastic configuration, you can rapidly add, edit, and remove configuration within systems to allow rapid response to new opportunities or threats. Elasticity is quite low throughout telecom, and a lot of momentum is lost because of rigidity. Most operator upgrades are trivial – e.g., to bandwidth speed or price – and occur only on a mass scale. Elastic configuration would allow individuals to configure with more variance and personalization.

Elastic discovery/insight refers to the ability to discover new insights and become aware of emerging opportunities and threats with enough time to respond. It helps you discover emerging, not-yet-mainstream trends as well as identify those that are fading into irrelevance. Such insight is important, as you can only react in time if you have made an observation quickly enough.

Why are all three dimensions needed?

If you have high elasticity in configuration but are low on insight, you may be the second or third runner-up in the race to a new opportunity. If you have high insight but low configurability, you may observe trends before anyone else but still fail to execute to capture the opportunity.

If you have high insight and high configurability, you can run at the speed of business, and if opportunities scale, elastic scalability will ensure smooth operations.

Let’s run the framework through a common real-life example: driving a car. At a macro level, we rely on a lot of insight to drive and don’t need exact, fixed plans and execution strategies to advance through our journey. With the benefit of navigation technology and traffic updates, we are able to optimize our journey for maximum efficiency, but if we lack the insight to react to immediate changes in our environment, we could drive straight into a traffic jam.

At a micro level, we continuously steer our vehicle to avoid bumps that we see in the street and take advantage of new shortcuts when we learn about them. The human capacity for elasticity and adaptability is an enormous asset in this system, even when the roads on which we drive are not elastically scalable to support new capacity.

With all three pieces in place, you could take the model one step further and rely on elastic discovery/insight to directly guide elastic configuration, achieving closed-loop automation with feedback control. In many other industries, manual process steps are eliminated and very large systems are built to support completely independent and self-contained automation. Is this too much of a dream for telecommunications? I think not. Implementing the three-dimensional framework for elasticity in telecom could be relatively easy within smaller systems and domains at first, offering the proof-point operators need to fully achieve business elasticity and take the promise of NFV one step further.