James Taylor's Decision Management« Don't confuse Performance Monitoring with Performance Management | Main | Top 10 reasons for not automating decisions - #10 »
June 26, 2006Events, analytics and business rules
A couple of days ago Oracle made an announcement about an Event Driven Architecture. This architecture clearly includes business rules as part of how you process events and shows how event processing and business activity monitoring go together. What struck me as interesting, though, was the absence of a discussion in the announcement of analytics. Why, given Oracle's deep data and data mining technology stack, was this not part of the solution for event processing?
In an event-processing scenario, business rules are clearly key. They allow you to define how to respond to events, to manage large numbers of potential responses for potential events and to expose this logic to business users. All nice features for event processing. Analytics, especially predictive analytics, are also valuable. How can I use analytics in an event-processing scenario?
-
I can process a stream of events as input data to a predictive model to see if the event data predicts a potential failure or problem or opportunity.
In this example the data for the model is built up by a sequence of events. The prediction can then be used by rules that process the event. Thus event 100 might provide enough data to make a prediction (say that a particular piece of equipment is going to fail) and a rule might use that to process the event differently (scheduling a preventative maintenance call for instance). -
I can treat an event differently based on predictions I have about the future behavior of the source of the event.
Other data I have, about a customer say, may enable me to predict their likely behavior. Perhaps I can predict their retention risk. Based on that prediction I might treat the event differently, scheduling a proactive call to profitable customers who show at high risk of churn when a specific event happens while simply noting the event for those at low risk of churn. -
I might use a regularly scheduled update to a predictive model to trigger an event
Every time I update a model, say of customer risk, I might check to see if I have moved from one risk segment to another and, if I have, I might push an event on the the event bus. This might then be combined with other events to change downstream behavior.
Analytics can really enhance event processing, especially in conjunction with business rules. Don't miss the opportunity. I wrote about this on my other blog here.
Posted by jtaylor in
Business Activity Monitoring
• Business Rules
• Decision Technologies
• Event Processing
• Predictive Analytics
|
Digg This|
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/416
Business rules are identified in the normal course of requirements gathering and analysis. While you are usage modeling, perhaps with use cases or user stories, you will often identify business rules. A rule of thumb is if something defines a calculation or operating principle of your organization then it is likely a good candidate to be documented as a business rule. You want to separate business rules out of your other requirements artifacts because they may be referred to within those artifacts several times. For example, BR129 was referenced by the Enroll Student In Seminar use case and likely would be referenced by your class models and perhaps even your source code. However, if you have only a handful of business rules or use cases, you may choose to document them right in the use cases. A rule of thumb: start out including them in the use cases until it becomes obvious, or painful, to do so. This may be because the sheer number of business rules is dominating the use case or because the same business rule is referenced in two or more use cases.
Posted by: Poul TAcker at January 29, 2007 11:03 AM
Post a comment
