Appian is again taking shots at others’ acquisitions from the sidelines in “Another Monster is Born”:

Bigamy is one analogy for what’s happening in the stack vendor land-grab for the BPM market. Another is “Frankenstein’s Monster.” And we all know how that played out…for the Monster and the townsfolk.

That’s only the beginning.  Appian is not impressed with OpenText’s acquisition of Global 360.  Frankly, I’m surprised they reacted at all (were they really competing that often with Global 360 or OpenText?)  But here’s a statement I strongly agree with:

BPM is not yet commoditized for the simple reason that BPM is not yet done evolving. Perhaps more than any other enterprise IT market right now, BPM is in a process (no pun intended) of innovation. BPM software is just now learning how to reach more people, drive more value and truly transform a business. Cloud BPM is driving a growing percentage of the market. Mobility has entered the game, as has social technology. This market is not yet complete.

In fact, there are other areas in which BPM is learning to reach more people and incorporate more mature technologies, as well as emerging tech.  But cloud and mobile are certain two big trends to watch (and, to Appian’s credit, two trends they bet on early… compared to other BPM vendors at least).  BPM is not yet commoditized.  But the demand is growing faster than the independents could satisfy it – faster than they could build their sales channels and development teams.  So it looks to me like a lot of interesting innovation will happen in pure plays or niche plays, but that bigger vendors are likely to acquire and incorporate those innovations (hopefully, not destroying them in the process). The question is, can BPM reach its true potential without the deep pockets of public market money or big company R&D?

But leave it to Appian to misunderstand what some of its competition are up to:

It seems to me that all the mega-vendors think BPM is simply a commodity. The mentality is that the more BPM technology you can acquire, the better; loosely stitching them together to create a creature that will succeed through sheer mass. OpenText is the latest example, but look at IBM, Oracle, Progress, etc.

I can’t speak to whether OpenText views BPM as “simply a commodity”.  However, I have some personal knowledge about Oracle, Progress, and IBM.  Oracle: guilty as charged.  They have a BPM strategy but it doesn’t feel like they are putting the gravitas behind it.  Ditto for SAP.  Progress has made BPM (aka RPM) the center of a coherent go-to-market strategy.  When a company reshapes their value proposition with BPM at the heart of it, I hardly call that treating it as a commodity or trying to succeed through sheer mass.  There are legitimate criticisms of the Progress approach, but they have brought together sound technical solutions across a range of product areas that pure plays don’t play in, and they’ve found a way to get behind a process vision for that.

Finally, looking at IBM – Appian is sadly mistaken if they think IBM looks at BPM as a simple commodity that it need not worry about.  Anyone attending IBM Impact in May can see how seriously IBM is taking BPM.  IBM’s customers and partners are taking it equally seriously.  In the very last session of the day on the third day of the conference, our own session at Impact was full to overflowing – as were nearly all the BPM sessions at Impact all week long.  IBM is hearing the message, and the investment in rationalizing their products into a much improved BPM offering is quite obvious to see for those of us in the trenches.

The concept of “Dynamic BPM”, when explained, is certainly useful.  But I’m not much of a fan of the term itself.  First, it is yet another buzzword that means whatever the vendor du jour says it means.  So all the vendors immediately do “Dynamic BPM” and incorporate it into their messaging.  IBM says that they do “Dynamic BPM” by automatically configuring the process in real-time (or read their own words here).  Oracle says they do “Dynamic BPM” by incorporating rules-driven process flows, dynamic service binding, and task management.  At recent BPM conferences, Dynamic BPM has been used to refer to “knowledge worker processes” or pieces of the process that can not be well-defined in advance (Anatoly Belychook’s blog describes this interpretation quite well, as well as a couple of useful design patterns within it).

Here’s where I see problems:

1. This name “Dynamic BPM” doesn’t really mean anything – each vendor can make up a definition that suits their software, or their competitive positioning needs in current sales cycles.  This just extends the already ambiguous use of the term “BPM”.
2. IBM’s notion of “dynamic” is really more about configuring the process based on early inputs to the process instance about its requirements.  A process that can’t do this doesn’t seem worth much to me.  BPM tools have been doing this sort of thing (in abstract) for at least 7 years.  However, they do have some technology to handle more complex factors (especially with respect to health care related industries).  My favorite part about IBM’s description of “previous BPM solutions” is that they “weren’t designed with agility and dynamicity [sic] in mind”.  That’s the kind of presumption you hear from someone writing product marketing content who hasn’t worked with those “previous BPM solutions” in the field (which, I can assure you, were often designed to be agile and dynamic).
3. Oracle seems to think if you have rules then you have “dynamic BPM”.  Last I checked, rules aren’t the future of BPM, rules have been around for decades as a business-enabling technology.  Applying rules to BPM isn’t exactly a new idea.  Just ask any of the former rules vendors, or Pega.
4. Dynamic BPM as a substitute name for “unstructured process” or unstructured subprocesses is more along the lines of Anatoly’s blog.  Its also the positioning of ActionBase and a few other vendors.  The issue here isn’t a “can you or can’t you” model unstructured process as part of an overall structured process – the question is how much does the BPM vendor’s software help you model or execute such processes.  Some BPM solutions help quite a bit (e.g. ActionBase), some help a little, some just don’t get in the way, and some don’t allow for this style of subprocess at all.

I think BPM Vendors need to keep focused on what their products do for business. A term like “Dynamic BPM” doesn’t tell me anything about what this feature or product will do for my business.  That’s not a surprise when the tail is wagging the dog (selling software to IT with IT benefits, rather than selling IT to business with business benefits).  Let’s drop the IT buzzword bingo and focus on what the business needs, shall we?

The News

So Oracle just bought Sun.  I didn’t think this had any real bearing on the BPM market because I couldn’t think of any BPM software that Sun has been pushing.  Dennis Byron of ebizQ confirms in his article “Does Oracle/Sun Mean It’s a Horse Race for BPM?” (registration required but it’s painless, I assure you), that Sun has already pretty well “de-emphasized the BPM-related elements in the remnants of SeeBeyond, which it acquired in 2005.” The only impact I expect the acquisition to have on BPM is that it assures that Oracle’s thought leaders will be spread even more thinly as they work hard to incorporate Sun’s many software offerings, not to mention as they try to figure out the hardware business for the first time.  BPM is such a small part of what Oracle does now, that it is hard to imagine it won’t get starved for attention inside the walls of Oracle.

The Background

This is an argument I’ve been having on-and-off with Dennis Byron of ebizQ this year, and in a  previous post on the subject,  I summarized my arguments that had been scattered across a few posts on Dennis Byron’s blog.  Dennis largely took the side of the big stack vendors, arguing that they innovate as much as the little guys (in general, and in BPM).  I took the general point of view that while stack vendors bring advantages to the table, innovation is not chief among those advantages, and that the innovation in the BPM space (and in most spaces) comes from the upstarts and smaller companies.

From the Analysts’ Mouths to…

Well, not that Gartner is the final word on everything, but their statements over the last 4 years are pretty illuminating, from my perspective (thanks to the folks at the Lombardi partner conference for bringing these front of mind):

Gartner, 2005: “Current offerings from IBM, Microsoft, Oracle and SAP provide weaker support for human workflow patterns integrated into a broader process, business-user-oriented rule definition and maintenance (for decisions, re-sourcing and flows), human collaboration, and integrated document and content flow, compared with popular pure-play vendor products [...]” – “Business Process Management: Act Strategically and Buy Tactically”, Gartner Group, June 21, 2005.

In other words, in summer of 2005, the assessment was that the stack vendors just “weren’t there yet”.  But the prevailing view was that if we just gave them another 18-24 months they’d get there.  Even the pure play vendors themselves worried greatly about growing as fast as possible during this “window of opportunity” while the stack vendors were playing catch up.

But, in 2007, what did Gartner have to say? Paraphrasing, their 2007 report noted that none of the stack vendors had a good, integrated experience for people playing a role in process improvement life cycles.  They specifically called out IBM, SAP, and Oracle on this.

Again, everyone thought, if we just wait 18-24 months, these guys will catch up.  The analysts would say it, the stack vendors said it, the pure play vendors again attacked their “window of opportunity”, worried about what would happen in 2 years when the stack vendors “caught up”.

And then in 2009,

“Products from IBM, Oracle and SAP do not yet address the ideal BPMS use case – even in vision – and this can’t be overcome by sheer marketing and sales. “ – Gartner BPMS Magic Quadrant, 2009.

Side Note: Examples of the marketing are everywhere, such as the SAP/Aris positioning here… I’m not sure if the use of punctuation and capitalization are supposed to lend credibility to the offering or just make it harder for spellchecker to check your work… but Chemical.PerformanceREADY as a product name doesn’t give me a feel-good that SAP and Aris have really gone deep in the chemical business and committed to it – the name doesn’t identify what processes are covered, and is so vague that the definition of the product could be that it runs my whole business or that it runs a background check (HR) process tuned to the chemical business.  And there’s a neat set of concentric circles that try to make standard SAP implementation sound easy.  But, having said that, at least the Aris division of SAP is beating the BPM drum whole-heartedly, which is more than we can say for most BPM-related software packages acquired by stack vendors.

So, essentially we have 4 years of reports on BPMS, and the “stack vendors” still haven’t provided a unified BPMS that really addresses the use cases that pure play vendors address. Meanwhile, pureplay vendors have shown a lot of innovation in terms of deployment scenarios (hosted, on premise, SaaS), and new software features.  If, in 2005, you put off your BPM implementations for 2 years to get the latest and greatest from the Stack Vendors, you’d still be waiting today, 4 years later, and the expected wait is…. still 2 years…

Why?

This isn’t an issue of capability. Each of the stack vendors has produced world-class software in other areas, and each of them employ a bunch of world-class engineers.  But BPMS has not received the attention, focus, and thought leadership that it requires for these vendors to be successful.  The folks making product decisions around their BPMS products may still think of BPM as a check-mark on their SOA software stack, and in any case they don’t seem to understand the incredibly broad potential of BPM (and of a BPMS). It looks to me like even the analysts (e.g. Gartner) have grown weary of the posturing of the stack vendors absent any real delivery compared with the pure play vendors.  And it isn’t lost on me that in general, all of the stack vendors have acquired pure play vendors only to see their pace of innovation stall or stop as they figure out how to integrate the new software (often in this argument, it is pointed out that since stack vendors buy pureplays, they “inherit” that innovation, but it just doesn’t work out that way in most cases).  And then because they’re often giving away the BPMS on the back of a stack SOA offering, they aren’t seeing the dollars attached to BPM that would drive them to increase their investment (self-fulfilling prophecy)…

Of course, in 18 to 24 months one of the stack vendors could surprise me and “catch up” to the pure plays (through actual engineering effort, not just by purchasing one of the existing pure plays), but I’m not holding my breath just yet.  If you want to get ROI in the next 18-24 months, go pure play, and get those projects in production.  And then see where the market is after that… and which tools make the most sense for the next leg of your process improvement journey.

So Who is Going to Win?

I don’t pretend to know who is going to win the BPM/BPMS market.  However, as a customer, I would be wary of pure play vendors that sell to stack vendors, when that stack vendor is not putting all their weight behind BPM and BPMS. If the stack vendor isn’t re-aligning their business behind BPM and expecting a significant percentage of their revenues to come from BPM, then the pure play vendor will likely suffer the fates of staffware, fuego, collaxa, and others who have been absorbed and (nearly) forgotten by the market. If you’re a pure play vendor, and you want your venture to succeed within one of these stack vendors, you need to make sure they’re really aligned with BPM – that they believe it is the future of the enterprise software business.  If they don’t, I wouldn’t have much faith that they’re really going to invest in the engineering needed to succeed.