Can Cloud Transformations Fail?
Yes. The end.
You have halted your migration, and:
- The sought-after capabilities are not possible
- New complexity is introduced to your environment with no noticeable gains
- Cost to maintain systems increases
- Mean Time To Recover (MTTR) is longer because of increased complexity
The worst outcome is that you’ve ended up in a state where reverting to your old system is near impossible because you’ve already transformed critical parts of your organization.
In this place you’ll spend most of your time adapting to make the best out of your Frankenstein-like systems, and your teams will likely make it work. Though as the issues pile up, and the progress towards the capabilities that your employees promised as the shared vision of “why we’re transforming” is delayed or stopped, your people will start to leave. In this scenario you’re left with a complex system, and a bleeding of tribal knowledge. And that tribe could have eventually made things work. Could have. In the book Accelerate, Forsgren calls out three tiers of organizations going through cloud migrations — High Performers, Medium Performers, and Low Performers. Medium performers represent exactly the scenario just described: groups partway through a transition or ones that have stalled completely and are now living in this new complex state.
Medium performers do worse than low performers on change fail rate in 2016… we believe this new work could be occurring at the expense of ignoring critical re-works, thus racking up technical debt which in turn leads to more fragile systems and therefore, a higher change fail rate.
The length of time an organization can fall into the medium performer category can be drawn out if they’ve decided for a “lift and shift” approach, without taking the time to have a true assessment of their apps’ ability to live in a cloud-centric environment. This “cloud-ish” state perpetuates itself through technical debt and tends towards compound failure.
Though to that point - you will be a medium performer as it is a transient state. Planning for this is crucial, and ignoring this may be enough to cause your migration to fail.
Becoming a medium performer and stalling your transformation should be seen as equal or worse when compared to failing fast.
Whew, that was a lot of gloom. Now that we’ve gone through the painful exercise of visualizing our “cloud-ish” doomsday scenario, we can wake up from our nightmare, breathe a bit and ask a few conscious questions. What factors contribute to a ‘cloud-ish,’ failed migration? How can we prevent it?
A cloud migration involves structured change and heavy planning, especially in regard to your people, communication structure and process. You should remove any idea of moving to the cloud being a silver bullet for your current problems. Instead focus on tailoring your apps and organization to the cloud itself. Going to the cloud gives you a new set of capabilities that, when unlocked in your organization, may shine a bigger light on the existing cracks along the way.
With that in mind, let’s unpack a number of factors and patterns that contribute to cloud failure and so highlight how they might be averted through better planning.
- Picking the wrong R and not optimizing your applications for the cloud
With ideas like “Lift and Shift” it’s easy to think that someone can come in, help you get to the cloud in a few weeks time and then magically you’ll see the benefits. I mean, yes you may see some initial benefits, but without proper use of a system like the 6 R’s, you’ll likely “shift” into a place that is not optimized for your needs and is costing you far more than it should. The pattern here is an initial cost savings, then an eventual cost overflow. Picking the correct path for your application from the 6 Rs is critical to ensuring that it takes advantage of the cost savings the cloud enables. Conversely, picking the wrong R can create cost-increasing behavior.
- Letting your core business slide during migration
Performance, cost/time of rollout, and new feature delivery to clients are your main competing interests during cloud migration. Forgetting about any of these items will have a drastic effect on whether or not you fall in to the “70% of all cloud migrations fail” number. Make sure that your core services and ongoing features are maintained as the number one priority amid change. With so much going on in the field, it is easy to take your eye off the ball.
- Keeping systems that are tightly coupled
Do you have systems that are dependant on each other? Can you deploy/change/fix one part of this system in isolation? If you move such systems straight to the cloud, you’ll likely not see the benefits from the faster delivery the cloud provides, and will begin to pile up technical debt when surrounding services become updated more frequently. The worst case scenario is waiting until much later in your transformation to tackle these highly coupled systems, and having your most brave architects and developers play a game of operation with your product.
- Keeping manual stop gaps and not employing automation
Falling in line with tightly coupled services, do you have processes that require human intervention? Depending on your architecture, you could end up with much more to juggle when deploying into a cloud environment. It’s very easy to miss a single step, or mistype an instance name when you have tens of them to accurately enter or restart. A single type can simulate a critical issue post deployment. Spending unneeded time in triage will slow you down even further, and will eat budget for those involved who are trying to find the needle in the haystack.
On the other hand, the cloud allows you to move faster by building in automation throughout the software lifecycle. This is particularly true for deployments, which can now be handled in days or minutes instead quarters or months. This fast deployment capability may bring to light cracks in your organization or process where automation is shunned. But if you have a manual deployment process in the cloud, you are not using the platform correctly. You also risk the sticky mis-deployments mentioned above.
- Security is not baked in from the start
Moving to a cloud native environment means you’ll have a larger surface of public facing applications. At first glance this may not look “more vulnerable,” but in general it means that there are more possible entries into your systems and data. Instead of several smaller, squishy balloons that may not pop, you have a larger, more tensile balloon for which a single pin is suddenly more threatening. If you wait until you’ve lost data from being hacked, you’ll move into an immediate all-hands to stop the bleeding. You’ll then have to go back and figure out what adding “more security” looks like for your in-flight environment. This will cause major setbacks.
- Not creating organizational buy-in through communication
Forgetting to involve the people who are on the peripheral of a cloud migration is an easy pit to fall into. You may not have actually forgotten them, but if your messaging is not clear, and you aren’t capitalizing on the in-house leaders your company has grown over the years, they may very well feel that way. Negative sentiment from lack of information or involvement can itself bring the momentum of a cloud migration to a halt.
- Poor planning
Really this is the overarching umbrella of all of the above, and is kicked off by asking “how did we get here?” The move to the cloud is not something that should be seen as a light task, and your organization should be ready to make the changes internally to ensure it’s timely completion, and has a plan for failure.
Planning for organizational change is equally, if not more, important than planning for IT changes. When moving to the cloud and unlocking the superpowers of near-unlimited scalability and often much higher resiliency, you’ll need to train/skill up your people for the new space. If your goal is to enable more experimentation paid for with the guaranteed resiliency of your new “five nines” system, your teams will need to have a workflow that allows this. Your organization will need to adapt, and so will your people. This is not something that will “come out in the wash” either, and must be achieved through communication and planning.
What do we do?
- Understand the costs going in, map out your ROI/TOC
- Plan for success and failure
- Build in security from the beginning
- Ensure your organization can welcome changes
- Use tools like Value stream mapping to identify gaps
- Adopt a change management framework
About the author: Derrick Medina is a Senior Client Solutions Manager in Solutions Architecture and Consulting at Kenzan, Amdocs' cloud consulting arm. Derrick is located outside Hamburg, Germany.