Windows 2003 Deadline Highlights IT’s Maintenance Issues

Dell released a poll report and white paper today, together with analyst firm Telsyte, which surveyed businesses in Australia and New Zealand on their approach to Windows Server version management. Having actually read the research report, I’m far more concerned about the spread of operating systems in use and the reasoning being why.

It’s not a bad survey. The sample size of 250 is large enough to draw some inferences, but you still need to be pretty careful about reading too much into things. Some of the results are drawn from a subset of the main sample, so the likelihood of statistical error start to get significant. 24% of people not aware that Windows Server 2003 support ends July 14, 2015? That’s with n=136, so the real proportion is anywhere between 16% and 32% (with 95% confidence).

Blah blah, boring statistics, blah blah, right? Well, no, because that’s the thing with surveys like this. If you’re not careful, you can pull out all sorts of inferences and draw the conclusion you wanted to, and point to the survey as ‘evidence’ supporting your position. If you’re basing business decisions on that level of sophistication, you’re going to have a bad time.

Instead, let’s talk about something we definitely can say about these survey results: IT departments are running multiple different versions of Windows operating systems that span a decade or more. A migration from one version to the next takes 7 months if we’re to believe the accompanying white paper.

I spoke to Dean Gardiner, Practice Lead for Data Center and Cloud at Dell, about the survey, and the discussion we had was thoroughly depressing.

Why Are You Like This?
Systems upgrades aren’t new, and yet we have some organisations with infrastructure spanning multiple operating system versions. Why? Lots of different reasons, none of them good. Some choice quotes from my discussion with Gardiner, and from the white paper:

These are not reasons. These are excuses.

“The majority of the challenges with the applications seem to be around SQLServer and upgrading SQLServer versions,” Gardner said. “Database dependencies become a big issue.”

“Back in the 2003 vintage, people tended to use shared databases across a number of applications. A lot of the time, customers have multiple applications sitting on one database, and it’s very difficult for them to extract themselves from those situations.

“I do think that most customers have done all the easy stuff,” he said.

For all the money spent on IT, is this really good enough?
Decisions, And Accountability
By easy stuff Gardiner means file-and-print servers and Active Directory, the kinds of systems that are at arm’s length from other systems, and that communicate over standardised protocols. They are loosely coupled, as distinct from these custom applications using specific versions of a database that is shared with multiple other customer applications. These tightly coupled systems are a challenge to change, it’s true, but let’s not forget that this is a problem of their own making.

Someone, at some stage, decided that building a custom application was warranted. They further decided that using a single, shared, database system was a good idea. Rather than second guess those decisions, let’s assume that there were, indeed, good reasons for doing so. Fine.

But these decisions had consequences. The benefits and perils of closely coupled systems were well established when I was learning about them in engineering school over twenty years ago, well before these systems were designed. However, and this is a point that is often missed, the responsibility for dealing with those consequences did not rest with those charged with making the decisions.

The rise of movements like DevOps is, in large part, a reaction to this issue. A planning and design team, often as part of a project, will make these decisions and then hand them over to an IT operations team who is then responsible for looking after the systems. Except, and this is a crucial point, there will be an application owner who uses the application and has a completely different reporting structure to the IT operations team. In some cases, the business owner will someone else entirely, further complicating the lines of responsibility.

Now you have some idea of the underlying reason for this kind of Windows 2003 upgrade mess. It has precious little to do with technology, and everything to do with how IT is managed.

It is, in short, a business problem.

Value In Use
Keeping the lights on consumes around 70% of IT budget, and while the amount varies pretty widely there’s broad agreement that it’s where the majority of the money goes. The companies I speak to assume a depreciation schedule on capital assets of three to five years in general, so if it takes you a year to run a project, any hardware purchased will spend 80% of its lifetime in maintenance mode. A project that takes two to three years to complete should be providing value for a lot longer than that to achieve any kind of reasonable return on investment.

Why, then, do organisations continue to use projects to drive the progress of their IT organisations?

The value of IT systems comes from them being used. Every day! Doing a project doesn’t provide value in and of itself, it’s the systems and processes that are put in place that create the value. I’ve borne witness to more than one ‘tech refresh’ project that dragged on for multiple years, and for what? To update infrastructure that no one ever sees, and often to provide no tangible benefits to the business. It’s simply replacing worn out equipment.

“The best case scenario for Windows 2003 upgrades is that you spend a lot of money and no one notices,” Gardiner said. “The worst case situation is you have a disaster.”

With incentives like that, who’s going to volunteer to run that project? If you mix in the reporting structure outlined about, with its inherently opposite motivations (keeping things running versus changing things, application versus infrastructure, IT versus business) you have a recipe for inaction punctuated by expensive, hasty change when there is no choice.

What if, instead of seeing this sort of upgrade as a project, it just became part of running the business?
You can trust your maintenance processes, because you do them all the time. Any bugs are detected by your testing systems, and if a new one creeps through, you get the n-1 system back online, add the new issue to the automated systems, and keep moving. You know your disaster recovery systems work because you use them regularly. There are no disasters, you just run things in a different place some of the time. Your systems are resilient because they are being constantly tested, regularly exercised. You can run marathons easily because you run one every week.

This is the secret sauce of the public cloud providers. If you’re in the running marathons business, that’s what you do.

There is no Plan, there is no Build, there is only Run.

Everything is Run.

This article first appeared in Forbes.com here.