Thursday, December 09, 2010

The 4Ds "Detect, Derive, Decide and Do"

The Interesting thing about the 4Ds

As I am sure all of us are familiar, it is in the framing of the problem that gives the greatest ability to abstract the problem.

Thus the framing where the 4Ds come into play.

Detect
This is the act of capturing the stimuli that comes from an outside source. This might be a sensor reading or a request to do some action.

The essence is moving it from one domain to another domain. In the case of temperature control, the heat sensor allows the capture of a stimuli of the "reality domain" to the "device domain". It may also be more virtual. I would argue that a web service call from one partner to another partner is the capture of the "request stimuli".

Included in this "area" is the conversion of the stimuli from the raw datum to a virtual version of that stimuli.

Note: You will see that I refer a lot to the stimuli. I do this because I believe that a service provider is constantly capturing stimuli in which to react. Perhaps even reacting to the lack of stimuli.

Derive
This is the act of correlating this stimuli with other stimuli or other derived understanding of the world. So what's does that mean?

When you think about situational awareness, it is basically an understanding of the world within the scope of context you care about. A big state machine in which reality (as it can be captured) is made virtual. Hmm.

CEP plays a large part in this because you can take various stimuli (called events and state changes), combine/aggregate/pattern recognize/intersect/unionize/... them and derive other stimuli (also called derived events). The power of which is events (happenings in a different domain) can be detected that can not be directly sensed in that other domain. Said differently, these events (or stimuli) that occur in a different domain can not be directly detected because there isn't a mechanism to capture the stimuli. However, by looking at patterns of events that you can detect in concert with other captured events, you are able to derive events in other domains that are not directly detectable . Wow! That's powerful stuff!

Let me give an example to illustrate this.

Let suppose that there exists (and there does) a camera that is able to take the picture of a car's license plate as it goes through a toll booth. This, obviously, would represent detect. This sensor takes a picture, converts the images of the plate and converts it to a variable that contains the letters and numbers of the license plate. As well, it includes the meta-data of that datum. In this case, the time and location that the picture was taken.

After some time, the car passed through another toll booth and another detect activity occurs. Except in this case, the meta-data of the license plate number datum has a different time and location. (I am assuming that the guy didn't just spin around the toll booth!)

Both of these events (stimuli) have been detect activities. Now comes the fun part.

Because the same entity owns both toll booths, it is able to compare the two detect events and derive a new piece of information. The elapsed time the motorist took between the two toll booths. This organization could then divided the distance (which they would know) by the elapsed time would would yield the average speed of the car associated with the license number between the two toll booths. This information would be added to meta-data about the trip which is a higher order abstraction that the passing of a toll booth. ( I am assuming that this isn't James Bond who has license plates that can swivel to a new one )

So, the adding of information or determining situational awareness is the role of the derive. I want to derive more information about the trip the license plate took.

More specifically, the determination that the motorist was speeding (specifically violating the law that regulates speed of motorists along that road) would also be derived.

Decide
The decide section, as its name suggests, is determining if and what to do because of the awareness of the situation.

In our example, the rules (decision logic) may specify that if the speed was over a certain tolerance, then we issue a ticket, if it is less than that tolerance, we ignore the stimuli.

Business rules engines are very good at handling this capability in a very configurable manner . But just as likely a case statement or IF THEN ELSE might represent the decide action.

Do
Again, being the master of the obvious, the name of this section represent doing the activity that was decided to be done.

In the case of the traffic example, it might issue a request to the ticketing web service to cite the offending motorist or that capability might be within the boundaries of the service and would execute its own mechanism.

How the 4Ds solves the Problem
Now that the 4Ds are understood and the offending motorist has contributed to the city's budget, your probably wondering, so how does this help me develop a solution?

With all abstractions, we are looking for ways to divide the problem. But not just for divide and conquer purposes. There are different mindsets and concerns that each of these areas would require. And potentially different expertise. A person that knows how to manipulate the sensor to take the readings dealing with harmonics and weight levels for a bridge may not necessary know the statistical equations to put those data points together to determine the bridge's stress or decay. Similarly that individual or team may not decide how we react to those stress levels. Nor are they necessarily the ones who will put the mechanics of put into the action the decisions. Perhaps they are, but this solution allows these factors to be separated.

Does this go beyond Event Processing and SOA

As I said earlier, I don't believe this is limited to simply CEP or expert systems. This is the nature of a reactive system, which all computer systems in truth are. Even "proactive" systems are reacting to an understand of the world around us and a potential threat or opportunity (also known as situational awareness). The difference, in my mind, between a proactive and a reactive system is a proactive system is one where the actions occur before that HAVE to be or for marketing purpose before the competition reacts to it.


Summary
So, in summary, I hope that I have given you reason to 1) think about systems as reactions to stimuli (events (changes in the world around us)) and 2) that when we break the solution up into the 4Ds, we are dividing the solution into logical segments that takes advantage of the discrete types of thinking.

Notes:
As always, I want to have a humble ego when it comes to my ideas. I realize that no man or idea is an island unto itself, but rather stands upon the shoulders of giants. I hope that if anything, it acts as a springboard for others to have even better ideas or acts to help enhance or dismiss my ideas into something more accurate and truthful. So, I will take any comments as constructive criticism.

2 comments:

Opher Etzion said...

Hi Jeff.

I like the 4D - it is a good phrase on more than one dimension :-).

See my posting on a variation of this we have doe in the past, and some thoughts about relation to proactive computing

http://epthinking.blogspot.com/2010/12/on-4ds-past-version-and-proactive.html

Stay well,

Opher

Unknown said...

Does your 4D model correspond to Boyd's OODA loop?