Establishing technology standards is not hard. Pretty much any first year college graduate can develop a list of products, vendors, and industry solutions that will enable the delivery of our business requirements. Although, a first year graduate student will likely choose products that are free and easy to use, rather than those having industrial support, but that is a different issue.
What’s hard, and I mean really, really hard, is developing a migration plan that gets you from the current state of whatever and heaven-only-knows to a nirvana state of only approved standards. To be clear, there are solutions to every issue I’ll call out in this post, it’s just that none of the choices are easy.
Here’s an example. Six years ago we deployed an application with six servers; two web, two application, and two database systems. Two years after that we increased capacity on the application and database servers by adding four more (two each). A year later, we added another application server and another database.
Today, we learn that the original six servers are reaching end of life and need to be replaced. This scenario is far more common than you might think.
Understand; half of the servers in this system have not reached end of life. If we just replace the aging servers, we will have to grant exceptions for the replacements or else the newest hardware will have (possibly) incompatible operating systems. At the very least we could have half the application on one version of the OS, and the rest of the app on another.
Additionally, our data center location strategy has changed and as a result the web and application servers “should” be relocated to another city.
So, here’s the difficult situation; do we upgrade all the servers and also replatform the whole system to the “correct” data center? Consider that the cost of upgrading the six newer servers and moving the application to the other data center will more than double the cost of what is actually needed.
The fallacy is that systems reach end of life as a combined unit, rather than as individual elements. You know this not to be true. We have all experienced the situation where a new version of software requires the latest hardware to run effectively. Anyone who took the jump from Word 97 to Word 2000 knows this all too well.
The notion that you can easily get to a new “end state” through incremental attrition is not true. At some point, you either have to upgrade solutions that are not due to be upgraded, or wait until all components are old, with some of them being very old.
Neither of these choices is appealing to an organization that tightly controls costs. So, pick your poison; Keep it cheap and only upgrade what must be upgraded - and approve exceptions. Then approve them again, and again as the cycle just repeats itself. Or, Upgrade everything when the first components reach EOL, losing the depreciation allocation on the recently acquired components. Or, wait until everything has reached EOL, and run the risk of running on components that cannot be replaced, or are no longer supported.
Developing standards is easy; exception management is hard, as you have to balance the desires for consistency/simplicity, versus costs, versus risks.