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.

Event processing at the core of automated commerce systems

This illustration is taken from Chris Taylor's Blog, where he posted a piece entitled:  "There's a technology tsunami hitting the world of commerce".  Chris makes distinction between the hype technologies:  cloud, analytics, big data, and mobile, and claims that all of them have role in the story of commerce, however the core technologies doing the heavy lifting are: integration, managed file transfer, in-memory data, log file management, event processing and business process.

As for event processing, Chris believes it is the core, and issues the nervous system of the commerce which enables to automate it, as commerce is event driven by nature - buy and sell are events, and so are payments, fairness rules, credit decisions, fraud detection, and management of the commerce system itself. 

Note that illustration follows the 4D: detect (channel), derive (pattern detection), decide (decision), do (actions).  The "decide" part is not necessarily "IF---THEN" rules, but can also be optimization or another event driven pattern.