SaaS integration: Tricky, but manageable

It was almost too much of a good thing. When Hines Interests Ltd. launched its real estate investment trust business, Hines Real Estate Securities Inc., as a complement to its real estate development business, it built the IT infrastructure around a bevy of SaaS products. But the need to exchange data between various hosted applications -- transaction processing, CRM, literature-fulfillment, and expense and vendor payment systems -- created a tangled web of integrations linking SaaS to SaaS and SaaS to on-premises applications.

5 Myths About SaaS

5 SaaS myths busted

It's the SaaS twist: Add too many applications, and you might to find yourself back in the bad old days, when the various applications in the corporate infrastructure wouldn't talk to one another. "When you're heavily reliant on SaaS, you're putting yourself in the position of siloed data once again," says Benny Lasiter, business systems architect at Hines Real Estate Securities.

Tips for successful integration projects

1. Develop an overall integration strategy that includes SaaS.

2. Take time to fully understand business process requirements before starting integration work.

3. Hire an information architect with a deep understanding of the business process requirements as well as the technology issues.

At least Lasiter had a plan. In many organizations, SaaS offerings sneak in through the departments within individual business units, often without the knowledge of IT. Rogue projects have become "the profile of SaaS" in the enterprise, says Ron Papas, senior vice president and general manager of Informatica Corp.'s on-demand group.

Later, as those applications multiply and grow, problems arise. "You do it once, twice, and five times later, you have these disparate solutions coming into the IT infrastructure. There's no strategy, no consistency, and there's a problem," says Benoit Lheureux, an analyst at Gartner Inc. "Most companies don't even know that they should have a SaaS integration strategy, let alone align that with their internal B2B integration strategy. That is a huge problem."

But you need not go it alone. As IT executives are working through their SaaS tangles, they're developing fresh integration strategies and getting help from new tools and integration specialists.

Three ways integrations can get tangled up

Things can go wrong even after SaaS applications are integrated with the rest of your infrastructure. Pervasive Software says these are three of the most common challenges:

1. New features that raise the bar: The SaaS vendor adds new features that you would like to use. Example: The vendor offers more granular reporting, but the process flows you've built need to change to take advantage of that.

2. "Improvements" to the SaaS vendor's API: SaaS vendors may revise application programming interfaces several times per year, and that can cause problems with customized integration work. Example: Outbound messaging is a mechanism that notifies another application that a change to the data has occurred and that an update may be needed on the other end. "For various reasons, SaaS vendors have had to change how that signal appears to the outside world," says David Inbar, director of marketing at Pervasive Software. That forces changes that may appear to be small details but still require altering your integration process or mapping. Inc. strives to ensure that updates don't break the way its API processes transactions. "Where that may fall down is if we change the behavior of the API calls. If it behaves differently, the customer's integration code may not know what to do," says Ariel Kelman, senior director of product marketing at To avoid such problems, the company keeps old API versions online.

3. Self-inflicted wounds: You make changes to your business processes that break the system. Example: You build a system for purchase orders and then decide to split the workflow for small and large customers, changing the process and information flows through one or more SaaS or in-house applications.

Key Strategist Required

"It is essential to have a central architect with an overall picture of the data, someone who understands the business side of things and the technical implementation of that," says Lasiter. Otherwise, unexpected problems are bound to arise.

For example, most SaaS integration projects touch back-end business applications, such as financial systems. As these links multiply, they swamp the central system. "All of a sudden, the performance of the finance application is crawling because you have all of these things connecting to it," says Rick Nucci, chief technology officer at Boomi Inc., an integration tool vendor in Berwyn, Pa. "It's like the old EAI days. You end up with this spaghetti code effect."

The flexibility of SaaS and the ability to change vendors quickly also present challenges, such as how to reconcile new SaaS applications with older data. For example, Lasiter switched SaaS vendors in May. "Now, here we are doing end-of-the-year processing, and we have data from two vendors. All of that has to fit together for year-end reporting," he says. In the SaaS world, he says, things constantly change. It's up to IT to manage all of the moving pieces.

Those headaches can be avoided by having an integration strategy that includes SaaS. But that runs counter to the ad hoc, need-it-now culture into which many SaaS implementations are sold.

Ad hoc isn't always a bad thing, says David Inbar, director of marketing at Pervasive Software Inc. in Austin. "It may violate a lot of textbooks, but that's how a lot of business gets done -- and gets done fast." But at big companies where dozens, or hundreds, of SaaS implementations can pop up, ad hoc projects can create a mess.

Whose Burden?

How are you tying in SaaS apps with your company's legacy data?

Our IT department is writing the hooks 29%

Our SaaS vendor is helping with integration 29%

We're not integrating with legacy data 16%

The business units that use SaaS deal with integration 13%

We're working with a SaaS integration specialist 4%

We're using a specialized SaaS integration tool 2%

Other 7%

For Lasiter, a structured integration framework evolved over time. Hines turned to SaaS because the real estate securities business had to be up and running quickly. It needed a flexible system that allowed quick changes, because business processes were still evolving.

Lasiter also wanted all of the data in a common repository for reporting purposes, so he decided to create an on-premises database that would serve as the core repository and traffic cop for data exchanges. He used a tool from Pervasive to create the integration links. "We built an insulating layer of integrations that allow us to maintain a central hub of data for reporting purposes," he says. And the design allows Hines to switch SaaS vendors fairly easily.

Who's in Charge?

IT department 71%

End-user departments 16%

Joint management 9%

Other 2%

Don't know 2%

Source: Exclusive Computerworld survey, March 2009, Base: 45 respondents

"We didn't try to do it all at once," he says. Instead, Hines added the integrations one by one over two and a half years. About 20% of the effort was coding. The rest involved defining business processes, analyzing data and figuring out the reporting requirements.

While Hines used on-premises middleware, it's becoming increasingly popular among other companies to use integration-as-a-service (IAS) offerings from vendors such as Boomi and Informatica. These provide a common integration hub for all SaaS-to-SaaS and SaaS-to-on-premises integrations.

"The main reason to go with hosted integration tools is rapid development," says Papas. While on-premises software tends to be upgraded every 12 to 18 months, SaaS vendors may revise their software three times or more each year. IAS vendors can help ensure that customizations for customers continue to work.

Zamil Industrial ITG, a construction products manufacturer in Dammam, Saudi Arabia, had no problems integrating its service-oriented architecture middleware with a service management application from in Solana Beach, Calif. "We implemented our SOA-based Oracle Fusion middleware before we went for," says Ahmed Abdrabalnabi, service planning manager at Zamil. Integrating it with employee information residing in Active Directory and an on-premises human resources application was "as easy as drinking a glass of water." The process took just a few days, he says, but that's because integration requirements were evaluated upfront to make sure was the right fit.

Although that time frame worked for Zamil's implementation, it would be overly optimistic for most integration projects. About 80% of integrations use basic technologies such as file transfers, and projects with SaaS applications tend to roll out faster than the 12-to-18-month window that's typical for traditional on-premises applications, says Annrai O'Toole, vice president of integration at Workday Inc., a provider of hosted applications in Pleasanton, Calif. Nonetheless, a typical integration project involving Workday systems, including the migration and cleaning of data, specification of business processes, and systems configuration, still takes around 70 days.

Next: SaaS users lose some control, but gain freedom

Learn more about this topic

The limits of SaaS

SaaS puts focus on functionality

SaaS surprises: Broader appeal, customization, more

PaaS gives developers a virtual toolbox

LiveOps moves from outsourcer to SaaS provider

This story, "SaaS integration: Tricky, but manageable" was originally published by Computerworld.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.