ManagementSpeak: We need to bring in some consultants.

Translation: Aaaarrrghhh! I waited until it’s too late and now I want to bring in someone else to either save me or to take the blame for accepting a helplessly doomed project.

The project wasn’t a total loss, though — it did give us this phrase and translation.

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.