From SOA to EDA: The Evolution of Enterprise Architecture in Financial Services

Businesses succeed by constantly creating differentiated customer experiences that drive value for their shareholders. They do so by leveraging their assets, credibility, customer bases, and institutional knowledge, but can sometimes be saddled with the “technical debt” associated with platforms and products they’ve implemented over time as part of approaches like service-oriented architecture (SOA) and message-oriented middleware for their enterprise architecture. So as the number of applications, compliance and audit obligations increase, their legacy infrastructure can hinder their ability to do either but event-driven architecture offers a solution.

The Olden Days of Enterprise Architecture

Imagine working with hundreds of applications and servers, and the only way to share information is with point-to-point messages. Historically, that’s how applications interfaced with each other at major financial institutions.

Standard Chartered Bank’s executive director of integration strategy programs, Srinath Sripada-Rao, knows this history well, and described the old way as a “hairball” of interfaces in this talk at EDA Summit in May 2021. It was also commonly called spaghetti architecture, and entailed establishing direct connections between each pair of systems that needed to communicate. Needless to say, it was a nightmare to manage, let alone scale. This “technical” view of the system where you physically (or virtually) take wire and plug into another system (and do it a hundred times over) cannot scale and is a nightmare to manage.

“Functional” View Opens Things Up

In the 90s, message-oriented middleware products like IBM MQ and TIBCO Rendezvous introduced ways of routing messages by queues and topics, and in the late 90s an approach called service-oriented architecture (SOA) reimagined IT deployments as a collection of functional boundaries. For example, the function “Payments” is a service that is available to other services. Another service like “Customer Experience” can use it for processing payments or refunds. A new class of software called an enterprise service bus (ESB) was responsible for making the Payments service accessible the rest of the enterprise and their ecosystem of partners.

SOA is based on knowing the endpoint for a service (or feature) and then invoking it via a request/reply interaction, as Srinath described in his talk during the recent EDA Summit.

SOA’s usefulness for enterprise architecture begin to wane when businesses started migrating workloads to the cloud. The point to point or one-to-many nature of messaging patterns in an ESB cannot be extended to cloud-based workloads and are particularly painful when deploying systems across multiple clouds.

If you, like SCB, want topology-agnostic applications that you can manage with a uniform, cloud-agnostic toolset via one control plane, you’ll want to work with microservices and use a platform that enables a secure yet steady steam of data movement across your enterprise.

It’s important to understand that this evolution is gradual. Not only for the business, but also for the industry. For the last decade or so, SOA has been giving way to newer enterprise architecture technologies like application programming interfaces (APIs), data streaming, and event-driven architecture (EDA) that offer (with minimal disruption) better customer experience, agility and robustness.

Bounded Context (Microservices) Coupled with Event-Driven Architecture

Systems based on services are made up of loosely coupled, reusable, and specialized components that work independently of one another. Microservices in particular are typically autonomous and self-sufficient because they have their own data store, thus can be containerized for easy deployment and migration between datacenters, clouds or both.

This cloud-friendliness opens a whole world of possibilities for financial institutions where they can port and deploy compliant microservices and craft new service experiences that go beyond their traditional in-house expertise.

To achieve the agility and innovation SCB was looking for, Srinath and his colleagues realized they needed a “fabric” that can host the applications, the services, the components – all of it – and create a seamless event-driven flow of information between them.

This is where an event mesh comes into play.

How EDA and Event Mesh Help Financial Institutions like SCB

Large financial institutions are critical to the health of the economy, and are heavily regulated and audited. Because of these lofty expectations and bureaucratic challenges, they need smart enterprise architecture to innovate and create operational efficiencies for the benefit of their customers, the markets, and shareholders.

A key part of this journey is creating standard systems and processes that can be reused across geographies, asset classes, and lines of business. To make this process agile and non-disruptive, SCB leans on event-driven architecture – specifically a global event mesh to integrate new countries and businesses without disrupting their core systems and operations.

All the in-country “flavors” are easy to deploy by using an approach that Srinath argues is most important for a scalable solution: taxonomy.

Taxonomy

Imagine your local regulator shows up and says “we need to monitor all transactions above 1 million dollars for the next 24 hours… starting now”. Can your systems handle this request?

If you are using well-designed event-driven architecture including good taxonomy on your event mesh, it’s an easy request to handle. In fact, with well thought out taxonomy you can zoom in and out of your entire deployment without worrying about where the applications are deployed – on-premises or in the cloud. You are simply choosing a coarse- or a fine-grained filter to monitor all data movement.

When you launch services in a new region, you allow traffic in and out based on your taxonomy. That makes it easy for you to launch services, and easy for regulators to check the boxes they need to check. For an institution like SCB, the same customer can have multiple profiles – as a checking accounts holder, a credit card holder, and a high net worth individual, to name a few examples, and a proper taxonomy helps you build an experience that best suited for their needs.

Back to the request of the regulator: “We need to monitor all transactions above 1 million dollars for the next 24 hours… starting now”. In event-driven architecture that translates at the system/topic level to “Listen to Cash/Payment/FAST/IN/1MM+” (assuming a topic structure of type/platform/country/tier).

Contrast this with how a legacy SOA system would have to manage this request. First, you’d have to figure out how do it, and then code each system to feed this information into another application that could be accessed by the regulators.

I loved the way Srinath summed up his experience with an event mesh. He described event mesh like the Uber of enterprise architecture: “I can go to pretty much any city in the world and just pull up the app and get a cab. If there are restrictions/specifics to that city, the app takes care of it but helps me get a ride.” (paraphrased)

That’s really how easy your enterprise architecture experience can be if you use the right event streaming and management platform to implement EDA and an event mesh, and follow best practices developed over many years by industry veterans like Srinath.

He summarized the benefits on an event mesh for a complex and global setup like SCB’s with this beautiful visual:

To learn more, check out Srinath’s EDA Summit presentation Standard Chartered Bank’s EDA Journey on YouTube.