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.

Defining 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).

Three dimensions of elasticity

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.

You can’t have one without the others

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.

Introducing elasticity into telecom

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.

CONTRIBUTED ARTICLE DISCLAIMER

Statements and opinions expressed in articles, reviews and other materials herein are those
of the authors; not the editors and publishers.

While every care has been taken in the selection of this information and reasonable attempts
are made to present up-to-date and accurate information, SDNCentral LLC cannot guarantee that
inaccuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage
or inconvenience caused as a result of any information within this site, or any information
accessed through this site.

The content of any third party web site which you link to from the SDNCentral site are entirely
out of the control of SDNCentral, and you proceed at your own risk. These links are provided
purely for your convenience. They do not imply SDNCentral's endorsement or association. The
copyright and any other intellectual property right and third party content belongs to the
author and/or other applicable third party.

SPONSORED

As VP Monetizer, Simo Isomäki is responsible for Go-To-Market activities and product management for Comptel Monetizer (tm), Comptel\'s integrated Policy Control and Online Charging solution together with partner activities aligned to the Monetizer GTM. He has held a variety of roles, including engineering, product management, business development and alliance management, within the organisation since 2000.

Comments

Congratulations for your article. I think that elasticity is a great challenge in SD-WANs. However, I have some questions. Where did you find this term Business Elasticity? Is it a common industrial term? Or is it an academic term? Did you have any reference for Business Elasticity definition?

When I wrote my piece, I did try to find a term used to describing businesses ability to anticipate and prepare for, respond to (in time) and manage scaling of the opportunities and threats that impact it, but didn’t find any so developed the term from Cloud Computing where we use ‘Elastic Scalability’ already.

Hope my term makes sense.

Making each domain and the whole business more elastic is a great challenge for sure but will enable it to cope with dents, bumps, stretches and shortcuts better.

I tried to find a term used to describing businesses ability to anticipate and prepare for, respond to (in time) and manage scaling of the opportunities and threats that impact the business, but didn’t find any when writing my article, so I developed the term used commonly in Cloud Computing where we use ‘Elastic Scalability’ already.

But I hope my term makes sense and is descriptive in my use.

I’m quite sure that there is a lot to work on regarding development of elasticity in many ‘software-driven’-domains, but I believe that bringing better and more comprehensive elasticity will help us cope with dents, bumps and stretches down the road better.

New Report: 2017 Network Virtualization Report

2017 Network Virtualization Report is available for free download. This FREE Report provides insight into the maturation of the overall network virtualization and SDN controller market, including the innovations in cloud networking

Free Report: 2017 Container and Cloud Orchestration

2017 Container and Cloud Orchestration Report is available for free download. This Free Report focuses on containers, cloud management, DevOps, orchestration, and automation solutions including key requirements to look for, and a sampling of vendor solutions available today.

Our Latest News In Your Mailbox!

To join our weekly or daily mailing list, and ensure that you are first to know about the latest in SDN and NFV sign up for the SDxCentral site and join our community!

About SDxCentral

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDNCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.