EDA is not just technical implementation

Some SOA-specialists tend to see events and event-driven architecture as a technical implementation; at a lower level of design. Well, it may be, but it needn't be. I'm thinking of EDA as modeling real-world events; at a higher level - even at a top level - of design. An event is a change of state: a certain condition coming true. Business events are the interesting real-world events that a company wants (has planned, is forced) to respond to. The response to the business event is the business process, which can generate new business events, and which can change over time. Business processes handle the life-cyle of the captured business events. Interesting is that a business event (real-world event we planned to respond to) mostly is stable, while the way we are responding (business process) mostly is not.

What I believe is that you can only start modeling business processes when you know the business events you want to respond to. You can only start modeling SOAs (which might be seen as a way to model business processes) when you defined the business events to focus on.

So in my vision events are not technical elements at all. Fortunately we have an ESB to capture the business events and publish them to all interested business processes which are implemented as SOAs. And fortunately we can use the same ESB to build an environment to monitor the state of our business in real-time. This state is represented by the collection of current business events. All based on open standards. Yes, that may be called technical, but with huge business benefits.