Forrester said it is noticing increased interest in EDA, which is in turn leading to five big mistakes it said need to be avoided.
Forrester Research has released a report that compiles five of the biggest mistakes an organization can make when using event-driven architecture (EDA), and how to avoid said mistakes.
Event-driven architecture is nothing new, and Forrester’s report acknowledges that fact. It does add that adoption has been accelerating recently, particularly “Forrester has seen increased interest in harnessing events for digital transformation in a manner like REST APIs,” the report said.
SEE: Research: Digital transformation initiatives focus on collaboration (TechRepublic Premium)
Forrester cites eBay’s account deletion notifications and Walmart’s order and inventory notifications as two real-world uses of events, and said that those uses are evidence that “organizations are moving along a maturity path from simply seeing events as a coding pattern to using events for business innovation.”
As with any adoption of a new technology, mistakes happen, in planning and execution. As Forrester said in its report, EDA is nothing new. By extension, neither are its problems, five of which Forrester said are best avoided. Luckily they provided tips on how to do so.
1. Don’t assume your first approach is the only one
If you come at an event from one angle, you may miss additional ways to use that same event for additional business functions, Forrester said. This goes doubly for those who have initial success: It’s easy to become blind to new possibilities when the first one worked so well.
In order to avoid this, Forrester recommends becoming familiar with lots of different contexts and architecture directions early on “so that you can consciously decide which may add value to your organization,” the report said.
In short, start by brainstorming what an event can do before trying to use it for a particular purpose.
2. Events aren’t the end all, be all
Forrester said that it frequently sees organizations that adopt EDA ignore other design models. Unfortunately, that means that events get used to relate loosely coupled event characteristics, which in turn ignores a more cohesive method of grouping related elements.
Instead of forcing EDA, use whatever is appropriate for the circumstances, Forrester recommended. “Use events alongside orchestration and APIs,” the report said.
3. Don’t limit yourself to one EDA technology
Technologies like Pub-Sub, Kafka and FaaS all have EDA applications, but if you assume one of them will meet all of your EDA needs, you’re mistaken, Forrester said.
“If you equate events with one technology, you limit your design options and reduce the business potential of your event strategy,” the report said. Aside from the three aforementioned technologies, options include streaming analytics, stream processing, cloud-based queueing services and others that each have applications they are best suited to.
4. EDA is more than just using events
It’s easy, the report said, “for developers to think that having events means they’re doing events as architecture. Architecture is organizing systems to deliver business value, so EDA implies events drive how your systems deliver business value.”
Actually implementing EDA means moving beyond using events to trigger a response and toward using events to build a way to contextualize events, catalog them appropriately and enable a business to take action on them.
5. Centralize your EDA strategy
Forrester said events are anything but localized to a single team. Instead, they move across domains and between teams and processes in such a way that if each team is allowed to develop its own architecture based on business events, things would quickly become incomprehensible.
Forrester said there are four key points of coordination for EDA: taxonomy, identification and classification hierarchy, formats and schemas, and patterns and tech choices. A successful EDA strategy will focus on those key points at first and be built from a central axis to assure smooth communications.