What Is Software as a Service?

Introduction

There has been confusion about the meaning of software as a service (SaaS) and on-demand. This confusion, further muddled by the existence of the former hosting and application service provider (ASP) models, has bred a range of often fuzzy and sometimes incorrect assumptions. For many it is difficult to ascertain whether SaaS or on demand imply that

1. the software application is hosted; that is some kind of hosting middleman is needed to provide users with access to the software, at a guaranteed level of service;
   
   
2. software is available in a hosted-form only, off-site, and is accessible via a Web browser, through a self-service type model, not through compact discs (CD) or uploads; or
   
   
3. software is available via a subscription model, where users pay on a daily, weekly, monthly, or per usage basis.

This is Part Two of the four-part Software as a Service Is Gaining Ground series.

Certainly, the recent generation of software, designed from scratch to be delivered as a service, fundamentally differs from traditional hosting models. This new generation offers a number of benefits that those earlier delivery models could not. Namely, although SaaS hosting models are still evolving, many of the technological problems that spoiled the first wave of ASPs have been or are being solved. For instance, in addition to improvements in security and reduced prices for bandwidth that bode well for hosting adoption, hosted software finally looks and feels more like traditional rich user interface client/server applications. This is because of tools such as JavaScript that provide error-checking and validation on the client side. Additionally, and possibly even more importantly, the development of dynamic hypertext markup language (DHTML) has allowed Web content to change every time it is viewed, by enabling a Web page to react to user input without sending requests to the Web server. This, in particular, has introduced a degree of interactivity to Web-based applications that was simply not possible a few years ago. Back then, users were either forced to fill in and submit cumbersome hypertext markup language (HTML) forms, or they had to run additional thin client software, such as Citrix MetaFrame, on their desktops. Neither of these approaches was satisfactory, despite the fact that while thin client software seemingly promised a good solution, it still had a number of shortcomings.

First, thin client software increased costs because the software had to be licensed on a per user basis, an idea that the hosting model was to do away with. This often caused the cost of the Citrix MetaFrame license to account for more than half of a less-than-enticing monthly fee. Second, because the screen was effectively being "rendered" miles away from where the user was actually located, it was slow and increased the load on the network at a time when bandwidth was at a premium price. Finally, users still had to run and maintain the proprietary thin client software on their desktops, defeating the object of running server-centric, Web-based software. As a result, costs were not being reduced by as much as originally promised.

However, with the advent of new tools, this has been ameliorated a great deal. In terms of the browser, support for very advanced graphics is still lacking, while the need for complex interactions on the client side has been mitigated by DHTML's help with minimization of server round-trips and page refreshes. One should expect more developments enabling more sophisticated interaction scenarios in the foreseeable future. Basically, well devised SaaS applications should be able to leverage rich user interface metaphors, without necessarily mandating them.

Based on this, one can define SaaS as software components that are developed or purchased and hosted by an independent service provider, and that are billed on a resource usage or per user basis (which can be changed and is not a fixed monthly fee). These software components do not require any user-owned or managed infrastructure, except for Internet access. The software is supported on a virtual infrastructure platform made up of physical equipment, such as networks and servers; storage located within commercial data centers and logical applications, such as Web sites; applications; and database software, which runs on the physical hardware and is delivered by the independent third party.

Different from Traditional Application Hosting

It is important to distinguish SaaS from traditional application hosting. Typically, a traditional hosting lease means that the user still buys the software and hardware but finances it in monthly payments. Under these terms, the hosting user enterprise owns rights to the hosted software, but the subscription is essentially a payment to third party to manage the hardware and infrastructure aspect of the installation. In the ASP model, the ASP vendor typically owns the software. The subscription buys the right to access the software for the period of the subscription on either a time basis or on a usage basis (e.g., so much for such a transaction).

Conversely, in the SaaS model, there is no upfront capital investment, and no hardware or software to purchase. Users and their implementation partners (Web developers and systems integrators) may only customize and manage the content, design, and business logic of their Web sites or pages. A good example of this is the way banks use check processing services. While software is used to run those services, banks are not paying to access the software, but are rather paying for a check clearing service. Another example would be the way the airlines use global distribution systems such as Sabre.

There are also technical differences between SaaS and application hosting. In the traditional hosting model, referred to as single tenancy, a service provider licenses an application from an independent software vendor (ISV) and remotely hosts and manages the application (possibly via an ASP), typically for a start-up charge and a monthly maintenance fee. In this one-to-one model, despite high availability and a lower risk of security breaches and service outages, users would often find themselves stuck in situations where they could not roll out new features quickly or respond nimbly to fluctuating customer demand.

To explain this more clearly, one should visualize a hallway with several locker boxes on the left and on the right. These boxes would contain database servers, application servers, operation system (OS) servers, and whatnot, and each locker box houses its own user—a single tenant. Each box would run on one instance or version of the application. Depending on the maximum capacity, some boxes would be larger and would contain latent servers if the tenant predicted they would be needed during peak periods. In this single tenant, multi-instance arrangement, every tenant spends significant time, effort, and money customizing their application in order to make their site unique. Customization requires developing code that is missing in the original foundation application or modifying the limited and existing functionality to replicate best practice features. Thus, as with traditional on-premise applications, these hosted applications also often require developers to graft on functionality that is not available in the original application. This takes significant time and money, and the customization is not supported. When the ISV has a new release of the application, it is all but impossible to roll it into the different customized versions, because it may break the enormous customization investment.

In contrast, the SaaS model makes use of multi-tenancy software architecture, in which one instance of the software and data model is provisioned to multiple customers who share the same hardware and database. With multi-tenancy architecture, the software can continually monitor and adapt to changing customer usage, as required. In this one-to-many setup, there is only a single instance of the software running in every locker box, so that frequent improvements in the software are automatically and seamlessly available to every tenant. Each box also contains multiple tenants, so instead of allowing the dormant servers within each locker to collect dust, the servers are dynamically maximized based on need. In the multi-tenant, single instance model, users pay only for what they use, while scalability is automatically adjusted based on actual usage. This model also has the additional benefits of a faster speed of deployment and of always running on the latest software version. Therefore, if a user's site experiences an unexpected surge in traffic, resources are automatically allocated so that the site does not necessarily experience slower performance. One should nonetheless note that multi-tenant installations that combine data from several companies into one application make upgrading faster and easier, but they also open the door to cross-company errors in data security, corruption, or compromise. Later in this series, we will examine some vendors' variations on multi-tenancy, which address the above concerns.

Another problem with SaaS is that the single software instance of the SaaS model typically makes disparate applications integration difficult, when one thinks of a broader approach that involves complex intra-enterprise business processes (and associated deep and broad functional capabilities). Conversely, with the traditional on premise licensing business models, customers can more feasibly modify their local software application instance to interface with other legacy applications. This was not possible with single instance hosted services. To solve the problem of customizing and integrating to existing legacy applications, SaaS vendors and ASPs have been looking to Web services, but it will be some time before the technology is mature enough to be able to replace the traditional, pesky message brokers and integration hubs that major companies still depend on. Thus, for the time being, message brokers and integration hubs are still a better solution for high-volume processing than Web services.

The Impact of Web Services on SaaS

Nonetheless, at the highest level, SaaS must be delivered as a service oriented architecture (SOA) approach and must embody Web services. The key benefit of Web services is that it decouples the use of functionality from the delivery of functionality, whereby the multi-tenant architecture allows users to customize their Web pages without building their own code. New features and functionality can be made available continuously, on the fly, as best practice features are identified and then made available. For more information, see Understanding SOA, Web Services, BPM, BPEL, and More.

Integration via custom coding and development eventually will be unnecessary once Web services become the preferred method of integration with a back-end system or an external service, and once all functionality can be exposed. For example, retailers and manufacturers might need to expose inventory or price information, or open a Web service to capture orders. There are already some commercial applications that can call a different, third party application while preserving the context of the original underlying application. With the newer technologies available, companies can literally write several lines of code to have one application talk to another.

The development of technologies, such as Web services and extensible markup language (XML) transactions standards, is making multi-vendor application interfacing more feasible. Thus, hosting companies will presumably be able to develop standard application interfaces for application integration. However, at this stage, Web services' share of the integration pie remains a tiny sliver, which means that successful vendors and ASPs must still be able to provide a complete gamut of interfaces that support not only Web services, but also legacy messaging protocols. To enable multi-tenant or one-to-many service, SaaS providers can partner with other peers to deliver a standard offering that is customized via dynamic integration and secure access to multiple application modules, with minimal customization of the application's core logic. For the time being, the hosted software service business model still applies best to applications that can be run in isolation or with limited, less involved interfaces to third party applications.

This may make SaaS compelling, because it has lower entry costs, and if the company does not realize value from the software, it can always stop using it (and stop paying for it). Like on-premise licensing, this model provides a steady stream of revenue for the vendor in the form of recurring monthly payments, but, unlike on-premise licensing, this model requires the vendor to assume the cost of hosting the application. In addition to being more easily accessed via the Web, thereby eliminating much of the dedicated network costs that past hosting arrangements entailed, the new generation of SaaS solutions surpasses the hosted applications of the past by being easier to acquire and deploy incrementally, as required, or on-demand.

Potential SaaS Benefits

The SaaS business model offers several advantages to both the customer and the vendor that offset the eventual, long run, higher costs of this model. By purchasing a software service (as opposed to purchasing a software license), the customer has little or no up-front acquisition costs, no hardware or software to buy, and no numerous support information technology (IT) staff to hire and train. The cost of acquisition is basically reduced to the cost of training employees on the application, the initial configuration of the application, and converting or migrating existing data.

Hosted SaaS is also easier to get running, partially because customization is limited, but also because there is no hardware to buy and no software to install. Moreover, there is no software to manage, fix, or upgrade, as this becomes the vendor's responsibility. Users get a semi-custom application without having to hire a phalanx of IT staffers to keep it running. Because the vendor or ASP is hosting the application, customers see only one instance of the software. On the other hand, with the on-premise model, the software is distributed to the customer and is installed on the customer's computers in a variety of environments, out of the control of the software provider. Again, SaaS reduces the pain of upgrades, as customers automatically remain current on releases, despite spending minimal effort on upgrades. Thus, traditional fixed costs turn into variable counterparts, since a customer only pays for software it actually "consumes". This may require some new approaches to IT budgeting, but it should reduce unnecessary software spending. Moreover, customers may start preferring to be able to pay-by-use, provided it is controllable. The more they can make their costs vary, and link to the volume of business, the better they should be able to manage their profit and loss (P&L) statements.

Further, these cost reductions may allow the vendor to charge more for a software service than a user-based on-premise license. Additionally, the SaaS model severely lowers switching costs, and should compel software providers to uphold higher levels of customer satisfaction and deliver better product functionality to ensure broader user adoption. Owing to the existence of only one instance of the software application, often the vendor only has to support one hardware and software platform, which greatly reduces development costs. Vendors can offer more targeted customer support while focusing on a single version. A single instance also means that the vendor can introduce software enhancements one at a time, breaking the dreaded major upgrade cycle and eliminating the cost that cycle generates. SaaS delivery gives vendors real time customer feedback, and astute vendors can continually monitor usage of their application and apply this insight toward continued product enhancements. On the buyer side, the lower acquisition cost of software services also makes these affordable for a broader range of prospective customers. In particular, this affordability gives smaller companies the opportunity to use virtually the same solutions as their bigger brethren, and thus expands vendors' opportunity to sell their service to a greater number of customers.

On-demand (Utility) Computing

The ultimate variation on hosted business models is on-demand (utility) computing and the associated pricing. This is a trend that has captured the attention of technology heavyweights including IBM, Hewlett Packard (HP), Oracle, and Sun Microsystems. Akin to common electricity or water services, on-demand computing allows customers to purchase processing power and access to software as it is needed, and pay based on how much and how often the software has been used. The key to delivering software on-demand is grid computing, which enables the dynamic allocation of aggregated commodity resources to meet changing demand. The product architecture here consists of multiple layers, including the physical hardware, enterprise applications infrastructure, and Web-based user interface (UI), that are orchestrated to adjust for new customers, changes in demand, and component failures. Between each of these layers are virtualization enablers that allow the combination of resources to be dynamically adjusted. For example, storage virtualization is the amalgamation of multiple network storage devices into what appears to be a single storage unit. This storage on-demand enabler, which is usually implemented via software applications, is often used in a storage area network (SAN), a high-speed sub-network of shared storage devices, and makes tasks such as archiving, back-up, and recovery easier and faster.

This emerging model may become attractive to large organizations, though almost all of the initial hosted applications have been targeted at small and medium-sized businesses (SMB). On Demand Business is the current slogan of IBM, which defines it to relate to nimble businesses interconnected into supply chains. The IBM On Demand Glossary gives the following definition of an on-demand business:

A company whose business processes—integrated end-to-end across the company and with key partners, suppliers and customers—can respond with flexibility and speed to any customer demand, market opportunity or external threat. An on demand business has four key attributes: it is responsive, variable, focused, resilient and based on flexible software delivery to power the business.

Based on this definition, on-demand includes SaaS, but entails more intricate business processes across the entire complex supply chain. SaaS currently addresses simpler chunks of functionality, albeit delivered through an on-demand (when needed) concept. How the true IBM on-demand business concept will be achieved in large companies remains to be seen, since these larger user companies will have to compete based on true business process innovation rather than on leveraging "low hanging on-demand fruit". However, true competitor differentiation will be difficult to achieve with today's product architectures, unless there is considerable investment in complex applications and their modification.

On demand also implies agile computing, where processing power is purchased and paid for according to demand. In this regard, the emergence of the SOA concepts and the development of virtualized computing have introduced the notion of almost complete flexibility in terms of which systems or services are used. Users of the system should be able to decide how much power to use or how many users have access to the software, because often, these numbers change by the minute. Nonetheless, despite much talk about pay as you go (PAYG) billing, it is still very rare, and can possibly be best applied at the mainframe end of the market. This is partly because these systems use relatively simple techniques. The very high upfront capital costs of machines make PAYG more attractive to both the supplier and the customer, and high-end system sales often involve a big service element. The two main system suppliers, IBM and Unisys, have been able to "bend" the power supplied and meter accordingly by over-provisioning the machines supplied. When demand is high at peak times, unused processors are switched on dynamically and the usage measured accordingly.

Yet, the fact remains that for most of the mainstream potential market, the proper billing of on-demand processing, applications, and services has been a major challenge. Namely, if something that is available is not used, then, increasingly (and logically), customers do not expect to be charged for it. On the other hand, if something is used, how is it measured? What if capacity is allocated on a provisional basis (or as a standby for emergencies), and not used? How are users to be billed? Furthermore, most enterprise applications are used unpredictably, and composite or tightly integrated applications add further complexity. In the future, these applications will increasingly be made of dynamically linked components and services, and some will be used almost continuously, while others only occasionally. To measure such usage, one might envision central billing engines that can measure hundreds of services, and are similar to current mobile phone billing systems, which can meter calls based on usage across a network of many suppliers, but this system has yet to be created.

More Common Hosting Model Concerns

Topping the list of doubts about hosting models is whether the hosted offerings can be properly integrated with existing on-premise applications. There is also skepticism over the usefulness of adapting hosted, SaaS, or on-demand solutions to unique business processes and practices, especially those requiring strict regulatory compliance. For instance, Salesforce.com and other SaaS-evangelist companies (typically identifiable by the word sales or net embedded in their names, see Comparing On-demand Customer Relationship Management Service Alternatives) generally offer good solutions for standard business operations. However, by using multi-tenant architecture, which requires volumes of customers on a single instance of the database, they sometimes cannot give companies the kinds of differentiators they need to increase sales and profits or to gain market share. These differentiators follow the "80:20 rule", where 80 percent of any company is similar to its competitor, and 20 percent is what differentiates it. It is this differentiation, which cannot be provided by SaaS, that will cause enterprises to still seek traditional vendors with specific industry expertise and broad functional footprints that can accommodate evolving business processes. Customizing UI field names will not cater to this need. Neither will the user's ability to write JavaScript, to put the universal resource locator (URL) for the script in a custom field, or the use of tab access and style sheets, all of which is what Salesforce.com refers to customization work.

Enterprises also want more control of their applications, as they need to be constantly changing configurations, adding new products, developing closer integration between their systems, and introducing best-in-class business processes. Also, many territorial IT managers will not be pleased with the idea of relinquishing parts of their IT kingdoms, and having to rely on an outside host's ability to impeccably run their data centers, even if the host is a viable business. These issues and a still budding market awareness may explain the findings of a recent study that states that over 60 percent of enterprises currently prefer the perpetual licensing model on-premise to subscription-based options.

The most common payment model today is for the customer to pay for a software license through a fixed fee based on the processing power of the machine (or machines) being used. A widely used alternative approach is for the user enterprise (licensee) to pay a fixed fee according to the number of users (or seats) accessing the software. To be fair, both approaches are relatively stable, allowing the customer to budget using a formula, while the vendor receives a big chunk of license revenue upfront, with a steady flow of annual maintenance revenue (usually 15 percent to 20 percent) thereafter. It is a steady, profitable model that customers and investors understand, and habits are difficult to break.

Another downside to hosted models is the long-term cost of leasing the service for the customer. One of the primary benefits of hosting is the initial negotiation of up-front costs associated with the rapid implementation of a production system. However, after a certain period of time, the subscribed system will cost more than an in-house production system. The hosted models' appeal is thus immediate gratification coupled with reduced initial financial pains.

This concludes Part Two of the four-part Software as a Service Is Gaining Ground series. Part One detailed the emergence of SaaS. Parts Three and Four will look at SaaS vendors and provider user recommendations.