In this article

... even if you are not that interested in networking anymore.

The tag-line is a play on the title of an article I recently posted on LinkedIn: I'm not that interested in networking anymore...

Interestingly, I've received a number of responses, both in the comments section and as private messages, suggesting that many "networkers" share that sentiment. Tenured network engineers and architects are exploring new job roles and the necessary skills they need to be successful in the future.

I'd like to expand and emphasize on a few key points from my initial article.

Networking has become more about data than process

The first step in learning any programming language is a focus on syntax and structure. Your focus is on learning procedural concepts, the process.

Once you learn the procedural fundamentals, you apply that knowledge to a use case at scale. Your focus must transition from process to data, the sources and sinks which drive the workflow.

Fundamentally, intent-based networking is keenly focused on the higher-level business policy, the input (or data source) and automating the implementation of the desired state on all network devices. In many cases, the details of that process has been abstracted by the vendor. For example, Ansible Collections are a mechanism for distributing process (playbooks, roles, modules and plugins) developed by the OEM to manage a device.

The means of defining and articulating the high-level business policy is value stream mapping (VSM). The goal of VSM is to define the current state and develop a plan to implement an improved future state.

My advice to network engineers, realize that knowing how to configure a firewall rule is less important than why the policy is needed to support the business function. 

Configuration Data Maturity Levels
Configuration Data Maturity Levels

To effectively manage policy, you need to move from device configurations and tribal knowledge as the source of truth to structured data which is accessible to all the enterprise stakeholders.

Security policy comes from both internal and external sources

As applications move from on-prem to cloud-based Software as a Service (SaaS) offerings, the security policy for these services are frequently derived from external sources. One example is Office 365 (O365). Businesses implementing O365 must provide connectivity for end users to data and services accessed through hundreds of Microsoft locations across the globe. The user experience is optimized by minimizing latency to the closest O365 service entry point location.

To optimize the application, organizations which do not implement split tunnel VPN configurations at remote branches must now do so to meet the service level necessary to effectively use O365. The security policy for this configuration is published by Microsoft using an application programming interface (API). The policy is extensive and changes frequently.

This is an example of a source of truth originating external to the organization. The security policy must be applied consistently and accurately to all necessary devices. The policy (IP addresses and URLs) specified is not originated from internal sources, rather is determined by the service provider, Microsoft in this case.

When network and security configuration inputs are both internally and externally derived, you must focus more on validation of the configuration data rather than the generation of the data.

Embrace the cloud

As a network engineer, even if your primary job function is to support your organization in an on-prem deployment, the exposure you have to cloud services, security, networking and applications will influence your perspective in your current role. Today private data centers may be shuttered as workloads are moved to the cloud, but that may not always be true. Much of networking engineering is adapting to bandwidth bottlenecks. The same is true of workloads and data in the cloud. 

Cloud providers are being commoditized. 

One example is Minio. Minio is an open source object storage system which provides a consistent view of data regardless of where it resides in Google, Microsoft or Amazon's cloud, in your private cloud or in a co-location service. Data that resides in AWS today may be in a co-location tomorrow, and in your private data center.

Software and commoditization enables mobility of workloads and data.


Our industry is changing, which is an opportunity for growth. Take the time to invest in your future with 'side projects'. Side projects are a great way to show initiative and value for your next career role. There are many more learning opportunities across the site – sign up today and explore the labs.

Don't be left on-prem!