Trend focus: Event-driven architecture

As companies become more digital and adopt outward-facing ecosystem models, they start to shift towards event-centric thinking. Event-driven architecture (EDA) is emerging as a key design paradigm for building digital banks and simplifying regulatory support.

Interactions through business events

AML is an area where EDA is eminently suitable

At the core of EDA is the business event, which recognises things that are of business interest, and notifies others about the occurrence to allow them to react to it. Each business event is a factual representation of something that has happened, e.g., an agreement has been signed or a payment made. Other areas, like product fulfilment, fraud screening, or accounting, can then take further action just based on the event.

From process orchestration to choreography

Events act as a complement to APIs through publish-subscribe or data streaming, and are particularly suitable when used with microservices. Domain-driven design provides a good entry-point to identify these events. Instead of traditional static orchestration of processes, events are often dynamically choreographed to solve business problems, and decouple consumers from producers. 

Early adopters focus on self-service and automation

LinkedIn, Netflix, and Uber are examples of early adopters, each with strong self-service focus. The use of EDA is growing within the financial sector, especially among new entrants, e.g., Funding Circle and Monza. In those cases, compliance is often cited as one of the drivers. There are also examples of where EDA is used for core banking transformation.

Some use cases in financial services include:

  • ING presented themselves as “the real-time event-driven bank” already in 2017
  • Nubank started as a card issuer in Brazil, and evolved into a digital bank around an event-based architecture
  • Rabobank underwent a journey to become an event-driven bank

Adoption challenges when not starting from scratch

The introduction of EDA does not come for free, however. Far from it. It requires adoption of event thinking, and a break from the traditional transaction approach usually applied in banks and other financial institutions. One of the biggest shifts is to accept there is such a thing as eventual consistency, and understanding the trade-offs that comes from that.

The ingrained methods to monitor applications and prevent and manage failures no longer work, and new sets of architectural patterns and best practices must be adopted across the organisation. And then there is the non-trivial issue with how to interact with monolithic legacy systems. The flexibility you get from events comes at a cost in terms of complexity that must be managed.

Once you get past these challenges, which some of the use cases listed earlier prove you can do in an incremental fashion, you must establish enterprise-wide discovery of business events.

Difficult to measure benefits in hard currency

Responsiveness is one of the key benefits of EDA, both from a customer experience point of view and the ability to integrate new business processes and regulatory requirements. Time-to-market can make or break a business case, and usability can help attract new customers, but otherwise most benefits are related to savings and flexibility in development and integration work.

From a business point of view, events provide a natural and easily understandable concept with clear implications, and allows the capture of significant business moments. In addition, the underlying technology then makes it easy to disseminate contextual data to where it is needed when it is needed without explicit integration work. The related logs can also be used for compliance and audit purposes.

From a technical perspective, EDA enables higher availability and scalability than many other development paradigms. At the same time, especially if domain-driven design is employed, it helps bridge the gap between business and IT, and different domains can evolve in parallel with clear interaction points.

Please share

This Post Has One Comment

  1. Peter B Lange

    Really good considerations. Regarding benefits in hard currency. There are some well defined KPIs for DevOps. When we apply concepts like events, APIs and micro services it is to get fewer dependencies to each other so each team can move faster. DevOps KPIs improve with CICD and improves even further when we re-architect the applications to smaller loosely coupled units. EDA must contribute to improved KPIs so I would suggest a mapping to those KPIs that some financial controller type could then make a $$ guestimate on. What do you think?

Leave a Reply