How Do We Transition from NetOps to DevOps?

Time for ChangeOver the last year or two there has been a lot written about IT organizations adopting DevOps and generally experiencing positive results. It’s hard to make the case that the benefits of DevOps are only applicable to an organization’s applications groups. So, what’s it going to take to drive a network organization to transition from NetOps to DevOps?

According to the Information Week Report entitled 2014 DevOps Survey, twenty-one percent of companies have already implemented DevOps and another twenty-one percent expect to within the next year. As discussed below, DevOps is less about technology and more about how organizations become more agile. One of the ways that DevOps is typically implemented is that application teams change the way that they develop and update applications. In a traditional application development environment, application development teams go through an extensive cycle of requirements gathering and application design prior to even starting to write code. As a result, the time to develop an application or to update an application is very lengthy. One of the key characteristics of the DevOps approach is that the application development teams write primarily small, incremental pieces of code that are put into production on a very frequent basis.

As mentioned, DevOps is less about technology than it is about agility and culture. That concept was emphasized in the 2014 State of DevOps Report by Puppet Labs which states “DevOps has always been about culture, not just about tools and processes. We found that the cultural practices and norms that characterize high-trust organizations — good information flow, cross-functional collaboration, shared responsibilities, learning from failures and encouragement of new ideas — are the same as those at the heart of DevOps.”

I recently attended an analyst conference hosted by Juniper Networks. One of the speakers at the conference was Steve Hallett, the vice president of cloud infrastructure engineering at Symantec. Steve talked about what Symantec was doing to adopt cloud computing. While I was interested in what Steve had to say about the technologies Symantec was using, I was more interested in what he had to say about the changes that were happening within Symantec’s IT organization. According to Steve, it had been relatively easy to get their younger application developers excited about moving to more agile development processes and leveraging open source-based applications such as OpenStack. He added that these young application developers became the champions of the cultural changes that enabled the organization to adopt a more agile DevOps approach to application development.

Steve then contrasted the agility and the culture of his company’s application development organization with that of their network organization. He stated that their network organization was stuck in a culture where it is acceptable to take weeks to implement a change and that that culture needs to change. Steve said that he was in the process of helping the network organization realize that it needs to become more agile and making sure that they had whatever training or other resources they needed to make the shift. The impression that he gave the audience was that either the members of the network organization made the shift or they would be replaced.

I will skip over the fact that it really upsets me to think of people losing their jobs. I will instead focus on the question raised in the title of the blog. The transition from NetOps to DevOps will take a combination of positive stimulation, such as happened in Symantec’s application development organization, combined with the realization on the part of network professionals that not making the transition has consequences. However, it isn’t sufficient to just send people off to training. Managers need to develop job plans for their people that combine formal training with on the job training and which lead the network organization in general, and network professionals in particular to the desired end state in a series of achievable steps. In addition, if they want network professionals to take risks and learn from failures, they also have to change the reward structure of the organization in ways that are highly visible.

About the author
Jim Metzler
Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.