The Truth About Software as a Service (SaaS)

Vendors say software as a service will cut costs and increase efficiency. They say it's enterprise ready. Does that sound too good to be true? It is.

1 2 Page 2
Page 2 of 2

The convenience of using SaaS applications—especially when adoption is driven by business users—can mask a significant IT challenge, notes Gartner’s Pring. That challenge is integration, both with other enterprise applications and with data sources.

In some respects, integrating SaaS can be easier than integrating in-house or ASP-provided applications. That’s because SaaS’s multitenant nature requires vendors to pay more attention to the data exchange and application programming interface (API) connections to other applications so that a broad variety of customers can use the SaaS application without any customization or significant hand-holding—both of which would defeat the SaaS vendors’ business model. “Integration is a little bit easier because someone has already given some though to it,” says Sapphire’s Perry.

Another factor, says MedImmune’s Young, is how separate the SaaS application is from other enterprise applications. “In a loosely coupled application space, it may be easier to bolt on SaaS apps if they use common APIs like XML,” he says.

Integration with enterprise data is a more straightforward issue, says Rob Desisto, a Gartner research vice president. Most SaaS applications are designed to export and import standard data formats for their application domains—vendors really had no choice if they wanted to be taken seriously, he notes.

Typically, SaaS works best when data is exchanged in periodic batches, not in real-time transactional environments, says Calvin Do, CIO at digital imaging vendor EFI. At EFI, salespeople use to manage leads, but after the lead gets past the quotation stage, the data is passed to the ERP system for deal analysis and order management. Similarly, performance reviews and résumé analysis happens in SuccessFactors, but salary and title changes, as well as new hires, are transferred to the ERP system. This approach requires duplication of data between the ERP and SaaS applications, Do notes, as well as some custom integration work to reconcile the data when it is brought into the ERP system, but he figures the effort took half as much resources as doing a similar integration between in-house apps, which are not as well-designed for interoperability.

In many respects, adoption of multiple SaaS applications mirrors what happened in the 1990s as companies brought in so-called best-of-breed applications and then had to figure out how to integrate them to execute business processes that transcended any one application. “This is eerily reminiscent of 10 years ago,” says Pring, although he acknowledges that SaaS vendors typically are much better at connecting to other applications and better at using standards than vendors were a decade ago.

Back then, most enterprises decided the integration effort for best-of-breed wasn’t worth the cost, so they began adopting suites instead. The same is likely to become true for SaaS, where the first such suites are already emerging—and CIOs need to understand that adopting a specific SaaS application may put them on the road to bringing in additional SaaS applications, ones that may compete with existing suites they’re heavily invested in, says Gartner’s Desisto.

For example, is intent on creating a suite based on its CRM software and its AppExchange platform through which other companies can develop plug-in applications for that use the same architecture and data model, thereby eliminating the need for customization that could cause breakage when is upgraded. ERP provider NetSuite has a similar strategy, though largely limited to the mid-market, notes Tier1’s Mankowski.

How to Protect Standards

Other issues arise when choosing to deploy SaaS applications, but these issues are familiar to enterprises with a history of outsourcing IT. They may not, however, be familiar to all SaaS providers, especially to those that have focused mainly on small business customers. Service levels. Because an outside entity is running the software, there’s always the fear that your enterprise won’t get the uptime levels and other services you need. had several widely reported service outages last winter, confirming some CIO’s worst fears about SaaS.

“But there have been no major issues since then,” says AMR analyst Bois, with or other providers. “Reliability is not as much a question as it used to be,” he adds, because SaaS providers typically deliver the same availability as most enterprises do, with uptimes of 99.999 percent. Bois does recommend that any SaaS contract include a service-level agreement (SLA) of at least 99.5 percent availability, which Bois says is the common minimum.

But don’t expect most SaaS vendors to have anticipated the need for SLAs, warns Gartner analyst Pring. Reflecting the vendors’ focus on mid-market customers, “85 percent of SaaS apps have no SLAs,” he says. Vendors targeting larger enterprises are more likely to have SLAs in place.

Security. Security concerns have diminished in many CIOs’ minds. There have been no reported breaches at SaaS providers. “I used to be concerned about sending sensitive information out,” says EFI’s Do, “but then I realized I already send out payroll information, so I realized I could trust outside providers.” He verifies the vendors’ security plans, though, before granting that trust. Schwab prefers that its SaaS providers segregate its data onto separate storage hardware when critical information is involved, notes Hohenstein, although it will allow commingled storage in some cases. “Either way, we have stringent requirements on security,” he says.

But not everyone is so trusting. “We have not gone to a SaaS provider for applications that use sensitive information,” says TI’s Murphree. “We don’t want to give up control.” Risk management. CIOs should make sure that they demand the same auditing and control requirements from SaaS providers that they would of any outsourcer, including “safe harbor” provisions for ensuring data privacy, rights to the software and all data in case the vendor goes out of business, and the ability to audit the vendor’s controls (including the use of SAS-70 self-audits), says Gartner’s Desisto. “Certification processes are now standard, so it’s easier to work with a reputable company for external certification,” says Accenture’s Modruson. The trick, says EFI’s Do, is to find SaaS providers who understand this need. “The light bulb is not on as much as it should be, since most are smaller companies,” he says. Another precaution to take is to get the rights to the software should the vendor fail, so you can run it in-house until you find a new option, says Sapphire’s Perry. As part of that, make sure to get backups of the data stored by the SaaS provider.

The use of SaaS can also help reduce risk. For example, “there’s less risk in trying to deploy SaaS quickly than there is in investing a lot of money on internal resources, which are the scarcest resources I have,” notes MedImmune’s Young.

In some industries, SaaS providers can assume their customers’ risk. Many U.S. small banks, for example, use SaaS providers, such as Intuit’s Digital Insight division, for their Internet banking and wealth management platforms, notes Basil Blume, CIO of Colorado Capital Bank. Small banks don’t have the resources to meet all the regulatory and security needs for such software, so it makes sense for them to use firms that do, are audited by regulators and assume financial accountability in case of failures, he says. “We transfer the risk. There is a bit of premium to pay, but then I don’t need to keep those developers on staff either,” Blume notes.

The Future: One SaaS Step at a Time

As the industry matures, enterprises may find that they can depend on SaaS for more mission-critical needs, perhaps even one day running their ERP applications in that model. “I would consider ERP via SaaS,” says Scientific Games’ CTO Steve Beason, “but I would need to get protected financially, not just feel comfortable about failure recovery.”

But there’s a lot more work to be done before that can happen, notes Gartner’s Pring. SaaS is possible today because there’s less custom enterprise code than in the past. “Twenty-five years ago, it was all custom code; 15 years ago, ERP applications were packaged and reduced custom code,” Pring recalls. But custom code today still accounts for about 60 percent of enterprise software, meaning there are a lot of areas that SaaS just can’t handle.

Galen Gruman is a frequent contributor to CIO.

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams