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 BPM as Elsewhere, The PurePlay vs. Stack Provider Debate Endures

user-pic
Vote 0 Votes

Scott Francis over at bp3.com replied to my last blog post (about Appian's 2008 results). (Thanks for the comment Scott!) He was picking up on one of the questions I had asked Appian's Matt Calkins, vis a vis "Why don't you guys (Appian) see Oracle, IBM, etc. more in sales situations?"

Scott commented:

"I think the distinction "pure-play" vs. "stack" is one of focus, not feature-function. It doesn't explain Appian's comments regarding "being in the wrong place" per se, but the implicit message in being a pure-play in any particular space is that because you are more narrowly focused, you are likely to innovate faster and put all the wood behind your one arrow (to borrow from an old Sun analogy).
"More diversified vendors can provide a lot of benefits - but one thing they are unlikely to do is really pioneer a new space - or even offer the best solution in an evolving space."

I treated it as a throw-away line in the earlier post but I want to make it clear: I respectfully disagree. This pureplay vs. suite or stack provider debate is as old as the software market. I saw it in the office automation vs. word processing battles of the 1980s. I saw the same thing in the enterprise applications market in the 1990s. We are even seeing it in the social computing market today. But 30 years of information-technology-market research have not demonstrated to me any overriding trend that software companies that sell a lot of different types of software are less innovative (or pure or feature-rich) than software companies that sell only one type of software.

You might want to deal with a smaller BPM (or ERP or enterprise application or collaborative computing) software company because you feel it provides more individualized attention or has exactly the functionality you need or knows your industry better or (a lot of other good reasons). But don't do it because of the pure-play argument.

What do you think? Send an email or leave a comment below.

(Scott concluded as follows:

"And they prove this out, often, by giving away the new software (whenever a commercial software company is giving software away, I think your alarm bells should be going off - sometimes "free" is the gift that keeps on giving!)"

I am not sure what freeware (or open source software) he is referring to in this sentence. But I wanted to show his whole comment so as not to break the context.)

-- Dennis Byron

4 Comments

| Leave a comment

His (Scott Francis') argument is missing some history. Most of the stack BPM tools are former pure plays that were purchased by the mega vendors. Does that all of the sudden make them less innovative?

What he might be referring to on the "give away" comment is that if you are buying other stack components, the stack vendor can afford to offer huge discounts on the BPM tool that a pure player couldn't compete with.

-- Good points, both. Thanks Mike-- Dennis

@mike : correct, i was referring to the give away of components that stack vendors do with various offerings - buy the database, get the XYZ for free! (that usually means they're not investing in the XYZ product... so your odds of having it be a market leader going forward are low). Pay attention to what a vendor actually charges you for - those are the areas their CEO and CFO are going to pump money into. The stuff they don't charge you for - it will whither on the vine (in general). yes there are exceptions of course.

Dennis, I think there *is* a real difference between most of the stack vendors and the pure plays, and it revolves around the stack vendors' SOA focus. This means they treat BPM as primarily service orchestration, and human interaction as a type of service. This is a "bottom up" integration focus, that constructs the process by stringing together a collection of services, and it is in danger of becoming hostage to the timing and architecture considerations of a SOA initiative at a customer (lessening agility and moving the process focus to IT refactoring or application normalization efforts). BPM may also be hostage to waterfall development methodologies and absolute separation of layers, both offered as best practice by the stack vendors (lessening agility because it does not provide quick iterations and uses too many tools and environments to be easily changed).

The fact that the stack vendors acquired pureplays does, in the short term, mean that you can play it both ways - get the financial security of a stack player and the previous innovation of the pureplay - but it also introduces a real problem... the roadmap after acquisition is usually all about integrating with the stack vendors' product stack, rather than developing NEW features.

This is absolutely what happened to each of the BPM vendors that has been acquired (the people I know at each of them confirm it). If we go back and use word processing as an example. Back in the day, this space was pioneered by small companies (Microsoft was small back then too, btw), and eventually won by the biggest of them (Microsoft). But the biggest software vendor (BY FAR) at the time, was IBM. they just weren't a player at all in word processing. They acquired lotus for its app suite and lotus notes... and where is IBM today in word processing? nowhere. So, it isn't to say that a big vendor won't win a space. It is just that you won't see the most innovation from the big stack vendors - you'll see the value of consolidation there instead.

So when the BPM innovation curve slows down, someone will win or will have won the space (or, like the EAI space, several large software companies will have taken all the oxygen out of the room). Social networking... you don't see evidence that myspace is now less innovative than facebook, since being acquired by the News Media empire? Or that wikipedia has done a better job in their space than google (knol anyone?) ? It isn't that big companies don't innovate - IBM is good evidence with all their patent filings. But the ability to get those innovations to market is impeded by all kinds of bureaucracy - lining up with major product releases, getting the attention of marketing, getting funding from a CFO who may not understand why they're funding something that is essentially a giveaway on their licensing agreements... Did Tivoli "innovate" more before or after IBM bought them? doesn't mean Tivoli wasn't more successful with IBM, but I think if you asked the people who worked for Tivoli, they'd tell you most of the innovation happened before acquisition. The big innovation AFTER acquisition was to figure out how to plug it into IBM's vast and effective sales force (sales went from about 100M a year to 750M a year in very quick order back in the 90's... )

I know it was a throw away line, but I'm surprised you disagree :) Go to starbucks. How good are their pastries? Now, try going to the local pastry shop, like "sweetish hill" in Austin. Its AMAZINGLY better... but the coffee is just okay. The examples are everywhere. It isn't a necessary side-effect of being big, but the anecdotal evidence is everywhere.

THANKS FOR THE COMMENT SCOTT. WITH THE VARIOUS COMMENTS ON THIS POST, I GUESS I'VE HIT A NERVE HERE SO MORE TO COME. THANKS EVERYBODY--DENNIS

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

Blogs

ADVERTISEMENT