Rethinking Talent and Culture to Lay the Foundation for 5G

 

In our 5G eBook, we talked about one of the biggest barriers that Communications Service Providers (CSPs) face in transitioning to a 5G world: the huge talent and culture gap between traditional network teams, who are used to doing things a certain way, and the world of DevOps and IP. As we say in the eBook:

In most CSP organizations, network teams have operated almost completely independently of teams focusing on Layer-4 through -7 services for years. They use completely different tools, and they literally speak (or at least code with) completely different languages. So of course, they see the network from very different perspectives… As 5G extends IT and packet techniques across the end-to-end network, those walls need to be torn down. Ultimately, if network engineers are going to be full participants in the unified 5G landscape, they will need to move towards the world of agile software and CI/CD and DevOps.

The eBook ran through a high-level roadmap of the steps forward-looking CSPs can take to bridge this gap and help traditional network engineers move up the stack. Obviously, however, there is a much larger conversation to be had here—and one that network teams can expect to unfold over the next several years. What should this cultural evolution look like in your organization? What does the concept of “NetDevOps” really mean? And, what are the most important ways that CSP network teams need to shift their thinking and their culture to successfully make the transition? Let’s take a closer look.

Inside NetDevOps

As CSP networking organizations look to evolve from traditional approaches to the world of agile software, they’re embracing a new way of thinking about the network: NetDevOps. In its simplest form, NetDevOps is about bringing DevOps principles to the design and operation of CSP networks. That is, creating a culture where the people architecting the network, and the people operating it and consuming network services, are constantly communicating and collaborating. In a NetDevOps world, the journey from conceiving a new network change, to building it out, testing it, gathering feedback, and releasing new updates, happens much more quickly. And, both network architects and operations teams rely heavily on automation to help them continually iterate.

Historically, CSP network changes have been complex, highly manual, and (for customers) excruciatingly slow. That won’t fly for many new 5G services and experiences, which require the ability to continually assemble and reassemble network resources on the fly. Which is why automation is a core requirement for bringing DevOps models to the network. Enabling automation, however, can be a journey in itself.

The networking team at Datapath.io laid out an excellent overview of what’s involved in a blog post, 10 Network Automation Principles for DevOps. The full post is worth reading, but some of the most important steps in this journey include:

  • Increasing network visibility: Before you can automate, you have to understand what’s happening. Network monitoring allows network engineers to collect key network performance and other parameters to understand what can be automated. This is the foundation of creating network rules and notifications that will ultimately replace manual processes. 
  • Simplifying the network architecture: Typically, this entails using SDN to separate control plane and data plane functionality, and virtualizing and converging disparate functions into a unified architecture. SDN is also the foundation of an “infrastructure as code” strategy, as it’s what allows you to apply open, non-proprietary code across heterogeneous infrastructure devices.
  • Driving out manual effort: By eliminating reliance on proprietary software, you can replicate the same code across multiple devices, and often eliminate manual configuration efforts. Open source software can also play a big role here.

Clearly, this is a very different model for CSP network operations. But network teams don’t have to reinvent how they do things overnight. Ultimately, 5G is about accelerating the delivery of new services to end-users—things like massive IoT installations, augmented reality, new real-time experiences, and more. As CSP customers adopt and consume services like these, networking teams will necessarily become steeped in digital culture. The more they do, the more they’ll find that a NetDevOps model makes far more sense to keep abreast of these demands than traditional ways of working.

Shifting Mindsets

NetDevOps can provide the technical framework for new ways of working. But, if networking organizations are going to thrive in a 5G world, they also need to change the way they think. Network automation, DevOps ways of working, CI/DC methodologies—all reflect a culture and mindset radically different from how we’ve thought about networks in the past. To succeed, network teams will need to:

  • Get comfortable with ambiguity. Traditional network teams are accustomed to highly structured processes, with clear goals and a fixed beginning, middle, and end. Transformation, however, means dealing with ambiguity in a number of areas: In network requirements as technology and market forces change. In development processes, due to much faster iterations. At management layers, in how work is prioritized, completed, and consumed. At the sales and marketing level, in how CSPs talk about services and capabilities with customers. The unknown is the new normal.
  • Rethink network requirements. In a 5G world, network engineers need to think about requirements in very different ways. Expect requirements to frequently be incomplete, sometimes even unknown when launching a new effort. Remember, in the new way of working, you’re continually gathering feedback and iterating based on what you learn. Requirements may come from the marketing arm of the organization through a product owner (in the case of a product) or from a customer (in the case of services). Requirements will often be articulated in terms of an envisioned implementation. Developers can help restate requirements to remove implementation biases. And architects should plan to work closely with domain experts to identify gaps and missing requirements.
  • Prioritize retraining. Transforming the development process begins with retraining, and that encompasses more than just adopting new tools. A big part of the modern developer mindset is embracing continuous learning (or risking becoming obsolete). You will want to provide network engineers with plenty of opportunities to learn new skills, and you may need to find creative ways to incentivize learning. Remember: the hardest part of retraining is changing the way people look at and deal with obstacles. Finding mentors who can help guide engineers through this process is often the most efficient approach.
  • Embrace transparency. This can be the most difficult part of the journey, especially for developers, because you’re asking them to work in ways that can be counter to longstanding practice and temperament. Developers often want to tightly control their code—sometimes even being secretive as a kind of job security. They also want the freedom to individually make design decisions. Moving to a more collaborative model, where everyone acknowledges group ownership and responsibility, will take some adjustment. 

Think More Like a Surfer, Less Like a Skier

The most important cultural shift that needs to happen deals with the way network organizations think about change itself. As we move into the more dynamic world of 5G and beyond, you can’t think of transformation as an event. Instead, it’s an ongoing process—the new normal for your organization. There is no point where you can expect to say, “We’ve finally arrived.” And the landing zone established this morning will often move before the sun sets.

Additionally, if transformation will be ongoing, networking teams must recognize that it’s necessarily going to be incremental. And they need to accept the implications of that: mistakes, retractions, and re-orientations will be routine occurrences, and need to be tolerated as such. Along the same lines, be prepared to recognize local successes, take what you learn from them, and use those lessons to optimize across the organization. The model moving forward will entail taking a step in what you think is the right direction (right now), measuring, and refining and repeating.

It helps to think about the difference between downhill skiing and kite surfing. The skier looks down the slope and comes up with a route and strategy that will ensure success—knowing the mountain won’t change during the run. Once decided, the plan will remain intact. The kitesurfer, on the other hand, knows she needs to get from A to B, but that’s about it. Her journey involves balancing against constantly changing forces of wind and waves, neither of which can be predicted, so any plan must be limited in scope and lifespan.

When you’ve spent your career learning to become an expert downhill skier, taking on kite surfing can be an intimidating prospect. But if you can be patient in your approach, flexible in your thinking, and ready to learn, you’ll find it’s a gratifying journey.