Goldilocks and the three Vers.


Posted on: Nov 04, 2013 by Mike Smith

Atos - Goldilocks and the three versThe intent of the Atos blog platform is to provide thought leadership on a wide range of topics to our C-level and technologist audience. From time to time though, I like to contrast that content with some real-world practical conundrums that I come across in everyday CTO life.

We run a range of services for our customers; all at different levels of maturity, and at different stages of their journey with Atos. One thing they all have in common is a complex set of technologies (and services) that all need to be maintained, kept up-to-date and refreshed periodically. This applies to the hardware that underpins the applications and services, and also the plethora of software – from equipment manufacturers, Common Off The Shelf (COTS) packages, and applications that we (or others) have developed.

Let’s concentrate on the software world. This maintenance regime is tricky. There is an entire stack of software that at each level has interdependencies with the layers above and below it; and often with other devices or services too. From firmware, through hypervisor, Operating System, service packs, security patches, drivers, middleware, applications … to specific application (and user) configuration at the highest level. There are version constraints between all interacting components and this all has to be configuration managed and each component needs to be moved forward in turn (complying with all of the constraints) – it’s an 11-legged race, everyone shuffling forward in turn for the whole to slowly progress.

And this is where we could fall into the trap of thinking that it is just “too hard”. Let’s leave it at the current version; not spend any time changing it; avoid the costs. But this approach leads to madness ... increasing risks as software gets further and further out of date; not just security issues, but diminishing knowledge and skills … and ultimately there will be a cliff; some elements will eventually be forced to move forward in order to retain support from the vendor, or to avoid extended support charges.

What we’ve been discussing here is Lifecycle Management and I think it’s one of the biggest challenges we have in our industry.

Some key milestones coming up are pretty well known: Windows XP finally goes end of extended support in April next year – that’s pretty close if you haven’t started your move to Windows 7. (Or perhaps Windows 8.1; one popular technique is to skip a version or two.) Windows Server 2008 has been given some grace … end of extended support has now been moved out to January 2020. However if you still have services running on Windows Server 2003 you only have until 2015 to replace them – and this could be a massive undertaking with hardware and application implications.

We have the same dilemma right at the start of the lifecycle too. Which version of software do we start off with? The latest and greatest that was just released last week – with all the new bells and whistles? … and bugs? Generally no, the latest stable and established release is preferred. That’s why I suggested Windows 7, not Windows 8.1 – though in the right circumstances with appropriate controls, go for it. We have another live example at the moment – do we implement VMware 5.5? It’s very new, but there are some known issues … and perhaps there are some unknown ones too. Or do we go with 5.1, but that has some Single Sign On complexities, or do we stick with the reliable and understood 5.0. Not as sexy, but it’ll get the job done. But hold on, that goes out of support August 2016; not too far away and we’ll need to upgrade before too long anyway!

There is a new dimension developing too. Interactions with cloud-based APIs, whose version numbers and features continually evolve. That’s another dilemma, and one that is generally not under our control. Just moving applications to a cloud delivery model only hides the complexity; it’s still there – be careful.

So what we need to do in practice is manage the risk and the cost; but accept that we must invest the time and energy accordingly. I think I’ve cracked it too. Goldilocks Lifecycle Management; versions that are not too old, not too new. Just right.

Share this blog article


About Mike Smith

Chief Technology Officer, Atos Distinguished Expert and member of the Scientific Community
Mike has been in the IT industry for over 20 years, designing and implementing complex infrastructures that underpin key Government and private sector solutions. Setting Atos technical strategy, researching new technologies and supporting the consulting and architect communities. Previously Mike has held technical and management positions in British Rail, Sema Group and Schlumberger. He has a daughter and a son, both keen on anything but technology. Mike's sporting passion rests with Test Match Special, and is jealous/proud of his son's Ice Hockey skills.

Follow or contact Mike