Why event-driven architectures are important today

These architectures enable the decoupling of rule-based services to microservices that consume and share data based on events

Development organizations sensing the shift from user-driven to machine-driven access patterns in APIs and services should consider event-driven architectures. These architectures enable the decoupling of rule-based services to microservices that consume and share data based on events. They are a capable approach to handling large volumes of real-time, complex transactions among IoT devices, data streams, workflow systems, and other services that sense and react to changing conditions.

You can better understand why event-driven architectures are more important today by looking back over the last two decades of internet-based architectures.

Most developers are familiar with two- and three-tiered web architectures designed to manage user experiences, process business logic, and interact with back-end APIs and data sources. There are mature patterns such as the model-view-controller (MVC) with implemented frameworks on many platforms to support these types of applications.

Developers learned quickly that separating business logic from presentation was important to scaling application development. Many organizations matured to engineering APIs as part of developing mobile applications, and some introduced service buses to help orchestrate multistep transactions and workflows across these APIs.

These are early steps to today’s architectural demands where users are no longer the primary customer of APIs. There are far more applications, data services, and sensors both internal and external to the organization that are the primary customers to API and services. These services are more capable and reusable to support new and changing business needs when they are engineered as microservices that can sense and react to events from an ecosystem of integrated services. This is why event-driven architectures are important today.

Defined: What is an event-driven architecture?

One easy way to understand event-driven architectures is to define services based on input and output event patterns:

  • Services that generate new events such as sensors, user input, and data streams.
  • Services that generate events through state changes. Examples include date-based transitions such as expiring subscriptions or wakeup alarms.
  • Services that largely process and consume events such as displays and dashboards.

Martin Fowler provides richer descriptions of event types that differentiate capabilities performed by the services. For example, event notifications broadcast without processing the response, event carried states broadcast complete details of the event, and event sourcing services record state changes.

Then there are different topologies, depending on how business logic is distributed. For example, a mediator topology may be appropriate if the architecture requires a centralized system to process raw events to then redistribute downstream change events.

There are operational considerations when designing event-driven architectures, including scalability factors, latency requirements, service levels, performance factors, security requirements and error-handling requirements.

The types of events, topology, and operational considerations are all factors in designing the architecture.

Examples of event-driven use cases

There are many business opportunities that align well to event-driven architectures. I spoke to several leading CTO at technology companies about event-driven architectures to better understand the types of patterns and applications.

Paul Butterworth, CTO of event-driven platform provider Vantiq, suggests that digital enterprises address real-time business opportunities by decoupling events from one business unit that may have value to others. He says, “The real-time, digital enterprise is naturally modeled as events that occur throughout the enterprise and the actions taken in response to those events. The key to the digital enterprise is that an event may occur in one business unit with a number of independent business units independently and asynchronously responding to the event.”

An example of this is when multiple businesses interact with common customer segments but sell different products and services. Every customer touchpoint with a business unit generates events that subscribing business units can consume. The decoupling makes it easier for business units to improve sales or customer experience because each unit can determine how to use the information from events of interest. One important implementation consideration is to determine the access rights and entitlements on who should get access to what events and with what types of data.

A second business need is around complex business processes that manage state changes. Karthik Ramasamy, the cofounder of event services platform Streamlio, suggests, “Event-driven architecture is valuable for applications where speed of response to events is critical or where processing events provide a more efficient way to track and update state. For example, microservices integration is often correlated with event-driven architecture.”

Consider complex supply chains where multiple components are manufactured in different locations and by different suppliers. With an event-driven architecture:

  • Supplier systems broadcast real time information on their production status.
  • Management systems capture events asynchronously and broadcast production orders.
  • Downstream supplier systems capture the production orders and adjust their manufacturing output.

Greg Luck, CTO at in-memory grid provider Hazelcast, says, “Event-driven architectures invert the normal practice of accumulating data and the querying it. Events are the data and processed on the fly. This requires messaging and streaming infrastructure to process that data. It can also be coupled with an in-memory data grid for fast enrichment and storage of results.”

This illustrates a whole new set of applications that can be developed based on real-time events where data is streamed to multiple consumers. Consider self-driving cars that broadcast and consume events in real time and where driving decisions can’t afford the latency of storing and retrieving information.

Creating event-driven architectures in enterprises

Michael J. Morton, CTO of the cloud-services integrator Dell Boomi, provides suggestions on how larger organizations should think about incorporating event-driven architectures: “Organizations creating an event-driven architecture to support key projects today should take a step back and think about enterprise-wide event integration, distribution, and management. Where once it was common practice for enterprises to run their business on batch processing, this is no longer sufficient to be successful and fulfill their digital transformation journey.”

The implication is that event-driven architectures can be applied with limited scope when instituted in enterprises that have batch processing or integrations with enterprise systems and SaaS platforms that are not event-driven.

Like most architecture changes, selecting appropriate platforms, starting small, proving value, and refactoring in growing capabilities collectively are a good way to iteratively develop event-driven architectures.

Copyright © 2019 IDG Communications, Inc.