All Posts in Technology

|In: Architecture|Last Updated:

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?

Comments

|In: Architecture|Last Updated:

Guess what’s now “best practice.”

A few years back it meant locking PCs down tight, preventing anyone outside IT from doing anything creative with information technology unless they could get it done with Excel.

“Shadow IT” … business departments implementing information technology without any IT involvement? An information security nightmare!

Nightmare? Look at the number of recent, massive data breaches whose targets have been … what shall we call the opposite of shadow IT … sunlit IT?

The actual evidence seems to show that shadow IT is, at worst, no less secure than sunlit IT.

The exact same cast of characters that advocated tight lockdown just a few years ago are now, without even a trace of contrition, writing favorably about how smart CIOs are supporting and leveraging shadow IT rather than trying to stamp it out.

Research current thinking on this and you’ll find the IT punditocracy has discovered IT has to handle some tasks more quickly than others. McKinsey, for example, calls it the “two-speed IT architecture.”

Welcome to the party, folks. You’re late. Did you at least bring some decent champagne?

To be fair: Just because these folks are latecomers, it doesn’t mean their insights are worthless. The McKinsey piece, while long on what the outcomes should look like and light on how to achieve them, is a fairly decent analysis.

Decent, that is, other than ignoring the significant role shadow IT will and should play in most two-speed IT architectures.

And, decent with this possible exception: “… companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.”

If, by “quicker,” McKinsey’s analysts mean reducing cycle times for fulfilling orders, then fair enough. While the notion that information technology can be helpful in reducing process cycle times is hardly a fresh one, it’s no less valid today than it was when first introduced in the mid-1970s or thereabouts.

But “quicker” might also mean implementing new strategies or responding to marketplace changes. If that’s what McKinsey means by “quicker,” it’s way off, because optimized processes are one of the biggest impediments to rapid change. That’s because optimized processes need supporting infrastructure, and infrastructure encourages stasis, with “infrastructure” including:

  • Business process design. As these things go, this is the easy one. Designing an efficient process just isn’t all that difficult compared to what it takes to implement one. Visio is the most adaptive component of process infrastructure.
  • Design of business process controls. Beyond the process itself are management practices and process metrics. Designing them isn’t all that hard. Designing them so they don’t do more harm by getting in the way than they provide in benefits? Trickier. A lot trickier.
  • Design and build-out of the physical plant needed to support the business process. This could be as trivial as setting up a new cube farm, or as complex and expensive as designing and building a factory. Ignoring all other aspects of this task, whatever gets built will have to last long enough to be relevant until the company has paid off the design and build-out costs.
  • Design (or selection), implementation, and integration of supporting information technology. Presumably, KJR’s audience knows a thing or three about this topic. To make sure it doesn’t get lost: The integration part is, in most situations, the most expensive and difficult technical dimension of the task.
  • Employee training. The need to train employees is obvious. That their education is part of your business infrastructure is less obvious.
  • Investment in continuous improvement cycles until process optimization has reached the point of diminishing returns. No matter what the new process, it’s the organizational equivalent of a skill. Skills take time, and money, and effort to acquire and perfect.

There’s one more factor to take into account to understand why investments in business infrastructure put the brakes on business agility, and that’s the project failure rate.In most companies, more projects fail than succeed. That being the case, once a company has a process and its supporting infrastructure up, running, and optimized, the fear that implementing its replacement will fail isn’t merely very real. It’s realistic.

And when the odds of success are low, it’s perfectly natural for a company’s decision-makers to take what looks like the safer bet — sticking with that has worked, even if, in the long run, the result will be an obsolete company that sells and delivers obsolete products and services.

Especially because, in so many cases, by the time it’s impossible to ignore their obsolescence, it will be someone else’s problem.

* * *

Next week: Shadow IT’s role in a two-speed business (not just IT) architecture.

Comments