A software system with an Event-Driven Architecture (EDA) is built around the idea that events are the most significant elements in the system and that they are produced somewhere in the system and consumed somewhere else in the system. The business value is that you can easily extend such a system with new things that are ready to produce or consume events that already are in place in the system. Of course, you can add new events as you go.
Yes, this is absolutely great. If you build something new there is no reason why you shouldn’t use this kind of architecture. However, focusing on the events is not the only thing you should do.
Instead, you should just build an architecture in which you have components or services and some kinds of “channels” between some of these components. Over a channel an event can flow from one component — the producer — to another one — the consumer. These components are loosely coupled and can exist in a distributed world. Some of these events are such that you broadcast them to anybody that has subscribed to them.
Thus don’t constrain your architecture to just be event-driven. There is really no money to save by doing just that. Let it be components with channels. The channels I am talking about were already adopted in the telecom standard SDL back in 1982. In EDA, it is basically a mechanism for brokering events. In the OMG standard CORBA from the early 1990s, it was called the “Event Service”. What a coincidence! Actually one way of thinking about EDA conceptually is really that it is all that CORBA was meant to be, but in the Web/Internet world.
The most interesting components are services. You get service-oriented architecture (SOA) at the same time, and more.
However, those of you who think this is fundamentally new have really not done your homework. It is probably true that the three letter combination EDA is new as it was for SOA. We have also got some new great platforms that make it easier to implement these ideas.
Over the years I have seen trends in the component world that put more focus on the components than the channels (and thus the events) between them. Other times it has been the other way around. However, there is absolutely no reason to choose. You should allow for both. But what we don’t need are more buzzwords. They don’t help us at all.
To summarize, you should go for a component architecture without any compromises. This is what made the Ericsson AXE system such an incredible success story more than 30 years ago. And thanks to its architecture, it is still probably the best selling product of its kind in the world. However, Ericsson had to build its own infrastructure managing components with channels since such solutions didn’t exist at the time.
Of course, this is still new to people who have not previously developed a component architecture. Thus those people have to come up to speed and that means training and mentoring. And to start with, you need some good technical practices. It is as easy as that!