By Caron Carlson in FierceCIO about an original article by Bob Lewis in InfoWorld (also re-posted below).
I love these pieces that serve as “zig” to marketing hype’s “zag” regarding the forthcoming bounty of life-changing glories bestowed by the cloud.
The cloud bounty is real, mind you, but remember folks: you don’t get something really great for nothing. If you don’t believe me, just ask a cashier at an Apple store!
[ I especially love any article that uses the words “geezer” and “cow pies”. Bravo! ]In all seriousness, moving to the cloud takes work, but that’s life. Progress demands effort.
Emphasis in red added by me.
Brian Wood, VP Marketing
—————
IaaS Requires Heavy Work by In-House IT teams
Infrastructure-as-a-service and platform-as-a-service offerings may deliver quick and relatively affordable ways to achieve scalability and improve time to market, but the cloud services also require a lot of work on the part of in-house IT teams, warns Bob Lewis at InfoWorld. Luckily, you can avoid a lot of mistakes by following the wisdom that “geezers” like himself have gained over the years.
“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,” Lewis writes, in his usual, inimitable style.
The first parable harkens back to IBM’s (NYSE: IBM) effort in the 1980s to develop a low-end printer that could be assembled robotically, he recalls. Unfortunately, the costly design necessary for robots to put the printer together wiped out the savings of robotic assembly.
Next, Lewis recalls that at one time it was widely believed that business needed to have a good process to automate before IT could deploy automation. Although it may make sense on first glance, processes are in fact conceived in the context of the technology needed to deploy them. So if the technology is restricted to existing manual processes, it isn’t likely to lead to new efficiencies or innovations. In other words, if you apply an old thought process, you are likely to miss new opportunities.
Back to the cloud, the complexity of IT systems–incorporating hundreds of applications cobbled together over years–makes designing for the cloud no easy matter. Each application probably requires unique configurations for servers and storage, and transferring it all to the cloud takes careful, time-consuming planning and execution. And it will keep IT departments busy for a long time to come.
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
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.
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.
http://www.infoworld.com/t/cloud-computing/migrating-the-cloud-means-more-work-you-think-198381
