While SDN makes sense on technological merits, it faces major barriers to adoption. And those barriers aren't technical.

One major barrier to SDN adoption is cultural. Carrier network engineers are currently hardware operators. They deal with dedicated, physical boxes that need to be transported, hooked up, configured with a command-line interface and occasionally visited in situ. SDN will turn carrier networking upside-down; engineers will become software developers, configuring networks using graphical software and writing code in interactive development environments. The only time they'll get up on their feet is if they have treadmill desks.

The job of being a network operator will change. It requires a lot of retraining and redrawing the lines, circles, and boxes on the org chart. (See The Three Faces of SDN and SDN Faces a Human Hurdle .)

Which leads to the second barrier: Power politics. Many network engineers will be simply unable to make the transition to software networking, and they'll be out of work. People resist being put out of jobs. Even tougher for SDN advocates: Some of these people will be upper management who've built their careers around hardware-defined networks. Many of these people are going to see the shift to software networks as a threat to their position within the company. They see the transition to software networks as a death-struggle, and they'll fight against it with every iota of their being.

Sure, hardware-defined networking has its issues. But people whose job it is to solve problems have a strong vested interest in preserving those problems. (I wish I could remember who said that -- it's brilliant.) If your job is to clean the hair out of the shower drain, you're going to fight like a Klingon against any attempt to eliminate shower-drain-hair as a problem.

But what of the benefits? Software-defined networks are more easily maintained, less expensive in capex and opex (allegedly), and more flexible, permitting the deployment of new services faster to customers.

That all appears to be true, but it's difficult to prove -- which is the third barrier to SDN adoption. SDN exists down deep at the bottom of the network, while financial benefits become obvious high up in the application layers. SDN requires foundational network changes whose benefits are indirect and difficult to quantify immediately.

So what's an SDN advocate to do? Start small, deploying SDN in new services. Do fast projects with quick, demonstrable financial return. Enlist allies in the organization where you can find them, and do your best to navigate around opponents without confronting them.

NFV, often mentioned in the same breath as SDN, represents a way to get SDN in the back door of network operators. Virtualizing a network application like a load-balancer or firewall, particularly if it's customer premises equipment, can be a small, local project with immediate financial benefit. Do enough of those and somebody's going to see that virtualizing the underlying network architecture is a great idea too.

As to the managers and senior VPs who fight SDN as a threat to their survival: Some will come around, some will be proven wrong and sidelined, and for others, you may just have to wait for them to retire. Putting arsenic in their coffee, tempting though it may be, will get you the wrong kind of attention.

— Mitch Wagner, , West Coast Bureau Chief, Light Reading. Got a tip about SDN or NFV? Send it to [email protected].