Business Process Management (BPM) is a business science applied by organizations to evaluate various aspects of how work is completed. Today the term implies incorporating both technology-based and non-technology-based methods for completing that work. Some vendors also use "BPM" to describe new and/or updated products that provide automated workflow technology - for the most part within a Service-Oriented Architecture (SOA). This article discusses a decision framework for evaluating BPM technologies.

Standards-Based Computing

In the scheme of things, SOA is relatively stable and mature compared to BPM technologies. When adopting a SOA, one of the biggest questions an organization faces is whether its software development organization should support both Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) Web service models, or just standardize on one model. By standardizing on SOAP, for instance, an organization makes a makes a more or less de facto decision to support WS-* standards.

In contrast, BPM technologies attempt to support a plethora of business process standards: e.g., Business Process Modeling Notation (BPMN), Integrated Definition (IDEF), Business Process Execution Language (BPEL), Business Process Modeling Language (BPML), and Unified Modeling Language (UML). And some BPM products, in turn, support multiple standards, even though most vendors, when asked, will admit that their proprietary Application Programming Interface (API) is either more flexible or more powerful than other supported APIs. This implies that proprietary APIs have more functionality than other more standard APIs, which makes for an inconsistent application support environment.

There is nothing worse than an API that supports 90 percent of what another API supports, since automation, in many cases, favors that which can be easily automated, not necessarily that which is more important to automate. While there is no discernable consensus on the business process language supported by BPM vendors, one feature that most vendors have in common is an Interactive Development Environment (IDE) based on Eclipse - albeit their own proprietary, plug-in versions of Eclipse. (This trend has contributed to the overpopulation of installations of Eclipse on developers' desktops, but that is a discussion for another article.)

Total Distributed Services Architecture

Many organizations that have been pursuing SOA are now realizing that adopting it without including BPM is in many ways an empty strategy. It's not even really possible to calculate or talk seriously about calculating the Return on Investment (ROI) of a SOA without considering a solution for BPM in the mix.

Initially, BPEL seemed to enjoy an API standards advantage in the BPM API battle that is currently under way. This API strictly supported Web services execution, which, in effect, is a rather austere approach to a service-based architecture.

Let me explain what I mean by using an example: from a reference architecture standpoint, when Enterprise JavaBeans (EJB) were originally specified, they required that all objects be remote. As a result, however, organizations struggled with not being able to co-locate them with other processing code; the specification was eventually changed to support local EJB invocation. BPEL, in the same way, views all services as remote Web services, and this too can result in an inflexible business processing environment.

Business Process Design

To begin with, it's helpful to put down on paper the first set of composite applications you'll require that will use a BPM product, keeping in mind that all of them will eventually be made accessible and secure and be managed by the SOA infrastructure. Otherwise, you will have only half an architecture - something which, unfortunately, many organizations realize only after they have set up a center of excellence, established best practices, and then started to construct their SOA using a service bus, service registry, and a security provider to administer Web Services Security tokens.

Buying a BPM product based on the APIs it supports is really just following the masses, in that standards support is always benign. Buying a BPM product just because it supports a certain business process language is important, but other features are equally important. The evaluation process requires going back to fundamental lifecycle concepts such as business requirements, value, and productivity. Understanding these factors will help you define what type of BPM you really need.

• A highly customizable embedded workflow engine for lightweight applications that require a small footprint
  
• An orchestration engine to reengineer and transform back-office applications into new leaner processes
  
• A rapid prototyping platform for building quick, non-mission-critical workflow applications.

The Requirements Matrix

A useful construct for deciding which BPM products fit best into your SOA is to create a requirements matrix - that is, a spreadsheet. (See Table 1.) The matrix needs to be completed only after you have determined your core requirements, as is the case with any technology purchase.

The matrix represents functionality domains, such as design, ease of use, automation, analysis and optimization, report generation, repository, human workflow, monitoring and management, and the all-important product architecture. In addition, the matrix represents an aggregation of the more granular BPM functions, such as process analysis and process discovery.

It is important to point out that scoring should be applied at the function level (although there is nothing preempting you from applying it at the domain level). The weight at this level is the average weight for the domain; the rating is the aggregate rating for the domain, and the score is the aggregate score for the domain. There are other important domains that are not included in the matrix, such as corporate strategy, market share, revenue, stability of the company, and license cost (or, in the case of organizations such as Red Hat, subscriptions cost). These items are important to the overall decision and should be included in a comprehensive analysis that is interested in evaluating more than just product functionality. Effectively, they should be analyzed by either business-savvy technologists or the business executives involved with the product evaluation.

At the unit level, function points are scored by applying a weight factor to a rating (e.g., score equals weight times rating). (See Table 2.) Essentially, the weight parameter is a proxy for an organization's requirement for a specific item of BPM functionality. If design collaboration is deemed to be unimportant to the organization, then it would be assigned a low value. Statistically speaking, it is subjective.

Ratings, however, should be more objective. A rating should be assigned based on the relative strength of the product's functionality vis-à-vis the functionality of products from competing vendors. In certain system use cases, a vendor may have strong functionality in an area that is considered not important to an organization. By applying the weight factor, the score is adjusted downward, and this functionality will have nominal impact on the aggregate decision score.

The weight parameter in the matrix is used to establish the relative need or importance of a feature for a customer, based on that customer's requirements. Since the weight parameter represents a proxy for the business or technical requirements, it is important to:

• Establish function points that address the organization's processing requirements
• Identify function points that are relevant to BPM products.

Unfortunately, these applications aren't like the ones in an accounts payable system, whose functionality is relatively well-known to the business practice. Products that carry the BPM moniker range from simple frameworks that can be embedded in applications (e.g., JBoss jBPM) to what is better characterized as end-to-end, workflow applications that dictate the user interface and application deployment architecture (e.g., Oracle BPEL Process Manager).

The Big Picture

Executives who make product purchasing decisions are, in most cases, most interested in understanding the big picture. Although product evaluations can produce an overall BPM product analysis view, it is really the detail behind the analysis that is of paramount importance. Nevertheless, it is always important to summarize your findings and recommendations in one graph.

Statistical Accuracy and Product Pricing

In the IT marketplace, products are more or less heterogeneous. This fact is reflected in their disparate prices. The best way of comparing them is by estimating the implicit price of characteristics (that is, function points). One way of doing this is by using a hedonic technique.¹

The hedonic technique was developed initially for the purpose of estimating the value of quality change in consumer goods. For regression buffs, in a linear model the coefficient of the explanatory variable is interpreted as being equal to the implicit price of a characteristic (for example, built-in version control). In my opinion, the hedonic method is the best way to differentiate closely related products in a product class if you really want to evaluate the comparative implicit value of the products.

Taking a hedonic approach, the following model could be expressed in the general form as: price = f (design, usability, automation).

However, although developing a hedonic model for BPM products would be useful for predicting what you should pay for a BPM product, it probably won't work as well for deciding which product is best for your organization.

Scoring, Ranking, and Weighing

In comparison to the previously mentioned technique, the spreadsheet approach is crude, but effective. And, although tedious, assiduous attention to scoring, ranking, and applying weights to function points is important to achieve a valid outcome.

As with any process, it isn't just the outcome, though, that matters. What you learn along the way is just as important (if not moreso) to the overall project and to your organization.

During an evaluation, you will come to understand what BPM products automate, monitor, and manage - that is, what they do. As a consequence, you will learn what type of BPM product your organization really needs, based on your requirements and the relative importance of those requirements as indicated by the weight assigned to the function point.

¹ For an excellent discussion of the hedonic technique, in which a paper I co-wrote with Dr. C. Edwin Young is cited, see x2.i-dat.org/~li/course_module/space%20and%20media/objective-subjective/land.pdf.

Frank Teti is a principal architect at FTA LLC. He was formerly part of Oracle and BEA Systems SOA/BPM practices and can be reached at frank.teti.llc@gmail.com.