Q&A: How event-driven architecture benefits financial services firms

Ali Khan: What is event-driven architecture?

Joe Kennedy: Event-driven architecture focuses on the creation, detection, subscription and reaction to events. An event is the change in state of an object, like liquidating an investment. The act of selling creates an event.

Traditional service-oriented architecture focuses on data in a static way—gathering it, storing it—rather than on data as a moving thing. In the real world, everything we do is event-based, like the response to a request, whether made by a person or by a machine. In financial services, a mortgage application goes through several different states from the time it’s submitted to the time the customer gets approved. Each of these states represents an event.

Traditional architecture requires a push, an intervention to trigger the next action. This means that things happen sequentially, and as a result take more time. With EDA, systems reply to events as they occur naturally. The system doesn’t have to wait for a response to take another action. By supporting asynchronous communications, EDA gives you more speed and flexibility.

Ali Khan: Can you give us an example of how this would work in financial services?

Joe Kennedy: Sure. Take loan origination. You need many different checks and balances to carry out when someone clicks that loan application button. Someone will need to do a credit check. Someone else might need to fill in or verify the customer’s bank account balance. Someone will need to sign off on the application. Meanwhile, the applicant might click a button in a few minutes to find out whether their application was approved. With an EDA architecture, you can handle those flows. You can create events around those things to let them happen at the same time.

Another example focuses on onboarding a small business customer. Today, any onboarding experience has to be fully digital. If it doesn’t take seven minutes or less, the customer will drop off and go to a FinTech where they can get a similar product in three minutes. With all the questions you ask a customer during the process, EDA allows you to simultaneously pre-approve that customer for additional products and services such as a line of credit, credit card, maybe a payroll service.

Ali Khan: Why is event-driven architecture so important?

Joe Kennedy: Because it allows an organization to respond to events as they occur naturally. Event-driven architecture allows processes to happen simultaneously. You can conduct related activities in parallel, rather than forcing a sequence. This adds great speed and flexibility to any process.

Banks need to deliver products and services faster in order to compete. A large bank, with its legacy systems, can now compete against an online mortgage lender—and deliver a broader portfolio of products to customers with more speed.

Ali Khan: How central is event-driven architecture to cloud computing?

Joe Kennedy: You can run an EDA on your own servers, but you won’t get the same level of benefit you’d get on the cloud. At the same time, cloud-based architectures don’t inherently have to be event-driven. But both have characteristics that work together in such a way that they naturally belong together.

Event-driven architectures supply speed, scalability and flexibility naturally by their design, and cloud architectures implement them by the way that they scale horizontally, so the two are a good fit. Moreover, when you’ve got EDA on the cloud, you can have AI monitoring for atypical changes, listening to multiple events for multiple things.

Ali Khan: Our work today is almost completely characterized by a distributed computing model—distributed services and distributed systems in a serverless design. How does EDA support this approach?

Joe Kennedy: There are many ways to build distributed systems. We’re constantly challenged in deciding between the request-for-a-sponsor architecture and an event-based model. In reality, many of the sponsor-request-response architectures would be better implemented in an EDA structure.

In contrast to the sponsor-request model, the computer turns on its own node automatically in an EDA design. What this means is that you’re able to manage bandwidth spikes faster and more efficiently. With EDA, servers turn on and off automatically as the traffic dictates. With traditional architecture, you have to actually turn on the server. The ability to adjust automatically, to manage flows dynamically and without intervention, is also more cost effective.

Ali Khan: There are pros and cons to every kind of design system. What’s a key challenge with EDA?

Joe Kennedy: Many financial services companies don’t put all their applications on the same set of servers. The server farm handling the ERP system doesn’t talk to the servers handling API interactions for payments. When you put your systems in the cloud, they’re all on the same servers and have the potential to be linked, which might cause unintended or unexpected consequences. You have to secure all of the nodes each application passes through. And you may have instances where asynchronous events fire multiple times, so you may have to do some retooling to deal with the redundancies.

Ali Khan: What kind of flexibility can you have with protocols?

Joe Kennedy: There are many ways you can design the servers to communicate with each other. Most are plug-and-play widgets—webhooks, APIs, even WebSocket. Any of them can be used in EDA.

Ali Khan: Why not just go serverless? What makes EDA the right move today?

Joe Kennedy: There’s a lot of migration going on now, and it’s important for companies to consider their business goals and outputs in order to make the right choice. Going serverless is certainly one way to improve performance, but re-architecting on a bigger scale would give you more value.

Modern architectures are moving to microservices and decoupled design. EDA is the way to accomplish that. EDA gives you scale, flexibility and the ability to respond to fluctuations in the market.

Ali Khan: How do you know whether the IT system you have is right for EDA?

Joe Kennedy: If your data flow is based on a flowchart and the steps must work in sequence, EDA may not be right for you. Or if you don’t have a million people bottlenecked on the login, the shopping server traffic isn’t pegged and manually initiating a ticket to turn on additional capacity is sufficient, EDA may not be necessary.

Ali Khan: Why do some companies hesitate?

Joe Kennedy: A lot of capability still resides on mainframes and legacy systems. Realistically, you can’t move everything. We recommend getting started in a modular way. Whether it’s a new product or service, start to experiment with EDA to deliver a new advantage to your customers as soon as possible.