Photo by PiggyBank on Unsplash

The banking industry has been under a tremendous amount of pressure lately. Interest rate hikes, increasing unrealized losses, and recent bank failures are pushing banks to increase the cost of credit while customer and investor trust erodes. These issues, alongside constantly changing regulatory and customer demands and technological advancements, are further fueling the relational transformation that is happening between banks and their customers.

Amid these headwinds, banks are also being presented with many new opportunities, including open banking, embedded finance, banking-as-a-service, mindful resource consumption, and increasingly tech-savvy customers.

Illustrative, non-exhaustive list of trends in the banking industry

However, to capture these opportunities, banks must continue their technology modernization to access new markets, accelerate innovation, and expand the value they create for their customers as they build toward the bank of the future they want to become.

These technology investments will help banks future-proof and adjust quickly and seamlessly to new industry developments. However, this is not an easy shift and right now cost-sensitivity is critical amid the ongoing economic uncertainty.

While some banks have modernized or moved to the cloud, many banks are still struggling with legacy systems, not having a full picture of their data ecosystem or how it’s being used. These are difficult issues to address as the market uncertainty continues putting pressure on discretionary spend and technology investments.

How then can banks build for the future while operating within the constraints of today?

An opportunity to accelerate and remain nimble

The good news is that not all banks must take the same long journey toward modernization. Whether in the cloud, on premises, or hybrid, there are opportunities to jump ahead and take advantage of new advancements. One such example is event-driven architecture.

With event-driven architecture, events pass from one service to another in a modular way. If one service breaks, the events may pile up until the service is back online and operational, but the remaining services downstream are not seriously impacted.

Rather than requiring an API call to transition between each step, event-driven architecture can enable a customer experience to flow on demand. Such a system improves the customer experience, optimizes compute via utilizing an on-demand pull method, and modularizes the entire system to enable easier and more efficient development of any one component piece in the future.

But what does it look like? Well, let’s see it in action!

How to transform your lending experience with event-driven architecture

In this fictional example, we will look at how a bank adopted event-driven architecture to build for the future while solving for customer experience challenges today.

1. Define the business outcome

Let’s say a bank wants to acquire more lending customers and has decided to improve the lending-customer experience to be more real-time for the customer and cost-efficient for the business as it begins to expand its lending products and prepare for the summer lending season.

2. Assess the bank’s existing technology

When implementing event-driven architecture for the first time, the bank will need to assess its current technology by:

• Assessing current bank infrastructure, including hardware, software, applications, databases, and networks
• Evaluating data flow, communication patterns, and system compatibility
• Re-examining the logical separation of functional components

Doing so will help to ensure support for real-time, event-based communication in addition to ensuring that robust data storage, processing, and analytics solutions are in place to manage increased data volume, velocity, and variety.

It will also help to identify which other transitions will be needed to implement event-driven architecture. For example, transitioning from monolithic systems to agile approaches like microservices is crucial, which may necessitate new development and deployment processes if not already in place.

3. Determine how to facilitate it with events

Next, the bank must review the core process flow and design how the user experience would be facilitated with business events that trigger the lending process. One way to do this is via a method called event storming, a collaborative modeling technique that can be used to investigate and comprehend complex business domains, process flows, systems, and events.

Illustration of event-storming session outputs

Using event storming helped the bank to facilitate communication and collaboration among cross-functional teams, including business analysts, developers, testers, and domain experts. This identified and gave a visual depiction of the bank’s system and process and sketched out the sequence of events that occur. The resulting “event map” gave the bank a shared understanding of the lending process flow that may be used to influence solution decisions and creation.

4. Design the experience

It is worth noting that breaking up a monolith and moving to event-driven architecture does not require an organization to redesign or rearchitect an existing user interface. However, for the sake of this example, let’s assume the bank took this project as an opportunity to also redesign the user experience to be more outcome-driven.

Using customer research and the event map, the bank then developed both web and mobile experiences, based on user needs, and built low- and high-fidelity user experience designs to prepare for development.

Illustration of web and mobile responsive user experience derived from lending process flow

5. Design and build the architecture

Next, the bank built the architecture by identifying event producers (systems or applications that produce the events), brokers (middleware that receives event producers and routes them to event consumers), and consumers (systems or applications that respond to events by performing a task). The bank then designed services that would respond to the events and facilitate the lending experience.

Illustration of event-driven architecture for bank lending

While doing this, the bank defined event schemas, registries, and versioning to help define what an event looks like and ensure consistent communication and evolution within the architecture in the future.

In the design, the bank also consolidated separate, existing microservices to ensure functional separation and independence. As part of the final solution, the bank also built machine learning models to analyze event data, which will help to continually improve its applications, models, and processes to predictively improve customer experiences in real time.

6. Build each component one by one

While the way to build event-driven architecture in a bank can vary organization to organization, it is generally best to build each component one by one. The bank did this by taking an agile-based product engineering approach, breaking down component development over a series of development sprints. Further, it created an easy on-ramp by working on developing producers and brokers in parallel with the current architecture so that consumers could be gradually moved over.

Illustration of agile-based product engineering methodology used for development

This approach enabled the bank to build a system custom-tailored to the original business objectives, while being able to flexibly adjust as the team learned during development.

7. Link the solution together.

Finally, the bank connected the architectural pieces together; linked the services, brokers, consumers, and producers; and leveraged test automation for quality at scale.

Through the use of demos, user feedback, and documentation, the bank was able to release product code into production on time for the summer lending season!

So, what did the bank get out of all this investment?

The immediate value and step toward your future

There are several benefits the new event-driven architecture provided the bank immediately, including:

Cost efficiency

The new lending experience reduced cost by shifting to an on-demand compute model so the bank would only pay for compute used, in addition to reducing infrastructure and maintenance costs.

Agility

Event-driven architecture, by design, is agile and flexible. This means the bank’s ability to manage the complex nature of its lending business, products, and customer experience became easier to modify and more adaptable to business requirements, constantly changing customer needs, and internal technology and operational changes, or new regulatory requirements.

Real-time processing

Event-driven architecture enabled the bank to process lending data in real time, improving the bank’s ability to respond to customers, address changes in lending market conditions, manage risk, and provide insights to make timely decisions.

Real-time data sharing, security, integration

Event-driven architecture provided both real-time data sharing and a secure way to share data with third-party providers, only sharing the necessary event data rather than the entire process. This enabled the bank to integrate with third-party providers while mitigating risk by still being able to enforce stringent data privacy, access control, and protection for their customers.

Observability and resiliency

To note, some events are based on monitoring metrics. In order to have an event-driven architecture, strong monitoring is required. By extension, building event-driven architecture can help with resiliency where metric alarm could be an event that triggers automated remediations. In this example, the system saved the bank’s engineers and IT personnel from getting woken up at 2:00 a.m. without immediate paths to remediation by helping to keep the system up and running without manual intervention.

In addition to this immediate value, the investment helped the bank to build for the future in several ways:

Scalability

With lending service components decoupled into their individual components, able to be replaced or scaled out as needed based on the event, the bank could handle the variable transaction volume during peaks and valleys in demand without affecting performance, something critical for those considering the scalable needs of banking-as-a-service.

Innovation

Connecting into events emitted as a part of the business and doing things differently with them unlocked a whole new realm of innovation for the bank. These changes didn’t impact existing systems while allowing for an “evolutionary architecture.”

Synergy and cost efficiency

In addition to investing in the cloud and following a common practice in the banking industry, the bank also began switching to serverless computing to only pay for what resources it used versus subscribing to large instances and wasting unused compute resources. With serverless relying on event-driven triggers that are more asynchronous and fault tolerant than API calls, the bank created a natural synergy between serverless and event-driven architecture.

Better interoperability and coordination

With dependency reduction a key priority in scaled banking enterprises, and many operating multiple technology stacks and teams, event-driven architecture enabled better integration with external systems and services via APIs and improved interoperability while maintaining tech-stack independence alongside easier coordination across teams and microservices. The combination of these allowed the bank to access new markets and offer new services to its customers.

These are just some of the ways in this example that the bank created value now and in the future. However, before undertaking the endeavor, banks should keep in mind several up-front costs and considerations.

The costs and risks banks should keep in mind

There are up-front costs and risks to adopting event-driven architecture, in particular with the bank’s talent, infrastructure, and operations.

Building your technology talent

Banksmust, of course, hire and train their workforce and build the tools and platforms to enable the use of event-driven architecture at scale. It further requires a developer mindset shift for how software is developed.

Shifting banking processes from strong consistency to eventual consistency

Many core banking processes are synchronous and transactional by nature, limiting flexibility while ensuring consistency. While event-driven architecture enables more resiliency and flexibility, it does so at the expense of implementing distributed transactions. For a bank, or any business with critical transactions, this means it must embrace using eventual consistency, a model in distributed systems where data is guaranteed over time, but not immediately. While this can be a methodological shift, if event-driven architecture is implemented correctly, the shift may not be observable as event-driven architecture can achieve eventual consistency (within milliseconds) via robust, asynchronous, and independent event processing, enabling continuity of safe and compliant processes.

Embracing system complexity, but avoiding distributed monoliths

Event-driven architecture shifts a bank away from monoliths that all move at once into decoupled modules. With this comes the need for a significant investment in infrastructure and the risk of increasing complexity of the componentized system you are trying to manage. Similar to other paradigms, when event-driven architecture is implemented incorrectly, it can become very complex and/or result in a distributed monolith. Such a system inhibits the potential cost efficiencies event-driven architecture can create, compared to monolithic structures, and would leave a bank with a more costly and complex system to manage. It is important to reexamine logical separations of functional components to untangle monoliths into decoupled modules. Doing so helps to avoid rebuilding a distributed monolith with event-driven architecture, which can be a more complicated and costly problem, if unintentionally created.

That said, in general, most organizations still consider the benefits to outweigh the costs, which is why we at Slalom continue to see the industry move toward the adoption of event-driven architecture right now.

How can banks get started with event-driven architecture?

While some banks and many tech companies are starting to adopt event-driven architecture, especially alongside serverless computing, to optimize costs, enable real-time personalized customer experiences, and help build for the future, I would note that none of these are trivial investments. If done incorrectly, event-driven architecture can create additional costs, risks, and complexity into banking systems. For banking enterprises ready to start the shift, consider the following steps:

1. Assess where you are today

To prepare for adoption, banks must first assess their current technology and determine whether and where it would make sense to implement event-driven architecture.

2. Make the shift to event-driven architecture a strategic priority

Shifting to event-driven architecture should be an investment on par with your top-level strategic priorities and its adoption needs to be sponsored and shared by your C-suite to reinforce how this technology imperative ties back to your business and customers.

3. Start small and build incrementally

“Big bang” new platforms often get a lot of pushback. You don’t have to replace or even map out your entire lending platform all at once. You can start with just a notification email being sent after an application is approved, for example. Work with your leadership, teams, and stakeholders to identify opportunities to start making small investments in event-driven architecture, and build from what you learn. This can help to show a path to development, piece by piece, alongside your existing system.

4. Invest in a center of excellence

Your people, developer culture, and organization will need to transform with your development philosophy, and the pilot areas where you begin using event-driven architecture will need support and spotlighting. You can help to do this by building an event-driven architecture center of excellence to help reinforce learning and accelerate enterprise adoption.

At Slalom, we know firsthand the challenges banks are facing today, and are working side by side with their technology teams to help build the bank of the future. Wherever you are in your digital transformation journey, we’re here to help.