Decoder

Event-driven architecture

A style of creating software that uses business events to trigger actions. Ideal for rapidly growing enterprises that need to respond quickly to changes.

Event-driven architecture (EDA) describes a way of building your business applications so that business events trigger actions within the systems. For instance, an event could be the change of a shipping address in one system which is then automatically cascaded to all interested services.

EDA is well-suited to enterprises that expect to grow rapidly and those operating in fast-changing markets.

What is it?

EDA is a way of architecting software systems that relies on business events to trigger actions. Basing the design on these triggering events gives you greater flexibility and the opportunity to add new behaviors.

Learn more

What’s in it for you?

Improved responsiveness and time to market. These are the major benefits of moving towards an event-driven architecture. The further you get down the EDA path, the easier it becomes to make radical changes.

Learn more

What are the trade-offs?

EDA introduces complexity — both in operating your systems and in your ability to understand them. You need to ensure that the events that are acting as triggers are core business events — things that matter to your operations..

Learn more

How is it being used?

EDA is best suited to those enterprises that need to scale and respond rapidly to changes in their environment. While it’s easier to build event mechanisms for greenfield systems, it’s perfectly possible to introduce them using your existing infrastructure.

Learn more

What is it?

Event-driven architecture models your business systems as a flow of events — when an important business event happens, your systems are alerted to that change of state. A simple example could be a customer changing their address: once that state change is registered, your billing systems get notified of the new address. This is in stark contrast to traditional request-based architectures.

A major benefit of this architectural pattern is that it is both scalable and relatively easy to change. EDA’s inherently loosely coupled nature means that it’s relatively easy to make changes in one particular part of your systems, without breaking anything else.

A well-designed EDA will be based on events that are meaningful to the business. The events could be triggered by user activity, external inputs, such as sensor activity, or outputs from an analytics system. What’s important is the way you define those events, so that you’re capturing something important to your organization.

By basing your designs on these triggering events, you gain flexibility; you’re able to add new behaviors without having to redesign the entire system.

What’s in for you?

In an uncertain world, many business leaders are attuned to the need for flexibility and scalability. And where responsiveness and time to market is key, event-driven architecture offers many advantages. With EDA, adding new events and processes is easy.

And the further down the path you go with EDA — the more widely you introduce it across your systems, the easier it becomes to make changes to your business.

Event-driven architecture has benefits over the long term too. It is easier to maintain as events aren’t dependent on particular systems, meaning you can change one particular part without breaking anything else. EDA allows you to respond more quickly: to take advantage of opportunities or respond to threats more quickly. So it actually affects both the top line and the bottom line.

What are the trade offs?

EDA can be complex. If your enterprise is relatively simple or unlikely to change significantly, EDA may not make sense. If you compare EDA to a monolithic application — large self-contained systems, such as enterprise resource planning (ERP) — there may be more things that can go wrong, it may be more difficult to understand. So if you don’t think you’ll need to scale or you don’t think you’ll need the flexibility, EDA may not be appropriate for you.

There are still some organizations — albeit fewer than there were — that don’t want to invest in technology, and don’t see it as something that should be a core competence of the business. For those types of organizations, EDA may not be the right fit.

How is it being used?

The easiest way to build an event-driven architecture may be to design your systems that way from the outset. Many of today’s renowned digital-native platforms embrace event-driven designs.

But not every organization has the luxury of starting afresh. And it’s perfectly possible to build EDA on top of legacy infrastructure. Many organizations we’ve worked with start with a single EDA-based project and expand from there, as they realize more benefits.

And EDA is compatible with efforts to become an intelligent enterprise. EDA makes it easier to automate actions based on outputs from your analytics systems. And because you define what business events are important to your enterprise, EDA is well suited to incorporate real-time information from a variety of sources, for instance if you wanted to deploy an array of Internet of Things sensors.