Cost of Customization – Cost of Variablization

Just made that up, LOL. Variablization, not sure that’s a word but it describes a recent conversion project I was privileged to work on. 

We are converting MANY major products into our Workload Automation environment. I will not mention product names, as it really doesn’t matter in the big scheme of things, at least IMHO.

The challenge and part of a normal lifecycle of powerful and multi-faceted products is that they tend to be customized along the way. This often involves using variables and product-specific specialized implementations of common automated functions to optimize existing processes and automated workflows.

On the surface, and in the short-term, making configurations easier to maintain by using variables and promoting re-use seems a “good way to go”, and for the group responsible for creating the configurations it can reduce the amount of initial work they need to do.

Likewise, if we consider the rise and need for ephemeral workloads (workload that can be demanded in depending on current conditions or preset variables, so that the workload can run differently depending on requirements determined at runtime or just before) the value of customization is apparent.

Now, enter ITIL and DevOps and other Change Management and Auditing processes. We have to consider the costs of support where we require well-documented support processes (including remediation) for Operations and those in the real-time support roles. This customization and variablization make troubleshooting and re-factoring much more difficult. To the point where, only the person who actually created the customization and/or variable values can determine what happened, needs to be done to remediate, and why. In other words, the predictability of the workload can only be determined at “runtime” because the customization and/or variable values can and do change each time it runs. 

Likewise, as time goes by, automation tends to cause support personnel to “lose track” of what is actually being automated (the process or workflow), and the original developers move to different positions, companies or experience life events and are no longer available for support.

In today’s modern IT world, where we can no longer afford complexity on the support side to minimize work on the dev side and given that things (products and personnel) will change over time, allowing this level of customization and variablization has a significant cost in every part of the application and enterprise workload lifecycle.

As an example of variablization I have witnessed, we have variables being used as parameters to jobs, scripts and executables. These jobs, scripts, and executables use variables to start and pass to other executables, and products that in turn use variables at all levels of their processing. When this is converted or support changes, the skill level required to change, convert, and support is significantly increased.

Modern IT includes many different and specialized ways to automate, just because we can doesn’t always mean we should, and as with any lifecycle that involves multiple groups across IT, we can only move as fast as the least mature group. In this case IT Operations or those responsible for 24x7 365 support.

After all this diatribe, a phrase I learned “a long time ago, in a land far-away” comes to mind. Keep It Simple Stupid (KISS).

Cheers