I completely understand the desire for stability in one’s production environment.  If an environment is performing activities critical to my business (booking orders, controlling my manufacturing facility, hosting a data warehouse, etc.) and it has been doing it successful for months or years why would I want to take the risk that comes from changing something/anything.   Yet there are times that I need to make changes.  I may need to add the most recent platforms to accommodate user growth, install the latest security fix, or take advantage of the latest Integrity VM capabilities.  So how do I do this while keeping the environment stable?

1.      Minimize the number of big releases. 

Recalling the past, customers would never touch a .0 release because they always wanted someone else to do it first.  Today we've enhanced the process with better testing and there is the ability to roll out new functionality that can be picked up anytime along the way…the customer's way - less disruption with improved release processing.  Big changes make users nervous.  They don’t want to implement anything that will destabilize the environment.  The more change, the more risk in a customers mind.  Some vendors will continuously come out with new versions of the operating environment and force customers to adopt it.  I personally believe, however, that it is better to make major version changes less frequent and then provide customers with new functions and fixes along the way in smaller bundles.  In addition, customers are looking for predictability in the patches/enhancements so they can plan for it.  Some of the more recent operating environments release security patches almost every other day driving customers nuts.

2.      Binary compatibility

One of the biggest challenges in moving to a new version is the time, effort and risk in recompiling and certifying applications.  This is a big reason for staying on older versions unless there is some compelling benefit.  If, however, the environment is always maintained independent of any change to the release, then the customer’s solution is much more stable moving forward. 

3.      Ala carte

Customers today like to have it their way.  Users don’t want to be forced to newer releases.  Users don’t want to adopt new functionality if they don’t need it.  In other words don’t change just for the sake of changing.  Instead, let me pick the changes that I want.  The key here is to give the customer the option to pick and choose which patches and enhancements they want to apply to their environment.  Don’t force them to move to the latest environment just to make it easier on the vendor.  On top of this you add the concept of bundling that makes ala carte selection easier for the customer.  In other words, give them “all new features”, “all fixes”, “all changes to enable new hardware”.  This ease of selection makes it much easier for customers to adopt and deploy, and most importantly gives them ways to manage the risk.  Additionally, provide customers tools that help them understand whether they’re current on security fixes, etc.  In short – ala carte, ordered and served in many different ways!

4.      Longer support lives

Often vendors will push customers to the newer release by cutting the support for previous releases.  Instead customers that aren’t ready to move or don’t see the need to move want to be supported.  They want to ensure that their environment is protected. 

The combination of these four items is what customers are looking for when they want to stabilize their environment.  If I’m missing something please let me know.  These are part of the key guidelines we drive towards in the development of our operating environments.

Don’t, however, be mistaken that by focusing on stabilization I am neglecting innovation.  Innovation is key to the future of our operating environments and in my next posting I will discuss areas that I believe still need progress within the UNIX operating system.