Well, as predicted, the news of IBM acquiring Lombardi was quickly followed by more acquisition news:? today Progress Software announced an acquisition of Savvion.
I can't say that I'm surprised - adding BPM is a logical step for Progress, and has been for some time (in fact, they were a good technology partner for Lombardi when I worked there).? BPM could help progress sell more than one product in one sale -because the sale is more about a solution to the process problem than it is about a specific product.
The price tag is certainly reasonable - $59M essentially.? Feels more like a technology buy than a business buy, but then, Savvion was also considerably smaller than Lombardi at time of sale (when I joined Lombardi, Savvion was much bigger than we were, and Staffware was the "800-pound gorilla", but Staffware got picked up by Tibco, and Lombardi grew faster than Savvion in the meantime).
Sandy Kemsley's analysis is that the most likely opportunity is CEP + BPM (since Progress has the Apama CEP offering).
Bruce Silver worries that this is the beginning of the end of BPM:
If we go back just a few years, four vendors on the business-centric end of the BPMS landscape stood out by empowering business to play a direct role in process implementation:? Lombardi, Savvion, Fuego, and Appian.? Their software featured model-driven design based on the BPMN standard.? It encouraged a new agile iterative design style based on business-IT collaboration rather than tossing business requirements over the wall.?? Where most BPMS vendor projects operated in a bubble disconnected from their customers? larger business process modeling and analysis efforts, these four vendors stood out by saying it would be better to unite them, to put business at the center of BPMS, not just at the center of process modeling and analysis.? If Smith and Fingar?s 2002 BPM: The Third Wave was the vision, these four vendors came closest to fulfilling it.
What a great way to sum up the concerns with the string of acquisitions.? In the comments to Bruce's post, Appian's CEO does a little grave-dancing, which continues in his own blog posting.? One might argue that he doth protest too much "we are not for sale!"? He tells some stories about how the founders' work ethic.? I have to tell you, Mr. Calkins, that these stories do not make you unique among the BPM vendors, by any stretch.? I think it is these qualities of determination (and often sacrifice) that allowed the four companies named by Bruce to get to the size they each achieved - but determination and hard work is not a guarantee of any degree of success, just one of the necessary ingredients.? Similar stories are in the lore of these other BPM vendors. Mr. Calkins paints the outcome as being Appian vs. Pega for BPM dominance. It will be interesting to see if he's right, or if the stack vendors (one or more of them) will double down on their investments.? The key thing that the larger vendors have that has been very hard on the pure play vendors is a much larger sales channel through which to move product - resulting, in many cases, in a customer already having a competing product before you even talk to them.? And then you have to prove your product is enough better that they should buy a second BPM tool.? That requires a sales staff worth their commissions, and an R&D team that is nimble and efficient.
John Pyke, of Cordys (and formerly Staffware), offers his assessment of both the Lombardi and the Savvion buys. Understandably, it isn't in his interest to look favorably on either one.? He discounts the value of the Lombardi and Savvion offerings to the companies that acquired them. Of course, he discounts the value of Staffware to Tibco too.? Interesting to say the least...
Tony Baer's take is that pure play executable BPM's days are numbered.? He may be right.? But some of his explanation doesn't reflect what we've learned at BP3 from deploying BPM in the field.? As he puts it:
Consequently, it is not simply the usual issues of vendor size and viability that are driving IT stack vendors to buy up BPM pure plays. It is that, but more importantly, if you want your BPM tool to become more than documentware or shelfware, you need a solution with a real runtime. And that means you need IT front and center, and the stack people right behind it. Even with emergence of BPMN 2.0, which adds support for executables, the cold hard facts are that anytime, anything executes in software, IT must be front and center. So much for bypassing IT.
Well first, these tools were hardly documentware or shelfware.? And the execution of processes can be achieved with these tools (in fact, it is the whole point of these tools).? Tony infers that execution requires IT to be front and center - but I would argue that this is a straw man that isn't relevant. If IT is front-and-center and delivering the right value and process to the business, I'm sure everyone would be happy.? The holy grail of BPM is that business and IT can speak the same language with respect to business process requirements.? That even after the requirements become a deployed system, someone from the business could still look at the BPM models (which are actually executing in a model preserving approach), and understand them.? Never was IT going to be out of the picture, but for the first time in a long time, the business could be involved in a meaningful way, rather than a "throw those requirements over the wall" way.? The rest of his analysis I can't take issue with.
In yet another forum, Jason Stamper has a great article and a few quotes from executives at Savvion and Progress. Dr. K takes shots at Lombardi:
Asked to summarise Savvion's key differentiators from the BPM competition, Dr Ketabchi said: "The first thing is the extent and scope of our functionality: for example our BPM comes out of the box with a business rules management system, which Lombardi does not. IBM has the Ilog business rules but there is no integration between Ilog and Lombardi."
"Second, we made sure our BPM is enterprise BPM -- Lombardi, Metastorm and those others are departmental BPM. Our BPM is event-centric and supports event-centric patterns, decision-centric operations, case management and so on," Dr Ketabchi told me.
Well, I just would guess that if Lombardi was only departmental, that Savvion would have sold for a higher price than Lombardi.? I would have been more interested in how Dr. K would see the new combined entity competing with the new terrain of providers, rather than rehashing the old Lombardi-Savvion debate.? I think being part of Progress gives Savvion new life and potential relevance in the BPM space, because Progress' other offerings are well-respected in the industry.
Finally, Neil Ward-Dutton of MWD Advisors, weighs in with his analysis:? Progress is looking for acquisitions to help grow the business, and organizing around a new principle called "organizational responsiveness".? A Savvion acquisition fits.? As Neil writes:
The obvious challenge: until now, Progress had a number of assets (Apama, Actional, DataXtend, etc) to help companies capture and analyse intelligence about changing conditions and customer interactions ? but it had no direct way to tie this to a system to help customers drive responses in business processes. The Savvion acquisition plugs this gap ? and at the same time, it helps Progress more directly engage business executives in conversation.
This reminds me of several years ago when Cognos was partnering with Lombardi to build a new application suite that would combine their existing strong analytics with the ability to actually effect change in the process or organization (what they previously had was rear-view mirror insight, without a direct tie-in to go-forward decisioning).? Unfortunately Cognos was purchased just before that solution saw a General Availability release.? But the story sounds familiar and relevant to me.
As an expert service provider in the BPM space, we just hope that BPM continues to evolve and improve - and hopefully these acquisitions will bring some new capital and resources to bear on the BPM space.? If not we'll have to wait for another generation of products, or for open source solutions, to carry the torch.