Building a Business Case for SDN

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-tn

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:

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.

Compare SDN against Traditional Methods

By now you have a good sense of how the SDN solution will perform, so it’s time to compare the time and efficacy of the SDN solution against your traditional method of performing the tasks.

Build Inter-departmental or Enterprise-wide Consensus

Similar to a cloud or BYOD initiative, giving visibility for SDN can help you bring the company together, and can also build support for improving how IT can drive the business. If you understand the pain points and how SDN can improve operations for campus security, collaborative tools, and the data center, you can evangelize how SDN can be a competitive advantage for each department. You can then rank departmental projects in order of priority and use each group as examples of how SDN can drive economic as well as employee benefits.

Determine SDN Cost Savings

Based on an understanding of the time differences between using an SDN solution and doing things the traditional way, you can come up with a comparison of CapEx and OpEx costs for the two different approaches. You should prepare a multi-year financial analysis of the costs and benefits that will sell the solution over the long term.

Create a Presentation

Finally, create a presentation that summarizes your findings. It’s important to tie the benefits of SDN back to direct business value, so you should include some examples of how SDN eliminates pain points in business units and allows the IT department to do its job more efficiently and cost-effectively. The presentation should also address what your IT organization will do to mitigate the risk that is associated with implementing the SDN solution. In addition to mitigating the risk associated with the solution not performing well, this includes mitigating concerns that management has about issues such as security, compliance and existing processes.

If you put in the work to prepare a solid business case for SDN, you should be in a great position to strategize how you will roll out SDN in your data center. The business unit pain points and cost comparison will help you prioritize your projects, and the business case will give management the confidence to let you proceed.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.