In simple words, Business Activity Monitoring (BAM) deals with monitoring business solutions to extract information relevant to the business and representing it in a way that is meaningful to the business stakeholders. This may include generating appropriate notifications when relevant business events occur.

A BAM solution helps answer questions similar to the following to the business:

• What is the status of Joe's loan application?

• How many applications did Mary underwrite last month?

• What percentage of the applications were approved automatically vs. manually?

• It's October. How far are we from our goal of having 10,000 members by the end of this year?

• How do I know right away when a fraud is detected by my fraud detection system?

• How much time on average is it taking to open a new account?

Now, if you think that BAM is nothing new and business has always wanted to know how it was doing, you are right! To implement BAM, business would define 'reporting' and 'history' requirements. IT would define the data fields needed to be captured in order to provide the necessary information. IT would then write the necessary code in the application to save the information and then provide some sort of combination of SQL and web pages to view the information. This solution works very well in a typical web based application or in an application that is deployed in a single solution environment e.g. Java or .Net. From an SOA and BPM perspective, this solution is limited due to the following reasons:

• A service is a black box - unaware of the context in which it is invoked. Building the reporting logic in the service may not satisfy ALL the business contexts in which the service will be invoked. Besides, embedding monitoring logic in the services is a bad design

• A typical BPM solution enabled by SOA spans multiple IT systems and is often represented as a collection of services orchestrated in a specific sequence. Using traditional approach, logic to capture monitoring information gets scattered in the services and the information gets scattered in the databases for those services

• It is possible that business monitoring requirement would change more frequently than the core business logic. Changing application code to support changes in the monitoring requirements is ineffective from cost and time perspectives

So, what does a good monitoring solutions look like in a BPM/SOA environment?

• It can receive events in a format defined by xml schema - this way any service enabled system can emit events that can be submitted to the monitoring solution

• It can retrieve data from any relational database. This would work well when the business solution is made up of multiple services deployed in disparate systems. Different services would store their relevant data in their databases but the monitoring solution would be able to pull data from different sources

• It monitors the business solution non-intrusively. In other words, monitoring logic shouldn't have to be coded in the service implementation. Instead, monitoring solution would simply configure the deployment environment, which would generate appropriate business events when services are invoked. These events are then collected by the monitoring solution

Finally, it is a good idea to keep monitor data separate from the core business data. For example, if business wants to monitor the time it takes execute a service, don't store start_time and end_time along with the core business data that service operates on.