June 24, 2024Platform Engineering

Financial institutions aren’t seeing ROI on technology spend without standardized and automated development environments

Learn why banks and NBFIs aren’t seeing ROI on technology spend and how standardized and automated development environments like Gitpod can help.

Financial institutions such as commercial, retail, and investment banks, wealth management firms, and private equity firms used to be slow adopters of technology, prioritizing perceived stability and risk mitigation over innovation. However, this trade-off between innovation and risk is no longer commonplace, as adopting technology doesn’t come at the expense of risking security.

Yet, this increased tech spending isn’t generating the expected returns. Analyst reports indicate that financial institutions aren’t seeing the ROI they anticipated.

Challenges with technology in financial institutions

In the financial sector, security & compliance are always top priority. Traditionally, banks believed that building custom software was the only way to achieve the functionality, security, control, and stability they needed. However, recent analyst research highlights a shift from this ‘build over buy’ approach. Banks now allocate over 70% of their tech budgets to automation, AI, developer productivity enhancements, and other technologies. Despite this, even between the highest tech spenders and lowest tech spenders, research shows us that banks are seeing less than 45% return on their tech investments.

This reveals several potential issues:

According to research, ‘day 2’ overhead is the biggest contributor to the lack of return on investment. Let’s dig into why.

Banks and NBFIs that don’t consider ‘Day 2’ overhead will never see ROI on tech investment

‘Day 2’ overhead refers to the operations and maintenance expenses of software. This sneaky cost often gets overlooked in initial ROI calculations, especially among banks not used to buying rather than building. Solving ‘day 2’ issues requires evaluators to be thoughtful about the software’s deployment model — whether self-hosted, self-managed, vendor-managed or vendor-hosted. Almost all banks will require a self-hosted solution and assume that, because they have chosen self-hosted, they must also self-manage. This is a misconception; self-managed software is the largest contributor to ‘day 2’ overhead for purchased technology.

The better alternative is to look for self-hosted and vendor-managed solutions that check the box on security requirements without the operational burden. This is especially true for platforms that automate and standardize development environments.

While the deployment model is the most straightforward way to address ‘day 2’ overhead, other factors also affect low ROI:

Banks should shift to platform as a product thinking

Many financial institutions now turn to platform engineering to centralize technology efforts, drive cost improvements and automate processes. Unlike traditional IT and DevOps, platform engineering provides self-service solutions that developers can use without manual interventions. These platform teams integrate security and compliance, and create a ‘golden path’ for development teams to follow.

However, platform teams who don’t integrate an adequate ROI analysis in prioritizing work can contribute to ‘day 2’ challenges or lagging platform adoption. Platform as a product thinking aims to solve this. It’s a mindset shift that focuses on user-centric, business-centric solutions rather than simply delivering infrastructure. Moving to this model allows solutions to be designed with a focus on needs and pain points, rather than ‘throwing solutions over the wall’.

Additionally, platform teams have historically only been able to focus on ‘outer loop’ solutions. The ‘outer loop’ refers to everything a developer does that follows committing code to source control, such as continuous integration tooling, deployment or monitoring solutions. However, ‘outer loop’ solutions have an ROI ceiling. Developer productivity is achieved by keeping developers in a flow state, not by pushing developers to use, learn and adopt additional tools that are outside their existing workflows.

Taking control of the inner loop

By shifting focus to the inner development loop, platform teams can deliver capabilities directly to developers, embedding new tools in their workflows and controlling the platform team’s ability to drive higher ROI.

Gitpod fits at the core of your SDLC
Gitpod fits at the core of your SDLC

Why banks should standardize and automate development environments

Standardizing and automating development environments ensure that developers always have an out-of-the-box development environment integrated with the latest platform tooling, security updates, and cutting-edge AI features. Ona's AI-native development platform helps the worlds' largest financial institutions solve the following problems:

Financial institutions must recognize that increasing technology spending alone will not yield the expected returns without addressing underlying inefficiencies. The biggest challenge lies in ‘day 2’ overhead costs, which can be helped with shifts in practice like platform as a product thinking and supporting the inner loop, both of which can be immediately supported by automating and standardizing development environments.

Ona is a self-hosted – but not self-managed – solution for automated and standardized development environments and AI-native development, often described as ‘the goldilocks solution’. Ona's unique deployment model ensures banks have no ‘day 2’ overhead while checking the box on all security and compliance requirements. Gain insights into how your organization can increase ROI on tech spend using automated and standardized development environments.

This website uses cookies to enhance the user experience. Read our cookie policy for more info.