BOP-4 BAM imperfections

  

Where the BOP-4 product stack generally looks very complete, mature and well designed, I have to admit I am still a little less enthusiastic about the Business Activity Monitoring (BAM) part.

In our latest project we have implemented a quiet extensive BAM implementation. We managed to implement a pretty useable dashboard, that satisfied the project and customer needs. However the BAM functionality did not feel quiet as “ready” as e.g. BPM.

BAM intends to monitor KPI-s that map upon a values used in a BPM. To get a graphical representation of these values in you dashboard a number of steps (and Cordys objects) is required.

1. 
   
   First the BPM values to reflect in BAM have to be explicitly exposed using the “Message filter” tab of the BPM. A selection is to be made of all values in the message map in the BPM.
2. 
   
   Next a Process Monitoring Object (PMO) must be created. This object defines the actual BAM data to collect in the BAM database, and the events when they are collected. It takes the BPM process as the input of the PMO. A selection of exposed data values and possible events must be made, and it is possible to process or enrich the data e.g. by using XPath or web services.
3. 
   
   Business Measure (BM) objects are intended to define the actual information from the PMO-s in the BAM database, to reflect in the report. A Business Measure is actually a SQL query that results in a aggregated measurements (averages, totals, counts) reported over a specific “dimension” (e.g. a Location, Person or Unit). This dimension ends up in a GROUP BY clause and it is possible to use a number of parameters in the WHERE clause. A Business Measure will result in a UI dashboard component and a related web service to get the specific data out of the BAM database. The web service can be used autonomously as well.
4. 
   
   The BAM dashboard is effectively an XForm, to which one or more BM -graphical components are added. There they can be linked to each other or to standard BAM components like “Time Selectors”. This way the output from one component  can be used in a filter of another. This way some kind of down drilling can be implemented. For a little advanced functionality scripting is required.

Though the functionality described above behaves correctly, there are a number of inconveniences and hence potential enhancements. I will name a number that come to mind:

1. 
   
   The number of fields to use in a PMO is limited. A PMO just offers a limited amount of fields for each data type (15x String, 10x Numeric, 10x decimal and 10x Date-Time). Exceeding one of these amounts results in an error message.
2. 
   
   Unlike other Cordys objects a PMO object must be manually unpublished before a new version can be published. There is no proper warning or error system available to prevent mistakes.  
3. 
   
   The possibilities to manipulate the looks of the dashboard graphs are very limited.
4. 
   
   Not types of graphical components are standard supported by BAM (like the gauge component). It requires intensive scripting.
5. 
   
   It is cumbersome to implement drill down features. Relations between data is now specified on graph level, and the business measures should already be prepared for the specific need. It would be more convenient to define these relations on data level.
6. 
   
   BAM does not support runtime packages; only staging packages
7. 
   
   BAM does not offer any standard reporting options (unlike Cordys Process Factory – CPF)
8. 
   
   In an ideal world PMO-s and BM shouldn’t be required. It would be nice to be able to specify data to expose on BPM level, and the relations too. This should be sufficient to define and populate a BAM database. When designing the dashboard standard graphical components should allow to select any data that should be displayed.  

At the recent Cordial event I was able to ask the development team after expected developments of BAM. They confirmed these imperfections and announced a number of enhancements that will be implemented with FP1 (Optimistic planning: end of 2010).

It is not hard to imagine I am looking forward very much to FP1, which I expect to solve a number of this issues!