While waiting in some line or other I noticed the young lady in front of me was reading a book about Watergate. She told me she was reading it for her history class. Her history is my current events. Ouch!

“Current” means different things to different people, which brings us to last week’s topic, the value of keeping your technology current.

Take IMS as an example. For those of you who also think Watergate is a historical subject (no, not “an” historical subject) IMS is an IBM product — a hierarchical DBMS, an technology that became obsolete with the advent of codacyl DBMSs, which in their turn became obsolete when relational DBMSs became available.

What’s good about IMS is that IBM still supports it. What’s better is that if you’re a DBA who knows IMS there are probably more jobs to be had than there is competition for them.

Here’s what’s bad: It’s hopelessly obsolete. Worse is that the only IT professionals willing to take those open jobs are either well on their way to geeze-land (like me) or don’t have enough on the ball to go after positions that will let them work on hot technologies like NoSQL, let alone mainstream SQL-oriented positions.

Worst news of all: If you’re the CIO or CTO of an organization that relies on IMS, you will never be able to make a financial case for converting to something modern.

Because there is no financial case for it. By now, your company’s investment in IMS is somewhere between formidable and incalculable. The cost of recreating the same functionality in a modern DBMS would be enormous.

After which the company would run exactly as it did before the conversion, only with that much less money available for other purposes.

The dots you’ll have to connect to associate the conversion with more revenue or less operating cost … the definition of “financial case” in most companies … are numerous enough that few business executives would sit still through your explanation, let alone buy it.

The problem is that most companies big enough and old enough to rely on IMS consider “business case” and “financial case” to be synonyms.

Most companies big and old enough to rely on IMS focus on financial engineering, not competitive advantage. If the CEO and board’s goal isn’t to sell more products and services to more customers, they won’t understand the business case for jettisoning obsolete technology.

Many IT professionals don’t either, because “obsolete” is an imprecise term at best.

In business terms, obsolescence is risk. That there will come a time when you’ll find yourself luring codgers out of retirement, or else have to settle for third-rate employees who can’t find any other employment … that’s a risk. A big risk.

There are others. Plenty of businesses still haven’t migrated from Windows XP, because it does everything the business needs, so what’s the problem? Again it’s risk:

  • Their anti-malware vendor will, at some point, drop support for XP. They’ll still need malware protection when that happens, and self-paced conversions are better than fire drills.
  • Computers wear out. Will Windows XP run on new hardware? At some point, no, and mixed environments are more expensive than homogeneous ones.
  • Printers wear out too. Will new ones have XP drivers? Many don’t right now.

But perhaps the biggest risk is the Stockholm Syndrome — the tendency of hostages to end up sympathizing with their captors. In the context of IT, it takes the form of accepting as normal the limitations obsolete technology imposes on business processes and practices.

You’re now a retailer, relying on batch mainframe COBOL systems. They are, everyone agrees, superior because they’re awesomely reliable and eat transactions just as fast as you can pump them in.

Nobody notices that while transactions are masticated and ingested in real time, they aren’t digested until 1 am, when the batch processes that post them are launched.

Because of the Stockholm Syndrome, it seems perfectly normal your company can’t ship orders until the next day. The delay is minor. Customers won’t care.

And when it turns out you have less in stock than you have orders, well that’s why IT developed a subsystem to inform soon-to-be-former customers their orders are now backorders, but don’t worry — backorders take precedence over new orders for the same item, whenever the shipment happens to show up.

Even if someone does realize batch COBOL’s limitations will kill the company, it doesn’t matter. There’s no money to fund a conversion to a more modern system. The board spent it all buying back stock to improve earnings per share. That’s much more important than winning and retaining customers.

Isn’t it?

KJR is back in business.

I’d love to blame 1&1 for last week’s mess. But to be fair, I deserve a lot of the blame, because I refused to accept the same counsel I give every client I work with on the enterprise technical architecture front.

I’ll get to that. But first, I have to unload. And so …

It happened like this:

A couple of years ago, 1&1 announced its new and improved system for building e-commerce sites. I tried the demo — they provided a temp URL for that purpose — and couldn’t make head or tail out of it. The new system was obviously more capable and absent a kludge or two that made the old system irritating.

But it had the downside of being horribly unintuitive, and 1&1’s on-line help mostly helped with the obvious stuff.

No problem. The old system was stable and did what I needed, kludges notwithstanding.

Then, last year I started receiving an occasional message saying they were going to shut off the old system. The last one I saw, dated sometime in November, said the last date would be the previous January.

I should have ignored the typo, but I was busy and figured I’d get one more warning before the end came.

I also believed their letter when it said that if I didn’t convert my site, 1&1 would convert it for me.

Instead … Things just kept on working until the day they didn’t.

Last Monday, to be precise.

No final warning. For that matter, 1&1 only converted my home page, and didn’t do a very good job of that.

As long as I’m unloading on 1&1, they also shut off subscribe/unsubscribe for the bulk mailing system I’d been using.

And, for that matter, the credit-card processor pre-integrated into the old system wasn’t available for the new system either.

All of this made me, even by my normal standards, cranky.

To be fair to 1&1, once I managed to get through the hold queue, which was, as you might imagine, quite long last Monday evening, 1&1’s telephone support staff were as helpful as could be, and, I have to admit, far more patient with me than I was with them.

Also, I felt better about my difficulties in figuring out their new system when I realized that for a good half of my questions the telephone support folks were putting me on hold so they could ask their experts how to handle the challenge.

So I’m not telling you to avoid 1&1 because they ticked me off. If, for some reason or other, you’re in the mood to start up a new e-commerce business and need a site-building, hosting, and bulk mailer all in one, their technology seems to do the job, once you slog through the process of figuring it out.

Why does this matter to you?

It’s like this. There’s a meme out there that says we humans only use 90 percent of our brains. The meme is false. We use 100 percent of our brains all the time.

We use 10 percent for thinking and 90 percent for rationalizing. That makes 100 percent.

There are businesses out there that still use versions of Windows and Office that haven’t been supported for years. Why? They’re rationalizing.

See, the cost and inconvenience associated with getting current is counted in hard currency. The benefits, on the other hand, count as risk avoidance, as in, there will come a day when they won’t be able to load the old OS on new hardware, or in a virtualized or cloud environment on whatever virtualization technology is in play.

The rationalization is, there’s always something else that’s more urgent than the conversion.

Right up until the time there isn’t. It’s pay it now or pay it … a much bigger it … later.

What I recommend to clients I advise on the enterprise technical architecture management front is to adopt a “design principle” that addresses lifecycle management. Possibilities include:

  • Stay current (more likely, begin migration projects shortly after new releases are announce to allow the situation to stabilize).
  • Stay one major release behind the current one, so as to always be on supported software while minimizing the risks associated with brand-new releases.
  • Alternate between adopting and skipping major releases. You stay current enough.
  • Update to new releases only when they either (1) have compelling new features you want; or (2) you have no choice any more.

I try to talk clients out of that last one, for all the obvious reasons.

Too bad I didn’t talk myself out of it when it came to 1&1’s site-builder system.

Clearly, it’s their fault, because that’s the nature of fault, and for that matter rationalization, isn’t it?