IBM: The Quintessential Integration Company?

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

IBM is serious about integration-you can tell that from it's book-end deals this month. At the beginning of May, IBM acquired SaaS and appliance integration vendor Cast Iron, a privately-held company, for an undisclosed amount. And now, at to close out the month, IBM announced the acquisition of B2B integration company Sterling Commerce from AT&T for approximately $1.4 billion.

Tony Baer, a senior analyst at Ovum, has an excellent assessment of the Sterling deal, if you liked to learn more about how that affects IBM's overall WebSphere strategy and business services branch.


After the Cast Iron acquisition, I spoke on the phone with Chris Vavra, the IBM product manager overseeing the deal. Also on the call were Chandar Pattabhiram, Cast Iron's vice president of marketing and channel, and Simon Peel, the senior vice president of strategy and marketing at Cast Iron.


They wanted to clarify a few points about Cast Iron and why IBM had acquired the company. Mostly, Pattabhiram and Peel wanted to clarify that Cast Iron had actually been offering integration-as-a-service since October 2008. I had misreported this, after getting confused about the marketing message around Cast Iron's recent OmniConnect announcement. I thought OmniConnect was the name for its integration-as-a-service offering, but no. OmniConnect is essentially a rebranding (marketing-speak for new way of advertising it) of its entire offerings, a sort of "uber" or umbrella brand, as Peel described it.


Along with that, there were a collection of upgrades-you can read about them in my original interview with Pattabhiram-including the new capability of designing in the cloud. Previously, Cast Iron supported running and managing the integrations in the cloud, but not design. With Cloud2, the company added design.


But beyond the discussion of Cast Iron, Vavra discussed how critical application integration is to IBM. Some of you may already appreciate this, but for those who don't know, Vavra pointed out that IBM is the revenue leader in application integration and in install base:

We've put a lot into it, from our messaging technology to our application integration brokers to our enterprise service buses to our SOA governance solutions and, five years ago, our DataPower SOA appliances. And we've continued to invest in this area, both organically and through acquisition, to continue to drive value to customers and to partners.

IBM had realized, however, that it needed to move more aggressively in the SaaS integration space. In particular, IBM wanted to be able to offer its customers multiple approaches to SaaS integration, and this is exactly what Cast Iron already did, Vavra said:

We did an analysis of how to best go about that and we determined far and away the best way to enter and accelerate the market was through the acquisition of Cast Iron. We did look at other options, and, frankly, we probably would have just developed something ourselves if it weren't for our being able to bring Cast Iron in. It's very strategic and a serious consideration for us in the transition to enable SaaS integration.

Another not-insubstantial factor: Cast Iron already had partner relationships with numerous SaaS companies.


The other thing I asked him about-and this is not in the published Q&A-is James Governor's suggestion that IBM actually bought a way to manage APIs. SaaS has expanded the use of APIs, but they're not always as developed as they should be, leading to new releases and updates. RedMonk has pointed out that this could become become a management nightware as APIs proliferate.


I think I caught Vavra off guard with that one, because his initial response was simple:

Customers don't buy API-management solutions, so from a product definition standpoint, I have to abstain from passing judgment because I guess I don't understand.

Pattabhiram stepped in, however, and pointed out that this is exactly the type of problem Cast Iron's technology handles for customers so they don't even have to know about it:

I think the context in which the person was talking about is if you have Salesforce.com connecting to NetSuite, and tomorrow you have new versions of the APIs for Salesforce.com and NetSuite, then you don't want the customer trying to open a 180-page Salesforce.com API manual and trying to figure out how to upgrade the connectivity. But with a solution like Cast Iron, given the power of our ecosystem and if we work closely with these companies, you'll automatically have these kind of new versions of these connectors built into the product in these scenarios.

Vavra jumped on board then, pointing out this is exactly the type of integration problem where middleware excels:

When you're doing integration, there are multiple moving targets and our middleware always masks those individual changes from the user so that if one application updates or if our platform updates or if they add a new end point, they can do that easily without having to deal with the underlying details, because we put that into our engineering, right?

It also is a reminder of why hard-coded, point-to-point integration can be such a bad idea these days.


Actually, IBM's focus on integration works for more than just IBM's customers, as Cast Iron's Simon Peel pointed out. Because IBM is not an application company, Cast Iron's partners didn't have to worry about being ... ahem ... cast out:

...if you look at it, IBM is the quintessential integration company because they're not an applications player. If an applications player had picked it up, then that would have been of much greater concern to our clients because obviously it could then potentially have been folded in underneath one application rather than remain agnostic, which is the key thing for an integration technology.

"IBM: The quintessential integration company." It doesn't roll off the tongue, but in this age of integration headaches, it might be a good messaging bet for Big Blue.