BPM testing & validation: How & Why?

BPM (Business Process Management) practices are becoming ubiquitous in the enterprise environment, just like SOA as a strategy for assembling the technologies that support business. Quite simply, the goal of any advanced enterprise application team is to get to a point where the business can manage its process, as it is executed in the software they and their customers use every day.

Enterprises are selecting from two options to enable their teams to define and assemble business processes:

1. Working with the BPM frameworks provided by their selected integration or platform vendors. These may include tools from TIBCO, SoftwareAG/webMethods, SAP, Oracle/BEA, Progress, IBM and Microsoft.

2. Using a "pure-play" BPM tool atop their architecture to model processes. There are several solutions in this category, including Appian, BEA Fuego, Cordys, Global360, Lombardi, Metasystem, Pegasystems, Savvion and SOA Software.

In either case, the company is hoping to achieve a high level of reliability in the orchestrated business processes, to instill trust that the intended business outcome will actually happen. This trust requires making the leap into validating not just the logic of the business process, but all of the underlying technologies and components that must support BPM.

We've seen a lot of activity in this space, especially over the past year, as companies move from pure integration to BPM orchestration initiatives. Our recommendations for ensuring quality and reliable outcomes usually revolve around orchestrating BPM testing and validation both from a "top-down" business process view, and a "bottom-up" technology component view.

Let's take a look at a typical business process for an Order Management application and simplify it to three levels. You have the BPM team that is defining the overall process, the Integration team that is assembling workflows that support the process, and the individual delivery teams that are programming or offering Component-level services that are assembled within the workflows (that support the BPM-defined processes).

The component-level teams provide tests that bubble up to the Integration team as they assemble the services into a Workflow that conducts one aspect of the BPM process, for instance a service that pulls in the Product Data into the workflow of "Place Order." Then the Integration team conducts their own tests of "Place Order," which become part of the validation process for broader testing at the BPM level of "Order Acquisition."

"Top Down" view: The guys at the top of the stack who are using BPM tools cannot possibly be expected to understand the issues and interactions that are happening at the Integration and Component levels. But they do need to know when an issue arises in their business process as it changes, and be able to report it to the teams who are responsible for delivering the underlying logic. They need to take the effort to Validate their business processes, and trust that the underlying delivery teams have done so at their own level.

"Bottom Up" view: The key here is to sign up each team for delivering a set of tests as they contribute technology components or Services into the Workflows that are assembled by Integration teams. Integration teams can take those component tests as "test harnesses" that describe what each component should do, and then tie them together as they are doing integration to provide proof that the expected workflow is valid when it is assembled from underlying components.

The key here, no matter what tools you use, is to validate business processes with tests that incorporate all of the validations that were conducted at the contributing integration and technology layers. This is the only way that you can trust that the expected business outcomes will happen, and trace the root cause of an issue at the underlying layers where the actual business logic and transactions occur.

Of course we have written and developed quite a bit around BPM testing & validation in this regard. We invite your comments on the challenges or techniques you have discovered on your own journey toward BPM in today's IT environment.

Comments

[Scott Francis]

Jason-
good post, and you've done a good job representing why testing and quality matter for BPM, as well as why it is a challenge to do right. At BP-3 we're always interested in improving on the work we do, definitely interested in hearing more about how iTKO fits in...

scott