The Network Automation Journey – It’s about Culture

I love this article by Tim Fiola, entitled “A Note to Management About the Network Automation Journey – It’s About Culture.” It does a brilliant job of explaining the real challenges around network automation. I’m going to riff off it a little bit today, drawing comparisons with OSS/BSS (which do happen to have a role to play in network automation).

He starts off with this gem:

“Most of the blog posts and information about network automation focus on the technical details and are directed toward the network engineers. There is more to the network automation transformation, however, than the technical aspects. In fact, one of the most important aspects of making the network automation transformation ‘stick’ is the cultural component. Network automation is a journey, and it does require a cultural shift throughout the organization, including engineering, management, and human resources (HR). Management needs to understand this cultural shift, so it can better enable the transformation and make it permanent.”

So true for network automation and OSS/BSS alike. There does tend to be a focus on the tech. But I’ve seen tech that’s perfect, but is un-usable because the culture / change-management aspects haven’t been incorporated into the transformation program. There’s a saying in golf, “Driving is for show. Putting is for dough [cash].” If we paraphrase this slightly for the OSS/BSS/automation world, it becomes, “Tech is for show. Change/culture is for dough.”

Tim continues:

“The technology part of an automated infrastructure is a solved problem: we have the technology. Ultimately, it’s the cultural component that makes network automation successful in the long term.”

I’m not sure that the automated infrastructure problem is 100% solved, especially for physical infrastructure, but his point remains valid.

“This cultural shift, at its heart, means changing the expectations around how many people it should take to run a network, along with the skill sets the people have. In order for the automation transformation to keep long-term momentum, it must be supported by management: everyone, from the first-line manager, executive management, and all the way to Human Resources, must play a part to sustain the appropriate culture.”

I’m perplexed by the conflicting messaging that often exists around network automation. Openly, there is the message of Zero Touch Assurance (ZTA) and the head-count reductions that support automation business cases. However, as Tim suggests, there does need to be a change in expectations about how the network is run. The conflicting, and perhaps even subliminal, message to ZTA though is that telcos are often built around an “empire-building” mindset, where reduction of staff leads to a reduction in status for the managers within the organisation. The RFPs requesting OSS/BSS tools still seem to include requirements that assume a large team is required to run them and the network. They’re rarely about comparing vendors for operational efficiency.

But I digress. Tim instead cleverly pivots to aligning automated infrastructure to corporate objectives and cashflow, as follows:

“Many firms have a high-level corporate objective to increase cash flow. A business is interested in executing as many value-generating workflows as possible because those workflows produce value and ultimately revenue. An automated infrastructure directly supports this high-level objective by allowing the business to:

• Execute revenue-generating workflows quicker, which brings in more revenue sooner.
  • This interval, between when something is sold versus when the revenue is realized, is often called the quote-to-cash interval.
  • Shrinking the quote-to-cash interval helps cashflow.
• Execute workflows with less friction, which leads to more workflows being executed, which leads to greater throughput and increased revenue.

Companies care about executing workflows quickly and without friction; when they do this, they minimize the quote-to-cash interval and increase the total amount of throughput, which increases cashflow.”

Exactly! The whole idea of investments in OSS, BSS and network automations are about executing workflows quickly and without friction. But they’re also about making things more repeatable, reliable and enduring, as suggested by Tim as follows:

“Worker turnover happens everywhere and all the time. In the worst case, when an employee leaves, all their knowledge leaves with them.

With an automated infrastructure, even when a person leaves, they leave behind a lot of their knowledge, enshrined in the automation infrastructure.”

Speaking of employees leaving,

“Another common high-level corporate objective is employee retention and satisfaction. For a moment, imagine your network engineers freed from high-volume, low-value intensive tasks. For example, many highly skilled network engineers are often relegated to perform tasks such as

• O/S upgrades
• [Etc deleted for brevity]

These types of tasks are well below the engineers’ skill set, but network engineers are often called upon to perform these tasks simply because they understand the technology and full context around the task. In addition to being below the skill set of a network engineer, a lot of these tasks also happen to be tasks that machines are great at.

Relieving your network engineers from repetitive, high-volume tasks that are below their skill set will improve employee satisfaction.

An automated infrastructure can perform these tasks and give engineers the time to use their high-level skills. This benefits the company because their employees are much happier; it also benefits the engineers because it allows them to exercise high-level skills that add more value.”

This shift to staff only performing higher-value activities should be an absolute objective of any investment in OSS, BSS and network automation. However, the skills, and the way they’re measured, changes appreciably too:

“One of the most striking examples of daily tasks changing in an automated environment is configuration management: instead of manually configuring devices at the CLI, network engineers will transition to maintaining configuration templates. This is a great example of the power of abstraction: instead of trying to manage the configs on hundreds or even thousands of devices, the engineer will design and maintain a relatively small amount of configuration templates, and then use those templates to deploy consistent configurations to the many devices. So, your expectations around how your engineers spend their time will also have to change:

• They will spend time on tasks such as templating, coding, etc. to automate away low-value tasks

• They will spend more time on higher-level network engineering”

But some engineers will strongly resist change, as per our earlier reference to skilful execution of change management initiatives. For some engineers, their expertise with CLIs are their one-wood (to keep the golfing analogy going), their primary sense of corporate self-worth. But as Tim says,

“The CLI-to-template transition is one of many cultural shifts that comes along with an automated network infrastructure. As with any cultural shift, there will likely be resistance among some engineers who see this as a threat to their jobs, skill sets, certifications, etc…

It will be important to understand that this is a huge change for your engineering staff, so you will have to be patient and educate them on why these changes are needed and how they benefit the engineers. In addition, it may be necessary to provide multiple opportunities for technical training so, as fears and resistance subside, the engineers have the chance to get on board and learn how to operate in the new environment.”

Like I said, great article from Tim. Kudos to him for taking the time to share his thoughts with us all in his article. Please jump over via this link and check it out from cover to cover.