Start small, succeed and then scale - Mark Palmer's best practice on employing event processing in an enterprise

One of the observations is that it is not trivial for enterprises  that are used to legacy systems and legacy systems and legacy developers to adapt to event processing thinking.  I have written about it recently.  A recent meeting with a customer triggered the initial reaction - "but we don't know how to work this way", the way they know how to work is: getting events, inserting them to a database, and ask periodic and on request queries.   I have also recently compared the request driven (legacy) approach and the event driven approach. 

Mark Palmer, CEO of Streambase, has recently written a "best practice"  on this topic of how to introduce event processing in an enterprise, and entitled the best practice "Start small, succeed and then scale".  

Mark starts by asserting that real-time becomes a must do agenda in many enterprises, and many type of applications, but the problem is that both legacy systems and people require an overhaul. 

His methodology is - choosing a small, but important application, put the best people on it, iterate if failure, learn from experience, and then scale it to other functions and applications.    I think that this is a good approach, it would also be interesting to have some experience reports about application of this best practice in reality.     I'll write more about this topic - later.

On Event Driven Marketing

Following my previous posting that talked about the effect of event processing on the life of some people, I came across another interesting article today that describes event-driven marketing, where event can be: "customer service call, a type of transaction, going through a spending level in a particular period, customer's birthday". This is different from traditional marketing, finding the right opportunity to issue personalized marketing is a capability enabled by processing events. More interesting applications - later.

Relativity and Event-oriented thinking

You may be familiar with the magnificent masterpiece of Escher called "Relativity". We see relativity everywhere -- on Saturday I've called home from my hotel in Burlington (since then I've moved south, and now I am in Hawthorne, NY) and told my daughter that I am sitting in the hotel waiting for the snow to end, in order to get out, and she said -- "how lucky you are to see snow", I have not felt lucky to see the snow, in fact, it kind of disrupted some pans I had, but in the world of a person that lives in Haifa, snow is a rare thing that occurs once every 20 years for a short time, so it is an attraction. At some point in my past I have been teaching a basic AI course, and the teaching assistant has taught the students Lisp. I have looked at the end of the semester on Lisp code produced by students - some got it right and wrote pure recursive program, and some wrote code that looked like Fortran thinking in Lisp.

The same relativity exist when dealing with event-based applications. Some people understand how to construct such applications, while other people think in other paradigms like request-respond, and are trying to do some blend here. It is perfectly OK to do an hybrid approach, but this should be a result of careful design, and not by chance. Bottom line - we need a methodology for constructing event-based applications and tools to support it - this will somewhat different kind of thinking... more about this topic - later,