BAM: Capabilities & Applicability (Part 2)

BAM Architecture in General

Architectural diagram on figure below shows general architecture of BAM solution and explain functions of each of them.


Modeling tool

Usually GUI based toolkit is used to define monitor model. The model contains definition of events that should be “caught”, metrics, triggers and KPIs. Finished model is deployed and monitoring can start.


BAM core

This is the main component of BAM solution. It generates event patterns according to the monitor model and deploys them on CEP (Complex Event Processing) engine. It later processes the received event data and transforms them in the desired form. BAM core can also communicate with the Process engine, start and stop the processes, generate events etc. according to triggers and alarms defined in the monitor model.


CEP engine

This is the lowest level component responsible for event filtering. The CEP engine receives query patterns from the BAM core. It queries the event flow both from the Process engine and ESB and sends the “wanted” events back to BAM core. Usually only process engine events are used for BAM, but CEP engine allows also filtering of ESB flow events. That can be used in more technical oriented monitoring, or combined with the business data, to monitor performance, resources usage etc.


Front-end

Front-end receives data already processed, with computed KPIs etc. and takes care of their visualization. Every BAM solution should deliver graphical front-end witch rich visualization possibilities, such as charts, dashboards or graphs. An advanced OLAP-like visualization tool can be also useful. One of the advanced features some front-ends also provide is a real-time view of processes, visualized on process graph. Here you can view process diagram as it was modeled and track the state of a particular process instance. It is also common that at least one front-end should be web based. In this case front-end should provide a possibility to assemble your dashboards “on fly”. This is done usually by AJAX based scripts. AJAX becomes a standard for web-based BI tools today and it is also supported by Jasper Dashboards, one of the hot candidates for open source BAM front-end.


Long term data mining BI tools

An optional component that can analyze data from long-term perspective, realize data mining and knowledge discovery processes. Discovered information is delivered back to BAM core. Mostly external tools are used for such cases nowadays but hopefully in future some of those tools will become a part of BAM solutions. That will allow the feedback obtained by those tools to be sent back to the bam core or the process server.

General architecture for BAM

Where to Apply BAM

A business process typically spreads across multiple large systems which in turn made up of subsystems and components. For example, an order (i.e. a business entity) for a broadband connection flows from one system to another. It goes through some level of transformation while getting processed. The figure 1 shows how an order flows among multiple systems such as CRM, Billing and Inventory etc. to fulfill an order in a typical business process.
Once the order for the broadband connection is placed by the customer online, it flows through different systems on the way to get fulfilled. The basic steps followed in the process above are:

• The order must be validated online for availability and geographical access.
• A broadband router must be shipped from the warehouse to the customer’s address.
• Customer’s phone line and broadband connection must be linked to the same billing account.
• CRM should be updated with the order fulfillment information for the call center to access when providing support to the customer.
The fault with this setup is that each of the systems is autonomous. They have their own alerting and reporting mechanism. This might lead to a scenario where the customer experiences problems with - the delivery of the broadband router in time, unable to receive a discount (if associated) on the combination of a broadband and a land line. Due to the absence of a proper BAM solution the service provider won’t be able to sense these faults before the customers do, causing an unwanted blot in the customer relationship.

In an opposite scenario with a BAM implemented on the service provider’s side:


• The data from not only the systems involved in the business process but also the related subsystems and components can be captured proactively.
• The collected data can be tracked and analyzed against the defined measures.
• Alerts can be raised to the applications and the people when something is not behaving as desired.

How to Employ BAM

To be able to employ a BAM solution effectively the preferred option is to put the entire business process under the supervision of a BPM engine as shown in the figure below.

Business processes executed by BPM

 

This setup can be extended to incorporate a BAM solution as shown in figure below. Under this situation, the BAM adapter is integrated with the BPM engine that in turn is integrated with all the business process systems. The BAM adapter traces the business entity through the business process and keeps comparing it against the standard or defined values. Let us set a KPI for efficient delivery in the abovementioned example, such that an order should not rest within the inventory system more than seven hours. To handle this situation the BAM adapter should track all the orders that go to the inventory management system. If it does not receive a status change notification within seven hours, an email or an SMS alert is sent to the system owner. In case an API (application programming interface) is available to interact with the inventory system, the specific order can be identified and the owner can be notified with an alert on the same. If there is no status change noticed within twenty four hours, an alert (email or SMS) can be sent to the customer with an updated date of delivery.

BAM integrated with BPM infrastructure

This way, BAM brings in agility and resilience in the business, not only that, it can also cut down the burden on the support services by proactively notifying the customers about their order status.

Enterprises that use middleware instead of a BPM infrastructure for business process orchestration can also incorporate the BAM support in their existing setup using an Enterprise Service Bus (ESB) and a logging framework.

In this case, the applications that cater to the part of the business process will require using a BAM logging framework for updating the status of the business entity (e.g. order) through its lifecycle. Multiple instances of this logging framework can be deployed throughout the enterprise and all of them can forward the logging calls to the BAM engine through the use of an ESB or an asynchronous messaging service.

BAM incorporated in a setup with middleware but no BPM

The BAM engine can revive the lifecycle trail of the business entity from these logged messages, trace its progress and raise alerts, alarms and communications as appropriate.