Customer Needs Drive Modernization Goals For Financial Services Organizations

The transition to mobile-driven interactions dramatically changed how consumers and brands interact, shifting expectations and putting pressure on organizations. For financial services, that shift — coupled with an influx of financial technology startups — is driving a reevaluation of their decades-old technology.

In response to changing customer needs, organizations are modernizing IT infrastructure to take advantage of new technologies in order to deliver more services to customers quickly. As these organizations address the challenges of modernizing infrastructure, they must also manage risks and costs as they determine their best path forward.

Out With The Old?

Many financial services organizations were established decades or even centuries ago and have been quick to adopt technology. Consider automated teller machines, first introduced in London in 1967. Every traditional bank adopted that technology, responding to customer demand for access to currency outside of traditional banking hours.

Indeed, technological advances frequently focus on customer-facing aspects of financial services, such as the ability to check balances from a phone and make bill payments via a website, but many advances were built on aging architecture.

The pace of technology adoption in the financial services industry has been slow, at least for traditional organizations. Several factors have contributed to this slow pace. In part, the traditional architecture has been reliable for decades, so why change what works? However, according to research conducted by Accenture, decades of building on top of an aging technology stack, along with the added complexity that mergers and acquisitions introduced, have essentially led to significant technical debt.

These aging technology stacks are the basis of most banking technologies to date, but they hold financial organizations back from delivering what customers expect from financial institutions today and limit future innovation. It's essential to maintain balance as you decide how to embrace new ways of doing business, adopt new technologies and find solutions that help you avoid excessive disruption to your core business.

When To Adopt New Technology

Many existing applications can move from on-premise to deployments in more scalable and responsive cloud environments fairly effectively, provided that you select the right architecture in the cloud. The challenge comes when organizations try to move legacy architectures to environments that they simply weren't built for. It may not be possible for these apps to get to a "perfect" state for cloud deployment, but by matching applications to the appropriate cloud architecture, you may be able to redeploy effectively on public or private clouds.

Alternatively, your organization might rebuild applications for cloud deployment using new programming languages and architectures. Rebuilding is a significant effort and could require new tools and staff expertise to rewrite the code for those applications.

The best way forward is to identify the 20% of your solutions that will account for 80% of your results. Review which applications are most in demand, and build those that will result in the greatest impact from your efforts. You'll likely need to rebuild some applications for the cloud, designed for scalability and responsiveness through the use of microservices, containers and Kubernetes.

For example, challenger banks are offering rapid end-to-end loan processing. Delaying on modernizing those application types may significantly impact revenue as more established financial services organizations lose mindshare — and customers — because your organization cannot respond at the speed that customers now demand. Other applications may have data sovereignty or compliance restrictions that make an on-premise or hybrid-cloud deployment preferable.

Three Principles For Planning Your Path Forward

The first step is to build new applications using modern architectures, not on top of your legacy stack. Adopting microservices architecture for new applications makes it easier to build apps based on new customer requirements and expectations. It also provides an opportunity to experiment without impacting critical revenue-generating applications.

As you do this, define your APIs well to prevent dependencies between microservices while still enabling the exchange of data. Remember, once APIs are published and available for use, they become one-way contracts. You'll be forced to guarantee backward compatibility. This is a critical concept that many organizations new to microservices and APIs don't fully grasp. Getting the APIs wrong can result in significant technical debt, even on newer technologies.

Once you've started by deploying new applications, you may choose to move existing applications to the cloud and use cloud-native solutions to power them. A common trap that many organizations fall into is reusing data management patterns learned from new applications and applying them to existing applications.

It's common for new applications to leverage NoSQL technologies for data management. However, it's a critical mistake to think that NoSQL technologies can be used for migrating all existing applications. Moving to a NoSQL database for existing applications enables a distributed deployment model but adds significant risk to the application redesign.

The differences between strict consistency (provided by the legacy database) and eventual consistency will probably require significant application changes to support. To limit risk, I believe it's important to minimize application changes by choosing a database that offers the same transactional consistency and durability your applications were built on.

Finally, don't try to boil the ocean. Tackle modernization projects on an application-by-application basis. This limits the scope of your immediate changes, allows your organization to adapt to changing development and operational models and helps you choose how, when and which applications you deploy in distributed environments.

Finding The Right Deployment For Your Organization

When moving existing applications to the cloud, consider moving from on-premise to the cloud using a hybrid model. For many organizations, a hybrid cloud deployment may be ideal, as workloads can be deployed on-premise or on private or public cloud platforms, allowing you to leverage cloud-first principles without introducing excessive risk or complexity.

Frequently, organizations talk about "digital transformation" and "moving to the cloud." From my experience, managing some workloads in on-premise data centers and in hybrid environments is still the best option. Adopting a hybrid cloud infrastructure enables organizations to develop and deliver in an agile environment while maintaining security and stability for applications that require it.