Back to reviewing some recent Blogs on event processing, this time I am looking at Hans Gilde's Blog talking about the two types of event processing applications: detection oriented event processing and operations oriented event processing. Detection Oriented Event Processing applications want to locate interesting information in a flow of data. Operations Oriented Event Processing applications want to take an action (which involves making decisions) based on incoming events.
This classification does not seem to be mutually exclusive, there are actually systems that locate interesting information in a flow of data, and after finding this interesting information are taking actions, which involves making decisions, based on that detection. Hans is right that these are two different things, one deals with the detection, the other deals with the action, and decision around the action.
Getting this classification further, let's look at two different issues: first -- what does the event processing system do (the "detection oriented") , and what are the results of the event processing system are used for (the "operation oriented").
Looking at the first aspect -- an event processing system can just filter and route event, it can also transform events (translate, enrich, aggregate etc...), and create derived events, it can detect predefined patterns, and it can detect patterns on the fly based on some reasoning, it can do part of these things, or all of them together, so an event processing platform is actually a tool box of all the above.
The event is then consumed by some consumer -- person, dashboard, system, and is (hopefully) used for something -- and this is the second aspect -- it may be used just for notification to a person, and what the person does or does not do is beyond the scope of the system, it can observe something and update a dashboard, it can diagnose something, it can do some real-time action based on decision, either in reactive mode or proactive mode (to mitigate some predicted state). This classification is based on a work we have done in IBM a few years ago by looking at applications in many industries, I have described this work in the past.
These two parts are typically decoupled. The event processing system gets events from some event producers, do some processing with it, and produce some events to the event consumers. There are certain set of techniques to do all these types of processing. The second type is done on what is called in the event processing architecture the event consumer. It gets event from an event processing system (or directly from an event producer if no processing is needed) and decides what do with it, the decision itself may apply business rules, and/or some quantitative analytic tools -- optimizers, simulators etc..., the decision can be totally automated ("autonomic"), semi-automated ("decision support system") or completely manual.
In essence, there are more and more systems that have complexity in both parts, thus the tool box to build this entire system is more extended, and while the execution is decoupled, the logic may be viewed in integrative way to build "decision processing network" in which "event processing network" is a subset, but it also includes business rules and quantitative analytics (and maybe some decision visualization tools).
I'll write more in the future abut the notion of "decision agents", introduced by James Taylor. This term reflect the atom of processing in both of the types that Hans is mentioning, however, in each of these type the agents are doing different things. I have mainly concentrated so far on the "event processing agents" type of processing in this Blog, but needs also to pay some attention to the other types of decision agents as well...
More - Later.
1 comment:
Thanks for reviewing the post.
I meant to differentiate between detection based on some understood interface or contract (e.g. detect that an order has been placed by getting an order event) and detection of events that are outside of defined or intended contracts (e.g. detect that an order may be a duplicate by checking against recent orders).
The latter is what I meant by detection oriented EP. I would consider the former to be a part of the operation, along with the decisions and results.
The simple cases of either detection and operation are generally equally simple and even similar.
As functionality gets more complex, I have noticed that the detection (per my intended distinction) and operation grow farther apart in many practical concerns from value and requirements all the way to coding.
Although it's possible that both detection and operation use the same EP patterns, I have observed separation in business understanding, development processes and non-functional requirements placed on the EP infrastructure.
Post a Comment