It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

We’ve seen this movie before.

It’s a new cast, and they changed the title, but the plot is the same: What was supposed to be easier and cost less turns out to be harder and costs more.

Not only that, but it has the exact same plot twist.

The old cast and crew was client/server computing. The new cast and crew is The Cloud. As InfoWorld’s always-worth-reading David Linthicum reports, “It’s harder, and it takes longer than many thought” (“This just in: Cloud computing is hard and takes a long time,” InfoWorld, 5/10/2012).

The plot twist?

Back in the early days of client/server computing (when the distinction between client/server and distributed processing baffled even many self-described experts, who lumped the two together) the discovery that so-called client/server systems often cost more to develop than their mainframe equivalents was quite a shock.

As I pointed out at the time (“Client/server confusion,” InfoWorld, 2/24/1997) the shock was misplaced because the analysis was badly flawed: Mainframe systems were developed by programmers already experienced in the development language and environment (COBOL/CICS) on already-deployed, stable platforms (IBM MVS mainframe computers).

The programmers who wrote the shockingly costly client/server systems had to learn a whole new language (C++ was a popular choice at the time). They also had to evaluate, select, purchase, install, and configure server and desktop hardware and operating systems, plus the network technology that connected them.

Oh, and they had to learn how to design graphical user interfaces, too — a change that wasn’t just technical, but cultural as well.

Fast forward to the present and the surprise finding that The Cloud costs more and takes longer.

Recognize the shared plot twist?

So far as I can tell, most IT shops trying to deploy in The Cloud have to assemble their cloud computing environments themselves. Then they find that developing for The Cloud isn’t just like developing for local hosting.

Some of the basics are obvious, like, you can’t buy your storage from Amazon while developing your application on Microsoft Azure. Unless, that is, performance doesn’t matter. (If this point isn’t obvious, it’s because inside your own data center, network latency is rarely an issue. When your storage and processing might be thousands of miles apart, the speed of light imposes limitations that matter a lot when you’re processing millions of records.)

Others issues are more subtle, like, if your cloud vendor contractually commits to a specified service level, that doesn’t mean you’ll actually get that service level … it means you either will get it, or get a credit to your account if you don’t.

Or, that not all cloud vendors put you in control of version changes … and in fact, some of the sloppier ones have been known to change their APIs without even notifying their customers that they’re doing so.

It isn’t that all of the differences cloud computing introduces are bad. Some you should be building into your own data center right now, whether or not you’re planning to build a fog (KJR’s term for a private cloud, fog being a cloud you’re in the middle of). As an example, modern information security architectures focus far less on protecting the perimeter, hardening assets instead. As one major benefit of cloud computing is access from wherever a user can connect to the Internet, cloud security is asset-based rather than perimeter-based, because there is no perimeter. (For an extreme view of this, check out Roger Grimes’ provocative “Why you don’t need a firewall,” InfoWorld, 5/15/2012).

Make your security asset-based too, and the challenge of providing access to mobile employees and teleworkers becomes a whole lot more straightforward.

There are two take-home messages from all of this, one for cloud-computing customers, the other for providers.

For providers: What are you thinking? Especially Platform as a Service (PaaS) providers should be delivering turn-key integrated development environments. Sign the contract and start writing code. That this late in the game, Google’s entry (App Engine) is a preview release is extraordinary.

For customers: Just because right now, on average, cloud computing costs more and takes longer, that doesn’t mean it’s the nature of the beast. It means doing something a new way almost always costs more and takes longer than doing it in a way that’s familiar … at first.

Will cloud computing eventually be quicker and cheaper than traditional in-house-data-center-based computing?

I’ll give that a definite maybe, and an even more definite sometimes.

“There are two words you never heard spoken on our sets: ‘Take two.’ “

– Herschell Gordon Lewis, aka The Godfather of Gore, aka the Great Guru of Direct Marketing, aka Dear old Dad (DoD)

If you don’t want anyone to read something, don’t put it on the slide.

The latest in PowerPoint fashion is to include complex graphics with unreadable labels.

It’s bad enough when a graphics designer decides to use mouse type to label the boxes in a graphic. But sometimes there are no good alternatives.

Take, for example, this well-known (in enterprise architecture circles, at least) representation of the TOGAF methodology and framework (The Open Group Architecture Framework, and don’t get me started about including “the” in an acronym).

TOGAFIf I was going to write about TOGAF and wanted an accurate graphic to help illustrate my points, my choices are limited. TOGAF has enough moving parts and interconnected concepts that any graphic describing it well is going to have a large number of elements to it, each of which is going to require a label so you know what it represents.

Which means small type. But you’ll notice, if you expand the image you can actually read everything. As a steadfast opponent of oversimplification, I’m okay with this sort of graphic. It isn’t what I’m complaining about.

This is what I’m complaining about:

TOGAF2When a presenter doesn’t render an image with a resolution high enough that the type is readable when expanded, it tells me there never was any intention to present actual information.

Whether or not it’s intentional or not, the message that’s being clearly delivered is, “I want to impress you with my sophisticated knowledge but don’t give you credit for having enough curiosity to want to understand this subject yourself, let alone the attention span you’d need to review the actual content.”

The message I take away: The presenter knows there’s sophisticated knowledge to be had about the given subject, hasn’t expended the effort to learn it, but wants you to think (s)he has.

Yes, I know. Most of the time you have no more interest in learning the details than the presenter has the ability to explain them. But don’t think of this as an opportunity for eyeball-glazing, mind-numbing boredom.

Think of it as a hobby. Some people collect stamps. Others collect coins, or rocks. You collect flustered responses to this phrase, inserted innocently into the presentation whenever you just can’t stand it anymore: “I can’t read the type. Would you please expand the view and walk us through this?”

Most likely, after apologizing for the poor resolution and some tap-dancing, the presenter will say something like, “Well, I’m not the right person to take you through the details, but I can bring that person to our next meeting.”

The second-to-last thing you want is another meeting (the last is to reward the presenter by agreeing to another meeting). So you say, “That’s okay. Just give me the high points.”

Or, “Will that person be working with us directly if we decide to do business with you?”

Or, “Maybe I’m misunderstanding the situation. Is that graphic on the page to provide information, or is it just decoration?”

Just keep in mind, this is a catch-and-release situation. Go ahead and play the fish until you get bored, but at some point you should let the presenter off the hook.

What’s even more annoying than this is that the trend toward unreadable graphics seems to be extending beyond face-to-face presentations to on-line and downloadable marketing, and even worse, to training material. There’s no defense — nobody to put on the spot and embarrass.

If you’re in a public service mood you might consider taking the time to send an email into the customer service black hole, to the effect that while going through the company’s on-line training course the graphic in question caught your eye, but its resolution was too low — could customer service please send you a readable version?

Maybe … just maybe you’ll eventually find yourself in touch with someone you can politely ask why on earth they’d include something that clearly does have text, but that just as clearly was never intended to be read, in their material.

But probably not.