In my previous blog post, I wrote about Process Data versus Business Data and the importance of background recovery processes. In part 2 of this blog, I will go into more detail on BPM Portals, Versioning and Exception Handling in BPM.
BPM Portal
A large scale BPM implementation would require a unified user interface for the business user community. The out of the box portal packaged in the BPM suite may not be flexible enough for extreme customizations. Also, process instance search is a ubiquitous functionality which would act as a first interfacing point for the user.
The BPM System Architecture is responsible for a process instance search framework. The challenge to build such a framework would be to integrate both the process and the business data in one single view. A process instance can be searched with a business attribute as a parameter and also the search can be performed with process data such as SLA.
One possible technical solution is to combine the process data and business data together as Database view, by which expensive database joins can be avoided between multiple tables of the business data schema and process data schema.
BPM Exception handling
Exception handling is one of the prime aspects of software design which attributes to the robustness of the application. Exception handling gains more significance in BPM space, since exceptions had to be dealt both at a system level and at a business level.
The significance of exception handling at a process modeling step cannot be ignored. There is a need to handle ACID transactions in BPM, with a business solution and it has to be captured in the model with business semantics. For instance, a classic example of flight, hotel and rental car booking when deemed as a single atomic transaction cannot always be dealt at a system level. If flight booking and hotel booking are two different applications in two different domains (if flight carrier and hotel are different companies), then system transactions cannot be propagated and even if it seems to be possible, system level locks for transaction may not be possible to be obtained since the whole transaction may exceed beyond days to complete. The ideal way to deal with this situation is to have three distinct transactions as business process and even if one fails the other transactions must be canceled using a business process. If flight booking has been confirmed and if hotel booking transaction fails, then flight booking should also be canceled, wherein flight cancellation must be modeled as a separate business process.
It becomes imperative for a BPM solution to handle system level exceptions gracefully. Since process instances can span across business days, in case of system exceptions the process state has to be persisted and should be able to recover from the state where it was left. This may not be possible always for each and every process instance. Sometimes there is a good chance that a process instance may get into an irrecoverable state. In such scenarios, it may not be desirable for the users to create a new process instance altogether. The alternatives for irrecoverable instances due to system exceptions are few, and one probable solution could be to create a new process instance and associate the application process data with the new instance, and programmatically navigate process the instance to the workflow step where it failed.
Another alternative is to create an exception business process. Any system level exception occurring in any of the application business process would trigger the exception business process, which would notify the user about the exception. Also exception process can notify a repair/admin team about the exception. Having a repair queue of exceptions can help the repair/admin team to get first hand information about the exception without the need for notification from the business users about what had happened. Also, irrecoverable process instances can be dealt internally within the IT team, without burdening the business users.
Process Versioning
A process undergoes lot of changes in a BPM lifecycle with multiple iterative implementations. The BPM System Architecture must be potent enough to handle multiple versions of process instances. Most of the modern BPM suites come pre-packaged with utilities to migrate the process instances from an obsolete version to higher versions. However, a process instance in an older version may not be always possible to migrate to a higher version, due to external system dependencies, when the external system itself would have undergone a version change along with the process. This is again in-line with the process data versus business data debate. The battle lines between process data and business data have to be carefully drawn in such way that any data on external system should not be a part of process data. A better way to hold reference to external application data is to hold reference to the unique business key attribute of the external system.
Conclusion
These are the some of the many items that must be considered for a BPM System Architecture. If the segregation between process data and application data can be achieved then having the BPM System Architecture would bring the additional flexibility in terms of solution design.
Follow
