I offended someone one time by referring to systems administrator as plumbers.

I certainly meant no offense…after all, can you imagine life without plumbers?  Furthermore I was considering myself in that category, as after all I am a systems administrator as well.  Anyways, even though it was a couple of years ago, sorry.

I still believe the comparison is adroit.  Given that I’m coming up on my 25th year of professional experience in the IT industry, I can say with some certainty that the comparison is more relevant than ever.

I’ve had the fascinating privilege of seeing this industry evolve over the years.  I remember when network engineering and systems administration was still seen as a “black magic” by many.  Toolsets and integrations were not very mature, or even existed at all, to the point that lots of scripting and coding had to occur to make things work.  Frequently, the capabilities that the organization or customers wanted didn’t exist as a product anywhere so we had to build it, many times by actually just writing the code or application ourselves.  And it wasn’t always webpages…many times it was command-line tools.

But over the years the industry has evolved tremendously to where most capabilities or features that you are seeking probably already exist, either as a product or integration somewhere, perhaps as an open source package, or more and more commonly as a SaaS offering all its own.

This is just as plumbing has evolved from a craftsman having to build pipes and fittings out of clay or whatever to buying a set of out-of-the-box parts at Home Depot that can just be fitted together to fit pretty much any use case.

So why do I make the comparison of IT to any other commodity, utility service?

As a service, people expect it to “just work”

All jokes about uptime and bandwidth aside, in general people expect their information technology services to just work.  Does anyone else remember when adding a new device to the network meant significant effort? Setting IPs, adding connections and configurations, configuring the device itself?  And if it wasn’t RJ-45-style Ethernet, oh boy you’re talking even more effort to add to the token ring or BNC terminators or whatever. But what about nowadays? The expectation is that you can just plug it into the wall…actually it’s not even that, it’s literally that your device finds and connects to the wifi access point.  People literally expect to walk into the building and have high-speed internet on their device with doing absolutely nothing, not even plugging anything in!

As the industry matures, so does the training and education mindset

Without sounding too much like an old fogey, I remember when the bare minimum to be an entry-level sysad was a college degree in computer science.  In retrospect, that’s really funny, isn’t it? What does algorithmic mathematics have to do with systems administration? But the expectation, even as a sysad, was for programming knowledge, data structures, knowledge of the CPUs and cache and RAM, and so forth.

But today, instead of a college degree more and more organizations look to specialized training and certifications.  If you need a top-tier Microsoft Exchange administrator would you rather, all other things being equal, hire a computer science degree or instead find an MCSE with a specialization in Exchange?  To be honest, I think someone with a Red Hat Certified Engineer framed on their wall commands my respect for their linux knowledge more than someone with a bachelor’s degree.

The approach to the job is maturing

One of things I remember most about being a systems administrator in the 1990s was that you had to really understand, at a surprisingly low level, what was happening on the wire.  For integrations between systems it wasn’t uncommon to have to go all the way to the RFC specs, or even reading source code. But the industry is so much more mature today. You can save tremendous amounts of time and headache by being able to connect systems together with open industry standards and connection configurations that are built directly into the system admin interface.  The required knowledge is less about 1s and 0s and instead more about being able to research products and quickly understand administration functions.

Furthermore, let’s say you have a task to stand up an Ubuntu Linux Server running nginx, to host a php application.  There’s probably a complete standard architecture and deployment recipe somewhere, perhaps even vendor-recommended, so you maybe don’t even need to do any analysis or configuration experimentation.  Instead of experimenting and designing from scratch, there’s a clearly-defined best-practice procedure to follow to deploy and configure, and you’re done.

So that’s why I think IT is like plumbing.  A plumber doesn’t have to have college degrees in mechanical engineering and fluid dynamics, they instead need to have experience and knowledge on which parts at Home Depot work best together to fit the use case they are trying to solve.

As the IT industry matures, the training and skillset required-as well as the cultural approach to the work-is changing drastically.  As either a practitioner or a manager, you have to keep in tune with these changes to ensure that you are keeping up with what is needed for success.

Postscript: I know for certain there are people who are going to disagree with me, who think that all your systems administrators should know how to read packets off the wire and troubleshoot problems.  But let’s be realistic (I call this “putting on the pragmatic overlay”). Given your time and budgetary constraints, are you going to fill out your entire team like that? Maybe you need one of two “troubleshooters” but I don’t believe it’s pragmatic to expect every member of your IT systems team to have that skillset.