Network Automation Engineer Persona: Part One

This is the first post of a series on the persona between “network engineer” and “developer”. This role does not exist in myth, but it is a natural evolutionary step forwards. This position inherits skills from both ends of the scale, but in itself is an emerging role in organisations globally.

Why describe personas? They are important because:

1. They provide a roadmap for a career
2. They provide a set of skill requirements to master for a role matching the persona
3. They provide a set of tool consumption and usage hints
4. They provide a viewing glass to defining thought processes

Some of the challenges both vendors and network technology consumers are facing today are related to the set of evolving personas in our field, therefore it’s crucial to understand them properly. Remember when you wanted to be a network engineer? You became the persona and worked your way through a set of learnings. Your thoughts and habits changed, along with your recognition and self awareness.

Evolution of Roles

Every industry evolves and some industries disappear. The need to move packets about on the Internet hasn’t evolved out of existence just yet; our current highly generalized reality is: there are more packets on the Internet today than yesterday and less today than tomorrow. Network engineers have classically designed and deployed networks using protocols and features that for the most part have been accepted and standardized by the industry. Some of these protocols require expert level knowledge to design a topology, implement the design and operate properly. As our various global economies surge ever forward, there is a drive on infrastructure operators (small businesses through to the largest) to make more changes and faster and predictably more reliably than previously. Whether the infrastructure directly generates revenue or consumes it is mostly irrelevant to this problem. The burden on infrastructure engineers (which includes network engineers) only increases.

Our humble network engineer persona is set for an upgrade. I argue (you may disagree) that obtaining an expert level certification like the CCIE or JNCIE is no longer considered the manifestation or pinnacle of recognition that we have previously sought. Solving the ‘volume of changes’ problem and dealing with ‘business as usual’ events is now key. I am also not suggesting that having deep level knowledge of Internet Packet based technologies is pointless, it’s the opposite. For this volume/event problem to be solved, deep knowledge of your business and technology stack is an absolute requirement.

Looking through the lens of logic, this knowledge is now a prerequisite for solving the problem of infrastructure changes stated above and the problem we face has transformed from yesteryear.

For those that are scoffing or perhaps even choking whilst reading this, sure, there will always be those that blindly do things. Our industry will always have the “have a go” types as well as the junior, senior and advanced skill-sets. Depending on the skill level desired, mental investment will vary.

The Gaps and Misunderstood View

Today, network engineers think they need to be developers. Developers do not want to learn networking and most view at as some dying arcane art.

Network engineers know IP transmission protocols, Ethernet, IP routing protocols and how to configure various network platforms to reflect a design.

Developers know software. They know how to write, test and deploy code and consume other services like databases and message queues. They are responsible for creating and consuming applications that generate and consume revenue.

Network Engineers traditionally do not know NETCONF, REST or aged mechanisms like SOAP. They know CLI, SNMP and the routing and transport protocols required to construct a network that is capable of forwarding packets between a graph of points.

Developers do not know CLI or SNMP. They will not be familiar with NETCONF either unless they work in the network space. REST is a natural place for a developer to be comfortable in. Developers tend to focus on the how as opposed to the what.

We have a huge chasm. There is middle ground for someone that understands networking as well as the various APIs and understands how to articulate what the data flow through a process looks like. They may know one or two workflow platforms and how to pass agnostic data into a northbound interface and ensure the southbound interface can reach it’s target.

This gap is the “Network Automation Engineer”. If this role existed in higher numbers, many projects globally would truly benefit.

If you want to read on, here is part two.

• Tags: Career
• Categories: Career