OPEN DATA CENTER ALLIANCE USAGE Model: Software as a Service (SaaS) Interoperability Rev 1.0

OPEN DATA CENTER ALLIANCE USAGE Model:

Software as a Service (SaaS) Interoperability Rev 1.0

Open Data Center Alliance: Software as a Service (SaaS) Interoperability Rev 1.0

Table of Contents

Legal Notice ... 3

Executive Summary ... 4

Purpose ... 5

Assumptions ... 5

SaaS Interoperability Usage Scenarios... 6

Business Driver Mapping ... 6

Usage Scenarios ... 7

Usage Scenario 1—Service Configuration ... 7

Usage Scenario 2— Bulk Data Transfer ... 8

Usage Scenario 3— Real Time Data Access ... 9

Usage Scenario 4— Service Aggregation ...10

Usage Scenario 5— Service Transfer...11

Usage Requirements ...12

RFP Requirements–Service Providers ...13

Summary of Industry Actions Required ...14

Legal Notice

© 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

This “Open Data Center Alliance

Usage Model: Software as a Service Interoperability” is proprietary to the Open Data Center Alliance, Inc.

NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Open Data Center Alliance Participants only have the right to review, and make reference or cite, this document. Any such references or citations to this document must give the Open Data Center Alliance, Inc. full attribution and must acknowledge the Open Data Center Alliance, Inc.’s copyright in this document. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way.

NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Open Data Center Alliance Participants is subject to the Open Data Center Alliance’s bylaws and its other policies and procedures.

OPEN CENTER DATA ALLIANCE

, ODCA

and the OPEN DATA CENTER ALLIANCE logo

are service marks owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited.

This document and its contents are provided “AS IS” and are to be used subject to all of the limitation set forth herein.

Users of this document should not reference any initial or recommended methodology, metric, requirements, or other criteria that may be contained in this document or in any other document distributed by the Alliance (“Initial Models”) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models.

Any proposals or recommendations contained in this document including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria does not mean the Alliance will necessarily be required in the future to develop any certification or compliance or testing programs to verify any future implementation or compliance with such proposals or recommendations.

This document does not grant any user of this document any rights to use any of the Alliance’s trademarks.

All other service marks, trademarks and trade names referenced herein are those of their respective owners.

Published August 2012.

OPEN DATA CENTER ALLIANCE USAGE Model:

Software as a Service (SaaS) Interoperability Rev 1.0

SM

Executive Summary

Software as a Service (SaaS) is a-model for service delivery based on on-demand software applications that offer an alternative to purchasing applications and providing local provisioning, integration, support, and maintenance. Characteristics of SaaS include multi- tenancy, pay-as-you-go subscriptions, central application management and infrastructure, frequent upgrades, and little to no custom code.

With the growing availability of many new SaaS solutions, organizations desire common integration methods and services to support agility and the rapid proliferation of new capabilities.

This usage model outlines five usage scenarios based on two perspectives of interoperability, along with success and failure scenarios for each. In addition, service provider requirements and an industry call to action are presented.

This document serves a variety of audiences. Solution providers and technology vendors will benefit from its content to better understand

customer needs, and tailor service and product offerings. SaaS customers will be able to benefit from the ability to interact with a common

solution across multiple providers for the same SaaS application. Standards organizations will find the information helpful in defining end-user

relevant and open standards.

Purpose

The ODCA SaaS Interoperability Usage Model was written to encourage consistent mechanisms to enable cloud subscribers to quickly and efficiently consume SaaS by standardizing interactions between cloud subscribers and cloud providers. With the primary benefit of cloud computing freeing up an organization from proprietary infrastructure, it follows that open standards are desired for interoperability.

The business drivers for SaaS interoperability follow:

• On-boarding and Administration: Enables subscribers to quickly establish and scale new service capabilities for their organization.

Reduces the overhead associated with ongoing SaaS synchronization.

• Value Add Business Processes: Fosters the ability to address market opportunities and business problems by dynamically construct- ing business processes that use SaaS-based components and data.

• Business System Migration: The subscriber moves from one discrete SaaS solution to another from the same or a different provider.

For example, moving from one customer relationship management solution to another.

• Business Continuity: Migrates or replicates SaaS-functional capabilities and data to address outages, security breaches, data corruption, or other disruptions, and encompasses both disaster recovery and disaster avoidance.

Assumptions

The following assumptions apply to all usage scenarios described in this document:

1. A properly executed service agreement is in place between the SaaS provider and the consumer that identifies capabilities, costs, operational level of agreements (OLAs) and service level of agreements (SLAs). This could be a document similar to the Commercial Services Framework from the ODCA.

2. SLAs and OLAs include items such as these:

• Availability

• Security, privacy and compliance

• Geographic hosting requirements

• Data owner, roles and responsibilities (e.g., backup, etc.)

3. SaaS is provisioned as part of a large scale solution used by many employees of an SaaS subscriber, though there is enough flexibility to include cases in which an individual department or end-user sources its own solution.

4. Interactions involve either a single application from a single provider or multiple SaaS solutions from one or more providers that are combined as part of a larger, end-to-end business process.

5. Automated provisioning of user identity and access management is in compliance with the practices described in ODCA Cloud

. When user accounts are added, deleted, or modified, SaaS solutions are automatically updated with these changes.

6. Out of scope are the following:

• SaaS providers moving SaaS solutions among IaaS or PaaS clouds.

• Interconnectability among SaaS solutions on the backend, which are abstracted, and therefore not visible to the subscriber.

Open Data Center Alliance: Software as a Service (SaaS) Interoperability Rev 1.0

SaaS Interoperability Usage Scenarios

Interoperability Perspectives

Interoperability perspectives are the basic categories that define the scope into which the business usages fall. Interoperability perspectives follow:

• Interconnectability —The parallel process in which two coexisting environments communicate and interact.

• Portability—The serial process of moving a system from one cloud environment to another.

In terms of SaaS, these perspectives can be applied at the data layer, the SaaS service layer, and the business layer.

• The data layer includes all SaaS data sources and sinks, as well as the protocols, services, and tools used to interact with that data.

• The SaaS service layer refers to all of the components that constitute the SaaS solution, which include runtime executables, libraries, mash-up components, and callable application programming interfaces (APIs).

• The business layer includes business context and composition where a SaaS solution is orchestrated with other services in a mean- ingful and productive format for specific business processes.

Additional information on interoperability definition and scope can be found in ODCA Usage Model: Guide to Interoperability Across Clouds

.

Business Driver Mapping

For each of the business drivers identified in the “Purpose” section, one or more corresponding usage scenarios are identified in the following table, aligning to the SaaS Interoperability perspectives.

Business Driver Interconnectability Portability

On-boarding & Administration Usage Scenario 1–Service Configuration Usage Scenario 3–Real Time Data Access

Usage Scenario 2–Bulk Data Transfer

Value Add Business Processes Usage Scenario 4–Service Aggregation Usage Scenario 3–Real Time Data Access

(not applicable)

Business System Migration Usage Scenario 1–Service Configuration Usage Scenario 3–Real Time Data Access

Usage Scenario 5–Service Transfer Usage Scenario 2–Bulk Data Transfer Business Continuity Usage Scenario 1–Service Configuration

Usage Scenario 3–Real Time Data Access

Usage Scenario 5–Service Transfer

Usage Scenario 2–Bulk Data Transfer

Usage Scenarios

Usage Scenario 1—Service Configuration

Business Drivers: On-boarding and Administration, Business System Migration, Business Continuity Interoperability Perspective: Interconnectability

Goal:

Interoperability between the cloud subscriber and the cloud provider to configure an SaaS solution in the context of initial provisioning and ongoing administration and maintenance.

Assumption 1: The SaaS subscriber has signed up for the SaaS solution, and the provider has provisioned a set of resources according to the selected multi-tenancy model: single or multi-tenant.

Success Scenario 1:

The solution is fully configured and tested without requiring the development of custom code specifically designed to run in that SaaS environment.

Steps:

1. SaaS provider establishes the admin account for the subscriber to use for confirming access and for controlling ongoing user administration, reporting, and customization.

2. SaaS provider provides online documentation and tools that define the scope of available configuration and customization features, in a clear and concise format, with step-by-step details.

3. Subscriber identifies business-specific configuration items. Items might include the following:

a. Branding that may include co-branding or white-label support for the subscriber.

b. System-level workflows that define how administrative and customization changes are made.

c. Policies that define high-level rules for how administration and customization are performed.

d. Role identification and mapping that define functionality within the enabled solution, based on end-user roles, such as super users.

e. User personalization that defines how each subscriber’s user can alter an online session with personal customization.

4. Subscriber effects the configuration and tests changes by using a self-service approach through an online portal or API. Changes take effect immediately.

Failure Condition 1:

Configuration does not work as expected, once the provider informs the subscriber that the solution is available.

Failure Handling 1:

Remediate according to support agreement.

Open Data Center Alliance: Software as a Service (SaaS) Interoperability Rev 1.0

Usage Scenario 2— Bulk Data Transfer

Business Drivers: On-boarding and Administration, Business System Migration, Business Continuity Interoperability Perspective: Portability

Goal:

Securely and reliably exchanging asynchronous data on a singular or regular basis.

Assumption 1: Data referred to in the interchange process originates from a data store at either the subscriber or SaaS provider site.

Assumption 2: Automated data exchange process has been designed, implemented, and tested, as part of service provisioning.

Assumption 3: Exchange can be single or bi-directional.

Assumption 4: Data can be exchanged through a third party.

Assumption 5: There is a method of providing a transactionally consistent copy of the data.

Success Scenario 1:

Data is successfully and securely exchanged between the subscriber and the SaaS provider. No application downtime will occur during data transmission and upload into the application data store, although there might be an impact on performance. A copy of the data is transmitted to the other party.

Steps:

1. Subscriber defines or refines metadata, transformation mapping, and schedule for data exchange at the source and destination.

2. Prepare source data for exchange in the correct machine-readable format in an industry standard, self-descriptive format, as specified in the provider’s documentation.

3. Establish a secure connection between subscriber and provider via an automated transfer.

4. Send and receive data with orchestration, such as handshaking, timeouts, and retries, as appropriate.

5. Perform data quality check.

6. Close connection.

7. Acknowledge receipt.

Failure Condition 1:

Failed to establish a connection.

Failure Handling 1:

Retry specified number of times and log errors. Alert subscriber if the maximum number of retries is exceeded. Both parties execute

Failure Handling 3:

Discard and re-exchange data or take other appropriate remediation steps, as defined in the SaaS application documentation.

Usage Scenario 3— Real Time Data Access

Business Drivers: On-boarding and Administration, Value Add Business Processes, Business System Migration, Business Continuity Interoperability Perspective: Interconnectability

Goal:

Synchronous access to data at application runtime through provided standard interfaces.

Assumption 1: Data is located in a data store at either the subscriber or provider site.

Assumption 2: Access can be as read only or read/write, according to the source provider policies.

Assumption 3: Access can be facilitated through a third party.

Assumption 4: No direct data access to data stores; the data consumer uses a controlled, scalable services interface.

Note: Real Time Data Access is a special purpose usage scenario of Service Aggregation, which is described in the next section.

Success Scenario 1:

Data is successfully and securely accessed with the ability to audit who accessed the data.

Steps:

1. Subscriber defines or refines metadata and transformation mapping at the source and destination.

2. API is consumed at the subscriber destination application.

3. Subscriber uses SaaS capability that requires data access.

4. Establish a secure connection.

5. Read, write, insert, and delete data through an API with access logging, as appropriate.

6. Close the connection.

Failure Condition 1:

Failed to establish connection.

Failure Handling 1:

Retry specified number of times and log errors. Alert the subscriber if the maximum number of retries is exceeded. Both parties execute remediation or manual intervention defined for the alert.

Failure Condition 2:

Error in create, read, update, delete (CRUD) process.

Failure Handling 2:

Retry specified number of times and log errors. Alert the subscriber if the maximum number of retries is exceeded. Both parties execute

Open Data Center Alliance: Software as a Service (SaaS) Interoperability Rev 1.0

Usage Scenario 4— Service Aggregation

Business Drivers: Value Add Business Processes Interoperability Perspective: Interconnectability

Goal: Self-service, heterogeneous service composition and orchestration (mash-up) across cloud provider and subscriber sites.

Assumption 1: New compositions are constructed from one or more APIs or components, from single or multiple providers, where at least one component is SaaS-based.

Assumption 2: SaaS subscriber is signed up for SaaS; SLAs are in place for SaaS APIs.

Assumption 3: Content aggregation can take place either on the server or on the client.

Assumption 4: Support is provided for open, standardized protocols (Widgets, RESTful web APIs), data formats (JSON), and standards (OAuth).

Assumption 4: APIs are versioned.

Success Scenario 1:

SaaS subscriber manages the composition of various services to achieve a new set of end-to-end functionalities through simple, open, easily-adopted APIs that are supported, documented, and have code examples.

Success Scenario 2:

SaaS mash-up consumption from a diverse set of platforms, including operating systems, programming languages, and applications.

Steps:

1. SaaS provider component developer develops and publishes mash-up components and descriptions.

2. SaaS subscriber mash-up composer discovers SaaS mash-up component.

3. SaaS subscriber mash-up composer uses mash-up tool or manual composition to build a mash-up and debug it using client-side diagnostics.

4. SaaS subscriber makes mash-up available as part of the service catalog.

5. SaaS subscriber end user invokes mash-up application by using enterprise credentials.

Failure Condition 1:

HTTP 400 or 500 errors returned by an operation.

Failure Handling 1:

Specific action is taken by the subscriber, based on the returned error code.

Usage Scenario 5— Service Transfer

Business Drivers: Business System Migration, Business Continuity Interoperability Perspective: Portability

Goal:

Migrate a particular capability from one SaaS solution to another from the same or different SaaS provider.

Assumption 1: Porting from one SaaS solution to another involves end of life from one source solution, and establishing a new service with another destination solution.

Assumption 2: There can be overlap in the services while cutting over from one application to another.

Assumption 3: Service configuration and data transfer are covered in detail as part of other usage scenarios, and are mentioned only briefly in this scenario.

Success Scenario 1:

The SaaS subscriber has exported all data from the source application and has established new service in the destination application. The source application is no longer available to subscriber end users.

Steps:

1. SaaS subscriber identifies destination SaaS solution and determines level and scope of transition.

2. SaaS subscriber formally notifies SaaS providers and sets transition timeline.

3. SaaS provider establishes service for the destination SaaS solution, including data and configuration.

4. SaaS subscriber decommissions any regular data exchanges with the source SaaS solution.

5. SaaS subscriber communicates changes to end users, and provides notification of any downtime.

6. SaaS provider of source application terminates end-user access.

7. SaaS subscriber directs end users to the destination SaaS solution.

8. SaaS subscriber recovers final data from the source SaaS solution.

Failure Condition 1:

Lock-In to the source SaaS solution such that it is expensive and disruptive to migrate from one solution to another.

Failure Handling 1:

Lock-In avoidance measures such as configuration through metadata, and ownership over data and format, and no custom code.

Failure Condition 2:

Unintended disruption to mash-ups.

Failure Handling 2:

Clear and timely communications within the SaaS subscriber.

Open Data Center Alliance: Software as a Service (SaaS) Interoperability Rev 1.0

Usage Requirements

The features in the following table are derived from the usage scenarios in the previous section, and are aligned with the ODCA Standard

.For this usage model, it is not intended that all of the features in a given column must be supported as a group. In practice, a given service provider solution will combine different service levels for different elements. For example, all Bronze Performance feature requirements must first be met before combining features from any other performance level. For instance, Gold Security features can be combined with Bronze.

Bronze Silver Gold Platinum

Application Basic Enterprise equivalent Critical market or business sector equivalent

Military or safety-critical equivalent

Security As per ODCA Provider Assurance Usage Model

Formal Documentation Online documentation for all service interfaces, GUIs, and command lines Self-Service

Configuration

Online portal and command line interface

Online portal, command line and callable APIs

Online portal, command line and callable APIs

Online portal, command line and callable APIs

Metadata Online metadata

catalog; Definitions in cloud provider’s choice of standard

Online metadata catalog with search; Definitions in cloud provider’s choice of standard

Metadata discovery with automated tools;

Definitions in recognized industry standard consistent with ODCA

Metadata discovery and mapping with automated tools; Definitions in recognized industry standard consistent with ODCA

Data Import/Export Format

Specified File Format

APIs APIs Versioned APIs

Asynchronous Data Exchange Process

Semi-automated, scheduled batch exchange, which may include manual steps and stages of data

Semi-automated, scheduled batch exchange with hook-up and reconnection, and orchestration

Fully-automated service interface hook- up and reconnection, orchestration and interconnection at large scale, with auditability and

Fully-automated service

interface hook-up and

reconnection, orchestration

and interconnection

at large scale, with

auditability and reporting

Bronze Silver Gold Platinum

Web Services Interface Standard

Programmatic web services in cloud provider’s choice of standard

Programmatic web services in cloud provider’s choice of standard

Programmatic web services in recognized industry standard, consistent with ODCA concepts

Programmatic web services in recognized industry standard, consistent with ODCA concepts

Web Services Scope Available for one or two key user- facing capabilities

Available for all key user-facing capabilities;

all data exchange

Available for all key user-facing capabilities;

all data exchange; some administration

Available for all key- user capabilities, all data interactions and all administrative items

RFP Requirements–Service Providers

Following are requirements that the Alliance believes should be included in requests for proposal to cloud providers to ensure that proposed services support SaaS interoperability. Additional recommended requirements are contained in the ODCA Cloud Based Identity Provisioning

and ODCA Security Provider Assurance

usage models.

ODCA Principle Requirement—Service is open and standards-based. Describe how the service meets this principle and any limitations towards the ODCA principle.

Configuration and Administration Requirements:

ODCA SaaS Interoperability Usage Model 1.0—The environment can be customized by the subscriber for specific look and feel, workflow, and branding considerations. The subscriber’s employees can personalize the environment for their individual preferences.

ODCA SaaS Interoperability Usage Model 1.0—The system provides a means to view system health, availability, and subscriber usage.

ODCA SaaS Interoperability Usage Model 1.0: The SaaS provider and subscriber will develop and maintain an agreed upon communication plan to advise the subscriber and any impacted subscriber employees of events impacting service or data.

ODCA SaaS Interoperability Usage Model 1.0—Should an incident have potential legal implications, notice should be given to the subscriber that an event has taken place and that specific laws or regulations may have been violated. Every reasonable effort should be made by the SaaS provider to communicate all details as soon as possible. If the risk is valid, and continued operations would put subscriber at risk, the SaaS provider can suspend services.

Data Exchange Requirements:

ODCA SaaS Interoperability Usage Model 1.0—The subscriber maintains ownership of all raw and processed data that is provided by or originates from the subscriber. The provider may not copy or distribute any subscriber data without the permission of the subscriber.

ODCA SaaS Interoperability Usage Model 1.0—Data exchange mechanisms are based on data-interchange standards, such as JSON and XML.

ODCA SaaS Interoperability Usage Model 1.0—The frequency and size of all interfaced data to various systems will be defined in a

documented design with the SaaS provider and subscriber.

Open Data Center Alliance: Software as a Service (SaaS) Interoperability Rev 1.0

ODCA SaaS Interoperability Usage Model 1.0—The system provides diagnostic tools and testing mechanisms that the subscriber can use to validate data exchange mechanisms using test data.

ODCA SaaS Interoperability Usage Model 1.0—Adequate logging is in place to detect unauthorized access, modification, or deletion of data in transit and data at rest.

ODCA SaaS Interoperability Usage Model 1.0—Use of the subscriber’s data is limited to the contracted SaaS service, and may not be used by the provider for other purposes, such as data mining or analytics, without permission from the subscriber.

ODCA SaaS Interoperability Usage Model 1.0—Authorized subscriber employees may securely export a copy of all subscriber data from the SaaS provider for backup, migration, or other purposes. In the event of service termination, the SaaS provider is required to retain data for 90 days to allow the subscriber time to export all data.

ODCA SaaS Interoperability Usage Model 1.0—When no longer required, data must be permanently removed in accordance with a mutually agreed upon data retention policy in order to prevent any possible unauthorized data recovery.

Web Services Requirements:

ODCA SaaS Interoperability Usage Model 1.0—Within the terms of the service agreement (i.e., service metering), the subscriber can utilize SaaS capabilities to build and deploy composite enterprise applications and mashups.

ODCA SaaS Interoperability Usage Model 1.0— Application capability is based on service standards if the subscriber is consuming SaaS as a web service (e.g., REST or SOAP).

ODCA SaaS Interoperability Usage Model 1.0—The system provides diagnostic tools and testing mechanisms that the subscriber can use to check connectivity, as well as the compatibility of web services used in a business process composition.

Click here for an online assistant, Proposed Engine Assistant Tool (PEAT)

, to help you detail your RFP requirements.

Summary of Industry Actions Required

In the interest of giving guidance on how to create and deploy solutions that are open, multi-vendor and interoperable, we have identified

specific areas where the Alliance believes there should be open specifications, formal or de facto standards, or common intellectual property-

free (i.e., IP-free) implementations. Where the Alliance has a specific recommendation on the specification, standard, or open implementation,

it is called out in this usage model. In other cases, we will be working with the industry to evaluate and recommend specifications in future

releases of this document.