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.

The world of business punditry is abuzz with JPMorgan Chase’s $2 billion loss. As it should be, I guess. Learning from the mistakes of others surely beats learning from our own.

On the other hand, there are many more ways to do things wrong than there are to do them right, and besides, for most of the business world the whole matter is about tribes who aren’t us—what “they” (JPMC’s) management) did wrong, and how “they” (our own management) should do things differently.

Ideas we can use ourselves are nowhere near as enjoyable. Valuable, yes, but enjoyable? No. And so, with some misgivings, I’ll forego the opportunity to critique yet one more blunder from yet one more group of grossly overpaid blunderers.

Instead, I’m going to tell you about a restaurant and some lessons it provides for you and your teams.

The restaurant is Travail. It’s a physically unprepossessing little place located in downtown Robbinsdale, Minnesota, an unprepossessing little Minneapolis/St. Paul suburb.

That’s as far as its unprepossessingness goes, though. It’s one of the rare eateries that makes a two-hour wait for a table a fine investment of your time.

Here’s the story:

The founders/owners/staff are thirteen or so talented chefs. The decor is early brick, with tables. The menu goes on two large chalkboards. The waiting list goes on a third. There’s a bar. The kitchen is visible, inside and through the front window.

What isn’t visible is the floor, because the place is packed. We arrived minutes after it opened, but the diners who had waited outside for the last hour filled all of the tables with crowd to spare.

Our group of four was fifth in line. “How long is the wait?” “Maybe 90 minutes.” We got drinks and chatted, not sure our patience was up to the task, but willing to find out.

When we finally sat, we ordered the Tastings — ten courses, none large. “What are they?” “Don’t worry about it.”

Served over a span of two hours, they were unique, without being either pretentious or contrived. Also, they were delicious.

Except, perhaps for the beets. I don’t eat beets, so I can’t say.

Travail is a wildly successful business in an industry known for its high rate of failure. So the factors driving their success might provide guidance for the rest of us:

  • Excellence comes first. Remember the six optimization parameters? Excellence … uniqueness, tailoring, customization, with no standardization … is what makes Travail’s food worth every minute of the wait. Quality (absence of defects: salmonella would be an example) matters too. The other four optimization parameters are whatever they are. Clearly, neither cycle time nor throughput matter, and the menu is priced so that fixed and incremental costs don’t matter either.
  • Every chef is a superb chef. Travail makes no compromises on staffing. It doesn’t try to substitute process for ability. It lives and dies on talent.
  • And, they work as a team. There’s no false dichotomy about talent and teamwork. They’re independent variables, and they’re both present in abundance.
  • Every chef takes turns as chef, sous chef, bartender, dishwasher … and server. Cheerfully — they enjoy talking with diners, explaining each dish and answering questions. Now pay attention: In their own way, chefs are geeks just as much as programmers and sysadmins, and yet there were no communications barriers, other than the ambient noise, just infectious enthusiasm about the subject.
  • The work doesn’t have to be fun, but it is fun. People can fake a lot of things, but they can’t fake that. When you’re preparing ten dishes per patron, plus the desserts (the dessert Tastings had four more dishes), with a room full of waiting patrons, the pressure is constant. Or could be. Instead, everyone working there wanted to be there.

Which leads to the final take-home lesson — the virtuous cycle that connects a sense of ownership to outstanding outcomes, and outstanding outcomes to a sense of ownership. At Travail, creating that sense of ownership is, admittedly, easier — everyone is, after all, an owner. But their legal ownership isn’t what makes everything work. It’s the attitude of ownership that drives them to achieve great results — not just the food itself, but the experience that surrounds it, which together were worth every penny.

Between the two-hour wait and the two-hour meal, that experience took four hours. It was worth every minute, too.