Credits: Phillipp Schume
The reference architecture depicts typical cases of a functional architecture in traditional BPM projects.This can be taken as reference, guideline and best practice to create the application architecture on any BPM development project.There will never be a 100% pre-formed solution, therefore this may apply for 80% of cases and case dependent adjustment are recommended to be done.

Architecture Overview

BPM Reference Architecture v1

The blue parts depict what’s usually part of the decision process of a BPM project.
The gray portion shows the pieces of the architecture that are usually out of scope to be designed by a BPM project are mostly part of a Enterprise Architecture initiative.
Most scenarios involve:

  • BPM itself with either coaches or a third party UI.
  • A shared service environment (ESB)
  • Shared data, which can either be enterprise master data management systems or simply other applications which have data that need to be accessed by one or more external systems

The reference architecture is divided into 4 layers:

User Interface (UI)

Visualization layer.

Mostly coaches are being used, therefore this can almost be neglected as coaches interaction with the process out of the box.
A commonly used alternative are custom UI, e.g. for mobile devices that interact with BPM using the REST API

Application (App)

The application layer holds the logic for each business application. Whether it is process oriented or not.

Business logic should always be solely held on the application layer and NOT distributed. Common mistakes are to have business logic either on the UI layer or even ESB.

If external systems interact with BPM, this can happen through different ways.

BPM can expose a service, e.g. web service, which would be called through ESB.

If the actual application is a combination of a external system together with BPM, it makes sense to interact using the WebServices API.

Integration – Enterprise Service Bus (ESB)

The ESB or Integration Layer is the portion of a architecture that integrates a application with other applications.

It is important to understand that a ESB is not a product. A ESB is a concept of a single instance (a bus) that exist within a company which enables you to access other enterprise services or data.

A ESB can be implemented different ways.

A very common and recommended way is to use existing products such as WebSphere Message Queue (MQ), WebSphere Message Broker (MB) or WebSphere ESB. However, it is not uncommon that clients have their own implementation of a ESB. Often even as custom java implementation.

Canonical Model

A ESB often implements the recommended pattern of a “canonical model”.This simply means that the enterprise data model “lives” on the ESB.Any application should basically implement this model. However, due to historical growth and many other reasons, application are often not able to do that or change their model into that fashion.For every service call that a application can do TO the ESB, the service data model gets the transformed into this standard model. From there it gets transformed into the target data model (if not the same).Through this, every transformation has only to be done once and is way more flexible for changes and enhancements as opposed to point-to-point transformations where every service call would have to maintained manually.

Join The Discussion

Your email address will not be published. Required fields are marked *