Level 3's Ewert: Why Automation Is a Boon to Employees

NFV-driven automation can revolutionize IT, but it need not displace the IT worker, says Travis Ewert, senior vice president of network software development at Level 3 Communications.

Instead, a change-management culture with an unrelenting focus on people can help the organization and the technician alike, according to Ewert.

Previously, in part one of this Q&A, Ewert talked about the pros of both software-based cloud models and the commoditization of IT in the context of NFV. (See Level 3's Ewert: Look to Cloud for NFV Models .) Here in part two, Ewert strings together the intersection between automation and team culture in the world of NFV.

Telco Transformation: What is the connection you see between NFV and automation in the network?

Travis Ewert: Good question, because I like to break these apart. The whole reference to SDN, the whole reference to NFV -- to me they're two big categories. One category is more automation -- how do you orchestrate and control help functions or services to come on and off the network and change to them on day two -- whether through portal, API, program or whatever.

Then there's the network itself, which can be virtualized, containerized, programmable packet processors, traditional network, whatever. So they're distinctly different things, but for NFV and those functions sitting on a virtualized instance, obviously you have to have tight automation on top of that -- especially since this is the "Brave New World," and there are not as many humans out there to try to do it the old-fashioned way. That's where orchestration and control-layer type of capabilities can be even more vitally important in a virtualized landscape or containerized landscape.

At Level 3 we've spent many years building that automation and control layer for PNFs (physical network functions) -- traditional routers, IADs (integrated access devices), optical boxes, whatever. Now we are doing likewise for VNFs. We think we started in the best place. Start with what you've got, which is where your customers already reside on the physical functions. Because if anybody thinks they're going to be able to service chain effectively without having automation on top of that physical network function or traditional network -- you have got to be able to do both. Most use cases for NFV end up being a function that's changed into a preexisting network or flow, whether that's a security application -- such as firewall on demand, a DDoS scrubber or whatever the case may be.

TT: You said something I'm very interested in, which is that there aren't as many humans out there "to try to do things the old-fashioned way." As you have all of this NFV-enabled or NFV-enhanced automation, does this threaten the workforce? Or does it augment or elevate the humans working on the network? Or is there a neutral effect?

TE: You kind of answered it yourself; I think it was with your second question. Whether it's on the service-delivery side or whether it's on the service-assurance side, our model or our mantra has been: build to an exception model. Meaning as you introduce automation, you have some sort of intelligent workflow that can catch that which falls out of automation for the human to then respond to. So you go from manual to automation-assist to automation exception handling where the human can catch them. Then you're just dealing with the smaller percentage that then falls out of automation.

Then what you're able to do is you're able to move that workforce to more pertinent tasks -- for instance, on the assurance side. If you can automate reactive handling, -- for example, that which breaks -- if you can automate break-fix, then you can put more technicians on proactive handling where they're working on issues that would become a customer impact if they didn't address it ahead of time.

On the service delivery side, it's something we have a history of, as you move people out of traditional roles to more customer engagement and consultation engagement. So part of that answer is to move them to more meaningful roles, more proactive roles, more consultative roles -- the ability to grow your business without adding headcount. If we grow volume, and do so without adding heads, then that's the other piece of it.

TT: Meanwhile, supposedly, there's a tech talent shortage. Do you see that sort of traditional HR way of looking at people's experience and backgrounds as a roadblock?

TE: Oh, absolutely. And if you were in my office, I could point you to my guiding principles.

The last one is "change agents," and if you look at everything we've talked about thus far, the hardest of all is that change-agent, change-management role because we've built a workforce out of highly skilled technicians that are all Cisco- or Juniper- or other-certified. As you move these folks into roles where they're maybe not leveraging some of the skills they had before, it's hard. It's less of an HR thing and it's more of an ops-endorsement or ops-embracing thing. If you successfully can get to that model we talked about before where you can move them into more meaningful roles, then there's less grief with those techs who aren't leveraging their skillset.

But the other beautiful thing that we have a history of, and that we've done, is we've actually changed some of the career pathing where that tech can move from junior tech to senior tech to even a functional lead where they're becoming part of a dev team. When you can begin to transform those technicians and those folks who become an extension of the dev team working through their requirements that's when you're really hitting your groove.

Within our Network Software Development team, most of our key folks came from network architecture, engineering, or ops disciplines, meaning that they didn't come out of traditional IT systems development. We did that on purpose as part of that career pathing -- as part of having a different kind of appreciation for customer experience, operational scale, networking as a whole, etcetera.

TT: So to whom should we be looking to lead the NFV charge? What does an NFV leader look like on paper?

TE: He or she does have that more-than-software-culture, microservices, frequent-change, or other type of background from a dev-methodology perspective. But that's probably more on the dev side of that answer. More on the infrastructure itself and otherwise, it's got to be people who have spent some time in more server-centric environments, virtualization environments. That expertise does reside in the enterprise, and some of that is very much portable.

TT: And what are these NFV leaders' "soft skills," as well?

TE: Soft skills, for us personally? The team culture piece is huge. And boy, that's what's kind of cool. If you look at fundamentals, DevOps methodology and that culture of teaming -- from architecture engineering, DevOps and the tight alignment of that -- if you do that really well, that's a tight-family, tight-knit type of thing, which is pretty neat.

— Joe Stanganelli, Contributing Writer, Telco Transformation