Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« Podcast: ESBs Offer Simplicity for Complex Times | Main | Living SOA Life on the Edge » May 30, 2008Keynote: Capturing the Events that Really 'Matter' to the Business There are two types of events that fit into enterprise event processing scenarios -- those that matter to IT, and those that matter to the business. While many organizations seem to have a good grasp on managing IT events -- such as a server crashing -- few are ready to handle business events. But this is changing. In his keynote presentation at ebizQ's recent Event Processing conference, Forrester's Charles Brett described how business event processing is the next great horizon for business, but is fraught with many challenges. (Replay and transcript of Brett's talk here.) The important challenge for organizations is to "understand which events matter," he said, adding that "some people think that all events matter." Those businesses that can successfully leverage event processing are those that can identify the events that have the greatest impact. This ability rests with the business, not IT, he adds: "IT doesn't necessarily know which events exist in the business and which ones could be used, or which are more relevant, or which are less relevant. Indeed, one the big dangers in event processing is one could have too many events many of which may not actually have a great deal of relevance." Brett outlined some scenarios where business event processing can make a difference. For example, if a customer didn't buy something its stops halfway through a transaction, it pays to understand why this happened. Or, if "a financial exchange came to a halt because they didn't know that something wasn't happening. They thought they knew what was happening; all systems showed green but an event screen wasn't coming through and the exchange grind to halt." Employing event processing to walk them through the chain of events can help prevent this disruption from happening again. Predictive analysis run against an event engine can help schedule field service calls to improve the uptime of critical services to customers. Such "non-IT events" businesses need to process and digest may come from sensors, signaling, production lines, and other sources inside the company, as well as outside sources such as radio, television, news channels, weather channels, Websites, and GPS, Brett says. Such events are "the ones that haven't been processed in the past but will be in the future." The best way to capture business events and direct them to business managers is through Business Activity Monitoring (BAM), Brett says. "BAM is really about taking events and raising them to a level that decision-makers or people who have responsibility for taking actions can do something." BAM is used for real-time analytics, "not only for processing and analyzing of event data, but also to feed visual dashboards and the like in order that people can see what is going on within the business -- very much intended for business users," he continued. BAM is still relatively new on the scene, and will take time to fully integrate into the business. The challenge with BAM is to avoid overwhelming business users with information, or alternately, reducing information about events to "such simplistic levels that it's just ignored." While some analysts say event processing is a natural extension of SOA, Brett feels that Integrating event processing capabilities into some earlier SOA implementations may prove difficult. SOA-based services "can be picked up by event processing and similarly when an event processing engine emits events out of on the downstream side, there's no reason why services shouldn't pick it up. So there's no architectural reason why they shouldn't fit together. The question really is going to be how the services were originally designed, architected, and delivered." A replay and transcript of Brett's talk is available here. ______________________________________________________________________ Posted by joemckendrick in Event Processing • SOA Events • SOA Research and Analyst Reports | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry: I am delighted to see this thread beginning to spool up. It is almost impossible to prdict which business events will be interesting to which community and when and why. The sales department might like to knowwhen a big PO has been issued to a suppler (yes I did mean it like that!) so that they can now target the supplier with a different sales message. "Now you are about to become a major supplier, let's talk about partnership - how our products can help you ..." The point is that when we are developing our systems we are so focussed on the pure specification that we don't thnk of opening the architecture up. While it would be overkill to broadcast every event, we hould now be thinking in terms of using bus oriented technologies to deliver the possibilty of notiying everything. That way subscriptions could camp on looing for what's happening in the busines. See the (only) blog posting at businessanditarchitecture.blogspot.com where I talk about EDA being from Venus and SOA from Mars. Since we cannot know the future, we must allow for change/extension. While we have often accounted for schema change, we do a less good job of accounting for changes in business process when we handle events. Posted by: Chris Bird at June 2, 2008 09:06 AM Post a comment
|
