Event-Driven Explainer

Event-driven computing has been around for a while. However, the asynchronous nature of event-driven applications requires that specialized knowledge, craft, and tools used to properly build event-driven applications.

“An event-centric approach to integration focuses on moving events (and streams of events) from publishers to subscribers. The data being moved may represent business events (e.g., a customer subscribing to a service) or application events (some state has changed). The important thing is that the events represent things that have happened, and that you generate events without regard for who or what may consume them.”¹

Unlike with request-response communications, event-driven computing is only now emerging from the realm of complex enterprise integration efforts. This emergence is due to a few different factors, including mesh computing (which is largely event-driven) and a focus on the experience.

Events (and their tooling) need to progress along with the same evolution that has happened with APIs/Connectors in areas such as security, governance, developer collaboration, and DevOps.

Until then, there’s an arbitrage opportunity for those companies that can take advantage of event-driven computing when their competitors can’t (because of technical skills, culture, or internal process limitations).

[1] Gartner, Choosing Between Data-, Application-, and Event-Centric Integration Styles, Matt Brasier, Joe Maguire, 21 November 2019

A human metaphor

Have you ever had your doctor say, “The blood test results should be here in about a week, call me”? The only correct response to that directive from your doctor is, “You know when the results are in, you call me.” Besides, the receptionist is busy enough that they don’t need to hear from me… “are my results in yet?” every day.

Business drivers

Fundamentally event-driven computing is about real-time responsiveness to something that happens (an event). It’s not just about streaming data (which could be how events are delivered) rather, it’s about subscribing to an event so that something interesting in that event is notified or updated when an event occurs (and with relevant information about the event).

Event-driven architectures are an asynchronous methodology that enables a more responsive, real-time execution of business capabilities.

Companies, especially in complex “solution spaces” are looking to get more real-time situational awareness. They need to make better decisions, in real-time, with the most accurate and up-to-date information available.

Benefits to companies are found in three areas:

1. Event-driven computing can be more efficient both architecturally and temporally. Meaning, with event-driven architecture, there’s less polling overhead, and the associated delay between polls is eliminated.
2. The world is shifting to experiences, and people don’t like delays. People don’t like to have to tell computers things computers already should know. And, people don’t understand why, for example, when their plane is delayed, they have to call customer service to start the rebooking process. The airline knows about the delay and who’s on the plane. Why isn’t the airline driving the rebooking process?
3. New technical possibilities open doors for innovation. When financial trading companies used events and algorithmic trading the entire financial (trading) industry changed. Event-orientation will create new opportunities. Companies that can take advantage of those opportunities will create new markets, deliver better experiences, and be more efficient than their competitors.

The key decision point for companies is: when real-time offers a business value justification, event-driven architectures are required.

Near-real-time is another opportunity. Requirements can be met with polling, though might have limitations to scale. For example, smart sensor applications like smart cities or manufacturing, or smart vehicles like some solutions for logistics and transport, might not always need real-time information.

Yet, the sheer scale of devices would make any sort of polling solution effectively unscalable. And, the innovation opportunity of a peer-to-peer event network of devices would be lost.

In summary, event-driven applications accomplish a few critical capabilities for businesses:

1. They eliminate latency. In financial services, this is often referred to as low latency messaging for high-volume environments. That’s a fancy way of saying, “I care about the price of a stock, tell me when it changes.” There is a class of applications for which knowing when something, an event, occurs is critical. You want to make a decision as soon as you can. And, those that make better decisions first win.
2. They allow for efficient information distribution. The publisher of the event doesn’t care who’s subscribing. This is a one-to-many information distribution mechanism that’s highly efficient.
3. They create unlimited interest audiences. When polling is used, there’s a “permission nature” based on the scarce resource (the server being polled). Do we want to overload the server? What if something important needs to connect to the server? With events, the event is published. There’s no impact as different applications start to take advantage of the event. In fact, since the event is readily available more innovation can occur as people learn what events are being published. This does beg a question of security, and that’s one area that events lag REST APIs (for example). Security and all technical implementation details are beyond the scope of this report.