[January 9th 2017]
Cloud computing has a significant role to play in financial services as a strategic solution for resolving the problems of legacy systems. Here’s how financial institutions should approach Cloud migration.
In my previous article (The new IT experience: Cloud as a solution to legacy system problems in financial services), I argued that Cloud computing not only make sense in its own right, but it has an extra and significant role to play in financial services as a strategic solution for resolving the problems of legacy systems. The argument is that the process of migrating to Cloud will facilitate the large-scale rationalisation and decommissioning of (largely home-grown) problem systems that bedevil financial institutions. The previous article explained the benefits that can accrue from migrating to Cloud, while this article provides more information on how to undertake such a migration. As stated above, the main benefit of Cloud migration for financial institutions is the opportunity to rationalise systems, applications, databases, data sources, etc., and thus eliminate large amounts of the redundancy usually seen in such environments. By doing so, IT-based business operations will become easier and cheaper to deliver and support, as well as being more accurate, timely and secure. Data management will become easier and more reliable, while data quality can be assured in ways that are impossible with the current myriad of overlapping/duplicating (but never agreeing) data inputs and outputs. Not only do fewer systems and more accurate data make it easier and faster to make changes and fix problems, but Cloud computing is designed to facilitate truly agile development practices, with development and test servers being spun up quickly on demand (a process that can take months in other infrastructure models). Improved data management alone can be the difference between achieving and not achieving regulatory compliance. My recommended steps for planning and effecting Cloud migration are: assess current systems; design to avoid vendor lock-in; manage processes and culture; create a business case for change; avoid over-planning; and drop applications that are not Cloud-enabled.
- Assess current systems. Cloud migration should start with an audit of the entire systems infrastructure and a reassessment of applications and databases. An audit is a valuable opportunity to rethink the value and relevance of existing applications and decide which ones are worth modernising and reconfiguring; which ones should be replaced by new applications; and which are no longer relevant and should be retired. A major factor in rationalisation decisions is redundancy – the target should be to have only one software module for each required function (build once, use many), and for there to be only one ‘system’ providing one business service (internally or externally). This compares to the current model that will often see dozens (perhaps hundreds) of systems doing the same thing for different business segments (eg how many reporting systems or risk systems do you have in your organisation?). One factor on which to base rationalisation decisions is how easy (or not) an application can be enabled to work in the Cloud while providing the major benefits of the Cloud (scalability, availability, security, etc). Cloud enablement should not be taken for granted. Some applications will convert easily to being Cloud-enabled; while for others it will be more difficult and the business case for doing so will be weak or non-existent.
- Design to reduce vendor lock-in. Vendor lock-in is not in and of itself a bad thing (the vendors are providing great services), but it needs to be an active decision and not something into which you stumble unthinkingly. Avoiding lock-in and thus retaining the possibility of moving relatively easy from one major Cloud provider to another may make sense from a strategic perspective, but it can also reduce the benefits that can be realised from Cloud. There is certainly a case for going ‘all-in’ with a vendor and this maximising the benefits. For example, event-driven AWS Lambda compute functions are not portable outside AWS, but they do deliver significant benefits within AWS. By comparison, using universal instead of proprietary technologies will afford you more flexibility in future. Eg implementing your stack on an open-source PaaS (platform as a service) such as Mesosphere will make your architecture more ‘portable’, consuming only the infrastructure from the Cloud provider.
- Manage processes and culture. Technology develops faster than culture and processes. Opportunities offered by Cloud computing technology can give organisations incredible benefits, but only to the extent that processes and culture are supportive of the new practices. Superfast speed of infrastructure provision in Cloud can still run up against a wall of bureaucratic processes if you let it. Changing mind-sets is a huge determinant of Cloud success, and is something that is too often underrated or even overlooked.
- Have a business case. Don’t make migration an end in itself. Never do anything without a clear and compelling business case. Benefits you should be looking to validate and quantify include reduced capital expenditure; reduced operating costs; resources freed up to work on higher-value activities; increased development velocity; faster deployments to production; improved ease of support; reduced operational failure rates; improved data management and quality; increased transparency (monitoring, surveillance, reporting); easier to achieve regulatory compliance, etc.
- Don’t over-plan a long-term migration strategy. We all know that no plan survives first contact with the enemy. Instead, set goals and start moving toward them in a pragmatic and agile fashion. Remember that the environment will be changing around you (and the world of financial services has changed enormously in the past nine years), so what is important today might be less important tomorrow. Waterfall planned approaches simply store up risk for later on. Better to fail early with fewer consequences than go for big bang approaches to infrastructure change.
- Don’t migrate applications that are not fully Cloud-enabled. This is a big one as to do so merely replaces old problems with new ones. Continued availability of applications – one of the key reasons for migrating to Cloud – is an essential function of their Cloud readiness, and you won’t get this if the application is not enabled for Cloud. Simply having something sitting on Cloud infrastructure is not the same thing as it being Cloud-enabled.
Conclusion: Theories of evolution argue for two factors: random mutation and natural selection. The survival of organisations is also subject to these factors, except that they have to choose/engineer their own mutations while selection is done by clients and other stakeholders. In my opinion, Cloud is one of those mutations that in future will be demanded by stakeholders, from clients and shareholders to partners and regulators. As data protection, cyber security and cost-effectiveness become bigger and bigger factors in the environment, Cloud will move from being an option to being a business necessity. Knowing how to migrate to Cloud will become a differentiating factor in continued and future business success.
Cliff Moyce, January 2017.
This article was published first at Tabb Forum http://tabbforum.com/opinions/cloud-as-a-solution-to-legacy-system-problems-part-2-6-steps-to-cloud-migration