BEAParticipate: BAM

Eduardo Chiocconi of BEA gave us a technical view of the ALBPM BAM functionality: what’s available out of the box, the extensions, how to create customized dashboards, security, and a bit of the architecture underlying it all so that we have a bit of an understanding of what happens in the underlying services and data stores when a custom key performance indicator (KPI) is defined.

Like every other BPM vendors’ BAM, ALBPM’s BAM is visualized as a set of dashboards that show KPIs for the purpose of monitoring the health of a process and early problem detection. There are some out-of-the-box dashboards including widgets such as gauges and charts attached to a data source, and the ability to create custom dashboards. As we saw in the architectural view this morning, there’s a BAM database to collect and aggregate the analytics data from one or more process engines, plus external data sources if you want a combined view. There is a single BAM database for each directory service, and an updater service that executes regularly to pull data from the associated engine database(s) to the BAM database. Data in the BAM database is very granular — down to the second, if required — but is flushed out as it ages, typically after a day. The OLAP data mart, which has the same data as the BAM database and is updated by the same service, is much less granular and is not automatically purged; this is used for historical analytics rather than the near-real-time requirements of the BAM database.

The out-of-the-box dashboards are instance workload, percentage workload by organizational unit, performance (e.g., end-to-end cycle time) including drill-downs to more granular levels, or a unified dashboard with all three of these measures. Surprisingly, these widgets are not currently provided as standard portlets, but can be wrapped into a portlet if required.

Most organizations will want to define their own KPIs and create their own dashboards: KPIs can be defined by a business analyst in the Designer as dimensions (e.g., time or geographic aggregation) or measures (e.g., averages and other statistical aggregations), and can be based on standard process variables or business variables. This causes a new column to be created in each of the three main BAM database tables to capture the necessary data for the three display widgets for that measure or dimension.

It’s also possible to specify the points in the process where the KPI data are captured and sent to the BAM database in addition to allowing the automatic update process to occur, giving it a sort of audit functionality. Internally, the BAM data are generated from the process engine’s audit trail, so you’ll have to have auditing enabled for all of the processes and events that you want to track in BAM (in many cases, you would turn off auditing for processes and events that don’t require it in order to improve performance).

ALBPM allows for role-based security access to the BAM dashboards, so that only specific roles can see them.

Future directions are to allow ad hoc dashboard creation and move to event-driven BAM, although that will require some architectural changes to the underlying database and services in order to handle the increased load that will result from allowing everyone to roll their own analytics.

The more I look at it, the less than I’m convinced that all the BPM vendors should be developing their own BAM like this; I think that there could be a market for a BAM product that can connect to many different BPM products as soon as we get some standardization around the process engine audit trails that are typically used to populate BAM databases.