Phil Gilbert | Perspectives in Process
Business process management requires a new set of technologies. By 2010, these will replace ERP as the primary focus of solution engineering at companies large and small. By 2020, managing process through technology will be second nature to senior executives, and the transactional systems we use today will be like mainframes. My blog talks about BPM today, tomorrow and where we'll be in 2020. Welcome.
  Home About Me About The Blog  Search  

« The Army You've Got | Main | On Technology Security Standards: BPM, SAML, XACML »

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: ,

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c6b4553ef00e54f7e70e78833

Listed below are links to weblogs that reference New BPM, or Old AppDev?:

Comments

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.

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

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.

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...

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Recent Posts

Archives

Categories

Blogroll

Etc.

    Subscribe

    Squidoo BPM Lens

Lijit Search