Introduction

This is the second blog about event driven architecture. As was described in the first blog item, there are several levels on which events occur and are relevant. It is important on which level you want to implement your EDA. In this blog I will concentrate on the application-to-application level and beyond and I will describe a reference architecture that we use at SynTouch.

Event Driven Architecture

Events are the driving force within the event driven architecture. Events are produced, detected, consumed and reacted upon. One of the main principles of EDA is the separation and isolation of the sources and the handling of the event notifications. The advantages and use cases for an EDA are:

• (near) Real-time availability of data. This is and will become more important in data driven companies.
• Flexibility of application architecture, as the applications are loosely-coupled by the use of events
• Integration of merged companies can be made easier.
• Real time master data synchronization.
• Asynchronous handling of commands, so that calling applications do not have to wait. This increases the responsiveness of applications.
• Processing of (IoT) event streams and learning from this (aggregated/joined) data (machine learning and AI).
• Predictive and prescriptive analytics by monitoring event streams and helping the business in proactive decision making.
• Serverless is a new cloud architecture paradigm in which functions are triggered by events. This makes this architecture highly scalable.

So what are the functional capabilities you will need within such an event driven landscape to support these kind of requirements? That is the content of the next section.

SynTouch EDA Reference Architecture

There can be a lot of different type of sources that can generate events, like devices, applications, mobile devices and other systems. Depending on the events you want to handle and the way these events must be processed, different components and capabilities are required within your architecture.

Actors

The actors are the components that play a role within this reference architecture. There are publishers and subscribers (or consumers) within this model. Publishers are the resources that produce the events.

Publishers

• The Enterprise Application Components (EA Component)
  These are the applications within the architecture
• Event Hub. This is an event handling component on the edge of IoT devices that produce a lot of events (>million/sec).
• The process hub is a component within the architecture that handles the (automatic) business processes. These processes can generate business events
• MDM/RDM (Master Data Management/Reference Data Management) entities are created/updated/deleted. This can be relevant events for your enterprise

Subscribers

• EA Components can react to events that are generated by other components in this loosely coupled architecture
• Events can also be interesting for a Datalake which data is used by artificial intelligence (AI) and machine learning (ML).
• Business processes can rely on events so the process hub can also be a consumer of events
• The datawarehouse (DWH) can be used to generate more up-to-date real time reporting, when data is captured real-time.

Core capabilities

An event driven architecture will need core functionalities which are the fundamental capabilities of the architecture.

PubSub
Events need to be published and directed to subscribers, so the publish-subscribe pattern is a core capability of the architecture.

Monitoring
Monitoring of events is important. Which events are generated, how many, how many subscribers, how much time does it take to handle the messages.

Security
All aspects related to security. Who can subscribe to which event, authorization on the topics and queues. Securing the data of the event in case needed. Access control of the event hub platform.

Channels
The messaging backbone to transport the events between the publishers and subscribers. The protocols that are supported by the platform, e.g. http, MQTT, AMQP, JMS. The platform can also have several SDKs for different programming languages like Python, .NET, NodeJS.

Event Processing
Events can be processed in different ways.

• Simple event processing
  A (business) event triggers another part of the business process. This can be a software- or hardware event.
• Stream event processing
  Stream event processing detects ordinary events as well as the significant and meaningful ones, screening them to determine significance and streaming them downstream to information subscribers. This helps in enabling in-time decision-making.
• Complex event processing
  This capability handles an ordered stream of event notifications, applies analysis and, if a certain pattern is identified, generates event notifications. This event can be distributed to event handlers. All kind of stream functions can be executed like filtering, joining and aggregation.

Advanced Capabilities

The more advanced platforms will add more capabilities.

Event Catalog
This is a component that manages the events that are handled by the platform. Subscribers/developers can look up events and subscribe to them. Just like an API catalog.

• Event Definitions
• Event API definition (think of AsyncAPI)
• Event store on which events can be subscribed

Event Modeler
Events can be modeled and defined.

Metering
Just like APIs can be used, metered and financially settled with consumers, this can also be done with events.

Event Mesh
Organizations have hybrid IT landscapes with applications both on-premise and within the cloud. In this case a network of event brokers can be needed (also called an event mesh). In this network, brokers are distributed over multiple cloud platforms and on-premise, but the publishers and subscribers are unaware of this topology. The event brokers are bridged on infrastructure level, and the event mesh will deliver published events to the correct brokers.

Event Replay
Events are stored and can be replayed in case needed. For example a new subscriber can process previous events.

Conclusion

EDA has a high potential in enterprise architecture on different levels, but it does not come for free. There are a lot of items to consider when building a EDA strategy.

We at SynTouch can help you to take this journey, so please contact us when you need help.