Automation of business processes. Part 2. Adaptive BPM

So, in the first part , what business processes are by the degree of their resistance to change, technical concepts for the implementation of a particular type of BP, as well as an example of the logic of adding / removing tasks from the adaptive model of BP.
In this part of the article I am going to describe in more detail how the adaptive BPM (aBPM) differs from the normative BPM (nBPM) and from Adaptive Case Management (ACM), then present the architecture of the resulting aBPM system.

Figure 1 clearly shows the transition from explicitly structured PSUs (nBPM) to implicitly structured PSUs, in other words, to ACM.

It is impossible to say that nBPM is the last century, and for ACM the future of automation is the management process.

For some BP in one context, one approach is more applicable, and for other BP in another context, a different modeling approach is applicable.

An example is the most traveled BP "application for vacation." It is possible to implement this process using ACM, or using the usual TreeSet.

This can be compared to hammering a nail into a board. It is good to take a hammer and hammer in a nail, and it is possible to take a plant for driving construction piles, then make calculations on the strength, amplitude, angle of impact and with this installation hammer a nail. The result is the same - the nail is hammered, but how difficult was the solution (including the design and manufacture of such an installation for piles) to solve a simple problem. A hammer for hammering piles does not fit.

It is important to understand which tool and in what context to apply to tasks.

nBPM - well suited to clearly structured and short on the duration of the performance of BP within the same company, for example, the same BP "application for vacation."

ACM - well solve problems with implicitly structured BP, for example in medicine and in insurance, when each instance of the process can be individually modeled according to the situation. Several examples of the use of AFM described maxstroy .

aBPM is, in my opinion, a cross between a clear structure of nBPM and a complex ACM. It is well applicable in cases of unforeseen changes in the BP model of long-running instances of processes.

A typical example from the financial sector is “loan repayment” (the duration of a BP execution is up to 30 years) - at the time of launching, the BP model is up to date and all process instances run are the same. However, for 30 years, new requirements for the process model (for example, changes in the legislation) have arisen, and the necessary changes are already applied to running instances of the process on the fly, that is, without interrupting the execution of this instance. All new instances of the process already contain these changes, the so-called BP evolution is taking place.

By chance, I most often dealt with aBPM, about which further narration will go.

The aBPM architecture is a "add-in" over any conventional BPM Engine.

The architecture does not depend on the manufacturer, which gives another opportunity to manage BP migrations from one BPM Engine to another (for example, as happened with JBoss BPM, when Red Hat refused to support and further develop this BPM "engine").

BPM-Adapter - encapsulates the functionality of communication with each type of BPM Engine; in this example, only one type of BPM Engine will be taken - this is open souce Camunda BPM (fork from Activiti BPM ), but in principle any combinations are possible.

PCS is the core of the system that controls all the processes in the BPM Engine. For example, when calling the launch function of a process instance, PCS takes control of the versions of the BP models and decides which version on which BPM Engine to run.

In the next part I will talk about modeling aBPM processes.

Looking ahead, I would like to mention the main idea of ​​aBPM modeling:

The aBPM model consists of two subtypes of processes:

- subject business processes
- technical business processes

Subject business processes are assembled from technical BPs , from which, in turn, a business logic model of this BP is built. In subject BPs only partial use of elements of the BPMN 2.0 standard is allowed.

Technical business processes accommodate the full functionality of the BPMN 2.0 standard.

Thank you for your attention, add to bookmarks and until the next part of the article!