Integration Issues May Hinder SaaS Adoption

As enterprises adopt multiple applications delivered as software-as-a-service (SaaS), a new integration wrinkle emerges: connecting black boxes that cannot be customized by the enterprise.






More Tech Trends on CIO Update

Riding the CMDB Tidal Wave, Part One: Understanding

IT: An Industry in Transition

Report: Most Aren’t Rushing Into Web 2.0

Should IT Embrace Consumer Technology?

If you want to comment on these or any other articles you see on CIO Update, we’d like to hear from you in our IT Management Forum. Thanks for reading.

Allen Bernard, Managing Editor.


FREE IT Management Newsletters




This puts an increasing burden on IT to use middleware and other approaches to integrate the apps—both among SaaS offerings and with their traditional in-house applications—echoing the efforts required to integrate “best-of-breed” applications common in the 1980s and early 1990s.

One way to help integrate the black boxes is to use a middleware-oriented application integration platform like Tibco or an appliance like those offered by Cast Iron Systems, said Tina Phillips, a principal at Deloitte Consulting. Another method is to use Web services, said Warren Weiss, a general partner at Foundation Capital, which has invested in several SaaS providers.

“But there are challenges in the security models, data models, business processes, and workflow,” he cautions.

In the traditional world of in-house applications, the burden of integration ultimately pushed IT to buying preintegrated suites, and the same may happen in the SaaS world, said Michael Mankowski, an analyst at Tier1 Research. “We’re revisiting the whole ‘best-of-breed versus suite’ thing. We’re back there with SaaS.”

Owning the Core

Traditional suite vendors such as SAP and Microsoft are already preparing for the SaaS-suite approach. The basic reason they argue is there needs to be a common underlying architecture, with a consistent data model and set of semantics to let the pieces fit together.

“You need a collaborative setting and a suite as a platform so we can get closer to service plug-and-play,” said Peter Graf, executive vice president of solution marketing at SAP. In SAP’s case, that’s the Netweaver platform. “If the customer chooses not to use that co-engineered center, they have to deal with the integration,” he adds.

In SAP’s view, the ERP core becomes the hub around which the other pieces of the co-engineered center are designed. The same is true for Oracle’s middleware-oriented Fusion approach, notes Foundation Capital’s Weiss.

Salesforce.com would like to become an alternative platform, in the same vein as SAP. Its AppExchange platform provides a consistent application architecture and data model for Salesforce.com’s applications and those of its partners, said Parker Harris, executive vice president of Technology at Salesforce. Integration outside of these applications requires the use of middleware, common APIs, and other traditional integration methods that IT must manage.

“We have a connector to SAP, and IT at different companies will use that differently according to their needs,” he said.

IT can also use middleware such as Tibco and WebMethods that relies on Web services to connect applications such as Salesforce.com and SAP, Harris notes, “So you don’t have to learn anything special about any of the apps’ APIs, but you do have to understand your data architecture.”

The Glue

The issue of domain-specific data models is why SaaS will probably evolve into collections of domain-specific suites, said Rado Nikolov, director of emerging business at IBM. “The data model is built around a specific customer profile (application domain), so building on that platform for a different profile makes no sense. (Any individual suite) is not a universal integration platform,” he said.

Instead, interactions across suites will be integrated in a traditional middleware or EAI way either by vendors seeking competitive advantage through compatibility or by IT when the vendors decide it’s not in their self-interest to work with other vendors’ tools. A way out of that captive-platform approach could be the enterprise’s use of a service-oriented architecture (SOA).

“As more applications adopt SOA, a lot of these integration issues start going away,” said Jeff Baker, Managed Services practice director at BearingPoint.

“With SOA, APIs, and open standards, apps can talk to each other, and integration can be done more simply,” concurs Tier1’s Mankowski. “Everyone’s waiting on that,” he notes. But SOA is no silver bullet, warns research vice president at Gartner. “There’s still a need for data definitions to be handled. Being consumable is not sufficient,” he said.

Today’s SOA can’t orchestrate processes designed for different architectures, with different data models and contexts, concurs Rob Beauchamp, senior director of software architecture at Sun Microsystems. “That’s the opportunity for next-generation architectures,” he said.

At enterprises “tooling will be needed to orchestrate their own business processes, as well as in combination with the base processes from the SaaS providers. Registries and metadata become even more essential in the new world, and governance of metadata outside any one provider or user becomes important,” Beauchamp said.