Building a Business Case for SDN
February 28th, 2014 By: Industry Perspectives
Steve Garrison leads go-to-market and brand development strategies at Pica8, and is a networking systems veteran with nearly 20 years of technology marketing experience. Steve has held global marketing positions at public and venture-backed companies, including Infoblox, Force10 Networks (acquired by Dell, Inc.) and Riverstone Networks (acquired by Alcatel-Lucent).STEVE GARRISON
Many companies are curious about how software-defined networks can improve their network operations, but no CIO will approve an SDN project without being able to make a business case to the CFO and CEO. In this article, we’ll look at some steps to take to build a business case.
What Does SDN Mean to You?
An important first step is to decide what you want out of SDN – what you think it can mean for your company. One way to determine that is to consider SDN’s benefits and then think about which of them are most important. Here are some benefits of SDN:
- Simplifying configuration and provisioning, thereby reducing OpEx by minimizing or eliminating manual configuration
- Performing traffic engineering with an end-to-end view of the network
- Supporting the dynamic movement, replication and allocation of virtual resources
- Establishing virtual Ethernet networks without VLANs
- Enabling applications to dynamically request services from the network
- Reducing CapEx by using bare-metal switches instead of name-brand switches
- Evolving network functionality more rapidly based on a software development lifecycle
- More easily implementing QoS
- Implementing more effective security functionality
These are some of the basic advantages that we hear touted for SDN, but others may occur to you as you consider the challenges of operating your IT environment and how those challenges might be alleviated.
What are the Pain Points?
With a good idea of the appropriate benefits in mind, the next step is to survey line of business departments about their IT needs, and how those business needs translate into the need for IT agility. You can then map the pain points back to IT processes needed and consider how SDN will help.
To help guide the discussion, let’s look at three typical network areas — the data center, the WAN (or inter-campus connectivity), and the campus itself.
For example, on the campus, you may rank security as your top concern and therefore focus the SDN discussion around onboarding devices into the network. SDN could help with the onboarding process – you could look at the behavior of recently added devices and potentially shutting those ports down, or isolating a device.
For inter-office connectivity or WAN, you may have latency or perceived bandwidth-limiting application performance. For example collaborative tools may need some SDN tuning to help improve the user’s experience.
And in the data center, a common pain point is the desire to make virtual machines (VMs) mobile, or to help manage workloads or for HA. The challenge is how to move a VM without disrupting the underlying network. Here the end game it to have a means to move the VMs and seamlessly “orchestrate” changes in the physical network.
Set up a Proof of Concept (POC)
The POC involves setting up an SDN test bed and determining if the SDN solution can deliver the benefits you’re expecting. Note that the SDN setup time should be included in any evaluation of the approach, along with the time it takes to achieve the benefits you are seeking.
Let’s take a look at setting up three POCs. For the campus use case of adding to an overall BYOD strategy, the idea of a programmable network tap using OpenFlow could be considered. The idea here is to be able to turn on tapping functionality on any SDN-enabled port, thereby not having parallel fixed infrastructure providing tapping functionality. The argument here is fixed CapEx / OpEx for purpose-built monitoring and tapping tools, or leveraging an SDN network tap that can be bolted onto your network and used as a dynamic probe. Here the POC could explore the overall cost of the gear (CapEx) and the cost for training in both non-SDN and SDN paradigms. (OpEx). You could also look at whether SDN provides you with all the functionality or just a subset. Once you have the technical details, you can make an informed decision.
For the collaborative tool project, you could compare increasing your WAN link, or increasing the port speed on your inter-campus fiber, and comparing that cost with adding SDN functionality to the gateway devices that interconnect your campus. You might want to have internal focus groups helping to measure the “before” and “after” of your POC. The quality of the service or the user experience is in fact the productivity metric. And if the collaborative tools are not used due to poor performance, you could suggest that without improvements the company has not fully realized the potential of better communication.
For the data center project, the SDN POC ideally would be to mock up two racks: one with SDN and one without SDN. This POC would look at the operational aspects of reassigning VLANs and creating virtual domains within a fixed IP fabric. Thinking in terms of service metrics, such as time to new application or service availability, or time to fault resolution, will help create tangible benefits and metrics for judging the value of SDN.