Sunday, March 31, 2013

The 4D - where is the starting point?

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.

1 comment:

Gagan Saxena said...

Managing the 4 D's as a coherent system is the best approach - and for any implementation, the starting point could be any one of the 4D's.

A Decisions First approach has been useful earlier on in the cycle when a Business Case is being developed for the Executive group - and then much later on during Project Closure when we need to measure whether we have been successful or not.

Once project funding and cost of operations is tied back to business goals, business requirements and affected operational decisions, systems design and implementation will get driven by decisions first as well.

The challenge is to keep event-driven systems relatively open to discovering undefined and unknown patterns - while being able to harness those insights into a business metrics driven framework that the C-suite can grasp.

A decision-centric approach seems to bridge the vocabulary gap.