Well, we aren’t. Or at least I’m not. But it does seem that experienced network engineers in small to medium-sized enterprises seem to know about a lot of things. This is evidenced by listening to the Packet Pushers Podcast itself. Today I was catching up on a few past episodes, and the conversation in just Episode 63 ranged over the topics of voice, server virtualization, data centre environments and much more. Why is this so?
The simple reason is that the network reaches out and interfaces with everything today. While the server jockey or the desktop support person can exist inside their own environment, the Network Engineer has to know about both those things and everything in between. In many enterprises, you can see the stratification of IT staff which results in the ever-increasing specialization of skills. For example, how often have you seen the “database” team, who look after their Oracle environments, but the servers are run by server admins, and the applications using those databases are maintained by yet another “application” team? And in many cases, the teams don’t much care how the others operate. The applications team only want to know the API specs, the server teams look after disk and CPU, and the database crew makes sure that nothing conforms to third normal form.
But the Network Engineer needs to interface with all of these teams. What latency is acceptable? What ports and protocols are used? What physical interfaces are you using on the servers? And on and on. How many times have you found yourself poring over the manuals to some software package or doing netstat commands on the servers to diagnose why that new app won’t come up. Similarly, with something like wireless, invariably the network engineer becomes involved when the new executive wants to get their new gizmo on the wireless, so into the network configurations we dive on different OSes, hardware platforms, phones and tablets.
With the rise of IP telephony and virtualization, the network is extending further and further into realms where previously the specialists reigned supreme. Voice is now another network service; where in the past maybe the network engineer’s interaction with voice was restricted to presenting some ISDN or ATM lines to a PABX and the voice specialist looked after the “real” voice service, now voice is being incorporated into the network. Phones are network devices – phones are switches in themselves. Codec choices, QoS configurations, PoE: these are all now part of the network. In virtualization, the convergence of fabrics means the merger of storage and network – FCoE, iSCSI and so on. The network engineer now needs to be aware of storage systems, requirements and integration.
So even if you are not directly involved with these areas (and in smaller shops, you may be the go-to person for all of these), you need to be aware of them, how they interact and impact the network.
Thus, the podcast discussions on Packet Pushers roam far and wide. Unless you work in a very large organization where you may be able to firewall yourself off into pure routing and switching, or specialize in a particular role like voice or wireless, odds are you will be reading, researching and learning constantly. This does not necessarily seem to hold true for other IT areas, except probably security, as they are concerned with the entire cross-section of the enterprise as well. The danger for network engineers is that while their knowledge might be a mile wide, it may be only an inch deep, if you know what I mean. I personally experienced this working for a long time in a fairly small place.
There is just too much now to know everything about everything. You can know everything about a few things, or a few things about everything. What this can mean is that when you don’t have the time to specialize, you will end up using your resources inefficiently. For example, if you can only afford the time to implement your voice system to the base functional level, you are missing out on so much functionality. As we all know, Cisco equipment comes at a reasonable price premium over some other brands. How often have you been asked by management “Why can’t you replace those expensive 2960s or 3560s with some NetComms from the local chain store? Well, some of that premium comes from the features you pay for. But do you use them? Do you even know about them? Do you have time to explore, investigate and implement the features that can make your life easier or improve security?
Increasingly it seems the answer is “no.” So what is the answer? I don’t think there is one. One downside of technology convergence is the elimination of specialist teams, especially in small or medium-sized enterprises. Voice, data, video and storage are becoming network services, therefore in the short-term, management seems to lump these into the network space and the previous teams are merged or downsized. Eventually, as organizations grow, the specialists will once again emerge. But instead of an isolated PABX engineer, the new voice specialist will be a network engineer with a focus on voice services. Ditto for wireless, storage, video, and so on.
Is this a good thing or a bad thing? It depends upon your point of view. Personally, I think it will end up being a good thing. Network engineers at this point in time have the ability to choose an area they are interested in and develop their skills to become specialists. Or they can take the opportunity to remain generalists, with a foot in different camps. The network is the platform, and the routing and switching will be the foundation. And let’s face it. In the glorious blah-blah-cloud future, once all the apps, storage and voice services are moved to the cloud, the enterprise engineer can return with those foundation skills to blissful purity of pushing packets at layer 2 and 3.
About Matthew Mengel
