How to avoid these 5 mistakes in event-driven architecture

Forrester stated that it is seeing an increase in interest in EDA. This is leading to five major mistakes it believes must be avoided.

Image by scyther5, Getty Images/iStockphoto

Forrester Research released ReportThis article identifies the five biggest mistakes organizations can make when using event driven architecture (EDA) and how to avoid them.

Forrester’s research acknowledges the fact that event-driven architecture has been around for a while. However, it does mention that the adoption rate has increased in recent months. Forrester said that they have seen an increase in interest in harnessing event for digital transformation in a way like RESTAPIs. 

SEE: Research: Digital transformation initiatives are focused on collaboration (TechRepublic Premium)

Forrester points out that eBay’s account deletion notifications, as well as Walmart’s order- and inventory notification notifications are two examples of real-world use of events. They also state that these uses show that organizations are “moving along a maturity track from seeing events only as a coding pattern to actually using them for business innovation.” 

Mistakes can be made in planning and execution, as with any adoption of new technology. EDA is not new, Forrester stated in its report. EDA is not new, but its problems are also well-known. Forrester identified five that should be avoided. They provided some tips for how to avoid them.

1. You don’t have to take the first approach.

Forrester explained that if you look at an event only from one angle, it is possible to miss opportunities to use the event for other business functions. This applies doubly to those who achieve initial success. It is easy for new opportunities to be overlooked after the first one failed.

Forrester recommended that you become familiar with many different architecture styles and contexts early in your career “so you can consciously choose which may add value for your organization.”

To summarize, brainstorm what an event could do before you try to use it for a specific purpose. 

2. Events aren’t the only thing that matters.

Forrester reported that EDA is often ignored by organizations. This can lead to events being used to relate event characteristics that are not tightly coupled, which then leads them to ignore a more coherent method of grouping related elements.

Forrester suggested that you don’t force EDA. Instead, you should use what is necessary for your situation. The report stated that events should be used alongside orchestration and APIs.

3. Do not limit your search to one EDA technique

EDA applications can be used for technology like Pub-Sub, Kafka, and FaaS. However, it is wrong to assume that any one of these technologies will fulfill all your EDA needs. 

According to the report, “If you think of events as one technology, then you limit your design options. This can also reduce your business potential for an event strategy.” Out of the three technologies mentioned, other options include streaming analytics and stream processing, as well as cloud-based queueing systems. All have their own applications.

4. EDA goes far beyond the mere use of events

According to the report, it’s not difficult for developers “to think that having events is architecture.” EDA means events are driving how your systems deliver business benefit. Architecture is about organizing systems in order to deliver business value.

SEE:  NFTs cheatsheet: All you need to know (free PDF). (TechRepublic)

EDA implementation is about moving beyond the use of events to trigger a reaction and towards using events in order to contextualize and catalog events appropriately to allow a business take action. 

5. Centralize your EDA strategy

Forrester claimed that events are not limited to a single company. Instead, they travel across domains and between processes, so that each team can develop its own architecture, based on business events. 

Forrester stated that there are four main points of coordination in EDA: taxonomy and identification and classification hierarchy, formats, schemas, patterns, and tech choices. EDA strategies that are successful will first focus on these key points and then build from a central axis in order to ensure smooth communications. 

Also, see