SDN: Not Necessarily A Job Killer

10 Twitter Power Tips

Have you heard the one about the engineer who implements load balancing by manually adjusting DNS records? Offered a way to automate that process, the engineer replied, "No thanks, I'd lose my overtime."

The product manager tried another tactic, asking, "Wouldn't you like to spend more time at home with your wife?"

To which the engineer offered a variant on a well-worn cliché: "You haven't met my wife."

That's a true story, and this engineer's reluctance to adopt what is inarguably a more efficient system isn't based on technology or business value. It's purely cultural, a "people" issue. In my experience, whether disruptive technology is embraced almost always depends more on its effect on staffing than on whether the technology itself is valuable now and a good long-term investment. When something's disruptive not only to systems and data centers but toindividuals and their understanding of where they fit in the big picture, watch the excuses fly.

[ SDN meets needs in many different types of environments. Read Why Campus Networks Need Software Defined Networking. ]

Automation in general and software-defined networking (SDN) in particular can provide real value to both the business and IT. First, delays in delivering new services andapplications often can be traced directly to the tedious andtime-consuming process of updating network components. SDN promises to slash delays by providing a more policy-based approach to configuration management. That means the front office will see new services and tools much more quickly. Second, robust SDN models also assist in routing around issues and adjusting the network in real time based on real network conditions. That promises to address failures and those unresponsive demos that mar customermeetings and frustrate the sales force.

But automation carries a negative cultural perception, so CIOs must approach it with extra sensitivity lest they be met with obstructionism. People whose roles include managing the network need to understand that automation is not intelligence; it is not the sentience depicted by science-fiction writers. SDN is not Skynet for the data center, and its goal is not to replace engineers, but rather to shift the burden of tedious configuration from people to technology. It does not imply a system with the knowledge to define the rules by which it operates. That requires engineers, skilled engineers.

In short, automating the addition of a firewall rule does not obviate the need for an engineer to design the rule.

CIOs looking to start down the path of adopting disruptive technology containing an automated component, SDN or otherwise, need to remember that the first and most difficult roadblock is going to be people. Some engineers simply can't or won't make the transition. For those who don't have skills in scripting and APIs -- core components of automation -- but want to learn, have a plan to address the gap.

Consider funding a training program, or supporting a professional development initiative for engineers that sets aside 10% of their hours to work on developing the skills they'll need to move forward.

Always emphasize the positive; don't approach adoption with the premise it's necessary because network engineers are failing to meet business needs. Emphasize that eliminating tedious tasks will free up time to innovate, offer increasing value to the business, and maybe even get home for dinner on time.