Is the Network Administrator Role Going Away?

EtherealMind: Please welcome Ziyad Basheer to his first post on EtherealMind.

Is the Network Administrator Role Going Away?

Network automation tools are nothing new, but vendors are starting to implement deployment simplifying tools such as Cisco’s AutoQoS and AutoSecure. These tools for reducing repetitive deployments’ costs and assist configuration are a mark of a trend. Dynamic deployment tools will only get more popular and eventually gain mainstream deployment within the multiple facets of the network.†

What does this mean for network professionals? Marginal network administrator roles are the ones in question here, as automation tools do not alleviate the need for enterprise and service provider network architects. Despite the fact that the more recent tools include dynamic application discovery and automatic network configuration, the network still needs to be designed.†

Who will be affected and who won’t.
* Pre-sales engineers – won’t feel any†repercussions as products will still need to be sold
* Post-sales consultants – interoperation with pre-existing gear will still be required.

The main category in which this will have an immediate impact is in the mid-size network category, or at least that’s what it looks like at this point. The duties of mid-size network administrators (200-500+ users) will lessen, causing the businesses to outsource the network inside of having it maintained in-house. This is already happening in small businesses which usually outsource the network to focus on their core business. Medium sized businesses however occasionally have in-house network administrators.

Automation won’t have an immediate noticeable impact. It’s merely an emerging trend at this point, one that we need to be well aware of as this is how the future of the industry is manifesting itself. Vendors are integrating these configuration tools onto the products diminishing the need for third parties to configure them; part of selling an ìend-to-end solutionî.

While this might not be prevalent in today’s networks, that day is coming. Eventually most of the network configuration tasks will be automated. As a network professional, how do you see yourself preparing for this shift, and will you have adjusted for the shift by then?

  • Tony Bourke

    I don’t think we’re going away, but I do think the role is evolving. Most technology is the transition of stuff we used to care about into things we no longer care about (automated or otherwise negated). Its like IRQs on PCs. It used to take a lot of planning (or rather no planning and a lot of troubleshooting), now its something we don’t ever worry about. We’re free to spend time doing other more productive things.

    There’s a lot of cool places networking could go that won’t scale with someone doing “int Superethernet 1/1″ on devices. Perhaps we’ll be more designers, more super villains than henchmen. The new data center role will come with a cape. “BEHOLD MY AUTOMATED FABRIC!”

  • Omar Sultan

    You raise some interesting questions. Our experience at Cisco IT, where we have heavily invested in automation, opex has done down, but not from headcount reduction. In fact automation has freed folks to work on more useful stuff (moving up the food chain, getting embedded with LoBs, etc).

    Mid-market is much more interesting as you note where there is pressure from more than just network automation. I think cloud services (IaaS and SaaS) will have broader implications for IT in general in this space. While the changes are not going to happen overnight, they will happen.

    My advice to folks in the space is to specialize in something to increase your value to your org–this might be technical (security, virtualization, mobilty) or business related (app-expertise, reg compliance).


    Omar Sultan

    • Ziyad Basheer

      Hi Omar,

      Thanks for commenting, great point there, the convergence of the IT disciplines. Another important thing to note is that IT professionals working for organizations usually wear more than one hat depending on the size of the organization, i.e. part network, part security, etc. Which as everyone is well aware decreases as the size of the organization’s infrastructure increases and more IT specialists are brought on board.

      Granted, the IT professional role within mid-size organizations will not fade-away, but as you and Tony Bourke pointed out above, the focus will shift from networking to other business enabling processes e.g. facilitating and managing the cloud services. Which is what I meant by the “Network Administrator” role going away, will the focus remain on the network? Very unlikely.

      Ziyad B.

  • Tony Brown

    Nice post!

    It must be really difficult for administrators nowadays to get the experience and work up through the ranks to become designers and network architects, especially as mundane tasks are offshored more and more.

    • Ziyad Basheer

      Thanks Tony!

      IMHO network administration in and out of itself is not the best career move an IT professional can make . In the sense that you’re hands-on is limited by the equipment the business you support has, your world is limited by whatever gear they have, only fun is during upgrades (Which face it, are not as often as we would like) and bringing up new sites. Network administrators are sort of care-takers. Perhaps gaining experience in that role and move onto consulting, which means constant change and a variety of solutions.

      But if one is seeking career progression consulting or contracting is usually a better career move, better exposure to various network setups and experience.

      Ziyad B.

  • Ben Story

    I disagree that the role will go away. I think more so that it evolves as all roles do. Things that we do manually now won’t be that way in a few years, but there will be something new that will have to be done manually. When was the last time you tweaked a buffer for a switch or router port? Now days we can mostly let IOS handle that, but that used to be a setting people manually tweaked.

  • Alex S

    There are Auto-this and EasyThat, automated tools that are intended to make life of engineers easier – or, more common, that the job can be done by anybody (= cheaper). I see it within company I work for, heck, even I am “outsourced workforce”. Filling in fields from given spreadsheet and hitting “Submit” button in browser can be done by anybody. But you’ll still need hero in shiny armour armed with Sword Of Ultimate Commandline (+3) being able to clean the mess and save the day when sh1t hits the fan and The System breaks. I want to be the one understanding what’s underneath.

  • Christopher Young

    I think that automation tools basically do the common tasks that none of us really want to do anyways. Backing up configurations, checking memory and CPU utilization, scanning configs for default credentials etc… It’s chores. Same way we have to make the bed, put out the garbage…or get a maid service.

    The real issue I see is in the coming years is in the future generations. Those chores teach people a lot of good habits. I wonder where the next generation of network admins will learn that VTP is a good idea in theory, not in practice. There are so many ” just because you can… Doesn’t mean you should” lessons you learn when you are the pfy. I wonder how we are going to replace that training ground….


    • Ziyad Basheer

      Hi Chris, I see where you’re coming from. What I was trying to convey in the blog post however is the fact that “smart” devices are on the horizon. Dynamic self configuration, reactive reconfiguration (in response to SLA measurements) and so on.

      The issue you’re pointing out can only be solved through experience. Vendors evangelize their proprietary protocols as if they were the greatest thing since sliced bread, but that is to be expected.

      Thanks for sharing your thoughts,
      Ziyad B.

  • Ben Johnson

    I agree with what – I think – is one of the points Alex S is making. There’s always going to be value in understanding what underpins the automation, especially if the automation goes a bit haywire.

    I’d liken this to PC software in my experience. I started using computers around the time of Windows 95, not DOS, and therefore had no real knowledge of what was really driving the software. Then along came Linux, which was a major revelation to me (and a godsend) as it forced me to learn a much more fundamental approach to solving any given problem. For example, ipchains taught me how firewalls (mostly) worked at the time. And, let’s face it, part of the joy of working in networking is working with the command line, not “Next, Next, Next, Finish” :)

    Admittedly, I’m still pretty young networking-wise (CCNA Sec). I like the idea of designing and consulting and I think that’s the direction I’ll be aiming my career. I’ve already got some experience with F5 kit, which is an interesting diversion that’s still related.

    Thanks for the article. It’s always good to make us think about stuff we might otherwise take for granted.

  • Mike

    I have heard this argument applied to everything from desktop techs to server admin/ops. Just because the tools “appear” to be getting simpler doesn’t mean that there isn’t an underlying need to understand exactly what they do. So any monkey can type- macro apply cisco-desktop. Does the guy next to me understand the dozen or so commands are pounded in for him automatically? Or does he only understand when I have a desktop, I type this single command for some reason?

    The desire to understand the technology and the underlying construct is what separates the “google tech’s” * from the men that bail them out when it all comes down around their ankles.

    Mediocre tech’s will always look for an excuse not to have to learn something and the excellent ones will understand the task at hand and decide when and where to apply the tools.

    * A google tech is one who googles an issue and systematically tries every suggestion that is returned without understanding or regard for the validity of the response.

  • Sam Stickland

    Gah! I was a programmer before a stumbled into networking. During my entire networking career I’ve always tried to automate things. IMNSHO it’s the only way networks can a) scale and b) be properly regression tested. But it’s always been a huge uphill battle. A lot (most?) of the commerical automation tools I’ve ever seen have been disgustingly bad, and the lack of an API or a even just a defined schema for network configs is a massive stumbling block.

    Oh, and everywhere I’ve ever worked anyone in network is overworked, particularly in operations. Some decent automation would actually free people up work on more important tasks.

  • Pingback: Network Dictionary – “Google Technician”()

  • Ian Bowers

    In my NOC we have IPT, IPCC, WAN/LAN, and Security engineers (I’m in the last little group). The NOC jokingly refers to e WAN/LAN guys as the “RMA engineers”. Between the initial design and subsequent redesign phases of a given network, there tends to be very little need for your basic WAN/LAN engineer or admin. Sure circuits will need to be called in and telco yelled at from time to time, and once in a great while someone will plug in an a poorly configured piece of gear that will bring your VTP or EIGRP environment to it’s knees. Bu for the vast majority of the time, everything goes pretty smoothly. Our poor WAN/LAN guys have years or even decades of experience, some have their CCIE (even one triple CCIE), and we have hundreds of customers around the globe. But for the most part any time they get a call, it’s a failed fan or cisco-blue colored brick that has to be replaced. They very rarely get any fun issues to sink their teeth into. Wan/lan

    • Ziyad Basheer

      Ah yes, the infrastructure vs services argument. The whole excitement in network engineer lies in customizing and tailoring the network for the customers’ specific needs.

  • John Harrington

    Large network owners want multi-vendor devices and ability to scale rapidly using automated build and deployment methodologies. Being able to expertly navigate the CLI of any single vendor will decrease in importance over the coming years, as deployment and troubleshooting become automated.

    The CLI will abstracted and absorbed in to a provisioning system. CLI knowledge will still be needed for verifying & troubleshooting the provisioning system. But network designers need to move up the stack and learn a hybrid skillset of both network engineering and scripting/coding.

    Every design you produce should answer the question, “how easy would it be to deploy/verify/troubleshoot this config in an automated manner?” Network designers will increasingly hand off their designs to a provisioning system, not a deployment team.

  • WhattheRick

    The trouble with getting a Walmart type everything under one roof deal.. is that this service will become a cult, a religion, and yes, you have them to handle your stuff, but they are also going to start handling social issues that have nothing to do with computers and networking…. it’s going to morph itself from a service to a form of government…. look at Walmart, look at Cisco… firing people who write books on Traditional Marriage… etc…. I am telling you…. better to keep things in house, that way they can’t control you!  Ever set up a website using a guy who gets all your stuff under HIS account??  Well he falls off the planet and you lose your crap or worse, he controls your stuff!!

  • cabling school Fresno

    These new tools in network administration are really great in simplifying the task of ensuring that computer networks are secured. However, those network administrators should not be threatened that they will lose their jobs because of this automation. They should train and educate themselves with the latest trends in the industry to ensure their tenures. We must remember that these tools are still operated by humans, therefore, their expertise are still needed in the industry.

  • Pingback: On Network Engineers and Industry Eccentrics | Twilight in the Valley of the Nerds()