New BPM, or Old AppDev?
In his recent post, Neil Ward-Dutton talks about how WebMethods customers are doing traditional application development under the guise of Business Process Management. Folks, automating a business process is NOT business process management! Sandy Kemsley says "these customers are coming from the traditional EAI-type usage of webMethods." Yep. And, in summary, Neil says:
"Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the workâis it business people, IT people or both?
"Unfortunately, getting to the bottom of things is not as simple as saying 'I need a human-centric BPMS" or "I need an integration-centric BPMS'."
Neil, you've hit the nail on the head! And, indirectly, you raised the key difference between what used to be called "the pure-play vendors" (like my company, Lombardi) and the "stack vendors" (IBM, BEA, Tibco, WebMethods). I prefer to use the terms "new-BPM" and "old-AppDev" to describe the vendors, but however you slice it, the new-BPM tooling is directly targeted at enabling new levels of participation of business people alongside IT people in the solution scoping and development processes.
As you point out, that difference has nothing to do with "human-centric," "document-centric," or "integration-centric" but whether the user is approaching use of the BPMS as a new developer tool (with, for example, the semantics of BPEL), or as a way to change the way business and IT interact during solution development. This developer-centric vs. business-centric approach is the key difference in deciding what tools you will be successful with.
Our experience is that if a company uses a BPM tool in the same old way (IT application development owning all aspects of the project and the business expected to deliver a set of detailed requirements at the outset of the project) then the project will fail exactly as often as any traditional waterfall application development effort. Which is fairly often.
But if the customer wants to move to a new model for those processes owned by the business, with the business contributing people full-time to the solution development effort, then the new BPMS tools are effective at increasing success rates, lowering costs, and delivering better solutions. The new BPMS tooling by the focused BPM vendors is better at this, far better, than any of the tooling the stack vendors provide. The old-AppDev vendors provide tools for their target market... and that is not business people with moderate technical skills. In contrast, the new-BPM vendors are focused on providing tools for a new solution development model, one that promises increased participation by the business, while retaining full-control for IT.
Technorati Tags: BPM, WebMethods


Hi Phil,Thanks for sharing the rest of the world with your knowledge & insights. As an Israeli, I wonder what part the "geography" and local mentality plays in implementing bpm + BPM approach. Here we have about 20 BPM solutions vendors but most of the organizations are not implementing the approach. Ususally the IT people are the ones to introduce it, so maybe you got one clue for the failure..as a newbie consultant I would appreciate any advise in building capabilities for offering companies a "corridor" for successful BPM implementation.
Posted by: Dafna Levy | December 05, 2007 at 01:10 AM
Phil, I couldn't agree with you more. As a pure play BPMS vendor like yourselves, we constantly need to guard against developers owning the tool and turning it into a custom development platform. We are a Microsoft .NET based product and we constantly need to remind our partners and customers that we are not Visual Studio (the proper Microsoft development suite) but a toolset for business users to deploy processes. In every project we need to remind people that we are optimizing processes and not building custom applications for cater for the shortcomings of ERPs specifically.
Those projects where IT, and specifically developers are involved, are generally challenging to say the least. They don't seem to get "process" thinking.
Well done on a post that hits the nail on the head
Posted by: Pieter van Schalkwyk | November 20, 2007 at 12:39 AM
It's true that the full-stack vendors all come from the lower end of the stack (and have more recently either acquired or built the upper BPM layers) and are therefore accustomed to selling these tools to IT as application development tools. However, in spite of the "new-BPM" desire to sell to the business, I still see a lot of the customer organizations treat this the same as the "old-AppDev" in that any major software purchase is made by IT, not by the business. In other words, it's more than just the culture and background of the vendors, it's the culture of the customers, too.
Posted by: Sandy Kemsley | November 19, 2007 at 08:13 AM
Phil, thanks for the link! I'm glad you agree with my quick'n'dirty analysis. I'm currently researching Lombardi, as well as the other leading BPM vendors, so hopefully my analyses will get less slower and cleaner as I progress...
Posted by: Neil Ward-Dutton | November 12, 2007 at 03:26 PM