Standardization is Good for NetOps

Standardization is sometimes viewed as an assault on innovation. Being forced to abandon a polyglot buffet and adopt a more limited menu sounds stifling, for sure. That may be because often standardization is associated with regulatory compliance standards that have official sounding names like ISO 8076.905E and carry with them checklists and auditors and oversight committees.

The reality is that there are very few standards (in fact none that I can think of) governing the choice of languages and protocols and frameworks by enterprise organizations. What drives standardization in the enterprise is more practical considerations such as availability of talent, sustainability, and total cost of ownership over the (often considerable) lifetime of software and systems.

Studies have shown the average software lifespan over the past twenty years is around 6 to 8 years. Interestingly, longevity tends to increase for larger programs as measured by lines of code (LOC). Systems and software with over a million LOC appear to have lifespans over a decade, lasting 12 to 14 years. While you may dismiss this as irrelevant, it's important to realize that at the end of the day, network automation systems are software and systems. They need the same care, feeding, and maintenance as software coming out of your development organization. If you're going to treat your production pipeline as code, then you've got to accept that a significant percentage of that automated pipeline is going to be code.

Over the course of that software or system lifespan, then, it’s a certain bet that multiple sets of operators and developers will be responsible for updating, maintaining, operating, and deploying changes to that software or system.

And this is exactly what gets at the heart of the push for standardization - especially for NetOps as they take the plunge into developing and maintaining systems to automate and orchestrate deployment and operation of network and application service infrastructure. 

Silos are for Farms

If you (or your team) chooses Python while another chooses PowerShell, you are effectively building an operational silo that prevents sharing of skills. Given that the number one challenge facing NetOps as reported in the State of Network Automation 2018 was a lack of skills (as reported by 49%) it would seem foolish to create additional friction by introducing multiple languages and/or toolsets. It is similarly a bad idea to choose languages and toolsets for which you have no local source of talent. If other organizations and nearby universities are teaching Python and you choose to go with PowerShell, you're going to have a hard time finding folks who have the skills you need to work on that system.

It is rare that an organization standardizes on a single language, but they do tend to standardize on just a few. NetOps should take their cues from development and DevOps standards as this will expand the talent pool even further.

Time to Value is Valuable

Many NetOps organizations already find themselves behind the eight ball when it comes to satisfying DevOps and business demands to get continuous. The unfortunate reality of NetOps and network automation is that it's a heterogeneous ecosystem with very little pre-packaged integration available. We found in the State of Network Automation survey that this "lack of integration" was the second most cited challenge to automation with 47% of NetOps agreeing.

Standardizing on toolsets and on infrastructure where possible (like application services) provides an opportunity to reduce the burden of integration across the entire organization. What one team develops, others can leverage to reduce the time to value of other automation projects. Reuse is a significant factor in improving time to value. We see reuse in developer proclivity toward open source and the fact that 80-90% of applications today are composed of third-party/open source components. This speeds up development and reduces time to value. The same principle can be applied to network automation by leveraging existing integrations.

Establish a culture of sharing and reuse across operational domains to reap the benefits of standardization.

Spurring Innovation

Rather than impeding innovation, as some initially believe, standardization can be a catalyst for innovation. By standardizing and sharing software and systems across operational domains, you have a more robust set of minds and experiences able to collaborate on new requirements and systems. You're building a pool of talent within your organization that can provide input, ideation, and implementation of new features and functionality without the sometimes-lengthy onboarding cycle.

Standardization also speeds implementation thanks to familiarity. The more you work with the same language and libraries and toolsets, the more capable you become. That means increased productivity that leads to less time spent building wheels and more time considering how to differentiate and add value with new capabilities.

Standardization is an Opportunity

Standardization can initially feel stifling, particularly if your pet language or toolset is cut from the team. But embracing standardization as an opportunity to build out a strong foundation for automation systems and software benefits the business and affords NetOps new opportunities to add value across the entire continuous deployment toolchain.

But don’t just standardize for standardization’s sake. Take into consideration existing skill sets and the availability of talent local to you. Survey universities and other businesses to understand the current state of automation and operations’ skill sets and talent to make sure you aren’t the only organization adopting a given language or toolset.

For the best long-term results, don’t treat standardization like security and leave it until after you’ve already completed an implementation. Embrace standardization early in your automation endeavors to avoid being hit with operational and architectural debt that will weigh you down and make it difficult to standardize later.

With standardization – just like security – sooner is better than later.