With the current process modeled, JK can begin to separate the process flow from the business logic. Increased flexibility and agility can be gained by creating individual services to represent the business functions the process flow can invoke. So, for instance, “normal value claim” can be a specific CICS application that the process flow engine can invoke with well-defined inputs and outputs.
The HIM component of a BPM solution can manage the process that performs claims validation for high-value claims. JK’s senior claims adjusters receive an electronic folder. The BPM system will manage a work list of claims for the senior claims adjuster role so any available adjuster can take ownership of that step and complete it. Specific claims can be reassigned or escalated if they’re not handled within a specified time.
The test for too many claims can be separated from the code and placed in an external business rule. If the threshold of excessive claims changes in the future, JK can just modify the business rule and not make a coding change. While this is a fairly simple example to illustrate the point, business rules can be quite complex and involve multiple predicate conditions. Business rules that are external to the process also can be reused in other processes and in business services, too.
There are times when the content of the service request might alter which service should be invoked in the process. An example is the test for claims of greater than $1 million dollars. While this could be implemented as an external business rule, it better illustrates the capability of DSS. The business policy JK has implemented is to handle high-value claims with different business logic. A different service is selected based on the real-time content of the process; there’s no hard binding of conditions in the code.
The last capability of the BPM system is business event management. Currently, there’s a separate path for detecting and handling fraudulent claims. With an external event management system, JK could do fraud detection before the claim ever enters the claims system. If fraud is detected, a separate process could be started that would be independent of the current claims system. This is important because there might be complex, seemingly unrelated events that indicate a possible fraud. The current claims system has limited sight into other events to be able to detect events such as duplicate claims or a recent address change.
BPM on System z
The deployment platform for your BPM system is a critical decision you must make. Most of your business services are probably already implemented, but may require some modernization to service-enable them. The platform choice for those services has already been made. However, the placement of the BPM system that performs the navigation and management of the business processes, including all the capabilities discussed here, is as important as the business service placement. There are three critical considerations when choosing where to deploy your BPM system:
Regardless of where your business service applications reside, if the navigation logic that ties them all together into a business process isn’t available, your business will grind to a halt. The first consideration for platform selection is availability. Your BPM should have as good or even better availability than your individual services. If some of your business services are modernized legacy applications residing on System z, it makes sense to deploy your BPM system there, too. With the highest availability in the industry, System z will ensure your BPM system isn’t the weakest link in the availability of your critical business processes.
Core business processes need to be efficient and perform well. Keeping your process navigation close to your business services reduces the overhead of invoking those services and reduces latency. Proximity to applications and data really does make a difference when the process navigation between each step occurs without network hops. Performance of your BPM system is the second consideration for platform selection, and running your processes on the same system as your business services leverages the strength of the System z in efficiently handling mixed workloads.
Business processes are a competitive advantage for companies and should be well-protected. The security of your BPM system and processes is the third consideration for platform selection. System z is known as the most secure platform in the industry and can ensure the security of your processes isn’t compromised. Availability, performance, and security are three compelling reasons for deployment of your BPM system on the System z platform.
We’ve looked at the capabilities of a robust BPM system. While we’ve focused on the run-time aspects of the core BPM system, there are many ancillary functions that should be mentioned. These include tooling for process and service development, governance for process models and business services, and monitoring of KPIs to assess the health of business processes during execution. These other areas should be considered when you select a BPM suite for your company.
Companies that have implemented BPM are more likely to remain competitive because they have the flexibility and agility to quickly change and stay ahead of their competition. BPM is an enabling technology for change that you should consider as you implement your SOA.