Practical BPM: Effective Use of a BPM Server

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Meadowbrook Insures Competitive Edge with Help from Adeptia BPM Server Practical BPM: Process Variables Practical BPM: Typical BPM Solution Architecture
	Discussion Forum "SOA is simply an architecture, not an end in itself and that to achieve all it promises, you need to implement business process management..." Contribute to this Discussion

By Rashid N. Khan

A BPM server is at the heart of a BPM system. It is a "black box" whose purpose is to control the execution of business processes and ensure that process incidents continue to move toward completion. In most cases, the BPM server has very little or no user interface. Instead it is a service running on a back office server that monitors and controls business processes. The BPM administrator provides all the configuration and management facilities of the BPM server. The key requirements of a BPM server are:

1. Reliability: The BPM server must have a very high uptime. Any downtime results in the business processes of the company coming to a standstill. While reliability is important by itself, its importance increases as the volume or the mission-critical nature of processes increases.
2. Scalability: The BPM server must enable companies to expand the number of users and the tasks they are performing. BPM is initially adopted in companies as relatively small departmental initiatives with a handful of processes. Once the benefits of the solution have been verified, its use is expanded to other departments and a larger number of processes. Thus, the BPM server, and the rest of the BPM solution, must be able to scale in terms of the number of users and the number of transactions that it can support.
3. Error detection and recovery: The BPM server must provide some mechanism for detecting errors in a business process or in the operating environment, and a method of gracefully recovering from these errors.

Scalability and Speed

A BPM server must be able to respond quickly to events. When a user initiates a new process incident, the BPM server must determine the next steps, activate those steps, and in the case of steps performed by people, send an email notification to the recipient of those steps. When a user completes a step the BPM server must again respond rapidly to the action and decide whether to execute subsequent steps. As the number of users, the number of automated business processes and the number of incidents for each process increase, so does the need for speed as more demands will be placed on the server.

The speed of the BPM server depends on a number of factors:

1. The performance of the computer hardware used to host the BPM server. In general, modern systems require high-speed multi-processor computers, a large amount of memory and fast disk drives with ample space. Upgrading hardware is one of the most cost-effective ways of improving overall system speed and performance. Moreover, the configuration of the computers on which the BPM server is deployed also contributes immensely to overall performance.
2. The design of the BPM server software and its architecture. Once a BPM system has been selected, its architecture cannot be changed. Therefore, it is important for potential buyers to investigate the architecture of the BPM server before they purchase in order to verify that it uses modern technologies that will not create performance bottlenecks.
3. The size of the business process. The larger and more complex a business process, the longer it will take to interpret it in real-time and make decisions about subsequent steps when a particular step is completed. Large complex business processes typically need more resources that impact performance.
4. The complexity of business logic. Whenever a process step is completed, the BPM server has to make decisions about the next steps to be activated. If a step has associated condition tables, this evaluation takes longer. The more complex the condition tables the longer it take to perform the evaluation.

A high performance BPM server provides a scalable architecture that maintains its performance and responsiveness as more users are added to the system and it is required to perform an increasing number of transactions. This is achieved by object-oriented design and the use of network and object load balancing techniques offered by modern operating systems.

Reliability

Many users participate in business processes automated by a BPM server. If the BPM server breaks down, processes will come to a standstill and will have a negative impact on productivity. A BPM server must provide excellent reliability and uptime. This is best accomplished by using an architecture that supports fail-over redundancy. If one server fails, there will be one or more back-up servers to continue processing with negligible impact on the participants or throughput of processes.

Reliability of a BPM solution, however, does not depend on the reliability of the BPM server alone. It also depends on a number of other infrastructure resources that are necessary for the operation of the BPM systems. These include network connectivity and reliability, databases and their reliability, and the reliability of other systems involved in BPM, such as email, document management, directory services, Web servers and others. When planning the reliability of a BPM system, it is important to analyze and improve the reliability of all other systems used with the BPM system.

Fault Detection and Recovery

A business process can come to a standstill even when there is no failure in the operating system or the hardware used to host the server. This happens when a process incident stalls due to poor or incorrect process design. When an incident stalls, no task is active for any user and no one is aware that the incident has stalled unless someone is constantly monitoring the incident. This is impractical. Furthermore, if one incident stalls, it is likely that others will also stall. Therefore, a BPM server must provide a mechanism of detecting stalled incidents and notifying appropriate process owners, who then can take corrective actions to resolve the root cause of the stall. There are two mechanisms that a BPM server can use to detect and handle stalled processes:

1. Periodic housekeeping: This is an independent software service that operates as a part of the BPM server. It is designed to run at periodic intervals. During these periodic intervals it performs a number of housekeeping tasks to ensure the integrity of the system. These tasks may include checking for stalled incidents, monitoring the availability of system resources such as memory, disk space and database connections, and finding out if tasks are late. If the housekeeping service determines that one or more incidents have stalled, it can generate email or system alerts so that corrective actions can be taken.
2. Incident completion time: Some BPM systems provide an "incident completion time" property as a part of the process definition. This is the time allowed for the incident to complete after it has been initiated. If a process stalls, the incident completion time will eventually expire, triggering a notification event. This feature may also be used to alert the BPM administrator that the incident time has been exceeded. However, this is not as good a solution as the first, since it waits until the incident completion time has expired instead of taking corrective action as soon as the incident stalls. Furthermore, the incident completion time may expire for reasons other than the incident stalling, such as a user who fails to perform his task in the allotted time.

The agility of the organization’s business processes is dictated by the quality of the "brain" that governs these processes. The BPM server is the brain of a BPM system.

Useful Links

This article is an excerpt from Rashid Khan's Business Process Management: A Practical Guide. Order your copy here:
http://www.bpmenterprise.com/yDQ

Ultimus
http://www.ultimus.com

About the Author:

Rashid N. Khan is the founder and Chief Technical and Strategy Officer of Ultimus Inc., a pioneer in business process management and workflow automation. Prior to establishing Ultimus, founded Sintech Inc., a leader in advanced software for mechanical testing. Rashid sold Sintech to MTS Systems in 1989, where he worked for a five years as a vice president and general manager. During this period he took the company through ISO 9000 certification. This experience made him aware of the need for business process management and workflow automation. Rashid obtained two undergraduate degrees from MIT in computer science and political science. Khan is the author of Business Process Management: A Practical Guide, has published numerous articles and spoken at a number of events. Contact Rashid N. Khan at info (at) ultimus.com or visit http://www.ultimus.com.

Rate This Article:  Current Rating: 1.00   Poor    Excellent                1    2    3     4    5   View all top-rated articles

Copyright © 2003-2008 – BPMEnterprise.com, CTQ Media LLC. All Rights Reserved
Reproduction Without Permission Is Strictly Prohibited – Request Permission

---

Publish an Article: Do you have a process management tip, learning or case study?
Share it with the largest community of Business Process Management professionals, and be recognized by your peers.
It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.