Your IT infrastructure: Propping up a house of cards

Every IT person alive has fixed something in the “wrong” way, a way that wasn’t scalable, secure, or otherwise proper, but a way that worked. It may have been intended to be temporary, but time passes and it becomes permanent. Over time, such fixes are often applied to problems caused by previous bad fixes. But they work, tenuously, for now.

This sort of activity takes place constantly, and indeed, it might not become a huge problem for quite some time. But there will be a point when there’s no more room for kludges and poor fixes.

[ Also on InfoWorld.com: Learn how data deduplication can slow the explosive growth of data with Keith Schultz’s Deep Dive Report. | Looking to revise your storage strategy? See InfoWorld’s iGuide to the Enterprise Data Explosion. ]

Simply put, when you’ve attached enough Band-Aids to the corpus that it’s more bandage than not, isn’t it time to start over?

It’s one thing to understand that such problems exist (and always will, to some degree) within a corporate IT infrastructure; it’s quite another when the problem is extreme and affects products your company produces, sells, and supports.

I’ve seen some horrifying examples of software development malfeasance recently — things like a thoroughly perplexing dependency on a specific network interface chipset for a simple client/server database application. I’m still puzzled how a standard Windows TCP/IP-based application developed and sold in 2010 could possibly be Ethernet-interface dependent. The only thing I can think of is that somewhere along the line, the developers “fixed” some problem with some terrifying shim that only works on Intel interfaces, and then wrote the requirement into the spec.

Another software-based example is an application that requires not only local administrator privileges to install, but also to run. In a domain environment, every user must be granted full local admin rights on their workstation to run this one application. It singlehandedly renders most corporate security policies moot. This application costs tens of thousands of dollars, and due to training and existing corporate mindshare, it’s apparently indispensable. It’s also an affront to all that is holy in IT.

And those are just two small examples. There are thousands more just like them.

One might think that the free market would take care of problems like this, because the company with the inferior product would necessarily be marginalized in favor of the company with the superior one. Unfortunately, that isn’t always the case. In fact, I’d say it’s becoming somewhat of a rarity, especially in markets with minimal competition.

The problem is the core of very many of these applications is quite old and written for a completely different era. As processors have become faster and RAM cheaper, the software vendors have opted to dress up new versions in eye candy and limited-use features rather than concentrate on the foundation of the application. To their credit, code that was written to run on a Pentium-II 300MHz CPU will fly on modern hardware, but that code was also written to interact with a completely different set of OS dependencies, problems, and libraries. Yes, it might function on modern hardware, but not without more than a few Band-Aids to attach it to modern operating systems.

Even there, problems exist. There are plenty of commercial software packages released and sold in 2010 that do not support Windows Vista, Windows 7, or Windows Server 2008. Their compatibility lists stipulate Windows XP and Windows Server 2003 only. And these are not cheap or niche products, these are point-of-sale systems, inventory systems, medical and dental charting and recording systems, just about any type of software you can think of beyond the code that runs at Internet speed. These are the dinosaurs that operate in small and large markets and have become de-facto standards in the smaller niche markets.

Naturally, the problems inherent in these applications force IT folks to implement further Band-Aids to get them to run in their infrastructures, exacerbating the problem. It’s a vicious cycle of bad ideas and worse implementations.

To make matters worse, more often than not, these problems aren’t apparent until the software has been purchased and is in the process of being implemented. Generally it’s too late to change course at that point.

So what’s the fix? Anyone involved in IT products or processes needs to stop tying ancient code and frameworks together with bailing wire and duct tape and take the time to do it right. Software vendors must bite the bullet and rewrite that 15-year-old application from scratch using modern platforms. It will require a sea change in Windows, with Microsoft jettisoning a wide range of internal hooks that exist solely to support Jurassic-era apps.

No, I don’t expect it to happen either. But I can dream.

This story, “Your IT infrastructure: Propping up a house of cards,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com.