Jul 21 ’09
Business Process Management in Your System z Environment: Enabling for Change
Gone are the days when you could write a monolithic program that performed ever y function you needed to implement your business solution. The pace of change is accelerating. To keep up and stay ahead of the competition, you need tools and processes in place to quickly adapt, yet remain flexible. Your company can’t afford to spend months or years adding new functions and capabilities to existing systems. An infrastructure built on a Service-Oriented Architecture (SOA) is a great beginning, but you need more than a collection of services with a standard way of describing and accessing those services through a service bus. The discipline of Business Process Management (BPM) can give your company the technology to leverage your SOA to create a truly agile infrastructure.
Business processes differentiate one company from another and yield competitive advantages. Companies with superior business processes endure. However, changes to your business processes don’t happen by chance.
BPM is a discipline that provides a way to build your business processes in a dynamic, flexible manner so you can achieve the agility you need. Figure 1 shows five aspects of a BPM system that will be described in more detail. These include capabilities such as:
• Process choreography
• Human Interaction Management (HIM)
• Business rules management
• Dynamic Service Selection (DSS)
• Business event management.
BPM combines these technology capabilities and your expertise to accelerate business process improvement and facilitate innovation. BPM builds on your SOA infrastructure by providing the technology to combine your business services into a composite business solution. This article describes each of the major capabilities of a BPM solution and illustrates these capabilities from the perspective of a fictitious insurance company.
Process choreography is the underlying workflow technology that lets you describe the sequence of activities that compose a business process to automate it. Process choreography doesn’t describe the business logic of individual activities, but provides the navigation logic to determine which activities to invoke and in which order. For example, a business process for a mortgage application may involve several steps, including determining existing assets, performing a credit check, and assessing the value of the home being purchased. Rather than using a paper-based process where the knowledge of the next step is either written in some obsolete procedures manual or kept in some expert’s head, process choreography gives you the tools to describe the sequence and relationships of each step to be automated. As each step is completed, the next step is automatically scheduled.
Typically, business processes are described using the Web Services Business Process Execution Language (WS-BPEL) standard. This XML-based language is used to create executable business processes and is sometimes called “programming in the large” because it represents the high-level navigation of the business process steps rather than the individual business logic of each step. The process choreography is specified in the WS-BPEL. While individual activities (steps) in the process are invoked via Web services requests, the business logic, represented by activities, doesn’t have to be Web services-enabled to participate in a WS-BPEL process flow. An Enterprise Service Bus (ESB) can convert the Web service protocol to the protocol the business logic application expects. This type of mediation provides a more loosely coupled connection that will give you greater flexibility.
There are many process design tools that can help you graphically build the business process and generate the WSBPEL artifact. You can build the process with such tools, define Key Performance Indicators (KPIs) to be monitored at run-time, and perform simulations to test process changes before they’re deployed. Once you have the process model built, you can wire the process activities to the appropriate realization of the business logic. When you have the process model defined and the activities wired, you’re ready to deploy the process model to the process server at run-time.
Human Interaction Management
Not all steps in a business process are programmatic; many require some human interaction for activities such as exception handling, gathering additional information, critical decision-making, or even initiating a new process. Some processes are exclusively human, so each activity is assigned to a person. A person can’t be wired into a business process at a specific step, so there must be an interface developed to let one or more humans interact with a process that can still be specified and implemented at run-time. This discipline is known as Human Interaction Management (HIM).
There are many implications in building a robust HIM system. There may be several people who can accomplish a specific task, so a role-based assignment system is required. For instance, a loan approval process may require human approval when the amount exceeds a certain threshold. In a large lending company, there are probably many people who have this role and can perform the function. Assigning a human activity to an individual involves ensuring they have the proper role in the organization. In addition, the task may be assigned to a work list that several people in that role are handling. That ensures no one person is overloaded with assignments while another person is idle.
Another consideration for a HIM system is the handling of people moving into and out of specific roles. Typically, the role definitions are maintained in a separate company directory, managed by HR, that the BPM system accesses.
Business Rules Management
As much as 70 percent of business processes involve decision-making logic. Building flexibility into your process model is important so you can quickly adapt to changes. An external Business Rules Management System (BRMS) can help you change policies and rules without having to go back and change the code or WS-BPEL for the process. A BRMS lets you externalize rules-based decision logic from your process navigation logic and application business logic.
For example, you might have a simple business rule that states: if a mortgage application exceeds $1 million, it needs approval from a senior loan officer. You can embed this rule in your code or even your WS-BPEL, but if you want to change the threshold amount, you’d need a developer to make a change to the code and then recompile and retest before that change becomes active. With an external BRMS, you have more flexibility; you can dynamically make the change to the rule without requiring a development cycle.
BRMSes aren’t technically part of formal BPM systems since they can be used outside of process management and frequently are. However, the functions a BRMS provides are critical to robust implementation of BPM.
Dynamic Service Selection
The rapid pace of change today requires business processes to adapt even more quickly and dynamically respond to change. The requirement for higher levels of agility calls for companies to implement further loose coupling of their processes and services. One way you can do this is with Dynamic Service Selection (DSS), which starts with creating encapsulated business services. Execution of these business services can be adapted at run-time based on business policy and user context. You can provide even greater flexibility to your business processes by letting them dynamically choose the target activity (i.e., selecting the business service at run-time based on the context and content of the service request).
By dynamically selecting the service end-points, you can move navigation decisions outside the process, enabling process behavior changes without changing the actual process specification. This helps you simplify the core processes and gives you more agility as you implement business policies. For example, a mortgage lender might use a different business service for a high-risk applicant with a poor credit score.
Business Event Management
Events are constantly happening in your environment that can directly impact your business processes. Some of these events, such as receipt of a home appraisal report for a mortgage application, are expected and a normal part of your business process. Other events, such as a fraudulent insurance claim, may not be expected.
Event processing is a well-established IT discipline. Simple events, such as receipt of an appraisal letter, are typically managed through a pre-defined step in the business process. Unsolicited events, such as a mortgage application, can even start a new instance of a business process.
Millions of these events occur daily in your enterprise; some don’t have response actions defined while others have automated responses where no human interaction is required. But a relatively new technology that’s changing the landscape of event processing is the ability to handle complex events where multiple related events occur. Available tools can recognize the relationships and patterns among multiple events, called event correlation, to give you additional insight into your business processes.
Complex events can span multiple instances of your business processes. For instance, property damage claims may be submitted by two different family members for the same item. You may have logic built in your application to detect this specific example, but fraud detection is becoming a very sophisticated discipline and may not be easily embedded in an application.
Once you’ve defined the event conditions to your event management system, including filtering and correlating them, you can define actions to take when the event is triggered. Those actions may include starting another business process for certain types of fraud handling.
Like BRMS, business event processing systems aren’t technically a part of the formal BPM systems since they can be used outside of process management. Most notably, event processing is used in the systems management discipline. However, the function provided by a business event processing system is critical to a robust implementation of BPM.
JK Insurance Co., a fictitious insurance company, provides property and casualty insurance to individuals and several hundred small- and medium-size businesses. Policies are sold through a network of independent agents.
JK’s current Claims Processing System (CPS) is a combination of legacy CICS and VSAM developed in 1987 with some front-end WebSphere developed in 2002 that provides customer access through the Web. Customers can submit new claims, check on the status of existing claims, and add new information to existing claims. CPS uses the Customer Reference Database (CRD) to access information for customers submitting or updating claims. Also in the CRD is information about whether the customer is an individual or company member.
JK recently evaluated the CPS system and decided to take steps to modernize it by adopting an SOA. Initially, they began to service-enable the CICS applications invoked by the Web frontend through the use of CICS Web services. While this has given them some flexibility, they really feel a BPM system would move them to the next level since their processes are currently defined in a high-level routing application. When process changes are needed, the application development team must get involved and it can take from six months to a year to fully implement and deploy changes.
For JK to start with BPM, they will model the existing business process. This can occur independently of the actual implementation and will result in a starting set of WS-BPEL that can be used to begin process improvements.
Current Claims Process for Individuals
Figure 2 shows a small part of the current process. While this process has been modeled using BPM tools, the process flow is currently implemented as a set of CICS programs. A group of senior claims adjusters review physical folders to handle high-value claims.
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.