A common question we get asked by our management, kids, and others who want a desired outcome. Besides being asked, we may ask this same question to our vendors, technical support, and others in order to provide a sort of pressure to receive a desired result. As you can see, this question has been historically seen with a negative light. However, I’ve recently began asking myself this same question in order to push myself outside of my comfort zone.

Since I’ve began studying for the ENAUTO exam, this question has become more prevalent than ever. As I’m learning the different APIs to each of Cisco’s flagship products: DNA Center, SD-WAN, and Meraki, I’ve began figuring out new possibilities on integrating these products with other tools in the IT workflow. Whether we (network engineers) like it or not, we must begin understanding how we can create business-driven integration points between the suite of products that provide the overall end user experience. You can no longer be stuck in your silo, otherwise, your career growth may be limited. With companies doing more with less, an employee must understand the larger picture, along with the technical requirements of their day-to-day job. Without understanding the larger picture, you may not be able to provide the additional benefits or innovative ideas that’s needed to help your company grow.

A way to level-up your value is to figure out how your team and department fit into the overall company. Obviously, your team provides IT services (network, storage, database, etc.), but I’m referring to knowing the actual business and your customers. A small tech company and a large financial enterprise are going to have different types of customers with different business goals. These different business goals can change how fast or slow your IT evolution happens. This includes tech refreshes, implementing newer technical solutions (i.e. SD-WAN), and other new “shiny” products. Selfishly as networking nerds, we always want to try the new and shiny products. However, in order to make IT work, you need to understand how your services are being perceived and consumed. For network engineers, this tightly couples with business application performance. Given the type of business, you may not be able to rip and replace your existing technical WAN or LAN design because network uptime is of utmost importance and even nightly maintenance windows are out of the question. So what are we supposed to do if we aren’t allowed to buy the new and shiny tool but want to be innovative? We ask ourselves “Why not?”.

Some of the easiest ways to become innovative without the need to drop 6 or 7-digit PO is by assessing the existing network devices, tools, and applications and figure out how we can abstract. Abstraction allows for you to focus on the business-driven problems, instead of figuring out how to upgrade 1000+ network switches. Whether your network device or tool has an API or still requires configuration via CLI over SSH, there are many network automation frameworks available (most are open-source!): Ansible, Terraform, Puppet, Python (including its many libraries), etc. that can help create abstraction. Network automation shouldn’t be considered innovative by itself, with most of the common use cases being configuration auditing and/or pushing mass configuration across the environment. Using network automation with these use cases really just alleviates duties from the network admin(s) and avoids deployment errors (given proper QA and testing). The real innovation begins when you combine techniques that network automation offers and provide value to your business and consumer. This is where I’m beginning to challenge myself and push outside of my comfort zone – providing innovative solutions using my network automation background.

One thing that I’ve been thinking about recently is “What’s next? After this wave of network automation and coding, what will we need to learn ASAP to stay relevant?”. Figuring out what’s next is on most people’s minds, but I’ve began to think about it from a business’ perspective, instead of the traditional technical perspective. One of my first thoughts is the consumption and integration of tools in the future. With APIs being common to applications and tools these days, we (network engineers) need to begin thinking about how our tools can communicate with one another – also known as service chaining. We get questions now about how we can integrate our network automation platforms, like Ansible or Cisco DNA Center, with ITSM platforms such as ServiceNow. My initial reaction was “Oh, that’s a software developer’s job.” Then, after thinking about the problem and wondering why I couldn’t at least take a look at the different parts required for the integration, I asked myself, “Why not?”. Now, I’m not saying network engineers need to become software developers. What I’m saying is that we can take the automation and programming skills that we are learning as part of this new age of networking, and apply them across other domains. You may think that’s over-extending your reach, and you may be correct, but the idea is that if you can provide that sort of value to your company, it shows the versatility you can offer in the future.

Besides creating integration on the back end, I’ve also thought about, “How do we begin socializing and distributing the scripts we are creating for other engineers?”. Yes, we can write SOPs on how to clone them from a git repository, spin up a virtual environment, install the script’s dependencies, and run them locally in a terminal, but what if we can provide an interface that everyone can consume – a web GUI. Recently, I’ve began looking at web server services such as nginx and Python web frameworks such as Flask, Bottle, and Django. The web GUI could be a portal for other network engineers to run automation scripts via point-and-click, or a self-service portal for other teams (i.e. requesting an IP reservation). I know this is beginning to look and sound like software engineering, and it definitely is going down that path, but “why not?”. This begins the next evolution of how we can provide more value and innovation to our company, without the need to buy the latest and greatest.

To wrap it up, I challenge you to find another area to apply your existing or newly learned automation skills. Whether that’s a Python coding project or building a TIG/ELK stack to collect streaming telemetry, pushing yourself to unfamiliar territory will allow you to learn what’s possible and allow you to grow. Remember, always ask yourself, “Why not?”