The Truth About Software as a Service (SaaS)

“What if we created a utility for enterprise automation? Then you don’t have to create a data center! Then you don’t have to have a CIO!”

That was Salesforce.com CEO Marc Benioff in June 2003, selling the benefits of the then-new concept of software as a service (SaaS).

Fast-forward four years, and Salesforce.com and dozens of other companies are inundating business users and CIOs alike with pitches for all sorts of SaaS applications. Right now, SaaS seems to be everywhere.

Of course, today, SaaS vendors want to work with CIOs, not replace them, but do CIOs need to work with SaaS vendors?

RELATED ARTICLES

Read related articles on why management costs need to be part of SaaS ROI calculations and three approaches for on-demand computing

Maybe. Sometimes.

“SaaS is just a means to an end. It’s part of a mosaic of solutions,” says Peter Young, vice president of IT at pharmaceutical company MedImmune.

“I view SaaS as another arrow in my quiver,” concurs Frank Modruson, CIO of the Accenture consultancy.

“SaaS is just another option,” says Rick Milazzo, CIO of clothing retailer American Eagle Outfitters.

But despite their tempered enthusiasm for SaaS, all three of these CIOs use SaaS applications…judiciously.

So far, the SaaS phenomenon has been largely confined to smaller companies. “For CIOs in the mid-market, SaaS may be the only way to get enterprise-class functionality,” notes Rob Bois, a research director at AMR Research. But as valuable as SaaS may be to smaller companies, that value may not translate to the needs of larger enterprises. CIOs at larger enterprises agree that SaaS can play a role in their software portfolio, but even its fans say that role may be limited.

SaaS and the Enterprise

There are many questions a CIO must ask when considering the use of a SaaS application. But perhaps the most critical question is whether your company wants to rely on software designed for use by hundreds of other companies.

“Don’t expect something unique. If you need everything customized, you won’t have success with SaaS,” says Lloyd Hohenstein, VP for finance, human resources, real estate and corporate communications at Schwab Technology, the financial services provider’s IT division.

But SaaS does make sense if the process “is not complex and is vanilla,” Hohenstein says. Unless there’s a reason to build technology internally—such as assuring service levels that a vendor can’t guarantee, SaaS is a good option, he adds. Assuming the software does the job well, of course.

What SaaS Is and Isn’t

The term SaaS is often abused by vendors who frequently use it to refer to any hosted application that can be accessed over an Internet connection, notes Ben Pring, a Gartner research vice president. “Some vendors are relabeling as SaaS more traditional application outsourcing approaches, and that runs the risk of both confusing and antagonizing buyers,” he says.

SaaS has a distinct meaning that’s essential to understanding its role in your application portfolio. With SaaS, there’s just one code base for the software, used by all customers, in what’s called a multitenant architecture. While the software might be configurable by users to their individual needs, the code itself is the same for all and is not customizable for any individual customer. Any enhancements made based on one customer’s requests immediately become available to all customers. So forget competitive advantage or differentiation based on the software itself.

The underlying data model and system architecture of SaaS is also not customizable. The advantage in this for the vendor is that it spends less time managing compatibility and upgrades across several versions of the software. It also spends less to support customers, as they all use the same version and they don’t run it on their own equipment. That’s one reason that venture capitalists have glommed on to SaaS. The VCs also like the fact that SaaS can reduce startup costs, promising faster time to market, notes Warren Weiss, a general partner at Foundation Capital, which has invested in SaaS startups since 1996.

For CIOs, this all translates to several advantages: faster implementation (because there’s no on-premise deployment), easier access to current technology (because changes are made just to the one code base) and fewer bugs (because having one code base reduces the complexity that can lead to errors), says Michael Mankowski, a senior vice president at Tier1 Research. It can also translate to lower costs for the enterprise if the SaaS vendor passes on the savings. SaaS is thus a new wrinkle in long-available, on-demand, outsourced IT models, such as the application service provider (ASP), business process outsourcer (BPO) and managed service provider (MSP). (See “Awash in Acronyms,” this page.) “It’s the next step in the evolution of software development,” says Gartner’s Pring. Examples include Salesforce.com CRM; Everdream help desk management; SuccessFactors employee performance management; and Ketera spend management software.

Where SaaS Makes Sense

The prime reasons for a CIO to consider SaaS are its faster deployment times, its lack of up-front license and infrastructure costs, and its ability to address vanilla business processes so you can focus your resources on custom processes that make a real difference, says Accenture’s Modruson. “Your startup costs are not as large, and you have the ability to get up and running quickly and change direction if needed. I don’t have as much flexibility with packaged applications,” he says. Equally as important, says Modruson, SaaS “gets us to having standard processes and a standard system across all units.”

But none of these advantages matter if the application area is highly integrated with or dependent upon other applications and processes. A SaaS application must address a fairly isolated function, says Ken Harris, CIO of Shaklee, a manufacturer of health and cleaning products. “That’s when SaaS is easy to do for the larger enterprise,” Modruson adds. Accenture deployed a recruiting management application via SaaS because it doesn’t interact to any great degree with other systems. Only after someone is hired is the data on that new employee sent to Accenture’s in-house ERP system, which manages the employee’s permissions and other attributes from then on.

Another key criterion for choosing SaaS is that the application isn’t one that differentiates the company competitively, such as improving customer service or enabling higher margins relative to competitors. Thinking about SaaS makes a company ponder these issues, which in itself is helpful in determining an IT investment strategy. “Companies have an inflated view of how unique their processes are. You always think you need more customization than you really do,” says AMR’s Bois. “No one’s going to care who you’re using for payroll or Web conferencing, or even office productivity applications,” adds Martin Perry, CIO of IT staffing firm Sapphire Technologies, which uses Bullhorn’s SaaS software for front-office staffing and recruiting.

Accenture’s Modruson notes that SaaS applications are less configurable (not simply uncustomizable) than the packaged applications most enterprises run in-house. That’s often a blessing in disguise because it forces the business to use standard processes rather than invest resources in customizations that have no real value.

But using a standard SaaS tool does not necessarily mean that every enterprise gets the same results from it, says Modruson. “The tool is the enabler of your processes. The business processes are what you control,” he argues. Several CRM tools, such as Salesforce.com, are praised for enabling enterprises’ individual processes while delivering them through a standard but highly configurable code base. “The configuration and how you use it is the secret sauce. Your process differentiations then come into play,” says Sapphire’s Perry. SaaS is best known in the CRM space, thanks to Salesforce.com’s aggressive marketing and its ease of use for salespeople compared to CRM offerings from companies such as Oracle and SAP, aided by the fact that sales groups often have discretion as to the applications they use, notes AMR’s Bois. But SaaS also is widely used in the human resources and procurement spaces, both of which have a history of being served by outside firms in a service bureau model. Examples include Concur Technologies’ expense and travel management software, SuccessFactor’s employee performance management software, ADP’s benefits management software and Ariba’s procurement software. SaaS applications also can be found in a wide variety of specialty areas, such as Web analytics, container allocation analysis for shippers and help desk management—all of which have histories of being handled by outside service bureaus. Applications in these spaces typically rely on batched data exchange and widely deployed, standard interfaces to internal applications, making SaaS an easy fit, notes Tier1 analyst Mankowski.

A third area that has seen broad SaaS adoption is Web conferencing, offered by WebEx, Citrix Online and Adobe. Applications such as Web conferencing and surveying work well with a SaaS approach because they let IT offer users functionality without having to invest in expertise and operations. “It’s a scale play. I wouldn’t build a survey tool myself because I don’t do that many surveys,” says Accenture’s Modruson.

Where SaaS Doesn’t Make Sense

If applications touch upon the core of the enterprise—typically ERP, financial, business intelligence and manufacturing systems—then SaaS should be approached cautiously, if at all. The main reason is that these applications are usually highly customized as they reflect the fundamental processes that differentiate a company from its competitors, says Shaklee’s Harris.

For example, equipment distributor Zones wanted to add a series of custom BI applications to analyze sales and distribution, but CIO and Senior VP Anwar Jiwani didn’t want to build the system in-house or dedicate staff to managing it. He considered SaaS-provisioned BI tools but realized their reports would be too generic to be useful. So he hired SeaTab Software to design and host custom BI apps. The idea was to keep Zones’s internal resource investments to a minimum while still getting the desired technology. “My goal was to outsource the BI development,” Jiwani says.

Another reason to avoid SaaS applications is that the functions you’re looking for are so key to your operations that you must own them. “We have extremely high standards in terms of availability, and we run things on a global basis from one instance,” says Dan Murphree, vice president of enterprise business applications at chipmaker Texas Instruments. “If a SaaS application weren’t available even for an hour, it would cause a major business disruption,” he says. “I’m not saying there aren’t service providers that could do it, but if we do it at our level of stability and control, we know what we’ve got.” Thus, Murphree reserves SaaS applications for noncritical functions, such as the IQNavigator, a tool for managing contractors, where downtime doesn’t halt operations.

A third issue that typically rules out SaaS is integration. When Mark Brewer, CIO of disk drive maker Seagate Technology, was pitched on-demand ERP by Oracle, he said no. “It would be wonderful if I didn’t have to manage the software patches, but the number of integration points to the rest of my environment is very high. Managing that would be a big problem,” he says. But he had no problem deploying several SaaS-delivered HR applications, because the integration effort was simple.

Some application domains are gray areas for SaaS, including CRM. One high-tech vendor ended up choosing Oracle’s CRM software over Salesforce.com because its use of CRM extended from order to cash, bringing the application into the heart of the ERP transaction system. The salespeople preferred Salesforce.com, but the CIO couldn’t make it work at the ERP transaction level necessary for the company’s sales processes. Not all companies need that level of integration, since they’re not constantly recalibrating their sales forecasts or inventories, but for those that do, it’s a complex integration task, agrees Schwab’s Hohenstein. “If someone is taking orders in the field, they need that integration. If not, the data can be sent in a batch mode,” notes Tina Phillips, a principal at Deloitte Consulting’s SaaS practice.

The Integration Challenge

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 Salesforce.com 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, Salesforce.com 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 Salesforce.com that use the same architecture and data model, thereby eliminating the need for customization that could cause breakage when Salesforce.com 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. Salesforce.com 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 Salesforce.com 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.