The now-leading software as a service (SaaS) specialist vendors are relatively small; the leading platform and application vendors are not quite ready with their SaaS offerings; and, for the majority of the mainstream users, SaaS-style application solutions remain niche-focused and otherwise experimental. Nevertheless, we believe that now is the time when enterprise IT departments should begin planning for the growing influence of SaaS in their business practices; establish in-house understanding of the opportunities, challenges and best practices of SaaS; and begin to track the involvement of their technology providers in SaaS-related industry initiatives.

• SaaS is a well-established phenomenon in some areas of enterprise IT. It is growing into a mainstream option for software-based business solutions and will affect in some way most enterprise IT departments in the next three years.
• There are multiple business and technology forms in which the SaaS model will manifest itself at mainstream enterprises; one model will not fit all.
• Enterprise software vendors have not yet established the best practices in supporting SaaS application styles, nor are there applicable industry standards.
• Traditional technology platforms, such as standards-based application servers, are sufficient for simple SaaS use, but advanced and broad-based SaaS offerings now and in the future will rely on specialized or extended SaaS-enabled application platforms.
• In the next three years, most mainstream users will face the need to understand the trade-offs of SaaS and non-SaaS software models, as well as the best practices of a mixed SaaS and non-SaaS IT environment.

• Understand the SaaS-related business and technology plans of your current business application, software infrastructure and development tool providers. Similarly, include SaaS-related questions in evaluating new software products and vendors. Give preference to vendors that have an informed and credible business position and plans for SaaS-style business software solutions.
• Plan to gradually add SaaS-style software solutions to the supported enterprise software options, but do not plan, in most cases, to migrate entirely to SaaS-based application software in the next five years. Prepare for the coexistence in your environment of SaaS and non-SaaS business software solutions.
• Establish guidelines for preferences in selecting SaaS or non-SaaS software solutions for future projects.
• Examine opportunities inside the enterprise to establish an "internal SaaS" mode of support for some business software.

SaaS is a growing phenomenon in the IT industry, now beginning to penetrate mainstream enterprise use. Leading packaged-application vendors have made long-term commitments to SaaS modes of delivery of their software solutions to customers. Platform technology vendors are reassessing the technology content of their application platforms (development frameworks, tools and middleware) with an eye on supporting the requirements of SaaS-style application utilization. All of these processes are early in their evolution. Currently, the leading SaaS specialist vendors are relatively small; the leading platform and application vendors are not yet quite ready with their SaaS offerings; and, for the majority of the mainstream users, SaaS-style application solutions remain niche-focused and otherwise experimental. Nevertheless, we believe that now is the time when enterprise IT departments should begin planning for the growing influence of SaaS in their business practices, establish in-house understanding of the opportunities, challenges and best practices of SaaS and begin to track the involvement of their technology providers in SaaS-related industry initiatives.

The SaaS model of rendering business applications is not new. In fact, market revenue of SaaS application solutions exceeded $4 billion in 2006, according to Gartner (see "Dataquest Insight: SaaS Demand Set to Outpace Enterprise Application Software Market Growth"). Companies like salesforce.com, NetSuite, Ceridian and many others have become broadly successful with their entirely SaaS-style application offerings. Most of the currently deployed SaaS applications are built on proprietary underlying technologies because the general-purpose application servers and platforms have lacked specialized support or tools for SaaS requirements. Recently, vendors like WebEx (now Cisco), Cordys, salesforce.com, Oracle, Microsoft and others have begun the work on offering reusable platform technologies for SaaS. The most notable of these offerings today is the recently announced Apex Platform, including Apex Code, of salesforce.com (see "Salesforce.com Challenges Conventional Thinking With Web Application Platform").

The purpose of most of the vendors in doing this is to create a foundation for a new ecosystem of independent software vendors (ISVs) — smaller application vendors that would develop their SaaS-style applications on a third party's platform, dramatically reducing their cost of entry. A platform vendor that attracts the largest ecosystem following would likely gain leading share and leading influence in the market. The vendors are pursuing different business models, offering the platform as a product for sale to ISVs, as a hosted service for subscription by ISVs or as an enabling technology for their own (and their partners') applications. As the SaaS-enabling race between platform and application vendors begins, users must understand their options and trade-offs: When do general-purpose platforms offer advantages compared to proprietary platforms? What features of platforms are the best predictors of the quality of the applications that run over them? What features of the platform are important for what patterns of use? How should ISVs choose platforms, and how should users subsequently choose ISV applications? The answers to these questions begin with the understanding of the nature and differentiating capabilities of the SaaS-enabled application platforms.

Platform middleware has been the enabling technology for business applications since the mainframe days (CICS, IMS). Application platforms have supported the changing application styles and adopted the requirements of the prevailing application styles of their times (distributed computing [Tuxedo, DCE], distributed objects [CORBA, DCOM], distributed components [Java EE, .NET]). As new application patterns emerge, new categories of platform technologies emerge as well. The most recent ones include the event-driven application platforms (Java Service Logic Execution Environment [JSLEE]) and SaaS-enabled application platforms (SEAPs), discussed here. The users during the transition times have a choice of using the well-established previous-generation platform technology or taking a risk and leaping forward to the specialized technology in hopes of gaining competitive advantage. This applies to technology choices in SaaS-style software solutions. The new way of enabling SaaS-style applications using optimized SEAPs will prove more resilient, more productive and more agile, but the older, now-dominating distributed component platforms (designed for use by enterprises in-house) are well-established, well-understood and substantially standard — all attractive characteristics to enterprise technology buyers. This research aims to shed some light on the field and technology trade-offs of the new platforms for SaaS-style applications.

Software is SaaS (also referred to as software on-demand) if it has the following characteristics (see "Evaluating Software-as-a-Service Providers: Questions to Ask Potential SaaS Providers"):

• It is deployed and managed off-premise relative to the user organization.
• It is owned by someone other than the user organization.
• It is charged on a usage-derived basis.
• It is shared by multiple independent user organizations (one software instance to many tenants).

Note here that SaaS is not quite the same as application as a service. "Application" implies end-to-end completeness for use and must therefore include user interfaces, business logic, data access modules and, often, access to external resources such as other applications, internal or external to the user organization. The majority of new applications are heterogeneous (composite). Many will combine some on-premise resources and some SaaS-style resources. Even an application offered in its completeness in a SaaS style may have some user-facing elements that are deployed locally for performance or network-independence considerations. The discussion of the compositions including SaaS and non-SaaS resources is beyond the scope of this research, but software elements that have a singular nature (SaaS or another) must be distinguished from application assemblies that often compose elements of multiple natures.

Note also that sharing of the software by multiple tenants (a definitional part of SaaS) can take multiple forms. (See "How to Evaluate SaaS Architecture Model Choices" for further discussion of these options.)

There are five key role players in a SaaS scenario (see Figure 1):

• The SaaS platform supplier (develops and owns the intellectual property [IP] of the platform technology, underlying the application software in question)
• The SaaS application provider (develops and owns the IP of the application software in question)
• The SaaS host (hosts and manages the application software and the platform technology in question in service of many user organizations [tenants] and, potentially, on behalf of many application providers and applications)
• The user organization (contracts with the application provider and is provided independent virtual instances of the application software in question)
• The user (an individual actually using the application software in question — typically, an employee or customer of the user organization)

These roles may blur in some scenarios.

In most cases, SaaS applications are developed over proprietary platforms, and the SaaS platform supplier, the host and the application provider are all one entity. In this case, the platform is typically not standard and not productized (it is "supplied" to only one provider). We believe the growing trend through 2012 will be away from proprietary platforms and toward productized and standardized platforms. This can be achieved by extending existing platform standards (such as Java EE) or by standardizing or at least documenting new SaaS-specialized programming models (such as Apex Code). The platform vendors will aim to enter the SaaS market, and the SaaS application providers will aim to create an ecosystem of partners around their platforms. Both trends will lead to the emergence of and growing competition among programmable SEAPs.

Example: Salesforce.com's SFA

In the case when the host and the platform supplier are the same entity, but the application provider(s) are others, the resulting SaaS offering is a PaaS — a platform for application development and deployment that is a service to ISVs building these applications and then, in turn, acting as application providers (presumably on the same platform) to the user organization(s).

Example: ForeSoft's dbFLEX

The application provider may be a department of the user organization, serving other departments similarly to a third-party provider serving its customers. Technically speaking, this contradicts the definition of SaaS, which requires that the application be hosted outside of the user organization (not just outside of a department of a user organization). We see growing adoption of "internal SaaS" and, while the business nature of such variation is quite different from the conventional SaaS, the technology involved is the same. Thus, the technology of the internal SaaS legitimately belongs to the SaaS model, even though the business implications and characteristics of internal SaaS do not.

In some scenarios, individual users may contract directly with the provider, leaving out the role of the user organization. This might be referred to as "personal SaaS": The user could have deployed the solution locally, but chooses to use the solution off the external site. Just as enterprise applications, when hosted by a SaaS provider, are enterprise-type SaaS, so personal applications, when hosted by a SaaS provider, are personal-type SaaS. Personal SaaS is out of the scope of this research and is not covered here.

Example: Google's Docs & Spreadsheets

Exceptions notwithstanding, it is useful to always apply the five-level role model to understanding the functioning of SaaS. In a traditional on-premise model, most of the SaaS roles are played by the user organization and the one-to-many hosting rarely applies (although subdividing data by regions or departments is common). The five-level multiplayer relationship of the SaaS model has significant impact on its technology and business requirements.

To support the definitional requirements of SaaS, providers must use suitable platform technology. The standard general-purpose application platforms, such as Java EE implementations and the .NET application platform, can be used for some simple and less demanding SaaS scenarios, using the isolated-tenancy model of deployment (see "How to Evaluate SaaS Architecture Model Choices"). Here, each user organization gets its own system instance (including an instance of the application platform and a database) and, thus, each instance serves only one user organization — each tenant executes in physical isolation. This model works when the provider hosts applications of a relatively few user organizations or when the number of users of each instance is small. However, the cost and complexity of adding, supporting and scaling up a new user organization can be very high. Platforms that are used for isolated-tenancy SaaS cannot be qualified as SaaS-enabled because there is nothing in these platforms that is specially designed for SaaS. The majority of user organizations that are committed strategically to the SaaS model of software are not choosing this model and instead use a dedicated SEAP, although, at this time, this means that they have to rely on proprietary platform designs because no standards have yet emerged for SaaS-enabling and multitenancy of application platforms. Some user organizations choose isolated tenancy to ensure complete isolation, thus expressing lack of trust in the SaaS one-to-many model. This is a familiar problem for most innovations coming to mainstream enterprises: "guilty of immaturity until proven otherwise."

The defining feature of a SEAP is multitenancy. The multitenancy of a platform is its ability to present itself and the applications that are deployed under its control as exclusively dedicated to a group of individual users (user organizations, tenants), while in fact using a common undivided space of computing resources and a single instance of the platform and application code to support multiple such tenants simultaneously. Multitenancy can highly optimize use of computing resources for a large number of tenants and users, but it poses a formidable challenge to deliver truly reliable and secure isolation of the logically independent (and sometimes adversary) tenant operations.

Note that SaaS-style operations can be delivered using regular application platforms (isolated tenancy approach to SaaS, often relying for scalability on virtualization or dynamic grid), so multitenancy is not a requirement of SaaS, but it is a requirement for an application platform, in order for it to be SaaS-enabled.

A more detailed list of features of a SaaS platform is listed in Table 1. Use this list to evaluate competing SaaS platforms relative to each other and to your specific priorities and circumstances. This is not a minimal required list for a usable SEAP, but rather a long list of desired capabilities. Most vendors will deliver some, but not all, of these capabilities, and most users will have a requirement for some, but not all, of the features as well.

Most application and platform vendors either offer or plan to offer support for the SaaS model. Some application ISVs target the SaaS model exclusively, whereas others are planning to support a dual model of letting the prospect choose a SaaS subscription or a perpetual on-premise license for generally the same product. Most platform vendors pursue this dual strategy in that they aim to offer their platform technology for both SaaS application development and in-house deployment applications as well. The market for SEAPs is new and the best practices in the vendor and user strategies are still being discovered. A few vendors have invested ahead of others in developing a strong productized (available to third parties) platform technology for SaaS. These include:

Apex Platform is, without question, the most advanced, although largely proprietary, example of a SEAP. Some of the technology is still in beta, but is imminent and already being extensively used by hundreds of beta partners. Apex Platform offers a runtime environment and a programming language (Apex Code, now in beta) designed specifically and exclusively for SaaS application design. The platform is driven by a centrally controlled metadata repository and all users, tenants, data models, process models, user interfaces and customizations are, in fact, implemented as metadata entries. This allows the Apex development tools to support rapid addition, change and removal of any of these fundamental components of a SaaS application (including new tenants, new users and new interface and data designs). The language is designed to support the data-facing back-end business logic of applications and delegates development of user interface logic to other tools, also part of Apex Platform. Although the language is nonstandard (it is a hybrid of Java syntax style and stored procedure-style data manipulation functionality), it is compiled down to Java and the entire application and the platform execute over a standard Java Virtual Machine. The Apex runtime (Governor) controls all activity and uses the metadata to enforce tenant isolation, including control of prioritized sharing of resources, preventing any one tenant from dominating resource consumption. Salesforce.com acts as the platform supplier, application provider and application host, but the platform also enables third-party ISVs to act as application providers, utilizing salesforce.com as that platform supplier and host.

Cordys offers an application platform for service-oriented architecture (SOA)-style projects, including an XML-based Java application server, a service management environment (SOA Grid), a business process manager, a rule engine and XForms or Ajax-based user interface framework. The internal architecture of the platform supports the notion of an "organization," which represents the tenant unit for a multitenant deployment. A shared organization contains data, metadata and processes that are available to all tenants, and specialized organizations contain components and designs specific to an individual tenant. Cordys development tools automatically make use of Cordys organization entities, allowing multiple instances of the application to run in a multitenant mode over a single actual instance of the Cordys platform. Beyond graphical design, programming for the platform is in standard Java, but not Java EE. To achieve multitenant support in the data store, the application provider must design the application to be aware of tenants. Cordys can also automatically allocate separate database instances to each tenant, freeing the application design from this concern by taking an isolated tenancy approach to data in the middle of multitenant functioning of the process. The existence of the shared organization in the Cordys model allows deployment of the same platform for nonshared on-premise use or shared multitenant SaaS use. There are several customer ISVs that have deployed SaaS-style applications using the Cordys application platform and have deployed, in turn, multiple tenants in these installations. Cordys itself does not act as a host, or as an application provider. In 2006, Cordys entered into agreement with WebEx (now Cisco) to offer jointly a SaaS-style composite application platform and marketplace. The outcome of that work is still pending.

Oracle Fusion Middleware includes the notion of a tenant profile — a metadata object profiling many aspects of a tenant configuration. The profile is available for introspection via Java, SQL and other application programming interfaces (APIs) and is recognized by the Oracle development tools, so Fusion developers are equipped to create multitenant-style applications. The Oracle relational database management system (RDBMS) also recognizes the profile and allows configuration of data in a multitenant mode, on demand (when a DBMS product other than Oracle is used, the application developer is responsible to ensure multitenant data isolation). Multitenant configuration is supported in Oracle implementations of the JSF framework (for multitenant user interface customization), ESB and BPEL Process Manager (for multitenant service and process flow customization), policy support (for multitenant process and data security) and Oracle Enterprise Manager (for multitenant administration and management). Many of the Oracle Fusion Middleware runtime and development tools are multitenant-enabled by way of organizing all configuration metadata in tenant-assigned partitions of the metadata store. However, the core execution container remains a standard Java 2 Platform, Enterprise Edition (J2EE) implementation, not designed for multitenant use. Oracle acts as a platform supplier now, but it plans to offer its Fusion Application Suite entirely SaaS-enabled, at which time Oracle will take on the role of the application provider and application host as well (in addition to the current Oracle CRM On-Demand, acquired as part of Siebel and not based on Fusion Middleware). The current installed base of Oracle Fusion Middleware as SEAP is minimal.

SAP's forthcoming suite of applications for midsize enterprises (now code-named A1S) is planned to be delivered as a SaaS offering and to be enabled by the next version of NetWeaver (now referred to as v.7.1). No further detail is publicly available at this time. However, see Gartner's "SAP Strategy Changes with A1S" for additional comment.

Microsoft's current CRM Live v.3 uses an isolated tenancy approach to supporting SaaS deployment (each tenant deployed on an isolated instance of the platform). The next version (code-named Titan), which is in beta now with several hundred beta ISVs, will be multitenant SaaS. The internal design of Titan is said to be heavily based on metadata-driven functioning (similar to the approach of salesforce.com), including metadata-driven multitenant data models. A programming language over the metadata environment is not planned (programming using .NET languages is possible in the form of Web services, referenced from inside Titan, but such services are not multitenant-aware). XML schemas that control functioning of the application will be published and can be used by advanced engineering teams to create design extensions beyond the tool-based nonprocedural application design. Several Microsoft system products are prerequisite — including SQL Server and IIS. Microsoft is focused on acting as the platform supplier, application provider and host in one, although opportunities for ISVs to create applications for the Titan platform are available and will likely increase over time.

We expect a significant increase in the number of available programmatic platforms for SaaS in the next 24 months. We also expect that support of SaaS operations will become an essential capability for leading platform and application vendors because an increasing number of users will adopt, at least in part, the SaaS format of software solutions. The competitors in the SaaS enablement business will come from many backgrounds, including the application platform vendors (IBM, BEA Systems, Cordys), the application vendors (SAP, Oracle), the Web business vendors (Google, Cisco/WebEx), the computing platform vendors (Sun, Microsoft) and others: The SaaS space is an intersection of many technology evolution paths. This pressure to win new business and to retain or establish leadership in the now-extended platform market will result in a new cycle in the battle for platform domination, leading to a rise of new vendors and demise of some previous-generation leaders. Users must give preference to vendors that invest to establish standards where they are now absent and to maintain openness in all of their technologies — in order to be protected from some of the inevitable changes in the platform market landscape.

Tactical Guideline: By 2012, more than 33% of ISVs will offer some of their applications optionally or exclusively as SaaS, most using a third-party SEAP.

We believe that the SaaS style of application deployment and contracting with solution providers will continue to grow. The growth of this mode of operation into the mainstream enterprise space will put pressure on ISVs to offer the SaaS option. The smaller ISVs will not be able to develop their own platform technologies, nor to establish a scalable hosting environment. They will typically look to join an ecosystem of one or several larger vendors, offering a programmable platform for SaaS. The vendors that offer a programming and deployment environment that is based on standards will reduce cost for such adoption and will have an advantage in attracting a new ISV following over their nonstandard competitors. Meanwhile, we do not expect that demand for in-house deployed applications will dramatically decline in the next five years. Thus, most application vendors will be under pressure to offer applications in dual mode: available as SaaS subscription or as perpetually licensed software. Maintaining the dual model of their products can be expensive for the ISVs, but saying no to their prospects can be perceived as even more expensive. Some ISVs will make the transition to the SaaS model exclusively, others will manage the dual offering for some time, but most will have a SaaS option available.

Tactical Guideline: By 2012, every leading platform technology provider will offer a SaaS-enabled application platform.

We believe that the SaaS style of application deployment and contracting with solution providers will continue to grow. The growth of this mode of operation into the mainstream enterprise space will put pressure on vendors to create a degree of consistency in their technology to reduce the costs and risks for themselves and for users. The leading application platform vendors will invest to offer a programmable platform for SaaS applications based on their proven technology engines, aiming to take a share of revenue in the growing SaaS market and to capitalize on the opportunity to upsell their platform products into a new market.

Increasingly, the leading platform vendors are also application vendors — in this situation, the use of a programmable SEAP will enable a building of an ecosystem of third-party ISVs, utilizing the platform. This is a particularly attractive proposition for the lead vendor, increasing its market influence.

SaaS also presents a notable challenge to platform vendors: The key buyer of platform technology changes from a user organization to an ISV. The majority of business of the leading vendors of platform technology comes from the user organizations (enterprises), and most will be compelled to expand into SaaS quickly to prevent new competitors from establishing domination in this new market and with these new buyers.

Simple SaaS support can be offered using existing standard platforms in an isolated tenancy model, but such an approach cannot compete with the ease of use, flexibility and scalability of the emerging SEAPs. Although most user organizations contract for a SaaS-style business application and do not engage in selecting the underlying application platform, users should be aware of the nature and characteristics of the platforms (even as application providers may want to hide the platforms behind the applications) and should give preference to SaaS application providers that are more confident and more competent in their platform engineering or who rely on an established full-function third-party SEAP. The platform underneath the application is an important predictor of the application's long-term flexibility, scalability and costs.