Menu
SaaS: What’s the real deal?

SaaS: What’s the real deal?

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

“What if we created a utility for enterprise automation? Then you don’t have to create a datacentre! 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?

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

“SaaS is just another option,” says Rick Milazzo, CIO of 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.

These are organisations like Surf Life Saving NZ, which has been using a SaaS CRM system from Oracle for more than two months now.

For Nigel Cox, business development manager, Surf Life Saving NZ, the business drivers for the decision were simple: “We don’t have to install infrastructure and it saves us on back-end and other administration costs”. The not-for-profit organisation’s IT needs are managed by a single independent contractor.

“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 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 customised, 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”, says Hohenstein. 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 relabelling more traditional application outsourcing approaches as SaaS and that runs the risk of both confusing and antagonising 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 multi-tenant architecture. While the software might be configurable by users to their individual needs, the code itself is the same for all and is not customisable 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 customisable. The advantage for the vendor is that less time is spent 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.

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 Tier 1 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).

“It’s the next step in the evolution of software development,” says Gartner’s Pring.

Where SaaS makes sense

The prime reasons for a CIO to consider SaaS are its faster deployment times, its lack of up-front licence 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 start-up 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. Another key criterion for choosing SaaS is 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. “No one’s going to care who you’re using for payroll or web conferencing, or even office productivity applications,” says Martin Perry, CIO of IT staffing firm Sapphire Technologies.

Accenture’s Modruson notes that SaaS applications are less configurable (not simply uncustomisable) 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 customisations that have no real value.

Several CRM tools, such as those from 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, aided by the fact that sales groups often have discretion as to the applications they use, notes AMR’s Bois. SaaS applications are also 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 Tier 1 analyst Mankowski.

As Jim Steele, salesforce.com president points out, questions around the SaaS model have “changed dramatically” in the past three years. The initial concerns were on whether the on demand model was “for real” and around its security and performance. Today, says Steele, they are around SaaS’ application in vertical industries and integration with back-end systems.

Still, another 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.

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 customised 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 analyse sales and distribution, but CIO and senior vice president Anwar Jiwani didn’t want to build the system in-house or dedicate staff to managing it. He considered SaaS-provisioned BI tools, but realised 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,” says Jiwani.

Another reason to avoid SaaS applications is that the functions you’re looking for are so key to your operations 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 was not available even for an hour, it would cause a major business disruption,” he says. Thus, Murphree reserves SaaS applications for non-critical 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 did deploy several SaaS - delivered HR applications, because the integration effort was simple.

Some application domains are grey 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, says Schwab’s Hohenstein.

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’ multi-tenant nature requires vendors to pay more attention to the data exchange and application programming interface (API) connections to other applications so a broad variety of customers can use the SaaS application without any customisation or significant hand-holding — both of which would defeat the SaaS vendors’ business model.

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, as well as some custom integration work being done to reconcile the data when it is brought into the ERP system. Yet Do figures the effort took half as much in 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. CIOs need to understand 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.

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 worry 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 per cent. Bois does recommend that any SaaS contract include a service-level agreement (SLA) of at least 99.5 per cent availability, which he 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 per cent 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 realised I already send out payroll information, so I realised I could trust outside providers.” He verifies the vendors’ security plans, though, before granting that trust. 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 they demand the same auditing and control requirements from SaaS providers that they would of any outsourcer, including “safe harbour” 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, 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. 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 back-ups 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.

The future: One SaaS step at a time

SaaS is a fantastic operating model but because of the disconnected nature of the internet it does not [suit] high critical environments, says Adam Neat, enterprise architecture director for Fujitsu Consulting.

Moreover, some critical questions remain: “What happens if the network goes down? What happens if the SaaS service gets struck down with a denial-of-service attack or some sort of other malicious (or not) security breach? These sorts of questions and others are still open without a clear mitigation approach.”

Organisations can benefit most when the application function is a commodity, like CRM or ERP; or anything that’s predominantly CRUD (create, read, update, delete) based, he states. “Whilst the Google machine is driving towards offline and resilient SaaS-oriented application constructs… SaaS still isn’t suitable for mission critical applications and possibly sensitive corporate data.”

As the industry matures, however, enterprises may find they can depend on SaaS for more mission-critical needs, perhaps even one day running their ERP applications in that model. 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. Yet, custom code today still accounts for about 60 per cent of enterprise software, meaning there are a lot of areas that SaaS just can’t handle.

With additional reporting from Divina Paredes

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags crmSoftware as a service

Show Comments