Migrating to the cloud means more work than you think

Taking advantage of the cloud — IaaS and PaaS, in particular — requires a lot more work than most IT departments realize. And before you roll your eyes at yet another column about the cloud, it gets worse: I’m going to do something we geezers in training do a lot of. That is, I’m going to explain that the young whippersnappers who think they know it all need to learn from our experience.

No, not because we already did it all on mainframes with Cobol — we didn’t — but because of two very different lessons we learned in two contexts that had nothing directly to do with business applications. One is designing for manufacturability; the other is about cow paths.

[ Move over, Amazon — IaaS providers are elbowing into the cloud. See how they compare in InfoWorld’s slideshow. | Stay on top of the current state of the cloud with InfoWorld’s special report, “Cloud computing in 2012.” | For more of Bob Lewis’ continuing IT management wisdom, check out his Advice Line newsletter. ]

Follow me along two cloud migration parables, the first of which takes us back to the early days of the personal computer (he geezed) and the second of which puts us in a woodland where everything we thought was simple about migrating to the cloud is, in fact, surrounded by cow pies.

Cloud migration parable No. 1: A printer’s tale

Back in the 1980s, IBM attempted to capture some of the low-end dot-matrix printer market with the IBM ProPrinter. As part of its attempt to keep the price down, so the story goes, IBM wanted the printer built robotically. It called in the robotics experts, who looked at its design and explained it couldn’t be done. The printer was too complicated for robots to assemble.

In response, IBM sent its engineers back to the drawing board (or probably the drawing CAD) to redesign the ProPrinter for robotic assembly. The result was a much simpler and more modular machine. In fact, it was so much simpler and more modular that the cost savings from having robots assemble it vanished.

Cloud migration parable No. 2: Cow paths

The second lesson we learned with important cloud parallels happened when we discovered that a piece of conventional wisdom about designing information systems was out-and-out wrong. The conventional wisdom: For IT to automate a process, the business first had to have a good process to automate.

It sounded convincing — so much so that its proponents never stopped to think that when someone figures out a process, it’s in the context of the technology used to implement it. If that technology is limited to ledger sheets, copiers, calculators, and interoffice mail …

It’s called “paving the cow path” because when cows wander around in the woods they wear down the underbrush to create a path. It’s not a very efficient path because cows don’t care about efficiency. They care about eating stuff.

Nonetheless, when humans then walk through the same woods, it’s a lot easier to follow the cow path than to create their own, so long as they watch their step. But when the time comes to build a road through the woods, paving the cow path will result in a very inefficient avenue.

That’s what “paving the cow path” means: missing most of the opportunities for added efficiency because you’ve used the new technology, but the old thought process — which is what IT did when it automated pre-existing manual processes.

The moral: Designing for the cloud is no walk in the woods

Successful use of the cloud depends on learning the lesson of the ProPrinter, and of the cows and those whose asphalt followed their meanderings.

Far too few cloud proponents take into account the complexity of most business IT these days. The complexity isn’t the result of IT being stupid or buying technology for the sake of technology. It’s the result of IT doing exactly what it was supposed to: choosing technologies that, with an optimal mix of cost and implementation time, best support the company’s internal processes and practices.

Usually this meant buying multiple COTS (commercial, off-the-shelf software) packages, configuring them so that they best fit the needs of the business, then integrating them to minimize the need for manual rekeying while maximizing the ability to pull useful information out of the company databases.

Multiple COTS packages plus extensive integration means a complex environment. Think of it as the equivalent of IBM’s original ProPrinter design, and the cloud as the equivalent of robotic assembly — except IBM could redesign the entire ProPrinter for robotic assembly. You probably can’t redesign your entire applications portfolio for the cloud.

A typical IT environment is complex, with a portfolio of hundreds of applications created independently based on different design standards created by different engineers at different times and in different situations. IT can’t “just” move one COTS application to the cloud. Each one has to be implemented with a specific server and storage configuration.

Re-creating it in the cloud is a nontrivial task. Twiddling it so it performs properly is a nontrivial task. Integrating it with all of the locally hosted applications you haven’t moved to the cloud yet is a nontrivial task. Documenting the configuration so that you can re-create it if need be is a nontrivial task. Making sure the license terms allow deployment on a third party’s virtual servers is sometimes a nontrivial task, too.

Maybe you’re moving an in-house-developed system to the cloud. That won’t be any easier. It won’t be a simple conversion, any more than redeveloping a batch mainframe Cobol application into an interactive, object-oriented replacement is a straightforward conversion. It’s another nontrivial task because you have to design with the cloud in mind, just as you would with objects in mind.

That’s one application. Moving a second one to the cloud isn’t merely a rinse-and-repeat undertaking; every application you move was designed to a different set of engineering standards, often based on a different design philosophy.

If you port everything you have to the cloud, you’re paving a cow path. But redesigning the entire applications portfolio so that it’s clean and consistent isn’t going to happen any time soon. If it was, it would have already happened because the savings from managing an elegant IT architecture would have been enormous, even when hosted inside a corporation’s own data center.

I keep reading that the cloud will cause IT to dry up and go away. What I never seem to read is how exactly it’s supposed to happen.

Like the old unplug-the-mainframe efforts of 30 years ago, it’s a nontrivial task.

This story, “Migrating to the cloud means more work than you think,” was originally published at InfoWorld.com. Read more of Bob Lewis’ Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.