Aug
28

A quote that sticks with me to this day is from the Prime Minister of Canada, Justin Trudeau, speaking at the 2018 World Economic Forum. He said:

"The pace of change has never been this fast, yet it will never be this slow again."

This is very true of technology today, especially for those who plan, build, and run communication networks. Physical manifestations of routers, firewalls, and load balancers are quickly evolving into virtual instantiations. They're now housed in virtual machines on generic hardware operating in a remote cloud environment. The complex vendor hardware that needs a team of network engineers to load, test, and deploy using Command Line Interface (CLI), now needs a new set of skills. Specifically, ones borrowed from software development. This includes Continuous Integration (CI) and Continuous Delivery (CD) coming together as part of the DevOps methodology.

advice-colleagues-communication-1161465

Collaboration is Key

Moving network engineers and subject matter experts to DevOps is not easy. It requires a high degree of collaboration between many departments. This includes (but is not limited to) product, planning, network engineering, software engineering, and operations organizations. Such a level of collaboration is an immense challenge. It's also one of the key determinants of success in the evolution toward virtualized network functions (VNFs) and service chains. These are the connections that bridge both physical and virtual network components.

Collaboration starts at the highest level. It requires a clear vision from leadership and all teams agreeing upon a common process. That process has to be supported by a structure of tools and procedures. Finally, culture is built around adherence to process and structure - this provides the cement.

Vision Leads the Way

Moving network engineering teams toward CI/CD, while managing both physical and virtual network functions, requires a clear vision. It's paramount to success. As competitors deliver faster, better products in swift succession, the rapid change of technology can be an intrinsic motivator. Executives need insight into their business and industry to understand and identify disruptive forces sooner. Product and Planning teams can provide valuable information to help leaders in their organizations develop their vision. Product teams can present metrics or case examples to drive home the need. Planning teams can lay out what is necessary and the timeframe it requires. This information can help executives know what they need to do to move their company forward and accelerate delivery.

The importance of accessible new content and features, with near-perfect reliability, is critical. It could impact revenue significantly should it fail. This is especially true for video on-demand, eCommerce, and gaming. A Chief Technology Officer (CTO), aware of industry dynamics and competitive pressures, would collaborate with planning, product, network engineering, and IT teams to develop an appropriate strategy. It would be one that requires all teams to provide consistent, near 100% reliable access to both content and the user interface. That means any changes to content, the network it's on, or the software that manages the UX should be coordinated. It should also be based on a model that supports 100% uptime, while allowing for frequent updates.

conference-learning-meeting-7095

Defining the Process

After establishing a vision, the next difficult task is to define a common process that all teams can adhere too. This is where many departments have to come together and agree on how work will be delivered. This includes steps, sequencing, and coordination. Traditionally operating in silos, network engineering, IT, operations, and Quality Assurance (QA) teams have each developed their own processes and procedures. With a significant need to keep up with the rapid pace of change and adapt to greater demand, a higher-level common process becomes paramount. The time comes for a single best practice that supports collaboration across all teams.

For small companies and start-ups, collaboration on a common enterprise process is a no-brainer. A few people work together - often in one location - and develop and test jointly to deliver new software and the network that supports it. This epitomizes agile development and delivery.

That model does not scale well to larger organizations, companies grappling with industry disruptions or government agencies struggling to break through departmental silos. Additionally, one of the biggest issues companies face is how to enable the entire business to move in the same direction. As such, many larger enterprises are discovering that the Scaled Agile Framework (SAFe) allows for a greater degree of collaboration amongst teams across an organization. SAFe provides integrated principles, practices, and proven processes that work for any large company or government agency that wants to operate in a lean and agile manner.

Building a Reliable Structure

Structure is the next component that requires tight collaboration. The tools and day-to-day procedures need to be able to maximize efficiency, accelerate speed to market, and reduce or mitigate outages and errors. This is where DevOps and CI/CD play a critical role. An effective structure needs lean operations and the ability to deliver within a short timeframe. CI/CD is where continuous development, integration, and delivery occur. Therefore, both CI/CD and DevOps are important practices within SAFe.

Here is an important tip: the IT team has more experience with orchestration and automation tools than you may think. Often, software engineering teams have been using DevOps and CI/CD for many years. Network engineers should collaborate with IT staff and software engineering teams to leverage their knowledge and their tool preference.

For example, if an IT application team is using Jenkins to orchestrate a toolchain, other teams are able to do the same. The company has staff with the knowledge and scripting capabilities to implement a similar toolchain for the network team. The same holds true for any purchased commercial tools. Additionally, teams can share licenses and vendor support. Teams can also extend license and vendor support into network development and management.

Recently, within my own organization, I took this a step further and found someone in IT who had the needed DevOps and CI/CD experience. I transferred that senior person onto my team. From there, I described our vision and provided the objectives to build both the structure and processes to accelerate network engineering deliverables. Though training your team is ideal, if you have a spur of the moment need, build your team by transferring staff.

chairs-company-desk-7065

Developing a Meaningful Culture

The final focus for any organization is creating a collaborative culture. Organizations often attempt to start with culture first, but their efforts fail. Dictating that all teams work together with transparency as partners, will not move the needle on culture. Every piece noted above - vision, process, and structure - must be in place first before attempting to impact culture. Culture is inherently difficult to change. I've attended many DevOps Days events and even a recent Red Hat Summit where this issue was front and center. The problem of culture-shift is the one area organizations struggle with most, justifying many dedicated breakout sessions.

"Culture is a way of working together toward common goals that have been followed so frequently and so successfully that people don't even think about trying to do things another way. If a culture has formed, people will autonomously do what they need to do to be successful."

                                                                                                  - Clayton Christensen, Harvard Business School

Attaining a collaborative culture requires bringing teams together, working on common goals to reach a shared vision, and embracing a jointly crafted process. Everyone's motivations will align if each team contributes to the process with vested interests. The structure provides the tools and means to enable the process. As the teams work together, either in small Agile framework or a larger SAFe, they will collaborate to develop software that runs both the applications that support the business and the network that carried customer traffic.

There is a management tenet that if you don't measure what you want, you won't get it. This is absolutely true. It is important to measure a collaborative culture and recognize teams and individuals who exemplify it. If a collaborative team comprised of IT, network engineering, and operations staff deliver incrementally faster (and it's proven with metrics), celebrate that success! Share the increased velocity when reporting to executives and highlight the business impact. You may also want to measure usage around shared DevOps tools including the amount of automation in the pipeline and in test cases.

The DevOps Advantage 

In today's economic landscape, no company can afford to operate silos focused entirely on their own deliverables. They must take the entire business into consideration. Executives and leadership teams need to craft a vision that relies on collaboration throughout a company's different operating units. This vision has to feed into collaborative development, based on an agreed-upon common process and defined structure. Most importantly, a company must build and reinforce a collaborative culture. Culture is both the gears and the grease. It can reinforce the process and ensure alignment. It can also foster collaborative team engagement. Any team can keep up with the pace of technological change. It's possible through true collaboration.

 

Learn more about DevOps and how it supports Continuous Integration and Deployment with Brian's professional course. Use your All Access Pass today!

Watch Now!

 

 

 

 

Brian Newman
About Brian Newman

Brian Newman is on the frontlines of modern digital transformation and has worked, in one capacity or another, for the three largest telecommunications companies in the U.S. He is a Lean Six Sigma Black Belt and certified by the Project Management Institute as a Project Management Professional, as well as Scaled Agile Inc. as a Certified SAFe 4 Agilist. Brian writes non-fiction work on a variety of subjects such as workplace culture and automation, while also producing online courses covering 5G and DevOps. And he's an inventor (U.S. Patent #5,835,907). When he's not behind his laptop, you'll find Brian on the water in his fishing kayak or tended to by his administrative assistant, Barkley (the Golden Retriever).

Subscribe to INE Blog Updates

New Blog Posts!