No, Software Defined Networking will not Doom Engineers

With the advent of SDN, there is a lot of speculation these days about the future of network engineers. An article in PCWorld written by Stephen Lawson of IDG News Service caught our eye a while back for doing an excellent job dissecting the situation: 

“Will software-defined networking doom the command line interface?”
“Will SDN spell doom for the tool that network engineers have used throughout their careers?” Lawson asks. 

“If done properly, yes, it should kill the CLI. Which scares the living daylights out of the vast majority of CCIEs,” Gartner analyst Joe Skorupa said. “Certainly all of those who define their worth in their job as around the fact that they understand the most obscure Cisco CLI commands for configuring some corner-case BGP4 (Border Gateway Protocol 4) parameter.” 

Now, Lawson did a great job of examining the question he set up. In our opinion though, the main issue is not with the CLI. Sure, command line interfaces were eventually replaced in many places with graphical user interfaces in the general history of computers. But CLIs have three advantages over GUIs that kept engineers using them: 

First, they took up less overhead than GUIs – in enterprise networking, you want to have as much processing power as possible moving packets around as fast as possible to maximize performance. Second, they were “simpler” from a programming complexity viewpoint – with less to go wrong, there would be less chance of a crash (and networking equipment has to be rock-solid stable, naturally). 

Finally, it took far less overhead to transfer input and output from a remote host when that input was limited to ASCII (or perhaps Unicode), instead of having to redraw and retransmit graphic frames every 1/50th or 1/60th of a second.   

Which brings me to ask the question: Would software defined networking negate or surpass any of these advantages? No. What SDN will do is automate some tasks that previously needed to be done “by hand” via a CLI. Automation removes the need for any interface, not just a particular type of interface.   

So, the real question – and one that Lawson addresses at the end of his article – is: “Are network engineers going to be made obsolete by software defined networking, when SDN can do so many things that required specialized CLI knowledge to accomplish?” 

It’s a scary question. Yes, there are some engineers who have banked their entire careers on knowing the ins and out of the Cisco command line interface. And those network engineers who cannot adapt will find themselves with a skill set that is obsolete. But that’s true of every job – you need to keep up with the changes. 

Let’s face it – network engineering isn’t just about what you know, but also how you think. It is not just a specialized set of knowledge, but the application of that knowledge to achieve goals and the ability to analyze problems, synthesize solutions, and evaluate results. (Bloom’s taxonomy may have its flaws, but it is very useful for explaining why IT isn’t just “knowing stuff.”) 

An engineer in any form is someone who solves practical problems. And SDN is just another one of those tools that can be used in the construction of the solution. It will, if anything, free up network engineers from maintenance and routine tasks, and allow them to focus on the really tough problems as well as big projects that can increase business agility, reduce costs and/or increase revenue. 

Will there need to be adjustments? Almost certainly. But, no, the network engineer isn’t going away anytime soon. In fact, the main reason SDN is important is because networks have become so complex and so large that they can no longer be micromanaged by human beings. Let the software do the trivial stuff – network engineers have better things to do.