Introduction
Software as a Service (SaaS) has become a hot topic over the past few years. As a result of this heightened interest, the Department of Defense Enterprise Software Initiative (DoD ESI) developed the SaaS Toolkit to provide independent and unbiased educational materials for the DoD information technology acquisition and management community. The toolkit is available at www.esi.mil and provides access to decision-analysis tools and contract-related forms to streamline the process of understanding, evaluating and acquiring SaaS offerings throughout the DoD. This article captures some of the key educational content from the toolkit and explains the key differences between perpetual licensing and the SaaS model.
What is SAAS?
SaaS is a method of software deployment and an alternative to perpetual software licensing. With SaaS, applications are owned, delivered and managed remotely by one or more providers over the Internet or an intranet, and licensed to customers as an on-demand service. An application can be run directly from a SaaS provider's Web servers or downloaded to an end-user's device; and it can be disabled after use or after the on-demand contract expires.
SaaS falls within the overarching delivery model that packages technical offerings "as-a-service." This includes Infrastructureas-a-Service and Platform-as-a-Service. These other offerings are not addressed in this article or in the SaaS Toolkit.
With on-premises, perpetual software licensing, the customer owns, operates and maintains software applications and the hardware servers that support the applications. With a SaaS model, the SaaS provider owns, operates and maintains the software and supporting hardware servers, which also reduces the customer's data center floor space and utility requirements.
Effects on the major asset of talented, skilled IT staff varies for customers depending on their enterprise objectives. SaaS reduces IT workload for any application acquired or migrated, which often will be leveraged to free IT staff to focus on more important tasks (since there are fewer applications, systems and data center facilities to maintain). See Table 1 for a summary of SaaS benefits.
Historical View
In the early years of the commercial computer industry, applications were bundled with computer hardware which, over time, became too expensive for vendors. The first software firms started in 1960 to support universities and businesses seeking to perform specific computing tasks.
The software industry began to expand rapidly with the introduction of personal computers in the mid 1970s.
This included businesses involved in the development, delivery and maintenance of computer software, as well as consulting services for product selection, implementation and training.
The expertise and resources required to deploy and maintain increasingly sophisticated business software applications created opportunities for alternative forms of software delivery models. While service bureaus have provided some technology-based services, such as those for payroll processing, since the 1960s, the concept of application service providers (ASPs) emerged as a viable alternative to on-premise software licensing in the late 1990s. Among ASP business models, which include SaaS and managed hosting services, the market for SaaS solutions has gained far more momentum in the 21st century. See Figure 1 for a historical overview of fee-based applications software development.
Pricing
SaaS fee structures can vary greatly by application and service provider. At the most basic level, there are two general pricing models:
• Subscription pricing based on a per user, per functionality, per month/year fee; and
• Usage-based pricing with metrics such as number of transactions over a fixed period of time.
Providers can charge a flat rate for unlimited access to some or all of an application's features, or varying rates that are based on number of users, application features, applications versioning, etc. (Note: A managed hosting service that requires a customer to license software and purchase or lease hardware servers is not SaaS.) Pricing can be affected by the providers' architectural models.
Multi-tenant (one-to-many) "pure" SaaS providers operate with the greatest economies of scale and pricing flexibility. Pricing can also be affected by a customer's special needs. A requirement that data cannot be transferred to any offshore location, for example, can impose additional operating costs on a service provider and therefore increase pricing to the customer.
IMPLEMENTATION
Roadmap
Most SaaS providers and third party systems integrators offer consulting services to help configure SaaS offerings to achieve a customer’s objectives. Many independent consulting firms now include SaaS implementation in their services portfolio and several firms specialize exclusively in SaaS planning, implementation, training, change management and long-term support for follow-on integrations with other SaaS or on-premise software applications.
Implementation processes range from simple to complex, depending on the scope of the business
solution to be achieved. For applications that can be addressed by SaaS — and more appear on the market virtually every day — implementation tasks and time to deploy are significantly less than attempting the same solution with an on-premise software implementation. Figure 2 provides the major steps for implementing SaaS.
New Applications vs. Migration
It is generally agreed that data conversions and migrations can be as difficult for SaaS as they are for on-premises software. However, this thinking is evolving since SaaS delivers new “net native” applications
that can be more easily integrated with any software available as-a-service (i.e., service oriented architecture).
SaaS providers are also making advancements with new software frameworks and tools to reduce the cost of converting a traditional software product and/or building a new SaaS equivalent. Typically, new SaaS applications are easier to implement, even if some functionality must be surrendered. Large organizations have an advantage of seeing that functionality restored through their SaaS solution by leveraging their business value to the SaaS provider in contract negotiations.
Many SaaS providers will invest in accommodating new functionality to secure a large organization’s business and to attract other like business from the growing prospect pools. When evaluating a migration from a perpetual license to a SaaS alternative for use of the same software publisher’s technology, there are additional financial issues to be raised.
First, since a significant investment has already been made in the up-front license fee for the perpetual license, the negotiation of the SaaS price per month should allow for discounting or a credit since you already possess the license. Ask the SaaS provider for appropriate price concessions to reflect these existing licenses.
Second, it should be clear that your existing application, as configured and interfaced, should be maintained by the provider. This results in a relationship that is more aligned with an ASP than a pure
SaaS model since you will want the title to the application to remain with the client.
In any migration from a perpetual license to a SaaS alternative that results in excess perpetual software licenses, the excess licenses should be made available for possible reuse within the DoD IT asset management framework. See Table 2 for a summary of pros and cons to be considered when evaluating a SaaS solution.
CONTRACTING
Service level agreements (SLAs) provide an agreed upon framework for the delivery of services and the measurement of service quality. SLAs are negotiated between the provider and the user to ensure
that the expectations of services are realistic and within the provider’s capabilities. SLAs provide detailed specifications of services to be delivered, the costs of delivering those services, the services’ availability, problem management criteria and performance measurements.
It is important to be accurate about the required level of service and how costs are determined for the varying levels of service required. The SLA should address what constitutes lack of service, how a failure to meet service levels is remedied and what happens if the SaaS subscription expires or is terminated.
The contract should very clearly address what happens if the SaaS provider is sold or goes out of business or otherwise can’t deliver the service required. For instance, all data must be transmitted in a format directed by the buyer to a location directed by the buyer within a clearly defined number
of days after notice from the buyer. For critical applications, an escrow provision or third party escrow agreement should be entered to place the source code in escrow in the event the provider files for bankruptcy or closes its doors.
To assist DoD programs in the development of SLAs for SaaS, the DoD ESI is developing a Service Level Agreement Template and a Service Level Agreement Checklist to be made available in a future version of the SaaS Toolkit.
SLA Development Process
Figure 3 illustrates the process that may be used when drafting and negotiating a SLA. This process may be helpful in guiding the contracting and program team in developing an SLA that meets the business and technical requirements desired.
SaaS is a software delivery model that should be considered by DoD programs but evaluated very carefully before selection. The SaaS Toolkit, located at www.esi.mil/, should be consulted to provide
a foundation of knowledge and access to tools to help any DoD program office decide if SaaS is the right model for its program.
Chris Panaro supports the DON CIO Enterprise Commercial IT Strategy Team. He can be reached through ESISupportTeam@navy.mil.