Financial institutions

Three Practices Observed for Cloud Adoption at Large Financial Institutions

By Jamil MinaChief Architect, Financial Services, Red Hat

Over the years, the popularity of the public cloud has grown in the financial services industry, holding the promise of delivering IT services faster and scaling those services on demand to meet peak business demand. Cloud adoption requires large enterprise developers to learn new technologies and become proficient in using them to maximize business value. For large financial institutions (FIs) that have complex technology ecosystems, comprising legacy and modern applications with unique architectures that have evolved or been acquired over time, cloud adoption is complicated and nuanced.

Large FIs, defined as U.S. businesses with assets of $100 billion or more and foreign banking organizations with combined U.S. assets of $100 billion or more, exist in a heightened regulatory environment to strictly manage operational risks and financial. This means modernizing systems must take into account the data gravity and application architecture associated with existing technology while remaining compliant with changing regulatory requirements.

Throughout the cloud adoption process, there are a few common practices that large FIs use; all come with their own unique challenges that can be properly managed by having the right change management process in place.

Cloud Adoption Practices

The attributes of successful cloud adoption require special attention to be both user-friendly and provide a consistent experience across all clouds. Developers must have rapidly provisioned environments to build applications, and the platforms on which they deploy their application must enable elastic scalability. The multitude of approaches taken by financial institutions to grow public cloud adoption can be categorized into three commonly observed practices that can be used individually or in combination: process protection, discrete development practices, and cloud abstraction. All three approaches come with challenges that will need to be addressed throughout the adoption process.

The process guardrail is used to help FIs mitigate operational risks and minimize financial risks associated with unmanaged cloud resources. This approach requires first verifying each request in order to apply it to the cloud; it tends to be long and often requires multiple approvals. As part of this process, developers are required to develop in environments that do not resemble the target cloud environment. Only once they have access to the public cloud do they benefit from the production environment which is usually made available for a short time. This short period of time is usually insufficient for developers to learn and adapt their code to the target environments. The process guardrail adds bureaucratic friction, increases long delays, and limits access to the cloud, which slows time to market for applications.

After the guardrail process, an additional practice called discrete development practices emerges when FIs impose the specific development practices on their preferred cloud service provider(s). These practices require developers to learn several discrete technologies, in addition to the new cloud stack. The combination of these two practices limits access to the environment given the lack of practice with it and the steep learning curve. This is compounded by added pressure from regulators seeking service interoperability, portability, and resiliency between cloud service providers. The cognitive load on the developer has a cumulative effect and impacts his ability to retain the necessary information in his working memory, making him less productive.

An alternative approach following the process guardrail is to adopt a cloud abstraction layer. FIs facing slow adoption often undertake large projects to add a proprietary abstraction layer to facilitate the delivery of applications to public and private clouds. There are a few downsides to this approach, such as the overall resource consumption and management distraction that occurs when building a DIY platform that hurts business value. In addition, the development process has activities that are performed on the local computer, which does not meet the needs of developers for career growth. Developers aspire to further develop their skills through new and better ways to build apps, aligning their skills with the industry as a whole, and keeping up to date with the latest practices and technologies. The problems associated with a proprietary approach to cloud abstraction can be mitigated by using open source technologies that provide developers with the opportunity to learn and develop their skills according to market needs.

While these three practices may seem simple, achieving cloud adoption in large financial institutions is difficult without a solid developer enablement and change management plan to help your organization’s developers achieve results. desired.

Developer empowerment and change management

Each of these cloud adoption strategies will require new technology, which introduces an array of challenges. Overcoming these challenges requires change management initiatives focused on business goals and outcomes. Enable developers by removing compliance burdens and technical debt issues to achieve cloud adoption success. Managing change to adopt new processes, systems and expectations doesn’t happen overnight and building expertise within developer talent takes practice and takes time to develop. To accelerate cloud adoption, large financial institutions need to focus efforts on investing in their people, streamlining the DevOps experience in hybrid cloud, starting hybrid on private cloud to promote the learning and experimentation, and testing/running applications in the cloud.

When creating a change management strategy, you should develop a consistent and repeatable process focused on building knowledge and expertise in new technologies; It’s easier said than done. Throughout the skills acquisition journey, the goal should be to move your team from unconscious incompetence to conscious competence by: convincing and converting, training, coaching and supporting. Early in the process, when you introduce a new technology to your developers and recruit people to be early adopters, you need to provide them with an overview of the cloud platform and the benefits that successful adoption will bring. It’s important to define what success looks like before developers begin training so they are aware of the results they are working towards.

Once a team of developers understands the cloud platform and the goals of the new features, they should be trained in using the platform in the context of the organization and the tools that will be available to them. During the training phase, it is important that developers are able to practice their new knowledge so that information is retained. The training stage should be mandatory before moving on to onboarding to ensure that developers are ready to access the platform. After the integration stage, when developers have access to the platform, it is essential that they have the right conditions to succeed. The change effort would face friction and could be slowed if there wasn’t a well-managed mentoring stage that gives them a safe environment to practice where there is no risk of data loss, d financial implications or failures. Finally, the last step in the skill-building process is to wean developers off their mentor and provide them with the right support system for help. Although it may seem like a time-consuming process, investing time in learning new skills will allow developers to become consciously proficient in using the target platform.

As cloud adoption continues to increase across major financial institutions, the hybrid cloud approach is becoming increasingly important, providing development and operational consistency across all cloud instances. Starting in the private cloud and progressing to the public cloud provides developers with the necessary context to develop their skills and build software that runs in the cloud. To create a frictionless adoption process, developer enablement should be an ongoing effort that includes development and support. Due to the ever-changing nature of the financial services industry, large financial institutions will need to implement a repeatable change management strategy to foster an environment that supports the developer learning process.