Migrating to the cloud means more work than you think

Moving applications to the cloud requires designing for the cloud, not following familiar paths to greater inefficiencies

Page 2 of 2

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.

| 1 2 Page 2