CIOIN

It was almost too much of a good thing. When Hines Interests launched its real estate investment trust business, Hines Real Estate Securities, as a complement to its real estate development business, it built its 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.

Reeling It In

More enterprises are increasing their reliance on SaaS. You only need to scratch the surface to see that SaaS is becoming a strategic tool for users large and small with an array of IT needs.

Take Medco Health Solutions in New Jersey. The US$45.5 billion (about Rs 227,500 crore) prescription benefit management company has more than 20,000 employees, and compliance is a strategic part of its business. Jayme Antonoplos, director of compliance management, says employees must heed and monitor a broad range of regulations, including internal ethics mandates, prescription drug laws and the Health Insurance Portability and Accountability Act.

Until 2006, the company oversaw its compliance efforts with a patchwork of internally written applications. Since then, Medco has begun shifting to on-demand services. One of SaaS's key advantages - speed - has already proved its worth during some recent acquisitions.

"Compliance activities have to start quickly," usually within 30 to 60 days of absorbing a new company, says Antonoplos.

SaaS advocates often point to the speed at which on-demand applications can be deployed. Keitaro Shigemasa, CIO at Link Theory Holdings, which produces the Theory brand of women's apparel, says time was a key factor in its decision to adopt Sky IT Group LLC's SkyPad business intelligence dashboard for point-of-sale analytics. And like Medco, New York-based Link Theory is a large company with multiple stakeholders in the system.

Tangled Up

Tangled Up

"We could have done it ourselves," Shigemasa says. "But we lacked the staff and the data warehouse tools. Plus, it would have taken three months or so to get it done."

It only took four weeks to deploy SkyPad, he says. And Shigemasa praises the service because it requires little effort from his staff to train or support users.

And Saas is beginning to shed its only-for-CRM image. Kenny Gravitt spent 33 years working at IBM and Lexmark International recovering used hardware assets and reusing the parts in refurbished goods or selling them. After a brief but boring stint in retirement, Gravitt started Global Environmental Services LLC, a 20-employee electronics recycling company last summer.

Having been nurtured on IBM's sophisticated ERP systems, Gravitt understood how vital it was to track the growing inventory of gear and the tens of thousands of discrete parts in his 70,000-square-foot warehouse. But his initial Excel- and Access-based inventory system fell well short of meeting his needs.

That's when Gravitt discovered SmartTurn, an online inventory management service from SmartTurn. He credits SmartTurn with giving his customers sophisticated insight into his supply chain operations without a pricey IT investment.

The SaaS tool, he says, "has won us two contracts" with major computer vendors, who pay the company to recycle hardware in Kentucky but can track progress in real time over the Web with SmartTurn. "It's our advantage over the competition," Gravitt says.

All this popularity could hurt SaaS. 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. "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.

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

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.

'Improvements' to the SaaS vendor's API. SaaS vendors may revise application programming interfaces several times a 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.

Salesforce.com 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 Salesforce.com. To avoid such problems, the company keeps old API versions online.

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.

The Need for a Strategist

The Need for a Strategist

"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, CTO at Boomi, an integration tool vendor. "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 recently. "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. "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 percent of the effort was coding. The rest involved defining business processes, analyzing data and figuring out the reporting requirements.

Cloud Seeding

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 Saudi Arabia, had no problems integrating its service-oriented architecture middleware with a service management application from Service-now.com. "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 percent 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, a provider of hosted applications. 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