The BPM System Architecture is the workhorse of an organization’s BPM vision to fulfill its strategic BPM needs and objectives. This article aims to provide insights into the BPM System Architecture and how it should be devised and evolved to fully support a seamless, scalable and dynamic platform for process implementation.

Most organizations in today’s world would purchase a packaged BPM suite which has abundant features out-of-the-box that supports the entire BPM lifecycle, rather than an in-house built custom BPM platform. The need for a BPM System Architecture is even more imperative for a packaged BPM suite, since the packaged products must be judiciously aligned within the scope of the Enterprise Architecture (EA) of an organization. A home-grown BPM platform would have a lesser challenge in terms of fitting into the Enterprise Architecture since it would have evolved within the EA scope right from the beginning.

The packaged BPM suites would seem to be more exciting and successful when implemented on a small scale like proof of concepts (POCs). However when these suites are stretched for a full-fledged implementation, its shortcomings may lead to a colossal failure.  A BPM suite can handle 10 process implementations with ease, but when it comes to hundreds or thousands of processes, a trivial mistake or a minuscule shortcoming in the BPM suite would proportionately increase the rate of failure.

It is imperative that a BPM System Architecture is built in such a way that a packaged BPM suite can be seamlessly integrated into an Enterprise Architecture. This article will provide insights and glimpses of a BPM Reference Architecture.

Process Data versus Business Data

Process Data is the one which supplements the process, but not crucial for the actual completion of the process. KPI, SLA and metrics are few examples of process data. A KPI or SLA might be based on Business Data but as such it may not be required for process execution. Business data is the actual driver of the process and would take it to completion. For example, in the insurance industry the business data would look like an insurance ID, a claim ID, insurance expiry date etc. Business data is critical for process execution and the process directly depends on the business data for the process to complete.
The BPM System Architecture should clearly differentiate between the process data and the business data. The business data would most probably reside in an independent repository (database) and would be accessed via an abstraction layer like SOA. The process data would be derived from the business data by the BPM suite and would reside in the BPM suite database.

The BPM System Architecture must clearly define the business data identifiers that a process should be aware of. For instance, an insurance process must be only aware of insurance ID. Anything beyond that would mean a nightmare to sync the process and business data. If the process data is defined with insurance ID and insurance expiry date, then any changes to the insurance expiry date in the external systems must be synced with the process data, which would be a nightmare if the number of business attributes in the process data grows. Instead the process should only be aware of the insurance ID and when the process requires the insurance expiry date, it needs to be pulled up from the external system using the insurance ID. In other words, the best practice to define process business attributes is to define it with unique business identifiers. An insurance id would be a unique identifier and all relevant details pertaining to the insurance policy can be pulled from the insurance id.

Process data like KPI and SLA can be derived again from business data. If an SLA needs to be defined on the insurance expiry date from the process, with the insurance ID, the insurance expiry date required for SLA computation can be pulled from the external system and the SLA can be derived. The SLA data for the insurance expiry date can reside in the process repository.

The BPM System Architecture should define a framework (like an integration component) which would act like a nerve centre to pull business date from the process with the help of unique business key attributes.

Long running process

Failure of process instance cannot always be avoided. But what would be unavoidable, is of course the graceful recovery of the process instance. A process instance can fail for a variety of reasons ranging from unavailability of system resources, data issues, network outages or technical glitches. The more prominent of these are the data issues.

A process instance in a telecom infrastructure provider would typically execute for months. If the telecom provider has a process implementation, for example to lay trans-Atlantic cables from the United States to Europe, such a process instance can get executed for multiple months. In due course of time, if the process instance fails, the situation may not demand to create the process instance altogether from the beginning of the process. It is then more likely it may not be possible at all, since the business data has undergone changes in due course of the process traversal. In such scenarios the process instance no-matter-what has to be gracefully recovered.

Let us assume that for the process described above, the process instance gets stuck at an activity where the process instance expects the length of the cable between pier A and pier B to be of certain length, whereas the business data for cable length is out of that range for what the process instance expects.  For the process instance to execute, the business data for cable length needs to be updated in the source record. The BPM System Architecture should have a mechanism to refresh the process with latest business data after the update and should recover gracefully.

Also, all long running processes which are vulnerable to failures and are critical to business wherein the re-creation of the instance is not possible, the actual business process must be supplemented with a background recovery process. The background recovery process must be designed in such a way that it must be capable enough to replicate any process instance and can hold the same state as the failed process instance before the failure. The input to the recovery process must be the business key attribute and the activity of the process from where the process instance has to start. This input activity would be the same as the failed process instance step. In order to design such a recovery process, it is absolutely essential to separate the business data and process data. Without this it would be very difficult to create a process instance from a specific activity within the process, since the newly created process instance should reflect the exact state of the failed process instance. This is only possible by associating the business data of the failed process instance to the newly created instance.

In my follow-up blog next week, I will go into more detail on BPM Portals, Exception Handling and Process Versioning. Stay tuned!

Follow