Focus On SDN Tools Obscures SDN Benefits

Software-defined networking has come a long way in the past year. SDN has moved from the fringe of lab testing to mainstream products that organizations are considering for implementation in production networks. Large networking vendors have implemented technologies that are soon going to be generally available, if they aren't already. Yet, for all the advances that SDN has made, it seems that people are still debating the wrong aspects when it comes to solutions. They are too focused on the tools to see what the tools can actually build.

Tools are useful. I have a garage full of hand tools and power tools that I can use to accomplish all manner of things. While useful, a single tool can't really do much. Tools are best used in combinations to achieve greater goals. A hammer by itself can't build a birdhouse. It takes a saw and nails to cut the pieces and hold them together. While it might be useful to have two different kinds of hammers available for specific use cases, it serves no purpose to argue about which hammer is better for fulfilling all use cases.

Unfortunately, this type of argument is happening with SDN. SDN proponents and detractors alike are very focused on the tools -- OpenFlow, NSX, ACI, and on and on. Pick a protocol or an implementation strategy and you'll find any one of number of people ready to attack or defend it as they see fit. The arguments are all very similar: questions about scaling or openness versus proprietary implementations. The circular logic at work is enough to scare away those who aren't die-hards when it comes to the nuts and bolts of implementing software-defined ideas.

Those who are scared away include the decision makers at companies. Why should they pick a side when it is clear that the smart people in the room can't come to a consensus? If both sides are going to argue the relative merits of a claw hammer against a roofing hammer, then the birdhouse is never going to get built. The decision makers have one rule for measuring success: Their concern is whether or not the network is running. Did incident reports go down after implementing SDN? Are my service requests being implemented faster? Am I still getting phone calls from the accounting department because the payroll system is offline the night before payday?

SDN vendors would do well to take a step back in the coming year. They should ask themselves one question before taking up arms against their bitter enemies in the opposite camp: How will the various SDN tools in my toolbox help me get things accomplished?

[Find out what questions enterprises considering Cisco ACI for their data centers should ask in "Cisco ACI: 4 Critical Questions For Customers."]

If you can frame the debate of application control in the context of helping your networking team anticipate changes when deploying new systems, then the decision makers will be happy. If you can tell the accounting department that network virtualization allows the payroll system to be more resilient in the event of an outage, they will sing your praises during staff meetings. The key is to make sure that vendors are discussing the tools as part of a larger strategy. They need to focus on how the tools work together to provide a framework for solving business problems.

A toolbox with a single tool is a useless toolbox. A toolbox full of tools needs a project to accomplish its purpose. As networking professionals, we need to ensure that SDN vendors are providing the context needed for tools to help solve business problems. The decision makers want to know that their investment is paying off for the company. They don’t care if you use tunnels, ASICs, or software forwarding. In the end, they just want to hear that the tools are doing their job.