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.

2 thoughts on “BEAParticipate: BAM

  1. Sandy,

    Since you also attended TUCON, what are your thoughts on TIBCO’s plans for BAM? I agree with your viewpoint that BAM – Business Activity Monitoring deserves a mature, robust product offering by itself. I would not however, limit its usage to BPM solutions only. In my view BAM has much larger ramifications beyond the boundaries of BPM implementations (to include existing applications/systems – which are not yet reengineered for participation in a BPM solution).

    I believe BAM as an application of “Complex Event Processing” has great potential and it is rapidly changing the landscape for BAM product offerings. I also believe that BAM will move away from just being a “Dashboard” to an invocation of another process that would leverage a business opportunity or react to a unique event pattern – leading to new ways of doing business.


  2. Kunal, I agree with you to some point: there is the larger issue of complex event processing/corporate performance management and a host of other acronym-laden technologies that go far beyond just business process management (although I like to think that BPM is at the heart of every business). There are great things that can be done when you start actually invoking new processes in response to the sensed patterns, not just present them to a user.

    The dashboard-type BAM is an essential for any BPM vendor these days just to get them in the door: it’s a checkbox on any RFP. However, I believe that most customers have much deeper needs for event monitoring, analysis and response, and BAM is just their first toe in the water.

Leave a Reply