Practical BPM: Establish a BPM Architecture

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Practical BPM: Typical BPM Solution Architecture Defining an Enterprise Business Process Architecture Commentary: Business Process Management Is SOA's Killer App
	Discussion Forum "...I see ESB being SOA infrastructure and SOA with ESB as its infrastructure provides BPM the data and services for gaining visibility into the business processes." Contribute to this Discussion

By Rashid N. Khan

Without a correctly established architecture, any business process management (BPM) software program will face unnecessary troubles.

Architecture Attributes

Key attributes of the architecture of a BPM server include speed, scalability and high availability. The architecture is based on modern object technologies supported by various versions of Microsoft Windows servers such as COM, COM+ and .NET. Similar distributed object technologies are provided by UNIX/LINUX platforms in the form of CORBA or J2EE.

A modern BPM server has fundamentally the same architecture as any other n-tier enterprise application designed for scalability. These applications use distributed object models (COM, COM+, CORBA or J2EE). The easiest way to understand an "object" is to think of it as a self-contained piece of software that can be called by other applications to perform a specific service or task. When an object is called upon to perform a function, a copy of the object is created in the server’s memory. This object persists for only as long as it is needed to perform the functions. During this time it consumes resources such as memory and database connections to perform the functions. Once the function is completed, the object "dies" and frees up the resources it was using so that they can be used by other objects. (See Figure 1.) A client application wants the server to perform a specific function. It sends a request to the server. The server creates an object capable of performing that function. The object then performs the function; once the object completes that function, it sends the response back the client, and then dies.

Figure 1: Using Objects to Handle Client Requests

One of the most significant things about objects is that their design needs to be concerned about supporting one client. They are "single" user and "single" function, and, therefore, easier to develop than a program that performs a function for many clients simultaneously. If more than one client asks for the same function, the server simply creates another copy of the object to handle that request. Objects are created to handle a specific request then die when the request is completed. Many objects can live simultaneously on the server to handle multiple requests concurrently.

Architecture Capabilities

Modern server operating systems provide an environment for the creation and management of objects. These environments have different marketing names, but for the sake of generalizing they can be called transaction processing environments (TPEs). The TPE provides an environment and services that allow for the creation and termination of objects and the allocation of resources for the objects.

In addition, the TPE also provides two other very powerful capabilities. 

1. Transactional integrity: If an object is created and performs a part of its function, but then a non-recoverable failure occurs (such as a hardware crash or connection failure), the TPE rolls back the partly completed transactions. This means that the task an object was created to perform is either fully performed or not performed at all.
2. Scalability: Scalability ensures that the performance of the system does not degrade as the number of users increases. System performance degrades because as more users require services from the server, the server creates the necessary objects to satisfy the request. As more objects are created they contend for resources such as memory and database connections. This eventually leads to bottlenecks and severe degradation of performance. Modern TPEs provides a feature called "object load balancing." This basically means that instead of deploying a singe server, the application can be installed on multiple hardware servers running in a cluster. In a clustered server environment, the TPE can distribute the creation of the objects on different servers in the cluster based on which server has the most resources available. Since this object load balancing happens dynamically, the performance of the server can be maintained by simply adding more servers to the cluster.

Server Connections

A server also needs to provide scalability for how clients connect to the server. The method of connection can be divided into two broad categories of applications:

1. Client/server applications: In a client/server application, the clients and the server are located on the same physical local area network (LAN), generally behind the firewall of the company. In these applications the client communicates with the server through technologies such as DCOM (distributed COM) in Microsoft environments and CORBA in UNIX environments. In this case the connection from the client to the server is over the company’s LAN.
2. Web applications: In a Web application the Web browser is the client. It communicates with the server via HTTP over the TCP/IP protocol. For these applications, the application server typically also includes a Web server. The Web server has a URL as a unique address and all HTTP requests for service are directed to this Web server where they are mapped to an object that performs the service.

A typical architecture of a BPM server is shown in Figure 2. It consists of the following components:

1. BPM objects and object layer: The BPM objects provide the business logic layer. These objects make decisions about actions based on the state of a process incident and other context information.
2. The BPM server database: This database contains information about the state of all process incidents and user tasks. It is used by the BPM server to make decisions, and is also updated following the actions taken by the BPM object.
3. The external database: These are databases external to the BPM system and contain business information that is used, processed or acquired by the BPM system.
4. The Web server layer.
5. Clients.

Figure 2: Typical BPM Server Architecture

It is also important to understand how such installations might be deployed for different levels of scalability.

Small and Medium Installations

A small installation is recommended for a demo or pilot installation of a BPM solution. In this configuration, all components of the solution are installed on the same server, including the database, BPM objects, Web server and other related services. Since everything is running on the same hardware, high performance from such as system cannot be expected.

In a medium installation, a separate database server is dedicated for the databases, including the BPM server and the external databases. Most companies already have dedicated servers for their databases and it is generally recommended that databases be hosted and maintained on their own servers for security and maintenance. This frees up more resources for BPM objects and provides more scalability.

Larger and Very Large Installations

In a large installation a separate server is dedicated for the databases, BPM server and the Web server. By separating the Web server from the BPM server, this configuration provides faster Web response as well as increased resources for the BPM objects to perform their functions. For very large installations the recommended configuration uses clustered servers. The servers are clustered in two tiers. The first tier, the Web tier, provides network load balancing. Incoming service requests over HTTP are routed to the Web server that is able to respond the fastest. The Web server then causes the creation of a BPM object on a server in the object tier that has the fastest response time at that instant. This ensures dynamic network load balancing, object load balancing, as well as redundancy. If any one of the servers is out of commission the HTTP request or the creation of the BPM object is dynamically distributed to the other servers.

Distributed Server Architecture

For large organizations scalability requires the support of multiple, distributed servers. In large organizations it is routine to find teams of people working together on specific business processes in different geographic locations spread out across the globe. Business processes span these locations. This brings up the challenge of providing a means for users or applications in satellite locations to participate with full fidelity in business processes. Using the Internet application model, it is possible to allow these remote uses to connect to a central server over the Internet and participate in business processes with the same capabilities they would have if they were local.

For a number of reasons, it is not practical or advisable to deploy a BPM solution using this model. First, the connection between the remote location and the BPM server over the public network may not be fast. This will degrade the performance of users at remote locations. Second, the connection may be intermittent, which means that users may unexpectedly lose the work they are doing. And finally, if an organization is very large with many users leveraging many different business processes, it may not be advisable to use one very large server to manage the business processes of the entire organization.

The preferred architecture for these circumstances is to use a federated BPM server architecture. In this architecture, each location has a BPM server that is independent of all other servers. However, these BPM servers are loosely connected in a "federation" over a virtual private network (VPN). The term "loosely connected" refers to the fact that the connection between the servers does not have to be available all the time, or available at the high speed. BPM servers use modern message queuing technologies to ensure that when they communicate with another BPM server, their messages are guaranteed to be delivered to the remote BPM server whenever the connection is available.

In this federated server architecture, a business process may be local or global. If a business process is local, it is available only to users in the domain of the BPM server it is installed on. However, if a business process is global, some steps in the business process may be designated for users who are not in the host domain of the BPM server it is installed on. Instead, these users may be located in any of the other domains. The host BPM server manages the execution of the process. When a step(s) has to be performed by remote users, the host server communicates with the remote server and sends a packet of information identifying the tasks to be performed and the user who must perform the task. It is then up to the remote server to ensure that the task is performed. At the completion of the task, the remote server communicated the results back to the host.

There are many significant implications of the federated server architecture:

1. The management of business processes is distributed. One server does not have to control the execution of processes for the entire organization.
2. A server can communicate with remote servers over a loose connection. This allows remote users to perform without being constrained by network speed or downtime. Whenever a connection is available, the remote server can transfer all the tasks and information to each other so that users at each location can then perform them at will.
3. The overall architecture is transparent to the user or business process owners.
4. As laptops become more robust, the use of small federated servers will enable mobile users to participate in business processes even when they are disconnected from the server.

Summary

To perform its functions, the BPM sever needs a memory that is provided by a database and an understanding of hierarchy and roles that is provided by organizational information. It also needs "senses" to be aware of what is happening in the organization. This is provided by the inputs that a BPM server receives from humans who participate in the process and the architecture that oversees it all.

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

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: 2.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.