Where does Business Process fit?

According to Paul Harmon, Executive Editor/Analyst at Business Process Trends, it's not unusual for Six Sigma teams inside an enterprise to be using a different set of business process software tools than those used by business process redesign groups, architecture teams, or IT analysts. In fact, quite the contrary is often the case. As explained by Paul Harmon in his article Building Bridges for Interoperability, "It's common that a single IT group uses several different business process tools."

To help alleviate some of the confusion caused by a single enterprise using multiple products in the same functional space, the Object Management Group (OMG) has embarked on a comprehensive effort to create business process standards that would allow different tools from different vendors to share models that describe the key elements of any specific business process model as well as relationships among those elements. OMG is not only pursuing a generic business process metamodel, but also an organizational metamodel, an ontology metamodel, and a business rules metamodel. As you might suspect, it's probably going to take a fair amount of time before a bunch of vendors from all over the world are going to all agree on just what should be included in all these metamodels.

Meanwhile, Proforma, a leading business process modeling vendor, decided to go off on its own and work with a number of leading BPM Suite vendors to build an interoperability bridge that would enable users of different tools to easily exchange, or migrate, their models across multiple different products based on a Common Interchange Format (CIF). The consortium created by Proforma currently includes: Appian, CommerceQuest, Fuego, Fujitsu, Insession Technologies, Lombardi Software, Metastorm, Pegasystems, and Savvion.

---

Let me digress for a moment...

What we have here is a classic example of why it's so vitally important to have an easy way to cluster similar products close together. How can someone look at a list of tools, like what's listed above, and determine that different products deliver overlapping functionality? It's certainly not possible to tell by just looking at the names. It's the job of technology architecture to indicate what tools are alike.

In Technology Architecture, 3-Layers, 4-Models, the category "BPM Suites" falls under the category "Application Integration" which itself fits under the category "Middleware" within the "IT Infrastructure" model.

[See IT Infrastructure.]

---

Actually, Proforma's ProVision is not itself a BPM Suite. Rather, it's a business process modeling tool. As Paul Harmon points out, BP Modeling tools are relatively inexpensive software products used by business managers, Six Sigma, and BP redesign teams when they analyze and redesign business processes. BPM Suites, on the other hand, are relatively more expensive, and are used by IT groups to create systems that can manage the runtime execution of business processes that include both automated and manual activities.

---

Digressing again...

If we look at Technology Architecture, 3-Layers, 4-Models, "Business Process Modeling" falls under the "Life Cycle" category called "Design" within the "Application Development" model.

[See Application Development.]

---

BP Modeling tools have been around for many years now. BPM Suites, on the other hand, represent a relatively new class of software products. The heart of most business process modeling tools is providing, at design time, an easy-to-use, highly-visual, end-user-oriented method for graphically depicting a business process in such a way that a business manager can readily understand, and then confirm or correct, how a workflow is supposed to work. On the other hand, BPM engines which sit at the heart of BPM Suites, are responsible for managing workflow execution and application integration at runtime.

---

One final comment...

You do NOT want to be comparing apples and oranges. BP Modeling Tools and BPM Suites respectively represent fundamentally different product categories. Make certain your technology architecture differentiates between them.

---