Found another interesting and thoughtful discussion of terminology: Workflow or Process Management. I like the six sided cube analogy, and I agree that BPM includes all those aspects. In this view again “workflow” is equated with the human dimension. The only critique I have of the post is: once you include all 6 facets, is there anything in the technical universe that is NOT BPM? This is then simplified to “Automate, Integrate, and Manage” which is similarly all encompassing.

I liked Phil Gilbert’s summary of the BPM Thinktank: It’s The People, Stupid! Phil’s point is that technology (and related standards) is not the key factor in business process management success, but rather the people implementing it. So, BPM is not “Fire and Forget”. (Sorry Phil, another military metaphor. 🙂 )

Without the human dimension, then what is “BPM” anyway? How can one claim the “B” part BPM without workflow? And thus we spiral to a rathole of circular logic.

It seems to me that this particular rathole is a consequence of attempting to define BPM by the things that compose it. This reductionist thinking is natural in high tech circles, especially those with a training in standard programming languages. (Myself included.)

Alternately we take a more holistic view and define BPM/workflow by the results that it produces: organizations that work more effectively and more efficiently; supporting people working in a more coordinated manner. This is similarly useless because essentially anything can be part of making an organization more efficient. For example, pencil and paper fall into this category.

Perhaps the best approach is to define BPM/workflow by what it is not. Clearly it is information technology, and does not move anything physical. It should be something beyond simple programming, so it is not a 3GL like Java, VB, or C++. It is not the storage or retrieval of data or documents because that is handled by databases and document management facilities. It is not basic communications protocols, because that is provided by TCP/IP and more increasingly things known as SOAP and WebServices.

Once you have removed all of the things that are not BPM, what is left? BPM/workflow is a philosophical approach to producing applications that allow people to work in a more coordinated manner. That approach starts with a model, but not just any model: it must be a model of the business aspects of the organization that will use it. The model must be time-aware in a way that standard programming models are not: it represents not only transactions that take time, but it must represent concepts of deadlines that are relevant to people and legal agreements. The model must be useful to business people both in training, understanding current status, and agility. A BPMS should have connectivity to components outside of itself, and those components should not be considered part of the BPM/workflow. These are all things that BPM/workflow uniquely adds to the approach to application development, that are not available in a non-BPM development environment.

The above definition is consistent with Bruce Silver’s comments in The Phony “War” Between BPM and SOA. I completely agree with Bruce that BPM and SOA are natural allies, not enemies. SOA is quite simply about how you structure your enterprise application, and that you use open standard protocols to link the pieces. SOA says nothing about having a business-relevant model, or which philosophical approach you take to building your application. SOA is another one of those things that BPM is not. Yet, BPM and SOA are perfectly compatible for developing applications that help people to coordinate their work and make their organization more efficient and effective.