I think there's a fallacy in the idea that there is any such thing as a ‘traditional’ SysAdmin. I've functioned in the SysAdmin role in many organizations, and many types of IT structures and industries – in every single instance my job description was notably different from the previous and subsequent employer. Different organizations have different needs – sometimes completely irrelevant to the local vs cloud question – sometimes it's just a function of the technological maturity of the organization itself.

Yes, the SysAdmin role is evolving. It's been permanently evolving, and it will continue to evolve, indefinitely. As the landscape of hardware and software changes, the implementation methodologies (local server room, off-site data center, ‘cloud’) change – so will the day-to-day duties of the ‘SysAdmin’ as those implementations will require. The nature of the operating systems running those systems has changed, and the skillsets that a Unix Administrator had to have in the 1980s is radically different than the skillset that a Win2008 administrator needs today – unfortunately.

I think part of the point of some of the posts was that it would be nice if today's ‘sysAdmins’ still had some of those skillsets – like the ability to write scripts, parse and analyze logfiles, understand the operational implications of implementation decisions.

For example, every day I deal with sysadmins who don't even know there is product documentation – much less having read it – so they're trying to troubleshoot why something isn't working, without even knowing how it's supposed to work, or what the correct configuration of the environment should be to make it work.

Another group seem to be unable to diagnose why the environment is not working – fundamentally, it's a flaw in not being required to understand the underlying network/application architecture, but secondarily, it's simply lacking the skillsets to think analytically – merely just double-clicking on an EXE and clicking Next on some wizards is what seems to be all that's required to get a job as a Windows SysAdmin in many cases.

Don’t get me wrong – I love the simplicity of product installations that we have today (I still remember installing Netware v2 with eighteen floppy disks!)-- but making things simple to use should not be an excuse for failing to comprehend how they work. The fact that I can configure DNS on a Windows Server in 10 minutes by clicking a few buttons and filling in a few textboxes with names and numbers, and it works, is a far cry from understanding how the system works underneath the dialog, or where to look for fixes when it doesn't work the way it did yesterday when I turned it on.

Part of this, I think, is the evolution of how people enter the IT job environment. In the early days of computing, most persons were self-taught, but organizations invested heavily in developing the necessary skillsets in their staff to perform the functions they needed. Sometimes that was a function of the complexity of the products themselves. One of the reasons we sometimes see such disparate skillsets among “Unix Admins” vs “Windows Admins”, is because Unix requires that level of knowledge. Microsoft has managed to bury a lot of that complexity in the Windows admin UIs.

Unfortunately, though, the conceptual knowledge is also lost, so configuring the system is what is taught – but troubleshooting it when it doesn't work cannot be done by staring at a configuration dialog. That requires conceptual understanding of the processes and the architectural relationships of the components involved.

Today we teach sysadmins in 2-year schools; we teach them to pass Microsoft certification exams; and we teach them how to fill in blanks and click on buttons – something 40 years ago we would have classified as a clerical job (filling out forms) – but we do not teach them the *systems* and how to manage them.

Assuming all of this is not going to change – one of the things that's going to radically affect the ‘sysAdmin’ landscape is a notable separation between those who fill out forms, and those who solve problems.

Bottom line, though, there will always need to be persons who are tasked with operating, managing, and maintaining the platforms upon which applications are made available to end-users, and those who wish to function in that role will need to evolve with the landscape – both for filling out forms, and for fixing broken systems.

Lawrence Garvin is a product manager for SolarWinds Patch Manager.

Related Links:

Lawrence Garvin, SolarWinds Product Manager, Joins the Vendor Forum