The webMethods Proof of Concept By Dan Green

---

Introduction

The webMethods Proof of Concept (POC) is a new customer rite of passage; hard work and determination fuse to produce a workable webMethods solution. But, just because the solution works doesn't mean that the project should be considered a success.

In fact, Proof of Concept projects can be the most debilitating projects that a webMethods customer ever pursues. By encouraging short-sightedness and abandoning development methodologies, Proof of Concept projects can kill an entire corporate Business Integration strategy.

---

Proof of Concept Hypotheses

"Proof of Concept" projects demonstrate software capabilities as they apply to a particular business problem. Alternatively, known as "Pilot Projects", POCs aim to prove a specific hypothesis.

An example of a Proof of Concept hypothesis is:

The webMethods Platform can be deployed to synchronize databases in multiple data centers.

Proof of Concept projects test hypotheses about the webMethods Platform while answering specific questions such as:

• Can the corporate network handle high-volume transactions?
• Can the webMethods Platform process 10,000 transactions per second?
• Can 10 MB of XML documents be batch-processed in less than 10 minutes?
• Can customer data be synchronized across databases worldwide?
• Can the reusability of code be increased using the webMethods Platform?
• Can time-to-market be decreased using the webMethods Platform?

It is only after the hypotheses are tested that a corporation can understand the limits of the webMethods Platform as it applies to their particular business problem. This knowledge is the first step in building a sound corporate Business Integration policy.

---

Anatomy of a Proof of Concept

A main selling point of the webMethods Platform is its strength in aiding enterprise-wide integration. Because we use the term enterprise-wide, it can be concluded that the corporate purchase of the webMethods Platform is not departmental. That is, key executives with enterprise-wide leadership often authorize the software's purchase. These executives become known as the "webMethods corporate sponsors".

The webMethods corporate sponsors face competing priorities. On the one hand, they seek to test hypotheses. On the other hand, they seek to justify the software purchase. In both cases, however, they want to do it quickly.

Shortly after finalizing the purchase, the corporate sponsors set into motion a Proof of Concept project.

The anatomy of a Proof of Concept project is three main pieces:

1. Identification of a business problem
2. Identification of success criteria
3. Development and deployment of business problem solution

For most corporations, an appropriate business problem is pre-defined. For example, if the corporation specifically purchased the webMethods Platform because of its guaranteed database synchronization capabilities, this will be the selected POC business problem.

Measuring the success of the Proof of Concept project, however, is not as easily identified.

As the measurement tool by which a POC's effectiveness is gauged, success criteria may take days to fully define. Success criteria may include metrics such as:

• Processes 200 XML documents per second
• Deploys within existing corporate migration strategy
• Completes transaction in less than .5 seconds
• Accepts new trading partner data via Web page
• Sends inventory control list to WAP-enabled PDAs

And so, with a business problem and success criteria defined, the third phase of the Proof of Concept begins -- development and deployment of a solution. This phase carries its own challenges and the remainder of this article discusses how careful attention to steps 1 and 2 above can ensure a smooth project execution.

---

[1]  2  3  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums