Introduction

On-Demand or SaaS (Software-as-a-Service) is the delivery of software functionality over the Internet from an application instance that may be shared across many clients. It is not simply ASP (Application Server Provider) re-invented. With ASP, an organization bought a license to a traditional piece of software designed to be installed within an enterprise and paid someone else to host and manage it. With on-demand, an organization rents a license to a software module designed for the internet from the ground up and the provider hosts and manages it.

On-Demand is becoming the new paradigm in software delivery and “the emergence of on-demand software is not an isolated trend; it is a fundamental, market-altering shift in how software is built, bought, delivered and used.” (Bill McBeath, Chief Research Officer @ ChainLink) It’s the frontrunner of the new “utility” computing movement in which technology is provided in the way power or water is delivered to the business, as a service.

A look at the sharp increase in on-demand adoption statistics verifies this trend. A 2005 study by IDC (summarized on Forbes) determined that almost 33% of respondents were using software on demand and that another 48% were considering doing the same. This is a sharp turnaround from a study 18 months prior that determined 70% of companies were not willing to consider on-demand. Furthermore, a study by Aberdeen Research in 2006 focusing on the use of on-demand applications in the supply chain, one of the business functions that was not an early adopter of on-demand, determined that half of the study participants said they now used or were considering using on-demand applications to manage select portions of their supply chains. Finally in 2006, Gartner claimed that by 2010, 30 percent of new software will be delivered via SaaS as businesses continue to adopt this approach.

Benefits

Furthermore, on-demand software-as-a-service comes bundled with a slew of benefits not found with traditional software models. Fifteen of these benefits are:

Pay As You Go

No more spending thousands, tens of thousands, hundreds of thousands, or even millions of dollars up front for a software license only to spend that much again on implementation and training costs. The cost is simply a fixed, relatively small (when compared to traditional enterprise software costs), monthly, quarterly, or yearly fee (often less than the maintenance costs associated with traditional licensed software).

Instant Deployment

The organization can start using the software the minute the provider activates its accounts, which can happen within minutes of payment in a true on-demand platform. Most of these offerings come with easy-to-use streamlined data import utilities that allow a buyer to fully set-up and configure the organization’s instance in a matter of weeks, or even days, not the months or years associated with traditional enterprise software deployments!

Single Instance

All organizational users see a single instance of the software when they log in, regardless of how many instances and boxes are required to support the software behind the scenes. No more one instance per organizational unit, department, or division.

Economies of Scale

The fact that on-demand software is built from the ground up to be a multi-tenancy model allows a provider to share the hardware and software instances required to support an organization’s instances across clients and pass on the savings generated by economies of scale to the provider’s clients.

Provider handles administration, maintenance, and headaches

Software-as-a-service is the ultimate in computing from a utility perspective - and the only hassle-free computing model out there. All of us know how much of a hassle it can be just keeping Microsoft Windows on a PC working on a regular basis - enterprise software can be much more complicated. But neither the sourcing team nor the IT department need to worry about that, the provider takes care of all the administration, regular maintenance, and associated headaches.

Free Upgrades

On-demand software is updated automatically by the provider when new features are available. With many providers, this often occurs frequently, and some providers offer significant free upgrades three to four times a year. Compare this to traditional enterprise software where a buying organization might get an upgrade once or twice a year if they are lucky, and willing to pay for it.

The customer has the leverage

Many on-demand offerings are month-to-month (after an initial sign-up period, depending on the provider, which is typically never more than six months to a year) and the organization can cease using the service at any time if the sourcing team becomes dissatisfied. A provider’s success is not measured on the income from the initial contract but by adoption, satisfaction, and, most importantly, client renewal. Unlike a traditional installed enterprise software provider who gets all the money up front and disappears, on-demand providers are in it for the long haul. SaaS providers continually strive to make their offering the best it can be.

Anywhere access

Because on-demand is internet-based, a user can typically access the full-functionality anywhere the buyer has access to an internet connection. This is different from traditional web-access to enterprise applications which requires a VPN connection and specialized client software.

Buy what is needed, and only what is needed

With the on-demand model, an organization can buy just what it needs and not a bundled package where its users may never use more than half the features. Recent studies have suggested that the vast majority of product features go unused by a customer. If this seems preposterous, count how many features of Microsoft Word an average buyer uses on a regular basis. Maybe 20 or 30 if they’re a real pro. Now compare this to the 300+ (or is it 400+?) features that Microsoft Word has. With on-demand, if the user base does not need it, the organization does not have to buy it.

Single Accountable Entity

With traditional installed behind-the-firewall enterprise software, if something went wrong the software provider would blame the third party integrator who installed it and the third party integrator would blame the in-house administration team and so-on. With on-demand, there is a single entity involved with and responsible for the software and so a single point of accountability.

Regular, Automated Data Backup

How often does the internal IT department back up organizational data? And, more importantly, how often do they test the backups in recovery drills? (Warning: Anyone who is faint of heart should not ask this question, especially if they are seeking a real answer!) For example, the primary author of this wiki is an ex full-time developer/architect who found it quite shocking how little time most IT departments actually spent on data backup and disaster recovery planning. Moreover, very few stored critical data backups off-site in a secure facility and those who followed the practice generally did not do so nearly often enough. However, an on-demand provider, who knows that up-time is their business, usually has a much deeper understanding of IT-as-a-service than an internal IT department and generally has backup, recovery, and disaster avoidance as part of its daily operating procedures.

Built for Change

Business never stands still, so why should its software applications? However, that’s what happens when traditional enterprise software is purchased – the buyer is locked into a single operating mode until the software is upgraded, which could be years once the up-front costs that were sunk-in to buy the initial license are considered. On-demand applications are built for change, since the providers know that if they do not keep up with the forward pace of the industry, their clients will have no reason to renew when their initial term is up.

Integration with office applications

The vast majority of on-demand applications recognize that Microsoft Office is the defacto standard for professionals everywhere and build-in integration capabilities for data import from, and data export to, these applications (and Access and Excel in particular), making them easy to use and populate.

Low Total Cost of Ownership (TCO)

On-demand dramatically restructures the economics of developing, delivering, and supporting business software. Triple Tree and the Software and Information Industry Association (SIAA) found that SaaS deployments are 50% to 90% faster with a total cost of ownership (TCO) five to ten times less expensive than traditional software!

57% of respondents said on-demand had a faster implementation time and furthermore, 61% gave an implementation time of under 3 months, and 84% gave an implementation time of under 6 months

an even number of respondents said customer service was better,

with the other half saying customer service was the same

Furthermore, another Aberdeen study in 2006 found that enterprises deploying on-demand solutions improve spend under management by 28% more than enterprises that deploy installed on-site solutions over the course of a year.

The ultimate impact is that on-demand allows an organization to escape, or bypass, the IT backlog and get a solution, and results, faster while improving the alignment between vendor and customer goals, lowering risks, and decreasing capital expenses. Furthermore, the release from the mundane administrative and maintenance tasks frees the buying team up to focus their efforts on higher-value strategic initiatives.

Challenges

Of course, still not everybody has such a rosy view of on-demand, so this section will review some of the myriad of concerns that have been presented and illustrate that not only are most of them unfounded, but that some of them actually reveal additional advantages of the on-demand model!

(It should be noted that some of these naysayers are also sellers of traditional enterprise software packages who get huge commissions with every sale and have every reason not to like a new model that slashes prices, and thus commissions, which they rely on to fatten their bank accounts.)

However, since it is poor form to promote any software model without addressing each and every potential concern that is brought forward, here is the long list of concerns that can be found in the literature and the associated truths that should set a buyer’s mind at ease.

The Data is Not Secure (especially in a multi-tenant model)

PepsiCo’s CTO said it best: “Our data is probably safer behind [the provider’s] firewall than behind our own”. IT is a provider’s business, and the security of their data and their client’s data is of utmost concern to them. Not only will they have developers on staff with security expertise, but many work with leading security firms who will conduct regular audits and monitor the provider’s domain(s) for external assaults, stopping them before they even get to the firewall.

No guarantee of reliability

Aberdeen’s recent study found that even in areas such as system uptime and application response time, more enterprises reported that these solutions out-performed traditional enterprise applications run by their internal IT department or a third party ASP. Remember, uptime is an on-demand provider’s business. Since a client can leave if they’re not happy, they tend to be much more responsive than an internal IT department whose jobs are a lot less dependent on the up-time of any single application.

No ability to manage enterprise data

It is true that an organization has less control over how their enterprise data is distributed across the database instances, but it is also true that most organizations do not want this control. Unless the organization employs database experts, the organization will not know how best to partition their data for maximum performance. Furthermore, as discussed in the section on benefits, chances are that the on-demand provider is much better at backing up application data for quick recovery than an organization’s internal IT department.

New on-demand offerings lack functionality

Opponents state that many on-demand offerings only have 70% to 80% of the functionality offered by their traditional behind-the-firewall installed applications. This point should be conceded, but considering that most organizations use less than 50% of the functionality offered by most applications, these offerings are still boasting an average of 33% to 50% more functionality than will actually get used, so this is a moot point.

No control in a disaster

True, but this is not something an organization should want unless it truly is prepared. When a disaster happens, it’s always preferable if someone more qualified is responsible for cleaning up the mess. And more importantly, the organization wants someone responsible who is prepared. For a software-as-a-service provider, application uptime is their core-business, downtime will kill them. In comparison, this is not true for a manufacturer, whose IT department is most likely so swamped that they haven’t even thought about disaster recovery recently while most on-demand vendors will have detailed plans that they will run through and update on a regular basis.

A vendor can afford to be sloppy

Providers of traditional software argue that because on-demand software providers always have immediate access to their software, they can afford to be sloppy and roll out upgrades without a lot of quality testing, adopting the “if something happens, we’ll just fix it later” attitude. In fact, the opposite is true. Since most on-demand providers use a multi-tenant model where all customers are on the same instance, a single bug, no matter how minor, could bring down all of their instances, and customers, simultaneously! In contrast, even a bug in a commonly used feature will generally not affect more than a small number of customers in an enterprise software provider’s user base. Thus, on-demand providers are generally much more diligent and thorough when preparing to roll out upgrades or modifications. After all, if they go down, chances are every customer is going to be calling in within an hour wanting to know what’s going on - and no one wants to be around when that happens.

Forced Upgrades

The primary author will concede this as a truth as well, but would like to know why this is bad? On-demand providers understand that the last thing their customers want is the rug to be pulled out from underneath their feet and take great pains to minimize the impact on what’s already there when planning an upgrade. Often the net effect is that if the user does not look for it or read the upgrade announcement, the user might not even know a new feature is there. As a comparison, the free upgrades are similar to the cable company deciding to offer more channels for free (even though this would likely never happen in reality, or at least not with the primary author’s cable company). The subscriber would not be forced to watch them, but if she wanted to, she could. What would be wrong with that? Compare this to traditional enterprise software providers who think nothing of rearranging the entire interface between releases and forcing the user to relearn the entire product, just because they thought the new interface was better. (Something even Microsoft is guilty of. Last time the primary author upgraded Word, almost half of the few features the author actually used weren’t where they used to be.)

Because the provider has the data, the buyer is locked in

In these situations, the opponent of on-demand is confusing old-school ASP with new-wave on-demand. Any true on-demand application is going to come with good data import and export utilities. Furthermore, a buyer can verify up front that the organization’s complete database can be exported at any time and most vendors will even allow a buyer to build export support upon termination into the contract. (They might charge a small service fee for their associate’s time, but nothing compared to what a legacy application integrator would probably charge.)

The application cannot be customized as the buyer sees fit

This is partially true, but again, this is not a bad thing. Name something every sane person relies on everyday whose inner workings they do not fundamentally understand that they would honestly risk attempting a major customization on. Take an average Joe who’s not a professional mechanic. Would he seriously risk rearranging the internals of his engine? If he were not a certified electrician, and of sound mind, would he risk re-wiring his primary panel? Software is just as complicated, and extensive customization is best left to those that understand the inner workings.

Furthermore, nothing prevents a multi-tenant on-demand instance from being downgraded to a single-tenant instance on its own (set of) server(s), at which point, the buyer or the on-demand provider can customize it to the nth degree (with the understanding that future upgrades will not be automatic or free, since this degrades the on-demand application and increases the work the provider has to do). Most providers will happily provide a client with a single-tenant instance if they do not mind covering the extra costs (which are probably still substantially less than traditional ASP rates), and many will do customized development if the buyer is willing to cover the costs. Some will even sell a license to customize and deploy the instance behind the buyer’s own firewall if the buyer so chooses, but then the buyer will have to accept losing many of the on-demand advantages, and the advantage of having someone else administer and maintain the application in particular. Finally, most of the extensions to the main platform in an on-demand software-as-a-service application are the direct result of customer input.

In addition, many on-demand solutions are built from the ground up to support a basic amount of customization capability on the UI and workflow so that the application can be configured to each customer.

The risk of losing everything if the provider goes belly up

This is probably the only real viable concern the primary author has ever heard, but this risk is not unique to on-demand software. This inherent risk is always present when using a third party for any service, and an organization always deals with this risk in the same way – they create a back-up plan.

If data is important, make sure each member of the sourcing team knows how to do a full export and have someone do it on a regular basis. If the organization’s data base is very large, contract with the on-demand provider to do a full-export to tape on a regular basis and have that provider either send the tape to the organization or to a third party storage facility.

If the software is important, look for a provider with an escrow agreement where their customers get a license to the source code and installation manuals should the provider ever cease business. Then the IT department could always run the application internally until another provider was found. But if the organization chooses a stable provider who is growing, chances are this is not a big risk.

Where are the SLAs?

The primary author really does not know where this concern came from. Most serious on-demand software providers these days offer SLAs, and some to five nines reliability. What more could a buyer ask for? In contrast, one could ask where the SLAs are with traditional enterprise software. If one is provided, it’s probably weak in comparison.

Where are the value added services?

Most traditional software providers argue that their offerings have more value because they often bundle a slew of value added services, such as consulting time, services, and free access to resource libraries as compared to on-demand offerings which often just offer the software. This is true, but it is also true that traditional offerings cost 5X to 10X as much. Let’s repeat that: 5X to 10X as much! With those profit margins, they can afford to throw in a consultant or two - they’re still making obscene amounts of money.

Therefore, this isn’t a fair question as the comparison is not fair. Traditional services build in a cost for every possible service a client might use, even though they know most of their clients will not use most of the services. On-Demand providers charge a minimal fee based on what a client says they will use. Most providers will offer additional value added services that complement their basic offerings for a small fee. Furthermore, when the total cost for the on-demand provider that includes every possible service is compared to the price tag of traditional enterprise legacy software, it is often the case that on-demand providers are still at least three times cheaper once the organization takes into account the software and services that it will actually use.

The buyer does not have control

As should be obvious by now, this isn’t true. The provider controls the software, but the client still owns the data, and, more importantly, the client has the leverage. If the provider’s service sucks, the client can leave. If too many customers leave, the provider will go out of business. The customer has control, and don’t believe anyone who tries to say otherwise.

On-Demand vs Installed Legacy Systems

On-Demand software has some significant advantages over traditional legacy enterprise software offerings, including those offerings hosted on ASP. This section will review those advantages and then review the main differentiators that can be used as a “sniff test” to weed out traditional enterprise software applications being offered on ASP that are being packaged and sold as on-demand when they really are not.

On-Demand Advantages

There are some significant disadvantages of legacy enterprise software systems when compared to true Software-as-a-Service offering, even when those systems are hosted on ASP. This sub-section overviews some of the advantages of on-demand SaaS offerings over legacy software systems maintained by an ASP.

No significant technology investments

With legacy enterprise application solutions, there is the need to shell out for significant technology infrastructures to support them; with on-demand, all the organization needs is the PCs already on the users' desks.

No assembly required

Legacy applications require customers to become technical experts in the software: installation, infrastructure configuration, integration, customization, issue diagnosis, and upgrades in order to work with the ASP effectively. This involves significant training, ramp up time, and paying for a large IT staff indefinitely.

No lock downs

Once customized legacy software finally goes live, it becomes a "strait jacket" that prevents future innovation and improvements for 3-5 more years (as upgrades are deferred as long as possible due to significant costs to re-implement new versions).

Speedy issue resolution

With a legacy enterprise application, the software vendor must often replicate a customer's unique environment (exact production versions of application, database, operating system, hardware drivers, etc.), which can take weeks, only to determine that the issue can not be diagnosed or fixed because (1) it's due to a customization (2) it's the responsibility of another software component provider or (3) the version of the software currently being run is too old.

True process expertise

True SaaS software vendors are experts in the business processes they automate. They can provide ongoing assistance in using new software capabilities, process innovations, and best-practices. In contrast, ASP providers are not expert in the software, only in maintaining racks in the server room.

Not Legacy on ASP

Sometimes a legacy enterprise software provider will try to package their hosted application on ASP as a true Software-as-a-Service offering. Fortunately, there are rules of thumb that can be used to identify a legacy enterprise software provider with an ASP offering trying to disguise itself as a Software-as-a-Service provider. Such an offering can often be identified by the presence of one or more of the following indicators:

A reluctance to pilot

Pilots represent a significant investment to a legacy application provider who will have to configure a new instance for each prospective client. In contrast, a true SaaS solution provider can enter the client organization name and flick a software switch and the pilot is immediately set to go.

Elephant hunting

Elephant hunting is when the salesperson tries to enlarge the deal as much as possible to maximize revenue before the client discovers the true benefit/cost ratio of owning the software. In contrast, a true SaaS provider will allow a client to buy the bare minimum knowing that the client will want to buy more once the client discovers how great the service really is. Furthermore, most true SaaS providers are delighted to offer a prospective customer a low-cost limited-use pilot. In contrast, a salesman trying to sell an enterprise software application on ASP will squirm and fret even at the thought.

Reluctance or refusal to discuss revenue

Ask the question "what would happen to organizational profitability if no new customers were signed over the coming 12 months?". This will cause a traditional provider serious grief and lead to significant downsizing. In contrast, an established SaaS provider would be able to maintain status quo.

Infrequent new functionality in any given year

In contrast, most true on-demand SaaS providers provide regular updates 3 or 4 times a year to their clients.

Hosted versions lag new releases

In contrast, a true SaaS solution is always up to date.

Insistence on single tenant or multiple instances

In contrast, a true SaaS provider will want to take advantage of the multi-tenant model to save both parties significant amounts of money.

Delayed or long implementations

A provider running a legacy application on ASP may require weeks or months before they can get a new client up and running. In comparison, a true SaaS solution provider can literally turn a new client on the same day a deal is cut.

Simple customizations require single tenant instances

In contrast, true SaaS implementations are usually built to contain a moderate amount of configurability from the ground up.

End of contract unknowns

With legacy in disguise, a buyer never knows if he'll be able to renew, how much it will cost, if he can get his data out of the application, etc.. In contrast, true on-demand SaaS providers will gladly specify everything for a buyer up front, usually in the contract.

On Demand vs. Legacy

If the choice between on-demand and legacy installed systems still seems to be a toss-up, then the following questions are good starting points to hone in on a decision.

What's in an architecture?

Although single tenancy vs. multi-tenancy may not be as big a concern as the pricing model, SLA, and customer support from a buyer’s perspective, multi-tenancy does have its advantages. Although one can admit that the SLA and customer support issues should be tops, if price is an important factor, then a multi-tenancy model will save both parties money. Furthermore, as Sudy Bharadwaj of Aberdeen eluded in his take of On-Demand Supply Management on e-Sourcing Forum, accepting a single tenancy model may cause an organization to miss out on the community benefits of a multi-tenancy model.

What's the real TCO?

This is probably the most important question a buyer should ask. If the TCO of an on-demand solution is high, especially when compared to other on-demand offerings, there is a good chance that what is actually being offered is a legacy ASP application in disguise, at which point the buyer should look for one of the other indicators of legacy ASP applications in disguise, as described in the last section, to find out for sure.

Remember, with legacy enterprise applications there are annual subscription/license, hardware, or middleware/database license costs after the first year. Legacy enterprise application upgrades require a maintenance fee. Middleware providers only support their releases for a fixed time frame, and if the organization does not upgrade within a vendor’s support cycle, the organization will find itself running an unsupported product, which will cost the organization a small fortune if something fails and they need it fixed. Finally, even the best hardware will not last more than three years without an upgrade in a production environment.

To customize or not to customize?

Many companies believe their business processes are more unique than they really are. Instead, they should stop fretting about the perceived uniqueness and weigh the advantages of more custom coded logic against the lower maintenance and upgrade costs of using business process tools and configuration capabilities instead of customization.

The Natural Evolution of Software

On-Demand is here to stay. Oracle CEO Larry Ellison said that he expects the on-demand business model to be an increasingly influential one and he personally owns large stakes in a number of on-demand companies that have been making headlines. Even Microsoft CEO Steve Ballmer has called on-demand software the most important trend in the software market over the next two or three years.

On-Demand software allows Supply Chain Management (SCM) to spur creativity and business innovation by freeing them from mundane administrative tasks. After all, the future of software will not only be about how software is supported and delivered, but about how it can make critical information more accessible and usable for tomorrow’s knowledge workers.

On-Demand is the natural evolution of software, and one that Gartner predicts will command a hefty 30% of the software market by 2010. Some people are calling it a revolution and saying the best is yet to come. For example, Jason Busch, founding partner of Azul Partners and blogger extraordinaire of Spend Matters recently stated that he predicted the next generation of on-demand software will:

incorporate external content and insight as a fundamental part of its value proposition,

leverage community and shared instances for the benefit of all participants, and

transform internal spend management service delivery models.

For the most part, this is true, though in reality the primary author predicts that the implementation and usage will likely be slightly different than what Jason is predicting.

However, one of the things that the evangelists, and there are many, are overlooking is that one of the key benefits of future software-as-a-service offerings is the forthcoming transformation to software-with-a-service. With software-with-a-service, offerings will be inherently customizable and provide instant integration (or touch) points to related on-demand services and value added offerings.

Furthermore, there’s this new evolution of rule-based programming called business process management (BPM) which has led to the development of workflow and process-focused development languages such as java Business Process Management (jBPM) and Business Process Execution Language (BPEL) which allow for the development of a new generation of workflow driven applications. These new workflow applications can be customized on-the-fly to incorporate modified processes and workflows that not only allow for the construction of more versatile and configurable applications than before, but also allow trained business users to define their own workflows through a visual environment. Furthermore, since these technologies are being built hand-in-hand with web-services, it should be obvious that on-demand offerings are going to be the first to incorporate these new capabilities.

Remember, as John F. Martin of IQNavigator says, "SaaS allows customers to focus on their core competencies and their business processes rather than becoming experts on software internals, technology infrastructure maintenance, or deployment methodologies."

Transitioning to On-Demand

As with any software implementation, a migration to on-demand technology should be carefully planned. Always start with a careful analysis that identifies what the organization needs, examines the user experience, and determines where data currently resides. The transition should then be controlled, starting with a pilot project to gain familiarity and experience.

Moving to an on-demand solution is not an overnight process as it's a change management process. The most successful projects transition small groups of power users at a time. These power users become the internal proponents, experts, and trainers and help bring the rest of the organization over to the new solution.

Know What Is Required!

Identify the specific problems that need to be addressed and the specific results that are desired. Develop a long-term roadmap and document expectations. Discuss the list with potential solution provider(s) and make sure that any provider(s) that make the short-list are capable of delivering solutions in line with the organization’s long term roadmap and expectations.

Talk to Other Users

Talk to other users of on-demand technology, including users of any solutions that are currently under consideration. Get their perspectives on how on-demand technology is benefiting them and best practices on how to best deploy the technology for maximum, and immediate, return on investment. [If a prospective solution provider is unwilling to provide a list of customer references, be wary. It just may be a legacy enterprise software provider trying to pass off an ASP offering as on-demand as the vast majority of true on-demand providers generally have no qualms about providing customer references to serious prospects.]

Identify the Systems that Contain Current Data

Determine where organizational data currently resides, how the data is going to be exported, and how the data is going to be imported into the solutions that are under consideration. Make sure the interfaces of the prospective systems will meet organizational needs, or work with the providers to update the interfaces or your export and import capabilities.

Start with a Pilot

The beauty of on-demand is that a solution provider can literally set up a pilot account at the flick-of-a-software-switch and allow a prospective customer to try-before-they-buy. In addition, most providers will happily engage in a pilot project to prove the solution at very little cost to the prospective client organization. (Many on-demand providers will allow free access to the system for one small pilot project if the prospective customer covers reasonable consulting fees and expenses. Furthermore, some vendors will even do a one or two day proof-of-concept on existing historical data for free for a serious prospect.)