Business Intellegence

BPM Architecture Considerations

Introduction

This paper outlines three sets of key architecture considerations required for a successful configuration of an enterprise Business Process Management (BPM) implementation and deployment. These considerations are:

• Deployment Environments
• Architecture Options
• Hardware and Database Sizing

In addition to architecture considerations, another important success criteria for BPM implantations is ensuring the organization’s IT group be involved in the early stages of the BPM tool selection process. This is due to the fact that many decisions made and issues uncovered in early stages will have long-term consequences and will be much more difficult to resolve after the BPM tool has already been selected. When IT is involved at the early stage, there is a much better opportunity for ensuring balance between both business and technology factors.

I. Deployment Environments

Although this issue may seem obvious for any software deployment, it is important nonetheless to address how the BPM architecture will be configured in order to get out of the way any preconceived ideas. Typically there are four distinct (yet related) environments that need to be configured during the course of a BPM implementation. These environments are:

• Development: This is used primarily for developing the BPM solutions. All the unit tests, bug fixes, and R&D type of work is done on the Development (or Dev) environment. This environment is not as robust as the others. Sometimes, the Dev environment may end up being the developers and analysts workstations depending on the type of BPM tool selected as outlined in subsequent sections.
• Test/QA: The environment is used primarily for deployment of solutions for testing the features and overall functionality and user-acceptance of solutions. There is no development taking place on the Test/QA environment. Sometimes this environment is as robust as the Staging and/or Production environments.
• Staging/QA: Depending on the IT infrastructure and governance, this environment is a duplicate of the Production and/or Test environments. This environment may be considered optional depending on the scope of the implementation.
• Production: This environment will be used primarily as a live environment. The final, time-stamped solution is deployed to Production.

There are subtle differences in the way the #3 and #4 environments above are configured. Each will have its own architecture options and sizing as discussed in the next sections.

II. Architecture Options

Depending on the BPM tool selected, there multiple architecture options to be considered. Below we have identified the four most commonly used options and typically most appropriate for BPM implementation. The selection of these options for each environment depends on different factors such as existing IT infrastructure, budget, and solutions to be deployed.

• Single-tiered or Standalone: This option provides a single and simple deployment for all the BPM components (BPM Engine, Application Server, and Database Repository) on a single machine. In addition, this option provides a simple administration, less overhead, and limited transactional capabilities. This option is for simple to moderate BPM deployments.
• Double-tiered: This option provides a two-tiered architecture deployment where on the one hand, the BPM engine and the App Server are installed on one server and on the other hand the database repository is installed on another server. This usually happens when the IT infrastructure already has some database instances that can be leveraged. This is a mid-level architecture option where there is a little more overhead and more transactional capabilities. This option is for moderate BPM deployments.
• Three-tiered: This option provided dedicated services for all BPM components. In addition, this option provides more complex deployment and administration; there is much more overhead but it is scalable.
• Multi-tiered: This is the most complex architecture where BPM components are divided into multiple dedicated servers for large-scale BPM deployments in an established IT infrastructure that includes clustering, load-balancing, and/or fail-over.

III. Hardware and Database Sizing

In addition to the architecture options, other considerations for architecting a BPM solution relate to calculating and estimating hardware and database sizing. These considerations are:

• Number of Process Instances per Year/Month/Week/Day
• Number of Users
• Number of Participants per Process Instance
• Number of Activities per Process
• Number of Attachments per Process
• Number of Notes per Process
• Third-party systems that will integrate with the BPM Engine (including identity management, enterprise content management, portal for displaying work lists)
• Benchmark Test results
• Vendor experience with other customers who have implemented similar architectures
• Current IT infrastructure

The considerations above relating to specific quantities directly relate to hardware performance – the more users and process instances involved, the greater the computing capacity is for the BPM Engine orchestrating the process. The benchmark results will determine the hardware (CPU, Memory and Hard Disk) and database sizing recommendations for the BPM tool.

---------------------------------------------

The author, Mukanda Mbualungu, is the Technical Director for SRA's Business Process Management Group (http://www.sra.com/bpm)