Don’t ask me how, but Ismael turned the hubbub over BPM vs SOA into a discussion of top-down vs “middle-out.” Both threads (including comments) are semi-instructive, but somehow in the course of things he challenged me to come up with proof that top-down (i.e. BPM implementation driven from the business model) has ever worked. The challenge came in the form of a double-dog dare, with the promise of a trip to Hawaii tacked on if I could come up with 3 top-down implementations that met his “BPM 2.0” qualifiiers. Doubting he was good for the Maui deal, I reduced it to a simple dinner bet, so now we both have some skin in the game.
Here are the ground rules:
- Significant-enough project (the process map has more than 100 steps)
- Integration with transactional systems through WSDL
- Human workflow through web-based interfaces
- Modeling and skeleton design done by process analysts* using BPMN
- Implementation done by IT people without writing code
- No technical support from the BPM vendor through executable design and deployment. [He doesn’t say into production, just deployment.]
* process analyst defined as: “cannot explain the difference between DO-WHILE, WHILE-DO, and FOR-EACH loops, even when promised a free trip to Hawaii with friends and family.”
I’m hoping some BPMS Watch readers will come to my defense on this one, most likely vendors supporting BPMN, but user organizations who raise their hand would be even better. I need 3 to win the bet. We haven’t set a deadline yet. You will be lavishly praised in the blogosphere and in the real world as well for proving that BPMS actually does what it says!
[…] Bruce and Ismael have a bet on over whether a top down approach to BPM has ever worked. Anyone out there working on BPM or BPMS should check out Bruce’s post here and help him out! Technorati Tags: BPM, bpms, BPM 2.0LicenseThis work is published under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. […]
Hi Bruce,
Goodness sake, what a ridiculous set of rules. You got hoodwinked by acepting the premise of a poorly asked question (actually, if you are promoting a certain agenda, then I guess the ground rules make sense… too bad that agenda has nothing to do with business or management).
OK, throw out the following 2 things: first, that you have to use WSDL and web services. If you talk to any business person they don’t care what the implementation is. You must throw out the WSDL requirement or else you’ve inserted hard core IT (to develop the service) into the mix. So how about this, “don’t worry about the underlying integration” as a requirement? Let’s just use the “integration mechanism that results in most favorable short and long term business benefit” without specifying a one-size-fits-all answer.
And throw out this dumb statement: Implementation done by IT people wthout writing code. What does this have to do with “top-down” vs. Ismael’s “inside-outside-3-seconds-in-the-paint” criteria. A mission critical process involving 100 steps will require some hard technical work… no question. The state of computing today just requires it. But whether the DIRECTIVES are coming from top-down – and the IT roadmap is being driven by top-down, business-defined goals and metrics is the key. BPM is NOT about “business people writing applications with no code.” Let’s call that, um, Notes or Excel or even SocialText. And you know where that’s gotten us.
Business Process Management is about busines people managing their processes better and aligning all the assets at their disposal (including those pesky programmers Ismael is apparently afraid of but yet embraces them with his BPEL schtick) so that their business is more competitive. What it is not about is defining dogmatic technical hurdles along that road.
So let’s change that requirement to: IT’s initiatives (whether building out their SOA or whatever) are governed by and aligned with the business’s use of the BPM tools and methodologies so that the MINIMUM IT effort is required to solve any particular problem (common services are discovered and used where appropriate, and new coding is justified by the BPM-based business plan).
In that case, we have a stable of customers who would be happy to talk to other BPM prospects about this. In fact they do, every day in reference calls etc. Without naming names, I’ll list three:
1) An online, hosted content provider who manages the content delivery from multiple sources to multiple destinations, allowing for routing of work to content editors, etc, prior to distribution. Top-down from CEO. Process analyst who has spoken at conferences about this.
2) A Fortune 150 company who needed to radically alter the way it was managing its end-to-end business in their most profitable division… NO execution was done up front, just a process layer maintaining state among a dozen or so legacy systems… and then over the past 2 years added improvements in the BPM execution environment… this was really “management of business processes.” Top down.. from CEO, CFO and CIO of the division.
3) Large health provider who is competing in a crowded space in Florida. Needed to improve employee issues while also dealing with regulatory requirements in the onboarding process (and offboarding). Dealing with nurses, doctors and such. CEO of health chain, and driven by CIO. Very top down. Tying results to metrics (i.e. really managing processes) was the key.
Bruce, I could literally go on and on. The thing about most BPMS providers is that they are so hell-bent on the technology of executing and orchestrating and BPEL and WSDL and worrying about what to call a process analyst instead of a business analyst or business technologist or STOP!
Those people and companies (including, but not limited to some BPM vendors) that are focused on the management of business processes – and everything that implies (including execution, because you have to do that too) – will be more likely to succeed than those who are focused on the technical requirements of what language you use and who does what with which tool. If you focus on the management and business parts of BPM, you will probably have many, many top-down success stories. And these stories will also have business results like this: in a shareholders’ meeting in 2005, a CIO of a customer was specifically called out for applause because a [Lombardi-based] set of processes had directly led to a reduction in working capital requirements of $250 million (on $3.2 billion of sales). Three years earlier: $400 million tied up in WC… now it’s less than $150m. Now that’s BPM! (PS – not one web service was injured in the making of that process, either)
If you go top-down, you will focus on the important bits.
Please send me a picture of Ismael paying the check 🙂
Phil
Phil,
I agree the rules strayed a bit from the issue of top-down. Actually the BPMN part seemed the most arbitrary to me, since only a few BPMS today use it. I was hoping Lombardi, BEA, Savvion, Cordys etc would come through. I’m still optimistic.
If you follow the thread on his site, you’ll see we haggled over the WSDL piece, but it was restricted to integration steps (e.g. not human tasks, business rules, etc)… and after all, the original piece that got this started was specifically about SOA and BPM, so I went along with it.
The second one – implementation without code – has nothing to do with top-down either, I agree, but it’s part of the BPM 2.0 idea both Ismael and I have been promoting (and I know how much you love anything 2.0!!), so I’m kind of sandbagged there. I would say Java or C# is code, XML is not really code.
So… Lombardi has BPMN, maybe can squeeze in under the clarified WSDL and no-code parameters. I don’t need 3 from you… just one would do.
is javascript “code”? if not, then #2 above qualifies. and we have many others (the other 2 listed use *gasp* non-web-service interfaces). the problem isn’t with BPM, it’s with the sophomoric notion that web services are somehow a superior way to integrate in _all_ situations… and that isn’t the case. if you drop the WS-* requirement, then all three above.
BPM is about the business. Us vendors should not be dictating the parameters under which solutions are _implemented_ in order to “qualify” as a BPM project.
In the same way that some vendors try to push their technology as “standards” we should also be wary of vendors who push their definitions of acceptable implementations as benchmarks.
[…] Last week, I challenged my friend and industry analyst Bruce Silver to point me to a BPM vendor that could identify three customers who successfully managed to use its product to build a complex business process that would leverge a Service Oriented Architecture, and managed to do it without writing code and with no technical support from the vendor. If you read the comments that followed Bruce’s post on the challenge, it looks like not all BPM vendors like the idea. I’ll be honest with you, this did not really come as a surprise. […]
[…] You may recall my dinner bet with Ismael last month. He bet I couldn’t find 3 BPM implementations that met the following criteria: […]