We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anne Stuart’s BPM in Action

Dennis Byron

In Stack vs. Non-Stack BPM, What's Best for You?

Vote 0 Votes

Scott Francis, CTO of the Austin-based business process management (BPM) consulting company bp3, has commented on my recent post redux about stacked vs. non-stacked BPM. The beginning of his comment is as follows:

"respectfully, I disagree with a few points - in particular the last one- that we should NOT compare one deal to others, one vendor to others. you asked for a bit of evidence, and now that you have it, you dismiss it, rather than entertain the possibility that it could be just the tip of the iceberg."

First I didn't say "we should NOT compare one deal to others" but that you "should not compare the IBM deal Phil (Gilbert, CTO of Lombardi) writes about with all IBM deals." You certainly should compare your IBM deal with your Lombardi deal.

But from a big picture point of view, I couldn't disagree with Scott's advice more. I never asked for a "bit of evidence." I always need a statistically signifcant amount of evidence. Be careful not to make important BPM or IT decisions for your company based on one data point, which is what Scott is urging me to do.

Not only is it one data point--or evidence as he calls it--but it is what they call on Law and Order--to keep the crime show thing going-- "hearsay evidence."

Not only is it hearsay evidence, but it's (I'm really getting into this now) evidence in a Cold Case, responding to a blog post I wrote in January or February.

Not only is it hearsay evidence, but it comes from a--I can't remember what they call it on TV -- a witness with an agenda (Phil Gilbert, the CTO of Lombardi). There's nothing wrong with Phil looking for a plea agreement of course.

And not only is it all those things, but it misses my point. I am turning myself in. I'm guilty of poor written expression.

My point is that the stacked vs non-stacked BPM debate should always be about the value of BPM to you. The stack vs non-stack BPM debate is not about arcane discussions of standards adherence, method of stack-layer integration, method of BPM-component integration, breadth and width of BPM functionality, feature knockoffs, etc. by the vendor community.

Phil's (and implicitly Scott's) argument is that the full-stack vendors such as IBM, Oracle (and I suppose Microsoft although no one ever mentions them in these debates) offer valueless BPM point products and suites because sometimes--and clearly only sometimes, probably even rarely--they price BPM either by deal or in the catalog or both as a bundle. SAP, Software Ag, TIBCO and others who offer almost complete stacks also often get lumped in this argument.

If you use one of those full stacks 'religiously,' it is more likely that you will get such an offer and that that supplier's BPM products will do a good job for you even though the products may only have 90% of the BPM features of a similar BPM suite not part of a full stack.

If you are not a 'religious' stack user or prospect, my bet is that you will not get a bundled deal proposal from a stack vendor. I don't remember if Phil Gilbert gave the details in the blog post Scott referred to but my bet that is if Lombardi lost the deal he was discussing to IBM, the guy who made the decision is one of those guys that wears Armonk Blue pajamas to bed.

Of course, if a BPM feature you need is in that 10% delta of feature differences, you have to go for the non-stack suite or a BPM point product choice or delay your project. Primarily you have to do what's right for the enterprise. In fact if you think you will ever need a feature that is in a theoretical 10% delta, you need to decide if you have enough clout with the full-stack vendor to encourage that vendor to add the feature in a future rev (that is, part of the equation is that the feature has to be there by the time you need it).

Part of the debate is that non-stack BPM suite and point product vendors will always be a step ahead of the full-stack BPM vendors in innovation. There is some merit to that. It's not logical and it is just as likely that any vendor of any type will come up with the next great BPM innovation but it's a matter of focus. The companies that are 100% in the BPM software business are more focused on BPM.

And in making the right decision for your enterprise, innovation and feature/function debates are only part of a bigger ROI/TCO exercise. In determining the value of an offer from any company, you will ask.

  • How easy or hard is it going to be to get admins and analysts for BPM product A vs. BPM Product B.

  • How easy are these BPM products to use (including training) from the point of view of the great unwashed.

  • Etc. Etc.

You know the drill.

And I have years of statistically significant data points to back up that opinion. There's no iceberg under there (can't think of crime drama quip to wrap this up).

-- Dennis Byron


| Leave a comment

Hi Dennis,

In answer to your question above: actually, no, as I said in my original blog post (Link here... You really should cross-reference blog posts you cite), it was a customer who told us this, not a prospect. We won the deal and in our post-win wrap-up they told us this. And, as I also said in a related post (Link here), this isn't one data point... ask BPM practitioners at any company where IBM has leverage and you'll probably get a similar story.

You assert that because IBM's "BPM suite" has "90%" of the functionality of the pure-plays it might be good enough BPM. But the issue of BPM isn't "functionality," it is "how the functionality manifests" so that a business user can participate, directly, in the duties of ownership of their processes. That's the big idea in BPM: direct business involvement in every aspect of their processes.

I will stipulate that IBM has workflow, rules, integrations, messaging, user interfaces, etc. etc... they have software that does everything under the sun (just search IBM's web site for 'business process management' like I did). Viewed through this primitive lens their mainframes have "90% of the functionality" of most any computer system ever built... does that mean it is "good enough BPM?" I doubt it.

The bottom line of my argument is this: regardless of what they label it, IBM does not have BPM. As I said in a comment on Scott's blog (Link here): IBM is using Websphere-based stalking horses to confuse the market into thinking they do BPM. The only other explanation is that their definition of BPM is wildly different from the pure-plays (in the same way that Orwell’s “War is peace? is wildly different from anyone else’s notion that ‘war’ and ‘peace’ are synonyms…)

So which is it, IBM? Do you not do BPM, or is your definition just very different from the pure-plays?



the crime analogies are colorful but pretty irrelevant. nothing i've read on your blog would constitute more than hearsay to me if i were the judge. and, surprising as it may be, you are not the judge, you are one of the lawyers pleading the case if you use your courtroom analogy. So if something i say (or phil says) is hearsay to you, then unsubstantiated arguments you make to the contrary must also be considered hearsay. Since we're now arguing hearsay, you might just look at which arguments make more sense.

The behaviors i ascribe to stack vendors are true, they are in line with those vendors self-interest. The behaviors you ascribe to them make them out to be above acting in their own self-interest, which to me is naive at best.

Where I do agree with you is that the decisions around buying BPM should be based on value. What you don't seem to understand or want to hear is that:
a) stack vendors will often drop their price to free for their "BPM" solutions... and
b) free is often not a good deal because the rest of the equation dominates software licensing fees (as you yourself have pointed out in other, unrelated articles...and as IBM itself has pointed out in its own research papers).

A third point that phil would make is that the stack vendors don't really offer BPM, but that wasn't the thrust of my argument (I agree, it just wasn't the point I was trying to make).



My enterprise-software blog opinions and related feature articles that have appeared here on ebizQ for the last two years on the subject of BPM and many other enterprise-software subjects have been totally unbiased and based on 40 years of statistically significant demand- and supply-side research from product, market and investment perspectives. As I said on another site on which I blog, my mission is to call out the enterprise-software vendor community on its propaganda and spinmeistering using cold, hard facts. I do this primarily in penance for the 20 years that I was a fairly successful IT propagandist.

The inexplicable multi-month drumbeat of accusations by the Lombardi folks that I am biased in favor of IBM and other so-called stack vendors would make a lot of past and present IBM, Oracle, SAP, and CA managers laugh. I am proud to say that executives at each company above (no one at Microsoft—except at the old Great Plains—even knows who I am) have tried to get my research removed from my respective employers’ websites (or CDs, or binders) at various times.

In fact pissing off some software supplier manager somewhere each year is my metric of research success. Although I can't figure out why, thanks to Lombardi, I've already met my 2009 MBO.

-- Dennis Byron

Leave a comment

Business process management and optimization -- philosophies, policies, practices, and punditry.

Anne Stuart

I am the editor of ebizQ.

Recently Commented On

Monthly Archives