By Jamil Mina, Chief Architect, Financial Services, Red Hat
Over the years, the popularity of the public cloud has grown in the financial services industry, delivering on the promise to provision IT services faster and scale those services on demand to meet peaks in business demand. Cloud adoption requires developers at large companies to learn new technologies and become proficient at using them to maximize business value. For large financial institutions (FIs) that have complex technology ecosystems, including both 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. firms 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 and financial risks. This means that the modernization of systems need to consider data gravity and application architecture associated with legacy technology while also staying compliant with the changing regulatory requirements.
Throughout the cloud adoption process, there are a few common practices that large FIs use; all coming with their own unique challenges that can be properly navigated by having the right change management process in place.
Cloud adoption practices
The attributes of successful cloud adoption requires careful consideration to be both user-friendly and provide a consistent experience across clouds. Developers need to be enabled with rapidly provisioned environments to build applications and the platforms, where they deploy their application, have to allow for 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 either used individually or in combination – process guard rail, discrete development practices, and cloud abstraction. All three of these approaches come with challenges that will need to be addressed through the adoption process.
Process guardrail is used to help FIs mitigate operational risks and minimize financial risks associated with unmanaged cloud resources. This approach requires the vetting of every request first in order to apply to the cloud; this tends to be lengthy and often requires several approvals. As part of this process, developers are required to develop in environments that do not resemble the target cloud environment. Only once they are given access to the public cloud are they provided with the production environment that is typically made available for a short window of time. This short period of time is typically insufficient for developers to learn and adjust their code to the target environments. Process guardrail adds bureaucratic friction, increasing long lead times and limited access to the cloud that slows application deployment times into the market.
Following process guardrail, an additional practice coined as discrete development practices emerges when FIs mandate the development practices specific to 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 restricts access to the environment given the lack of practice with it and the steep learning curve. This is compounded by the added pressure from the regulators who are looking for service interoperability, portability, and resiliency across cloud service providers. The cognitive load on the developer has a compounding effect and impacts their ability to retain the necessary information in their working memory and that makes them less productive.
An alternate approach following the process guardrail is to adopt a cloud abstraction layer. FIs challenged with slow adoption often undertake large projects to add a proprietary abstraction layer to ease the delivery of applications to both the public and private clouds. There are a few drawbacks to this approach, like the overall resource consumption and management distraction that occurs when building a do-it-yourself platform that detracts from providing business value. Additionally, the development process has activities that are done on the local computer, which does not meet the developers’ needs for career growth. Developers aspire to further develop their skills through new and better ways to craft applications, aligning their skills to the industry as a whole, and staying up to date on the latest practices and technologies. The issues associated with a proprietary approach to cloud abstraction can be mitigated by using open source technologies that provide the opportunity for developers to learn and grow their skills in alignment with market needs.
While these three practices may seem straightforward, it is difficult to achieve cloud adoption at large FIs without a robust developer enablement and change management plan to help your organization’s developers achieve their desired outcomes.
Developer enablement and change management
Each of these cloud adoption strategies will require new technology, which introduces an array of challenges. Overcoming these challenges require change management initiatives that focus on business objectives and outcomes. Enabling developers by removing compliance burdens and technical debt struggles will ultimately make cloud adoption successful. Change management to adopt the new processes, systems, and expectations does not happen overnight and creating expertise within developer talent requires practice and takes time to grow. To accelerate cloud adoption, large financial institutions should focus their efforts on investing in their people, streamlining the DevOps experience across the hybrid cloud, starting hybrid on the private cloud to promote learning and experimentation, and testing/running applications in the cloud.
When creating a change management strategy you need to develop a consistent, repeatable process that is focused on building knowledge and expertise in new technologies; this is easier said than done. Throughout the skills acquisition journey, the goal should be to take your team from unconscious incompetence to conscious competence by: convincing and converting, training, and mentoring and supporting. At the beginning of the process, when you’re introducing new technology to your developers and recruiting people to be early adopters, they should be provided 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 that they are aware of the outcomes that they are working towards.
Once a team of developers understands the cloud platform and the objectives of the new capabilities, they should be trained on the use of the platform in the context of the organization and the tools that will be available to them. During the training stage, it’s important that developers are able to practice their new knowledge so that the information is retained. The training stage should be mandatory prior to progressing to onboarding to ensure that the developers are ready to access the platform. Following the onboarding stage, when developers are given access to the platform, it’s paramount that they are provided with the right conditions to be successful. The change effort would face friction and could be slowed down if there isn’t a well-managed mentoring stage that gives them a safe environment to practice where there is no risk of data loss, cost implications, or failures. Lastly, the final step to the skill acquisition process is weaning the developers off their mentor and providing them with the right support system to get help. While this may seem like a time consuming process, investing the time to learn new skills will enable developers to become consciously competent at using the target platform.
As cloud adoption continues to rise across large financial institutions, the hybrid cloud approach is becoming more prominent, providing developmental and operational consistency across all cloud instances. Starting on the private cloud and progressing towards the public cloud provides developers with the context needed for them to develop their skills and create software that runs in the cloud. To create a frictionless adoption process, enabling developers has to be a continuous effort that includes nurturing 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 learning process for developers.