July 31, 2014 | Written by: Christian A. Schmidt
Share this post:
“It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.” – Charles Darwin
Photo courtesy of Peter Isotalo and is reproduced with permission under the GFDL.
Known challenge: When excessive technology leads to opportunities for innovation
Vasa: In the 1500s and early 1600s, the cannons on warships were used to fire initial volleys with the main objective of crippling the opponent’s ship so that it could be boarded and seized. With the introduction of warships with two gun decks, the main objective changed to firing broadside volleys that would sink the opponent.
No one in Sweden, including the shipwright, had ever built a ship with two gun decks. But even so, many secondary innovations were added during the construction of the Vasa—innovations like increased length, the additional gun deck, extensive carvings and other changes. The evolution within warship architecture went at a rapid pace, and no cost was spared. But these innovations, which were too many and too haphazardly added (without much planning or attention to how one thing would affect another), were one of the main reasons the ship sank.
(Related: How to avoid the Vasa syndrome on your next cloud journey — Part 1)
In today’s cloud projects: Building a new infrastructure is no easy task because server workloads have an affinity with or alignment to the standardization, virtualization and automation of the existing infrastructure. Therefore, the workloads must be carefully analyzed, and the potential gains must be weighed against how easily they can be deployed in the cloud (whether it’s public, private or hybrid cloud) and adopted to innovative application programming interfaces (APIs) that enable automation and simplicity.
When applied to the right workloads, cloud will most likely deliver game-changing value, but when applied to the wrong workloads, the value can be lost altogether (when compared to a traditional IT-driven delivery model).
This is often because of the fact that not every workload is the same in terms of its importance and cost to the organization, which can easily affect the workload’s outcome or success criteria in the cloud. Some of the most critical workloads are often so costly to the organization both financially and operationally that a move to the cloud has the potential to provide considerable benefit. Other workloads may be highly optimized already, so there is very little to be gained from such a move.
I often see cloud strategies being formed as isolated pockets within an organization, without any interlocks to the rest of the company. Even though these strategies all appear to solve specific and tactical problems (for the most part they were getting quick and successful results), without any integration to the remaining enterprises, they will continue on as a tactical approach focused too much on local benefits.
If you want to find more information about migration frameworks and workload categories, one of my fellow bloggers, Ram Ravishankar, wrote some great blog posts on these specific topics: “Four steps to identify and relocate an application portfolio to the cloud” and “How to classify workloads for cloud migration and decide on a deployment model.”
Innovate with care
It is clear that the Vasa was originally planned to be a small, traditional ship. But because of misdirected innovations, it ended up becoming a large, heavily-armed ship with no regard for factors such as stability, stiffness and sailing characteristics. The result was a ship that was not seaworthy. The Vasa had insufficient ballast for stability in a light breeze and adding sufficient ballast (had there been room for it) would have put the lower-deck gun portals at or below the waterline; it was what we would call a failure.
In the modern world, business projects can be particularly challenging since they may affect many areas of an organization. These areas can have different stakeholders with conflicting views of requirements and project outcomes. The fact that every project has a risk of going off-track is amazing; indeed, statistics show that between 60 and 70 percent of business projects are considered a failure (these results are subject to interpretation, and may be even higher than reported).
Robert F. Kennedy said, “Only those who dare to fail greatly can ever achieve greatly;” it’s crucial to learn from our mishaps. I agree to the point that there are as many different ideas about project failure as there are projects, and this itself can be an obstacle to rating successful projects. “Failure” remains a subjective term. A common definition of a failed project could be a project that was not delivered on time, to budget or which did not achieve initial objectives. The idea of failure criteria is somewhat negative and the fact that one person’s success is another person’s failure can encourage a “we just have to get through this” attitude despite the consequences of the actual failure.
What if we planned for success rather than failure? With a clear idea of our success criteria, would we then be less likely to fail? Would that have changed the story of the Vasa? I don’t know about you, but I sure don’t know.
Please share your firsthand cloud experience—which obstacles you encountered along the way and if possible how you managed to solve them. Comment here or connect with me on LinkedIn or Twitter @PowerOnCloud.
Please visit the IBM Cloud website for more information and check out how IBM can help you on your cloud journey.
I sincerely hope that this series has made you consider the proper approach for your next cloud project. If you want to learn more about the Vasa and the lessons learned, Richard E. (Dick) Fairley, a professor out of Colorado Technical University, made this well-compiled article.