The maturity of any technology and its adoption into mainstream use typically follows a common pattern – so much so that we can often use the most perplexing question being asked in the industry as a proxy for such progress. I call my graph the Sleepless Nights Measure…

For technology-driven innovation the basic premise is that as time goes on, the complex of questions being asked shifts from being technical to business related and then to operations related. Of course, as time passes and new innovations arise, the business viability comes into question once again. It is fairly easy to map any new technology along this adoption timeline.

Looking at SDN along these lines, it is pretty clear from all available industry surveys and analyst reports that the main questions being asked in the industry around SDN have evolved from technical feasibility to operational scalability. For NFV, the progress is even faster, though it has been a late comer to the technology alphabet soup.

SDN when viewed through the lens of a data center solution seems relatively contained in its scope and defined in its operational role. However, when it comes to telecom networks (or carrier networks or service provider networks), SDN becomes a part of the bigger puzzle – a very important part, but a part nonetheless.

In order for SDN to be deployed in service provider networks in any significant way, we need to ensure that we are pulling along as many pieces of the puzzle as we can. The role of SDN as a control point for the network and data center infrastructure makes it quite intertwined with layers of functionality that lie both below and above it (if you were to visualize it as a stack of horizontal layers).

Southbound from the controller is the network and data center infrastructure layer. The role that the SDN control layer plays in the service provider network depends a lot on the infrastructure that is in place. There is a lot going on in this layer when it comes to service provider strategies. NFV is the biggest of them all, but there are other considerations for white-box strategies and data center architecture, such as centralized vs. distributed for telco applications, or underlay vs. overlay solutions. The SDN control architecture and its introduction is affected significantly by all these choices that need to be made in the network and data center infrastructure layer

Northbound from SDN control is the management and orchestration layer. How well this layer works with the SDN control layer will eventually determine whether the goal of a zero-touch network with full automation can be realized. The open questions in this layer are even more complex. By design, the SDN control layer has subsumed a lot of traditional network management capabilities (like configuration, topology awareness) into itself. OpenStack and other cloud management systems coming out of the data center world have orchestration capabilities (although minimal on the network side), and there is a lot of work being done in enhancing those tools. Meanwhile, there is a heavily invested OSS/BSS layer in telco networks that in many cases are due for upgrades to be in sync with the way services will be created and consumed with the introduction of SDN and NFV.

A mechanism to expose network and service capabilities through APIs and self-service portals becomes a critical part of this transformation. This is what makes the network “programmable” – be it by users, applications, or devices. Where some capabilities exist, they probably need to be augmented. Where they don’t exist, the benefits of all the hard work in transitioning the entire vertical stack below cannot be reaped unless there is a way to expose and monetize these capabilities. It is fair to say that the most important part of the puzzle is marketing and monetization of all these new capabilities. One of the most common requests these days from CTOs is to go and preach the SDN/NFV gospel to CMOs.

For each layer of the infrastructure I described above, there are probably four key metrics that will drive the pace and the order in which the transformation happens. These are:

1. Business Priorities. What is an immediate priority? Revenue, cost savings, improving user experience, automation?
2. Infrastructure Lifecycle. Where is the infrastructure lifecycle at any given point? Is the existing infrastructure overdue for upgrades, or has it just been commissioned?
3. Operational Processes. How flexible and mature are processes to changes?
4. Organizational capability/competence for change. How adaptive are organizations and the culture to change and acquire new competence?

Now, going back to the SDN layer itself, it is hard to imagine central control logic for the infrastructure coming into place instantly. The deployment of that control layer itself needs to go through phases. And again, I believe, it will be affected by the same four above mentioned criteria. Most operators will try out their first SDN use cases in contained domains and evaluate before introducing use cases that have deeper and more complex touch points to existing infrastructure.

The reason service chaining has been a prime initial use case for SDN is precisely this: It can be operationalized with much less impact on standing processes and organizations – being primarily a policy-based automation/personalization solution. The advent of NFV brought forward the need for seamless interconnection between existing IP infrastructure and the data center networking fabric. The need for personalization of the connectivity, of making it more application- and underlay-aware, is now pushing the need for the control layer to be aware of both the IP and the optical infrastructure capabilities.

Different operators will have different starting points for overhauling this control layer and implementing an SDN-based solution. However, the end game is still the need to make the underlying infrastructure programmable in real-time and then being able to create monetizable services on that infrastructure.