IBM Business Monitor

IBM BPM solutions are intended to run the process oriented aspects of your business. An example process might be that of handling sales orders. When an order arrives, the order is built, the customer is billed and then the product is shipped. All of this may be governed by the execution of the process. Great!! But now consider that hundreds of such orders may be processed a day. After a few months of operation, you may find that you have the following questions:


In order to be able to begin to answer these kinds of questions, we must have some mechanism of capturing the raw information that we are later going to analyze. IBM BPM provides an out-of-the-box solution to capturing such information and presenting it to the user through the Performance Data Warehouse story. An alternative to the IBM BPM supplied monitoring is to employ and integrate the separate IBM Business Monitor product.

IBM Business Monitor is its own rich and sophisticated environment and, once again, could trivially be the topic of its own book. Here we will try and discuss Business Monitor in context of IBM BPM.

The high level architecture of Business Monitor (Monitor) is that it acts as the target of events sent from external applications. In our story, IBM BPM can be considered such an application. Events are generated from IBM BPM and consumed by Monitor.

So … what might be considered an event? The answer is primarily:

BPD Process information

BPD Activity information

Tracking events

These low level events seem quite technical in nature and not immediately that useful to business … for example, BPD activity XYZ started or Tracking Point ABC was invoked. The nature of the event by itself isn't that interesting but if we place it in context it suddenly has meaning.

Let us look at this simple process as an example:

A customer submits an order, we build the product to specification, we charge the customer and finally ship the product. If we now say that the start and end of a BPD step generates events, we immediately can start examining the operation of our processes:


Notice that these are Buisness Level questions which can be answered by overlaying what our process means with the data that is produced at different steps in our process.

To be able to answer these kinds of question, we have to model the notion of a single instance of a process and then when multiple processes have completed, we can aggregate such individual instances together. The information that we wish to collect on a single instance of a process are generically called metrics. Metrics are the meaningful data items associated with a process instance. In our sample process, these are potential metrics we could define as wanting to collect:


When IBM BPM generates events that are sent to Monitor, these events are raw events. There is nothing in them that provides these nice and clean metrics. The raw events are almost purely technical in nature. An example of a raw event might be (not real data)

Event: { processId: 1234, step: TakeOrder, state: completed, dateTime: 2011-07-07T17:34Z }

which might signify that for a specific process instance identified as 1234, the step in the process that the developer called TakeOrder has completed at a given time. Trying to build sense out of raw events like this would be impossible (or at least extremely difficult). It is here that Business Monitor comes into play.

Business Monitor has the notion of a Model. A model is a description of the logical metrics we wish to collect (eg. the value of an order) and the rules used to populate or construct that metric from the raw events arriving from the external systems. The Monitor Model is the bridge between raw events and the business friendly metrics. Monitor Models can be constructed in two ways. They can either be generated by the tooling or they can be built using the Monitor Model editors supplied with IID. A hybrid approach is also possible where generated models can then be modified by the Monitor Model editors. Personally I feel that to be effective, one should understand how to build a Monitor Model from scratch. Not only does this grow confidence and understanding in the product but if and when generated models need to be modified, there is significantly less mystery involved.

Page 2

No Comments
Back to top