Introduction

Data is the buzzword these days: organizations want to be data driven. They create a lot of data, want to create value out of this data and want the data fast and available 24/7. Therefore the IT architecture needs to be flexible, scalable, resilient, responsive and message (data) driven.

This is where an Event Driven Architecture (EDA) can help and in the next 4 blogs I want to guide you in this event journey.

This first blog will be about events in general and how they can be utilized on all kinds of levels within an organization. In the second blog I will talk about a reference architecture that organizations can use as a starting point. It explains which capabilities are relevant in such an architecture. In the third blog I will describe some principles and guidelines that you can use within an event driven architecture. In the last blog I will explain how an organization can become event driven. I will take you through a maturity model and the steps that you can take to get to a level that your organization needs to reach its business goals.

So let’s start talking about events in the first place, because this will be the basis for the rest of this blog serie.

Events

An event can be defined as “a significant change in state” within a system. Events are everywhere within your organization and can be found on different levels. Dealing with events has become more popular again because of its use within Microservice– and Serverless architectures. Within such architectures services or components communicate through events which makes them decoupled and scalable.

Events are also used within application- and data integration, and (complex) event processing/streaming. In both situations the number of event occurrences differ. In data- and application integration there are less events and they differ in type and content. Examples are NewCustomerCreated, CustomerMoved, ArticleCreated, ArticlePriceChanged. Complex event streaming is more about the handling of events that are of the same type, but coming in a constant stream. Examples are stock rates, temperatures of a motor, bank transactions. The difference between “simple” and complex event streaming is that in the latter case event streams of different types are combined to discover smart information or patterns. An example of simple event streaming is the detection of anomalies within bank transactions. An example of complex event streaming is detecting the correlation between the number of online sales, region and weather conditions.

So when talking about evens, these events can occur on different levels. Depending on the level you are talking about, different tools and techniques are used.

Levels of Events

The following 6 levels of event handling are discussed:

1. Component level
   Application components can be developed with an event driven mindset. Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. ReactiveX(RxJava) was one of the first implementations of this programming paradigm.
2. Application level
   At this level components process events within the scope of the application, for example a button is pressed and a menu is shown. Microservices and serverless functions communicate a lot through events. The result is that applications become more responsive and scalable. Event sourcing and CQRS are two event patterns, described by Martin Fowler, that are used on this level. Event sourcing is a pattern where the events are the basis for application state. CQRS stands for Command Query Responsibility Segregation and in this pattern the query of data within an application is separated from the commands. This is a complex pattern which I have not seen much used yet.
3. Application to Application level
   On this level applications are decoupled by events and is used to implement application- and data integration. For example when an order is placed within an order management system, an event is raised that a sales order is created, and a warehouse system reacts on it by checking the availability of the product. Another example is the use of Master Data Management systems that generate data events in case new entities (e.g. a product) are created. This new entity can be sent to all systems that are interested in it. This way the architecture becomes more flexible, and becomes easier to replace- or add applications that are connected through events. On this level MOM/ESB and (advanced) event brokers are most suited and found.
4. Domain to Domain level
   Larger companies are usually divided into functional domains and to integrate these domains (advanced)event brokers can be used. On this level and beyond, event governance will become more important and in this case advanced event brokers are more suited. Organizations can also be global and then you need even more advanced features like an event mesh. This is an architecture layer that enables events from one application to be dynamically routed and received by another application, no matter where these applications are deployed (no cloud, private cloud or public cloud). This mesh is created and enabled by a network of connected event brokers/hubs.
5. B2C / B2B level
   Organizations more and more execute their business within supply chains and other eco systems. Business events are sent to customers and/or partners. For example sales orders are handed over to transport partners or customers get notified on their mobile phones that a package is underway. Advanced event brokers are needed on this level, because governance is unavoidable.
6. Public level
   The same holds for events that are interested for public, like stock market rates and temperatures.

Note that Domain Driven Design (DDD) and Event Storming are techniques that are used on all levels. The DDD is used to design components within applications and event storming is a workshop method, introduced by Alberto Brandolini, to discover events between those application domains.

Conclusion

Events are everywhere and are occurring and used on 6 different levels. The component-, application-, application-to-application-, domain-to-domain-, B2B/C- and public level. Depending on the level you are talking about, different tools, functions and methods will be needed.

The use of events can make your architecture more flexible, loosely-coupled, resilient and scalable.

In the second blog within this series, I will be talking about a reference architecture that can be used for level 3 and onwards.