This is Escher's famous picture "relativity" reporduced in Lego blocks. I reminded of the relativity issue while reading Paul Vincent's Blog entitled: "Is CEP subset of BPM"?
Well, if you ask the BPM marketing persons they will probably say yes, as today we can see event processing as part of a BPM stack (well, for some vendors). However, this does not say that event processing is a subset of BPM, the same question can be asked about databases, BPM suites store stuff on databases, so databases can be, by the same token, considered as subset of BPM. In the 5th Event Processing symposium, last week in Trento, we had sessions dedicated to the relationships of event processing with BPM, IT management and Robotics. IT management also viewed, for years, anything that has to do with events as a subset of IT management, and they are also right, since IT management deals with events, again, it also deals with databases. Talking with a simulation person he told me that event processing, of course, is a subset in simulation, and actually invented in the world of simulation (I thought that it has been present also in ancient operating systems). So everybody have their own relativistic view about event processing being a subset of something.
IMHO, Event processing, like databases, is a generic technology (BTW, some database people view event processing as a subset of data management, which IMHO is also not true) that can be embedded in various frameworks. The question is whether we need one generic event processing technology for say - all three domains I mentioned: BPM, IT Management and Robotics, or does each of them need its own variation, maybe they need different (possibly overlapping) subsets of the same technology as seen in this Venn Diagram? More about it - later.
1 comment:
Opher,
This is a good blog as always. I've been super busy at work, and haven't been responding as much as I'd like.
Regarding your comment about event processing being a generic technology:
-- It's true that one way to look at event processing is generic, and we could engage in discussions about how to classify technology
-- But, that's a vendor view-point. What are the products, how do they integrate?
-- And assumes some degree of account control with the customer to sell product segments
-- But what about event processing in the large, and what can we do to use it in society, industry, govt?
You know, we've discussed "very large event processing" (VLEPN) before, and there is no single product that could fill the (operational) need, but there may be concepts, tools and products to help fill an architectural need. A community VLEPN architecture.
For example, let's say that a group of federal, state, local, tribal, orgs want to improve response to emergencies. Right now there are struggles over who has control, the "top dog" then tries to build a system where everyone has to pour their data into, then the "top dog" can have situational awareness, be able to make decisions, etc.
The paradox, is that these types of communities are network based, and event based, and the situation begs a community-owned VLEPN architecture. Different orgs can field DBs, CEPs, BPMs, etc. but they would all have different owners, and be introduced at different times.
A community owned VLEPN architecture would certainly have language aspects, technology aspects, acquisition, operations, etc.
Thoughts?
++harvey
Post a Comment