I've been taking a step back recently and have been thinking deeper about development, IT and automation in general. �I've been reading The Phoenix Project which has spurred a lot of ideas and general observations about how to be successful at running a DevOps IT shop.

As I continue to read I can't help but see a repeating pattern of the way IT "work" should be done. Forgive me as this post was more or less thinking out loud.

The key is to genericize everything.

Genericize your PowerShell scripts, your server builds, your projects, your "work". Attempt to create generic templates that can be reused over and over and strive to define anything that may prevent your work from being generic as a parameter.

What's your "work"? IT Manager? System Administrator? Software Developer? It doesn't matter.

We all have "work". We all are presented with a plateful of inputs which we are then supposed to process into a useful output. What's the fastest, least error-prone and most efficient way possible to do this?

Treating IT work as a simple set of generic templates that accept a set of parameters (input) and providing a consistent, dependable result (output).

I realize this sounds like pie-in-the-sky mumbo jumbo so let me put some context around it.

Here's a tactical example you're probably familiar with. We have all probably either imaged an operating system or know what that means and what advantages that brings.

In the days of yore I was used Norton's Ghost product to deploy OS images to desktops. I'd get the OS installed, configure it how I saw fit, install the applications and make sure it was pristine. If then seal it up and push out a dozen copies to desktops. It was a huge timesaver but I was constantly dealing with exceptions to my image.

I'd always have a user with a specific requirement that didn't fit the mold. I'd then have to tweak multiple desktops with all kinds of different settings.

No matter how much I tried I could never create a "perfect" image that didn't require some tweaking post-deployment. �When I did actually tweak my image its take me forever because I'd have to install it, tweak and resell it again. It wasn't easily changeable.

Fast forward a few years where I was doing OS deployments with SCCM. With SCCM we were encouraged to make an extremely thin base OS image; an image with only tweaks that we were 100% positive everyone in the organization needed (generic).

We then used multiple task sequences to layer configuration changes and various application installs at build time. This prevented cementing changes preimage and then having to tweak the end result. Each task sequence step was universal and could be applied to any number of desktops (generic). If we needed to change something in the step we'd create a task sequence variable (parameter) to change things.

Writing good, reusable PowerShell scripts is another example. The goal is to create scripts as generic as possible and include anything that might need to change as parameters to the script. The same goes for functions inside the script as well! "Generic" thinking encompasses the entire spectrum of IT work.

Now take a harder topic to genericize like a project. A project has a plethora of moving parts. It has multiple inputs, variables and different streams of output. How can this concept apply here? Again, it's all about the mindset. Going into a project immediately start looking for patterns. Before making a decision, ask yourself three questions;

  1. What's the generic template? What attributes will go unchanged regardless of what context this is being applied in? This is your "slim image" or "reusable PowerShell script".
  2. What are the attributes that are liable to change given the context the process will run in? These are your parameters. These could be things like the people involved, time of year, current workload for other projects, etc.
  3. What is the type of output given the merging of the template and the parameters? Make it generic as well. Is the process supposed to produce a built server? Is it supposed to shore up security holes? If so, how can those outputs be genericized as well?

It's hard to put into coherent words what I'm seeing. I hope this post doesn't seem like some meandering nonsense. Perhaps I'm making it too generic. :) I believe it's a mindset. It's a constant reminder ringing your bell before you make an important decision that will force you to never make static changes. �Always keep everything possible as generic as possible and apply configuration �"layers" or parameters as often as needed.

Join the Jar Tippers on Patreon

It takes a lot of time to write detailed blog posts like this one. In a single-income family, this blog is one way I depend on to keep the lights on. I'd be eternally grateful if you could become a Patreon patron today!

Become a Patron!