BAM And CEP: A Marriage Of Necessity Or: Why BAM Must Use CEP
09/06/2004
By David Luckham, Professor Emeritus of Electrical Engineering, Stanford University
The dashboard model of Business Activity Monitoring (see http://www.complexevents.com/about/articles/bam_beginnings.html) is the basic model for the current generation of BAM tools. The essential idea is that these tools, when configured properly on your IT layers, will alert you when events happen that have significance for your enterprise’s business goals and operations. These tools work by detecting and processing single events from the underlying enterprise IT layer. This is simple event processing. Some tools may let you specify event-condition-action rules that are triggered when significant events happen. This is a step toward automating the real-time actions you want to take to manage your enterprise.
I predicted in that article that if you bought a BAM tool and got it installed and working on your IT layer, it wouldn’t be long before you would be asking for more than the current version of the tool could do. In other words, you’d find it helpful in managing your business. And using it would give you ideas about what else you’d like to do. Some BAM vendors have already anticipated this too, and are working like crazy -- building the next version of their tools. They think they know what you might want their tools to do next. So the coming year in the BAM market is going to be an interesting one!
I’m going to make a few guesses of my own. Three of the trends are business policy monitoring, business impact analysis, and probable cause analysis, all of which have many variations and approaches. I will not contribute any more three letter acronyms, but you’re welcome to call them whatever you’d like.
Starting from the dashboard BAM capability, here are things you can expect in the next year. I’ll explain what I mean by each of them. By the way, some tools may do some of them now. Here are five levels of increasing BAM capabilities:
Tools that monitor conformance to a predefined (out-of-the-box) set of policies are out there now. For example, you might want to monitor for a policy that “the wait times for access to the financials database and the customer database should never together exceed 30 seconds.” The tool will monitor this policy because it has a built-in capability (out-of-the-box) to monitor metrics such as the wait times on each resource, and it understands simple arithmetic. If some of your business workflow processes accessed both databases you might want this policy monitored to keep them running on time. Of course, you could change the 30 second time limit to something else on the fly.
Let’s start with Level-2 on my list.
Roll your own business policy constraints: You might have some new policies that you’d like to know are not being violated by the business processes of your enterprise. Lets take a simple example for illustration. Suppose you’re trying to improve your “demand-driven” restocking of inventory to keep purchasing costs down. Ideally, you would purchase stock only when it is needed. Suppose you have a very simple design for your processes consisting of two concurrent workflows, both triggered by a customer’s order. One is an order fulfillment process that draws on inventory to fill the order. The other is an inventory control process that, concurrently, sends out restock events to replace the items in the order. Some of those restock events may be unnecessary, resulting in increased costs. You want to enforce a basic policy, “Don’t order stock until a customer’s order reduces current inventory to a critical level.”
By: Don Tapscott THE ONCE SLOW, REGULATED, and predictable telecommunications industry is receiving a serious wakeup call. Recent increases in...Learn More
Print this article
Email this article
Talk Back!
Write to Editor
By: Don Tapscott THE ONCE SLOW, REGULATED, and predictable telecommunications industry is receiving a serious wakeup call. Recent increases in...
