Ten Steps for CIOs to De-Risk SDN

There is a new breed of CIO embedded in the boardroom looking at the digital business. These CIOs are aiming to do more than keep the lights on.

They want to make their corporate networks more like the cloud. They want the ability to respond to application requirements quickly, whilst keeping data secure and helping the delivery of policies like secure BYOD.

[easy-tweet tweet=”New CIOs want to make their corporate networks more like the cloud” via=”no” hashtags=”cloud”]

However, most rigid corporate networks simply can’t handle the kinds of performance, growth, change management and automation that these companies demand. What they get instead is an unacceptable 30 or 60-day wait for suppliers to make network changes. They have to wait for router deliveries. They have to wait for software upgrades. They have to submit support tickets for a simple network changes. They get poor service.   

Fortunately, there are a whole host of innovative technologies in the market such as Software-Defined Networking and Network Function Virtualisation, deployed by nimble suppliers, that are revitalising enterprise networks. Software Defined Networking [SDN] particularly can provide flexibility and superior performance to give the CIO and their organisation the competitive edge they’re looking for.

We have been using SDN concepts for over a decade and, in doing so, we’ve learned some valuable best practice tips for the successful deployment of a SDN platform that we’d like to share:

Business case

1. This might seem basic, but its important, you don’t ‘buy a SDN’. It’s not a product – a network – you can pick off the shelf. SDN is an enabling capability that sits in your network.
2. SDN can offer compelling enterprise benefits, and you will need to be able to convey those benefits to the Board. You will need to present a business case for SDN to your CFO and CEO peers.
3. While SDN’s business benefits are real, they can be difficult to demonstrate. SDN involves network changes at the foundational level, so the benefits can take time to appear. Start with a small implementation project. This will help you demonstrate the advantages of SDN and can pave the way for additional funding for future projects. Focus the implementation on a business use case that is near and dear to your company. SDN, for example, can foster more rapid service development and provisioning and when that’s demonstrated alongside mobile app development, business executives can see how SDN could expedite delivery of new products and services and lead to increased revenue streams.
4. Consider the cultural implications of SDN within IT. IT leaders should take a page from today’s DevOps market and encourage collaboration among network engineers and software developers when planning, testing and executing SDN strategies and implementations. IT organisational charts may even need to be rewritten as roles and responsibilities change.

SDN is an enabling capability that sits in your network

Deployment

1. Rather than move to an all-SDN setup in one move, consider gradually combining SDN with more conventional networks. SDN solutions need to reflect this hybrid approach.
2. SDN requires networking staff to switch their focus from hardware to software. With SDN, IT staff configure networks with graphical software and write code using interactive developer tools. This requires new ways of thinking, new types of training, perhaps even new positions on the IT org’ chart.

Danger zones

1. Security! By moving the “brains” of the network to a central Controller device, SDN creates a new vulnerability: If the Controller is taken down by an attack, the entire network can crash. SDN solutions require additional security measures, both built into the architecture and delivered as a service.
2. The term SDN can mean different things coming from different suppliers. For IT departments, that’s confusing. Standards will help. While some standards already exist, more standards — and more mature ones — are still needed.

Working with network service providers

1. If you plan to work with a service provider ask some basic questions before engaging, for example:
   1. How do you support SDN in your network services?
   2. What types of SDN-based tools, portals and applications do you provide and what functionalities do they enable? 
   3. Can I see all of my sites by location name?
   4. Can I see all traffic per site? 
   5. Will I be able to differentiate traffic and determine who’s using bandwidth?
   6. Can IT change and configure bandwidth on demand and schedule bandwidth as business needs require? 
   7. Do you service provide a business-continuity solution, using the Internet as a backup solution?

My last point would be this, if you’re going to upgrade your network, look for a network service provider that has SDN in the roadmap with clearly delineated benefits, services and delivery dates.