SDN Maturity Model

by | April 6, 2015
SDN Maturity Model

One of our key goals at Itential is to promote SDN and help companies grow in maturity in this fast emerging technology. In support of this we have defined version 1 of the SDN Maturity Model, as shown below:


There are two primary components to the model: the maturity curve and what it means to be at each level, and the prerequisite skillsets we believe you must have present in your organization to take advantage of SDN. Let’s dive into each of the levels we have defined in version 1 of the SDN Maturity Model:


This level is primarily concerned with the beginnings of SDN knowledge within your company. Typically this involves the hiring of a consultant(s) to do some introductory training presentations, possibly free introductory sessions from one of your existing vendors, or even assigning a senior level engineer to do some research into why you should care about SDN and reporting back to the team.  At this point you are very hardware focused in how you manage your network, though there are plenty of software tools floating around helping you manage things. Your staff is very comfortable logging in via CLI and configuring the equipment in the network, and you can’t see a world where EMSs cease to be something you rely on.

This is also the point where you should start assessing where you really are with regard to readiness to begin the SDN journey. To avoid being a solution looking for a problem you should build an understanding of SDN, and likely NFV concepts, and then formulate a vision for the direction you would like to move forward with. Without this vision you absolutely should not move forward, or you will spend a lot of money on vague ideas trying to find a purpose.

Proof of Concept

Once you have educated yourself on what SDN can do for your company and defined a vision for where you want it to take you it is time to make it real, at least in your lab. At this point you should build a list of vendors you are interested in, based on your vision, and secure the funding to begin your lab work. Your vision should clearly lead you to a set of use cases that will validate your decision to begin this journey, but if it doesn’t you should take a step back before spending any money and revisit what you are trying to accomplish. A vague, poorly defined vision will result in flushing money down the drain with no return.  It is vital to your success that your vision be clear and well defined.

It is hard, but this is the time to start considering how you will move from that hardware focused view of the past and into the software focused view of the future. You need to begin thinking of the high level goals and business cases that can justify the expense involved.

The meat of this phase in the progression up the model is the work done in the lab. You will spend most of your time trialing various vendor platforms, hopefully focusing on those that are open and multi-vendor in function, and building the demonstration of your vision. As the lab trials reach maturity you should begin having internal demos to key stakeholders within the company. This includes Engineering, IT, Operations, Customer Care, and even Product. You want everyone onboard and excited about the possibilities this brings for the future. The result will be a revision of your vision, most likely, due to the input from all involved. SDN is not an Engineering only project. It impacts everything. As a last note here, you should not despair if this phase takes a year or more to work through. This is not a race, it is a journey that must be done correctly.

The exit from Proof of Concept should involve: a corporate backed vision, clearly defined and prioritized use cases to be implemented, a list of preferred vendors based on their capabilities as proven in the lab, a solid business case that has been contributed to by all organizations to prove the next step should be taken, and a date on the calendar where you present the body of work to acquire funding for implementation.


In a nutshell, at this point you should have a few key prerequisites in place: funding, cross-organizational buy in, defined standards you will be adhering to in your implementation, and a staff identified/assigned to drive the effort to completion. At a high level your implementation plan should resemble:

  1. Cross organizational training on
    • SDN
    • Network Abstraction
    • Standards chosen as a guide
  2. Requirements definition
  3. Design
    • Network Design and Planning
    • Early OSS planning
    • Services Definition
  4. Market Trials
    • Simple implementations, possibly with “friendly” customers you have worked with in trial situations before
    • At least 2 trials before beginning full blown implementation
      • Trial of single market with single service offering based on SDN
      • Trial of multiple markets with multiple offerings
  5. Implementation
    • Network Implementation
    • OSS Implementation
    • Product Launch (or migration of existing products to new SDN platform – the vision drive this)

This phase is not short, as with the Proof of Concept phase, and may be a multiple year effort.


At this point you should have completed all trials successfully, have a fully trained staff, and have evolved your OSS to work with SDN/NFV driven networks. You should also have put serious thoughts in how to further evolve your OSS from one of a record keeping system, that is frequently out of sync with reality in the network, to a Real-Time view of your network where the network and the users of it, whether customer of internal personnel, drive the entire process. The network will be fluid and dynamic and the focus of this phase is to make the systems supporting it to be the same.

Use of CLI interfaces at this point should be very minimal. Simplified UIs should be in place where employees and customers are managing the network almost like a piece of software, as opposed to the neolithic, static environment that networks are in today. Network Orchestration should take the place of manual manipulation of the network.

It should start becoming clear how much faster products can be rolled out to customers in this dynamic environment, which is the beginning of the next phase.


At this point you should have a very mature, SDN savvy staff. You should have a focused common vision and understanding across Engineering, Operations, Customer Care, IT and Product. You should have a near Real-Time OSS environment in place that will allow you to do things such as:

  • Customer Self Service
  • Allow for a Self-Healing network
  • Have an Inventory that truly mirrors the real-time state of the network
  • True Zero Touch Provisioning
  • True Predictive Analysis

In addition the concept of Service Velocity should become a reality. Product should be able to design an offering, trial that offering in a lab, trial that offering in a market, check the take rate, and make the call on wider launch of the offering to all markets in a matter of months, with minimal funding required to do so.

This is the Holy Grail of SDN. SDN’s vision is about dynamic networks, improved customer satisfaction, reduced cost, and increased revenue for the operators. If you focus on the technology side alone your case for SDN may not fly with your executives, but the promise is so much more!

Patrick Moore

Patrick Moore currently serves as the Director of Network Automation Strategy at Itential where he has responsibility for managing the delivery of services to implement network automation for clients leveraging both Itential products and custom developed solutions.

Read More Posts From Patrick ›

Comments are closed here.