BPM is a discipline of business and cultural change; part of it is about technology, said an audience member, summing up the confusion.

BPM deals with problems like supply chain management, and within those problems, you may use BPM technology, responded Angel Diaz, a product marketing manager from IBM.

I would like see BPM term move back to the business and have some other term for technologies of BPM. Maybe then as vendors we might finally come to an agreement on what BPM really is, added Lombardi CTO Phil Gilbert.

Then Gilbert took his crack at a definition, terming it a methodology to get businesses to change the way they manage processes.

The challenge is that the market for BPM products isn’t IT departments, but the business organization. And on this side of the house, the customer may be quite sophisticated when it comes to articulating organizational improvement, but remain naive when it comes to judging or forming expectations regarding off-the-shelf tools.

The perception gap of course is that while virtually every vendor in the market says that they have a tool to resolve this, members of the audience termed business process management a discipline that was far too diverse for any single tool to handle.

BPM as a product category itself is quite diverse. It can extend to tools that help you model processes, along with deployment tools that help you integrate them and generate executable code. And it could extend to the Business Activity Monitoring (BAM) dashboards that track how processes are executing.

And of course, ultimately any business application could be deemed a process tool because it automates some form of business activity, and furthermore, that enterprise apps like ERP, CRM, document management, content management and BI are spawning their own flavors of what they call business process management.

Everybody is coming at BPM from their own product base, noted Scott Byrnes, a product marketing manager from Handysoft.

In other words, everything and nothing is a BPM tool.

The confusion was evident when vendors on the panel were asked their opinions on whether BPM modeling or design tools could double as RAD tools.

The confusion stems from the fact that process modeling tools are designed with the same kind of visual ease that RAD tools were for developers, and that both sets of tools are designed for generating executable code.

Furthermore, there a clear distinction between products that evolved from the document-centric workflow automation tools of a decade ago and those that have emerged as integration offerings from middle tier J2EE platform providers.

We definitely see both use cases, said David Shaffer, a product manager Oracle, who explained that in many cases this was entry level strategy that helped seed the market for BPM among its existing customer base. Sure, some people use BPM as RAD tools, responded Lombardi’s Gilbert, who countered that BPM tools make poor RAD tools because of the need to master supporting technologies or frameworks such as BPEL (Business Process Execution Language).

Our View

The BPM vendor community clearly has an identity crisis, while users of BPM tools have diverging expectations of what BPM tools can do for them.

The source of the dilemma is that the term business process is in fact quite subjective: something that you call a task, activity, or workflow might be something that I call a process. And some confuse the functions of conventional enterprise applications, like an inventory management transaction in a SAP, a full-throated process.

Compounding the issue is that, while the audience for BPM tools are supposed to be analysts, architects, or power users from the business, the highly graphical offerings that can be used to model or design processes are easily confused with RAD tools used by developers. The confusion systems from the fact that RAD tools and many BPM tools generate executable code, so at first glance the tasks that each set of tools performs are the same.

Making life more interesting is the potential synergy between BPMN, a modeling notation for business processes that has received wide vendor support, and BPEL, the web service orchestration language that is not exactly welcomed in open arms by BPM pure plays (e.g., vendors who are not IBM, BEA, Oracle, or SAP). Most BPM vendors accept BPEL grudgingly, if at all, because they feel it does not adequately represent the context of a business process.

When BPMN and BPEL first emerged several years ago, IBM’s Stephen White wrote a technical paper demonstrating a proof of concept for mapping BPMN to BPEL. BPMN was developed by the BPM community with full intention to output to an execution language. When we cornered White at the conference, we asked him how satisfied he was with the mapping, he replied that he was happy with it, but only as far as the technical capabilities of both languages would permit.

At this point, White and others within OMG (which manages BPMN) are launching a BPMN 2.0 revision that they feel would address its shortcomings in representing highly looped, recursive processes and data mappings. If and when that happens, the questions over whether you can faithfully translate a BPMN model to a BPL web services orchestration will surely flare anew.