There is a growing category of outsourcing services that we are encountering that have many of the characteristics of cloud services but are, in fact, not cloud services. While this category of service offerings (which we refer to as “XaaS” for this article) does not fit into the definition of cloud services, they are also very different from standard outsourcing services: They include offerings such as backup and restore as a service, voice as a service and hosting as a service.
In this article, we will describe this category of service offerings and discuss how it differs from standard cloud computing and outsourcing offerings. We will also look at the implications of these distinctions for contracting purposes.
In many cases, XaaS offerings are promoted by new entrants and suppliers in the outsourcing arena, particularly equipment and software providers that are adding service offerings as a means to ensure a continued market for their products among customers who are increasingly attracted to buying services rather than investing in capital assets. These new entrants are oriented toward sale of their products and associated support services, and they approach the contract terms for their XaaS offerings from the standard of a standard product sale, which can place them at odds with customer expectations.
There are a number of important similarities and differences between XaaS offerings and typical cloud services. The XaaS offerings include standardization of architecture and leveraging common processes, tools, release schedules and resources, which allow the supplier to more easily scale the solution. However, XaaS falls short of cloud computing where it relies on an embedded, largely dedicated infrastructure, which imposes fixed costs on the supplier. As a result, the XaaS supplier cannot offer the elasticity and on-demand features of cloud services, and, instead, may require exclusivity or a term or volume commitment as a means of ensuring the supplier can cover its costs and earn a reasonable return.
The particular terms for these XaaS offerings can vary significantly. Each supplier’s offering has to be assessed very carefully for not only the stated cost of the services, but also for the exit costs and risks associated with the service. There can be some substantial compromises required with XaaS offerings for which many customers are not fully prepared.
Some of the factors that have to be weighed in the decision of whether to use these services include (i) the ability of the customer to move to an alternate service provider, (ii) the competitive sensitivity of the outsource function, (iii) the criticality of the outsourced function and (iv) the customer’s reliance on the vendor’s IP and knowledge for support of the outsourced function.
Service Commitments. As noted above, the supplier’s investments often require it to obtain a customer commitment for a minimum term or revenue, which is markedly different from true cloud contracts. We find that this is often less of a concern in practice, since a customer often needs a corresponding commitment by the supplier for continuity of services to ensure the availability of mission-critical support services and sufficient time to plan the transfer upon termination to an alternate provider. This means that the customer will require a corresponding term commitment by the supplier to continue providing services under the same terms. True cloud contracts, by comparison, typically allow the supplier to discontinue the services and change the terms under which the services are offered on little notice.
Cloud services suppliers will only commit to their standard service offering, which the supplier reserves a right to change from time to time. XaaS suppliers will commit to a more detailed description of its services, and those services are often adapted to meet the particular customer’s needs. Indeed, the extent of adaptability of the offering often determines the customer’s ability to use the XaaS service.
Service Quality Protections. With cloud services, there is typically no testing or acceptance process, since the service is a standard offering that does not vary by customer. XaaS, on the other hand, typically includes customer-specific features or functions and, therefore, includes testing of key transition milestones and deliverables against agreed-upon criteria. Cloud services often come with only a few service levels and no service level credits. However, even when service level credits are included, they are generally nominal or accompanied with unrealistic hurdles for obtaining them. The service levels for XaaS are designed for the supplier’s technology architecture, which means they are naturally constrained by the capabilities of that architecture, but the customer can obtain meaningful service level credits. This is important because XaaS often relies on infrastructures or environments that are dedicated to the customer. Consequently, an XaaS provider cannot rely on the typical cloud provider’s claim that “service level credits are unnecessary as a quality incentive, because the provider’s failure to maintain high quality would have an equal effect on all of its customers.”
Customer Control Rights. Standardization of basic architecture is central to XaaS offerings, so the customer will have little to no control over that. However, unlike cloud arrangements, XaaS solutions often allow specialized configurations and customer-selected third-party software to be integrated into, or interfaced with, XaaS solutions. In this respect, XaaS offerings allow more control than true cloud offerings.
Similarly, where a cloud provider retains the right to change its architecture with limited notice or consent from a customer, XaaS offerings include more constraints that require some change control process to protect the customer. An XaaS provider retains the right to update its offering to current versions of the technology, but those changes are contractually required to be implemented with notice, testing and assurance that they will not have a material adverse effect on the customer.
Compliance Obligations. A cloud provider’s standard service comes with no commitment to comply with any particular laws. With XaaS offerings, the provider’s flexibility may be limited by its architecture, but the discussion regarding compliance with laws does not significantly differ from those in other outsourcing agreements: Suppliers generally resist commitments to comply with any customer-specific laws but will agree to laws applicable to their delivery of services to the customer. Customers of XaaS offerings typically receive audit rights to allow the customer to verify that the service meets the contractual requirements. Cloud offerings seldom include such an audit right.
Data and Security Protections. An important distinction between the typical XaaS offering and cloud services is the customer’s increased ability to obtain data protection assurances. With cloud services, data may be processed and stored anywhere, the customer has no right to approve subcontractors, supplier controls are not subject to review or approval, and there is no guaranty that all data will found and erased or returned. With XaaS offerings, data location is fixed in the contract, there are agreed-upon limitations on subcontractor access to data, the level and type of security is often a customer-selectable option, and the contract includes assurances regarding the return or destruction of data.
Intellectual Property Protections. With cloud services, the supplier retains ownership of all IP, the only exception being the customer’s ownership of the data it provides. XaaS suppliers are equally concerned about retaining ownership of their standardized solutions, but there are sometimes exceptions for customer-specific adaptations. However, the XaaS supplier’s concern about protecting the flexibility of its “solution” may result in a joint ownership or a license option in lieu of sole ownership of those adaptations by the customer.
Service Continuity Protections. Cloud service contracts contain no commitments regarding continuity of personnel, allow the supplier to interrupt services for suspected violation of usage rules and contain no business continuity commitment. The picture is much different with XaaS arrangements, which lend themselves more easily to some personnel continuity commitments, interruptions of service are limited to protecting service integrity and are limited in scope and time; and business continuity is often available as priced options based on the amount of protection required.
Termination Assistance. Termination assistance with cloud contracts often amounts to no more than a commitment to return the customer’s data; the customer has no rights to continue using any of the supplier’s IP following expiration or termination of the services. XaaS contracts often include a commitment to assist the customer with the transition of services back to the customer or to another supplier, including the customer’s right to extend the period of the services as needed to ensure a smooth transition.
Post-Termination Rights. Post-expiration or termination rights vary with the nature of the services. For XaaS suppliers that are also in the business of selling their hardware and licensing their software, the customer generally has the right to purchase or license the components for continued use. In addition, where customized changes or configurations are made to allow integration with the customer’s environment or customer-selected third-party software, it is not unusual for the customer to obtain a license to continue using those customizations.
XaaS offerings do not provide all of the on-demand and elasticity features of cloud services. However, they do offer many of the benefits of standardization without many of the pitfalls that stymie the adoption of cloud services by large companies concerned about protecting their important functions and sensitive data. XaaS may well be the bridge for companies to eventually design their processes and systems to allow them to migrate many of their systems to cloud computing in the future.
To read this complete article visit Business & Technology Sourcing Review - Issue 18.