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.

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.
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.

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.

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.

“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 Service-now.com in Solana Beach, Calif. “We implemented our SOA-based Oracle Fusion middleware before we went for Service-now.com,” 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 Service-now.com 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.

Possibly Related Posts:

• Untangling Network Difficulties
• Unifying Communications
• CFO: IT’s New Boss?
• More Work, Low Pay
• Reducing Storage Complexities

 Print This Post