Event-driven architecture can be understood in many ways, but the main idea is that systems and services react to different kinds of events. This kind of architecture can help to make an organization’s systems more reactive and certain changes to processes can be implemented more easily. For example “customer-created event” could be emitted when a new customer is created. Then services and systems that are interested in this event could process the event and act accordingly. If a new service is interested in this then the functionality would be easy to implement.
Like with all other architectures there are trade-offs and fallacies with event-driven architecture. One biggest problem and the trade-off is that event-driven systems can become complex and hard to understand. The “bigger picture” might be lost in the details and making sense of the process and what is being done in it, might be hard to understand. Martin Fowler has for example mentioned, “The danger is that it’s very easy to make decoupled systems with event notification, without realizing that you’re losing sight of that larger-scale flow, and thus set yourself up for trouble in future years”.
One thing that organizations can do to prevent this, is to document the processes that these events and services are implementing. Also, some kind of lightweight process and integration system can help to make some sense of this. These systems can listen to the same events and orchestrate what events are sent and in which order. Another way that these systems could help is that they would just be a tool for monitoring the business processes.
The main point of this rambling is that like with other architectures and methodologies is that there is no “silver bullet” and every approach that the organization takes, needs good planning. Every architectural approach needs to be carefully thought and planned.