In reaction to my recent post, Gagan Saxena responded with "decision first", stating that the starting point is decision. Goals and decisions need to be managed, and the event processing is a means to achieve these decisions.
Taking the 4D (detect-derive-decided-do) approach, there might be multiple starting points:
The detect starting point: Start with instrumentation and sensing. Create event, and publish them. The event utilization and processing comes second, based on what is available
The derive starting point: Start with the situations that need to be identified, then determine what need to be detected in order to derive this situation, and the decision is on reaction to the situation.
The decide starting point: As proposed by Gagan, start with the goals and decisions needed to achieve these goals, the determine what is need to be derived and detected to achieve this goal.
The do starting point: Start with the action, which can be a workflow, and treat the rest as trigger to the action.
Each of these approaches may be valid in certain scenarios and circumstances.
I argue that in event-driven systems goals are more linked to situations than to decisions. In cases where the decisions are request-driven, a decision is requested due to getting to a certain point in the workflow that requires a decision to achieve some goal. In event-driven systems the decision is required to react to a situation, thus the first goal is associated with the situation, then there is another goal of how to react to the situation. The decision might be simple (notify somebody), or complex (optimize some objective function based on predicted events).
Each of the 4Ds have to be managed as an entity. The detect part need to be managed in order to determine sensors, frequencies, fault tolerance etc.., the derive part need to be managed, and this is the glue to the rest of the Ds, decisions need to be managed, and actions need to be managed. It is a benefit if all of them can be managed in a coherent system and not in four different systems. More on this - later.
