Yesterday we all heard about IBM’s announcement that it will be acquiring Lombardi Software. Few of us were surprised. While the BPM sector remains strong, the recession has been hard on venture-owned firms who must inevitably get sold if they can’t grow enough to go public.
And we found IBM’s positioning in the press release interesting, to say the least: “Lombardi's department-level approach to delivering process management complements IBM's existing strengths in enterprise-wide process management software”. Departmental? Yes! That’s exactly what we have been saying for a while. But “complementing” is hard to do in an IT-oriented middleware stack.
We’ve been recognized as the fastest growing enterprise BPM vendor because of the agility our unified environment delivers. (I could go on about that but I won’t since that is why we have a marketing Website:). But I think we can now all agree that a seamless and cohesive approach is better? If you do disagree, it would be great to understand your thinking.
IBM, for one, we know clearly disagrees. They say they will “preserve” Lombardi within its mix of disparate stack applications: “the investments of clients and partners in existing IBM and Lombardi technologies will be preserved, allowing customers to take advantage of the broader set of capabilities without needing to replace existing systems.”
Good idea? We don’t think so. And the blogosphere jury seems divided as well. Bruce Silver had the best line when responding to the IBM briefing on the announcement: “BPM involves process (Websphere), information (FileNet), and people (Lombardi). Now we have a separate BPMS for each of those. Isn’t that great? Ummm, no.” Agreed. Neal Ward Dutton observed “…there is almost 100% product overlap”.
Acquisition does not mean instant integration, as http://bpmfocus.wordpress.com/2009/12/17/ blogged: “…digesting the new acquisition and building new value will be challenging (and for Lombardi, being digested will not necessarily be the easiest of experiences).“ Having multiple BPM suites that rely on excessive integration is a recipe for frustration. Stack vendors can acquire multiple “BPM” solutions that draw more questions from customers than provide answers.
More painfully, they create new dependency on an IT-controlled methodology that increases complexity, and constrains innovation.