Thanks for the shout-out, ebizQ although I could have found a more colorful quote to represent my posts – definitely some good discussion on these boards last year. Here’s a link to their pick for top quotes.
In a breakout session at Lombardi’s Driven 2006, I was paired with a gentleman from BearingPoint to discuss BPM vs. SOA in our session. My central thesis at the time was that the value-proposition of SOA was primarily directed at IT – while the value proposition of BPM was focused on business drivers (including ROI) – and as a result, SOA projects were much more likely to be successful if driven by requirements from BPM projects. After all, work tied to ROI is more likely to get funded and get finished than work that… isn’t.
Recently I commented on Keith Swenson’s post, and then saw this ebizQ article by Glenn Smith, of Appian: “SOA needs BPM”. Glenn articulates a series of excellent points to support the premise that SOA really needs BPM:
BPM can succeed, albeit more expensively, without SOA, but without BPM SOA is only an internal technology initiative which does not directly address any business problem.
I couldn’t agree more – SOA is grease for the wheel, but it is not the wheel. And then Glenn describes SOA as it was initially defined: as an architecture, not a product. Again, it is nice to hear someone else saying what we all know to be true despite millions in marketing spend by stack vendors:
SOA is an architectural style for developing distributed systems. It is not a specific technology, but can be applied to many technologies. It encourages loose coupling of components and enables flexibility. Individual services can be modified with no impact on the consumers of those services. Services support reuse, and can help preserve and extend the value stored in legacy systems by making their capabilities more widely available.
He then goes on to explain why BPM benefits from the use of SOA, and why the traditional tensions between this camp aren’t particularly problematic because the very nature of the loose coupling of a Service Oriented Architecture (SOA) allows for the teams to operate largely independently and interact through well-defined service interfaces.
Well, this was a surprise for me this week – the news that Software AG (SAG) is buying IDS Scheer. Clearly there are complementary businesses from the perspective of what they’re tackling (SAG being integration centric, IDS Scheer being very modeling and enterprise architecture focused). Everyone seems to be waiting for the other shoe to drop – what will Oracle, SAP, and other players in the space do as a result of this acquisition? Are more acquisitions to follow?
As Forrester points out, “IDS Scheer needed an execution engine in order to remain relevant and credible in the eyes of process pros responsible for expanding enterprise BPM initiatives.” So it looks like a good fit from that perspective, and also from the point of view of altering SAG’s image as being too integration-centric (reinforced by acquiring Webmethods). Forrester expects a successful marriage, with the “big losers” being the big partners of IDS Scheer: Oracle and SAP.
More coverage from “BPM in the Real World” on ebizQ here. Based on a reading of posts on Twitter, there is some speculation that SAG now becomes a tasty target for SAP. But then, SAP isn’t known for paying a big premium in its acquisitions…we’ll see.
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.
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.
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…
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.
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.
Dennis Byron published this article back in March, but I missed it. Part 2 of 2, the focus was on the CFO’s requirements.
From our perspective, the key passage is right here:
As mentioned above, through your CFO’s (or CEO’s) intervention, your company’s partners may affect your BPM-enabling technology choice. In addition, CFOs may be interested in the partners of your BPM suppliers. Often the association of a BPM software supplier with a big-name consulting firm such as Bearing Point, Patni or Accenture will provide CFOs peace of mind even if you actually use the services of smaller BPM consultancies.
For example, a professional services supplier such as bp3 has a close but non-exclusive relationship with Lombardi Software, and you might want to look for such product-complementary partners once you have finalized a choice of technology supplier.
(Our emphasis on BP3, above)
I happen to agree with this point, and clearly our customers do as well. Often as our customers are choosing a software vendor, partnerships with big consulting or outsourcing firms are part of the evaluation criteria. Equally often, they are interested in BP3 (or companies like ours) doing a piece of the work or being responsible for the core BPM delivery. Customers want to know that they aren’t “locked in” to a single consulting provider, and they also generally want access to boutique firms that are really experts in the area, in addition to the big, generalist, firms.
I went back and read part 1 as well, and its a good read, with broad mention of vendors in the space and their pedigree- and proof that there is still no shortage of software vendors to the BPM space! Which, I think, just proves that business process touches everything. I suspect we’ll see a whole wave of BPM software in OEM deals and arrangements going forward, to put BPM closer to the many problems that other software already (mostly) addresses. I thought it was interesting how many of the software vendors mentioned were previously service providers. For service companies entertaining becoming software companies, I’d recommend reading a previous post on this subject (you can skim by reading the first two paragraphs and the last three paragraphs if your time is limited).
Lance’s article on “Witnessing Process Failure in Action” is edited and posted on ebizQ today. Check it out – and the whole series (scroll down to get to the featured articles), which is primarily guest-authored and pretty consistently high quality.