Sector as a Service #2 – Reborn in the Cloud
Once organizations have implemented or built their first cloud applications, they will find they have a powerful cloud platform available that comes with these applications. They can now consider leveraging more of that platform, not only to create additional solutions but also to renew the existing applications landscape. This may be a matter of simply ‘cloud-enabling’ legacy applications by providing them with a new front-end and integrate them with the cloud applications. But applications can be completely ‘reborn’ too, taking full advantage of living in the cloud.
I was listening to Andy Jassy’s keynote on AWS Reinvent and one key statistic that he mentioned struck me. He said that 32% of all apps that moved to the cloud had reduced downtime. Moving apps to the cloud reduces downtime? Who would have thought? It’s considerations like that which make you ask yourself if you should have many more of your apps ‘reborn’ in the cloud. Most of my clients are doing pilots by moving certain apps to the cloud and using those pilots to learn and plot their future.
One thing I will say is that it is truly about ‘rebirth’ of these apps, not just migrating them to the cloud. Forrester analyst James Staten makes this point thoroughly in his blog post. Apps that are reborn in the cloud need to adapt to the cloud and not the other way around.
If you are thinking about rebirthing apps in the cloud, here are a few things to consider:
First understand your application landscape, segment it and plan their destinies. Are you forecasting certain applications that are going to rapidly increase in end-user population? Maybe they are customer-facing apps or employee-facing apps? Do you spend a lot of money on tier 2 apps? Are you dealing with apps on an underlying infrastructure that has lagged behind in applying patches and being current on security updates? The tier 2 apps in the employee-facing and corporate-services domain can be a good target source to do some pilots around moving apps to the cloud. Cloud works better when you start small, experiment and learn from it.
Then you have to ask yourself whether you should leverage Platform as a Service (PaaS) or only the Infrastructure as a Service (IaaS) side. Both come with their inherent pros and cons. Adopting a PaaS means a steeper learning curve for the organization in the short term but better rewards long term. Whereas with IaaS adoption for apps, you get quicker savings but the impact is lower.
Also, you have to keep in mind not all code will work in a public IaaS cloud. So picking the right apps for the pilot will help with testing out these edge cases and will build valuable enterprise knowledge.
Let’s say by now you have identified some decent number of apps (say 40-50) to migrate and have made a choice around using IaaS and PaaS providers, then comes the hard part: building the business case. Keep in mind that there will be one-time migration costs, even if you are migrating to a public IaaS cloud. And the costs go up if you are adopting public cloud PaaS platforms like Force.com or Google App Engine or Engine Yard.
Another factor to keep in mind is the training effort and change management in your teams to learn from this pilot and apply broadly in your company. Furthermore, you should consider if you can generate more value with the same apps if you had more features in them. Maybe a great mobile interface?
Finally, don’t forget the governance aspect of it. Having apps reborn in the cloud doesn’t solve the governance problem; it only makes it more critical to address.
To quote James Staten again: “Don’t think migrate, think transform.”
In fact, I would add: Think “Reborn in the Cloud.”
This contribution by Vikrant Karnik
Part of Capgemini's TechnoVision 2014 update series. See the overview here