The picture is the view seen from "Midreshet Sde Boker" , where I have driven yesterday (3.5 hours drive each direction !) to attend the opening ceremony of the activity which my second daughter (out of four), Adi, is going to participate during the coming year. This is an activity in which high-school graduates postpone their army duty for one year, and invest it in volunteering activities, and learn leadership skills, in the Negev dessert, "in the middle of nowhere". From the Greek philosophy we have two competing views of the relations between the individual and the society -- the individual-centered, where society is aimed to serve the individuals, and society-centered, where individuals are part of society. Our universe is very much individual-centered, so it is a refreshing to find a group of young people who are ready to contribute one year from their life (yes, without being paid), to do volunteering work that help the society.
In moving back to "event processing", it is clear that event processing is not a detached thing, as the customer really wants a manufacturing system, or trading system, or billing system, and technology is only a way to achieve it, it is also true that there are typically no pure event-driven applications, but parts of applications that do event processing, which makes the interoperability, the ability to embed event processing within existing paradigms, and the ability of systems and applications to sense and respond, is a critical success factor.
Consequently, we'll see more and more event processing systems embedded in application integration middleware, rather than a stand-alone engines. More on that - later.
4 comments:
I agree 100% that the customer just wants to be able to do their job better (they don't care about technology). Thus we have the typical tension when a new extension of technology happens -- the effort to discover the theoretical extent -- vs.-- the effort to extend the tools the customer already has.
There is no right or wrong way to explore this space. In fact we need to explore all ways simultaneously, and with cross-talk so we can learn together.
Thus, in addition to work on theoretics, on the other end we can start asking:
"What can the customer do with events, that they couldn't do without?"
Of course that takes a use-case analysis to ferret out...
And a benefit of doing use cases is that the community creates a "story" that can be told by the non-technocrat. This is important, so the story of eventing, and imagining possibilities is taken over by the people that would want to use it in their normal course of work.
Harvey - I agree, as a matter of fact, EPTS is launching a team now to do the use-case analysis.
Harvey, I hope that you don't look at our community as a bunch of technocrats (-.
Post a Comment