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?
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.