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?
I’m certainly glad to see you are back in business – and you shared a good lesson.
Welcome back, Bob!
Count me among those who always advise staying current, but fail to do so in quite a few cases!
To answer your question, you do not adopt a technology when it is so new, it is not a standard, and a lot of stuff will not run on it smoothly or reliably.
Pleased to see that you are back in business, Bob and I hope you were not too tough on the tech support staff. In my former life of providing and managing tech support functions I experienced many cases where the end user thought there would be “one more reminder” no matter how many reminders there had been. And yes they then believe it is “your” fault when the end does come!
Loved your 10% thinking 90% rationalizing comment.
As for reasons — aside from dollar-cost and time-cost constraints — as John Moore said new technology does not always run smoothly nor reliably, Also sometimes new tech will take more resources (memory, CPU) than can be obtained. I believe that NASA — an agency not constrained (too much) by money — stays a couple of revisions behind due to reliability and equipment constraints.
I agree with you Bob: Clearly it’s THEIR fault. They put a gun to your head and made you wait until the worst possible moment to act…
Of course, there is another possibility, that like the rest of us, being the smartest and most experienced person in the room isn’t enough to keep us from knowing what our blind spots are and giving someone else the 2″ x 4″ needed to keep us out of our poop. Nice article.
Time when it doesn’t pay to stay current:
– The time when the update hoses your machine. Unfortunately one is rarely in the situation where we know that ahead of time.
A recent update to Win8.1 hosed my laptap, and I am having to rebuild it.
Oh well…
I suppose, sometime or other I’ll have to talk about the difference between patch management and release policy.
But not now …
Examples do exist:
(a) Embedded systems that are not networked in the traditional sense (i.e. they may have connections to outside, but “outside” has no capability to change executables inside).
(b) Special-purpose systems where the total cost to upgrade is very, very high, or risk of upgrading exceeds the risk of not upgrading.
Those are two different areas, but neither fits in the standard administrative IT world, either.
The subject on the mass mailing was “Keep the Joint Running 3/30/3015: Hard currency”. Nice to see you’re not just current but a millennium ahead of the rest!
In spite of my advanced age I like to think of myself as a Millennial in spirit!
When you shouldn’t stay current–when changing actually is a waste of money. I never figured out the reason so much COBOL is still in use until the boss suggested “upgrading” our web site backend from Perl to something else.
Why? Anything else will also require maintenance and the initial outlay cannot be justified: spend $$$ changing all the code and making sure nothing at all changes for the users. Where is any benefit to the company at all to come from that? (It will upgrade my skills and make me more employable 😉
If you don’t need new capabilities, then upgrading is just a cost. When it gets too expensive to hire Cobol programmers or when you finally decide you need a new platform in order to deliver new products/services to your customer, then you can make a cost/benefit justification.
Mike …
Fair enough. Except, that is, when the time comes that the folks supporting the mainframe batch Cobol retire and the best industry talent has no interest in replacing them.
There’s also the “need” question. Businesses base their processes on system limitations just as much as on their capabilities. So batch architectures result in 1-day cycle times when competitors might be providing an equivalent service in real time.
But in the business, nobody credits this as enough of a competitive challenge to be willing to invest in a replacement system.
In my experience, business decision-makers, faced with a situation like this, solemnly declare that their customers are wrong. And so, their customers defect to providers who do deliver services in real time.
Every situation has its own merits, of course, so these generalities don’t fit every one of them. If I had to place my bets, though, I know where I’d put my money.
I work in an Infrastructure group, and after decades of notifying, begging, and pleading for other teams to stay on supported platforms (forget about “current” or even within fog-horn distance of that) we finally found a strategy that works. We present present a signature form to the application/service owner that states they will pay (fully!) for any support work caused by running a version no longer supported by the vendor. Our normal “internal” support paths will only apply to supported versions of products.
This is clearly a somewhat silly way to manage this, but I’m continually stunned at how effective it is to have the “owner”–usually far above those making the decisions to defer–sign a document acknowledging that they are on the hook. I attribute this to a human desire to avoid blame being just a bit stronger than the desire to procrastinate…
By coincidence, I’m recommending a “pricing-driven architecture” model to a client right now. The company makes extensive use of the internal-supplier/internal customer operating model, so making obsolescence expensive seems like the most logical governance mechanism available.
I’m delighted to hear it’s worked in other circumstances. Thanks!
I have one extremely specific example of not staying “reasonably current” on a piece of software.
I play one particular strategic wargame which is probably too cerebral for most people (it covers all of World War II in the Pacific, and you manage units as low as individual PT boats). There is a supporting program written to use Java 6. This supporting program was written and is maintained by two volunteers who also play the game. The game itself is now maintained by a single volunteer developer who happened to be on the original development team. The company no longer supports the game, but these guys have all signed non-disclosure agreements and are allowed to do the modifications and the supporting program.
Java 7 was such a departure from Java 6 that the supporting program developers haven’t yet had the time to figure out how to port the program without major disruption to users, who might be using it on up to a dozen active games.
I emphasize that these are stand-alone programs, not web-based. They are not subject to the prominent Java issues everyone was and is so hysterical about.
As far as I can tell, nothing else I run uses Java at all so I feel no compelling need to install Java 7. Doing so will be a moderate-to-major operation since it automatically upgrades the existing version. I either have to “hide” Java 6 from the install process, or I need to reinstall it after installing Java 7 (for some reason I haven’t explored, yet, you can install 6 with 7 active but you can’t install 7 and keep 6).
As I said, this is a very specific example. On the whole, though, I do agree that software should be kept reasonably current; just wait until you know the version you upgrade to won’t break what you’re doing.
You’ll have an intriguing decision to make when you discover the need for an application that will only run on Java 7, not earlier versions.
Glad you are back in business with this column!
Me too.