sm Open Data Center Alliance Usage: SERVICE CATALOG
Legal Notice This Open Data Center Alliance SM Usage: Service Catalog 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 SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo SM 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. 2
sm Open Data Center Alliance Usage: SERVICE CATALOG Executive Summary The worldwide market for cloud services encompassing both dedicated services available via private clouds and shared services via public clouds could top $148.8 billion in 2014, up from $68.3 billion in 2010. The sheer, and growing, volume of available services make it challenging for any organization to assess their options, measure what services are being delivered, and determine what attributes exist for each service. Service catalogs are designed to aid organizations in their assessment and selection of cloud services. A service catalog is an essential component of any provider s offering; it is the mechanism by which a customer can determine the capabilities and characteristics of one or several providers services in a normalized manner. But there is a lack of consistency and standards which could provide a baseline for service catalog attributes. The Open Data Center Alliance SM recognizes the need for a well-implemented set of service catalog requirements that will enable precise standards for comparability across various providers offerings. This Usage Model is aimed at shaping the best practices and mechanisms that should be included in service catalogs. Purpose The goal of this Service Catalog Usage Model is to highlight the need for the cloud industry to create consistent ways to describe standard services to encourage the evolution of a dynamic global marketplace based on open discovery and free market principles. As well as standard services, the Service Catalog needs to permit providers of cloud services to add value by offering extensions of standard services and providing custom solutions. The provider benefits from greater volume on the standard offerings, with lower costs of sale and more opportunities to optimize the service delivery, but also has the opportunity to differentiate with extended and custom solutions. The organization subscribing to the cloud services benefits from greater choice, liquidity, and price transparency on the standard services, while still being able to select extended or custom solutions that provide further value specific to their needs. The requirements and outline processes described in this Service Catalog Usage Model enable organizations subscribing to cloud services to perform a more precise and programmatic discovery of comparable services among providers and to better price and negotiate service extensions with reference to the nearest comparable standard services. In turn, providers of cloud services will be able to extend standard offerings in a standardized way to add differentiated value between their services and a competitor s similar services. This thinking is applicable to all kinds of cloud services, from Infrastructure as a Service (IaaS) to Platform as a Service (PaaS) and Software as a Service (SaaS), and to other kinds of services such as Virtual Private Data Center as a Service (VPDCaaS). 3
taxonomy Actor Cloud-Subscriber Cloud-Provider Description A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. An organization providing network services and charging Cloud-Subscribers. A (public) Cloud-Provider provides services over the Internet. API Accessibility A key requirement of this Service Catalog Usage Model is the Application Programming Interface (API) used to access the catalog. A medium to large enterprise Cloud-Subscriber expects to programmatically and securely interrogate via an API the Service Catalogs of multiple Cloud-Providers to assess capabilities, qualities, availabilities and prices of services as needed. This activity will typically be linked to the orchestration or migration of large numbers of services, either in individual units or more often in blocks of service resources. As such, an individual Cloud-Provider s Service Catalog is one of several data sources that we will feed into Cloud-Subscribers own internal service catalogs and policy orchestration engines. A graphical user interface (GUI) is oriented towards a manual process and is essential for an individual client or small business. However, a GUI is of relatively low importance to our target Cloud-Subscriber, who may choose not to use it at all for service discovery and selection. Instead, Cloud-Subscribers need a robust and detailed API interface to interrogate the Service Catalog. The following high-level diagram depicts the basic interactions between Cloud-Subscriber and Cloud-Provider, highlighting the key role that the API will have in the discovery and related subsequent service activities. Management, Monitoring, and Reporting Service Catalog Data Model API Provisioning and Deployment 4
The Open Data Center Alliance believes the formal definition of the Service Catalog data model is important for the evolution of an enterprise-ready open cloud marketplace. A common data model for the Service Catalog will help drive widespread adoption by Cloud-Providers and enable Cloud-Subscribers to access Provider Service Catalogs using one standard data model interface. By providing a clear set of requirements at a variety of service levels, carefully underpinned with a set of common legal and commercial master documents, Cloud-Subscribers in this cloud ecosystem will be able to execute at scale, with more confidence and with much lower overhead to adoption. Usage Model Example Cloud-Subscriber wants to host an instance of one of their applications at Cloud-Provider. The solution consists of multiple physical and virtual infrastructure components with specific Service Level Agreement (SLA), compliance, and end-user performance requirements. Cloud-Subscriber wishes to programmatically interrogate each Cloud-Provider s catalog to determine whether Cloud- Provider can offer: 1. The desired standard or custom services, such as: Specific VPDCaaS, IaaS, PaaS or SaaS services to host the application 2. The desired technical attributes, including: Capacity, performance, automation, OS, etc. Bandwidth, connectivity, network capacity to access the service 3. The desired environmental constraints, such as: Geographic location Regulatory/legal requirements or pre-approvals Validated third-party assessments, etc. 4. The desired SLAs and qualities of service, including: Operationally, by product Provisioning/de-provisioning times 5. The desired commercial terms, including: Cost per unit of capacity or consumption Cost uplift/rebate for each service assurance parameter Cost for any custom extensions Discount structure for scale, base commits, etc. Surcharges (as necessary) for pre-reservation of capacity, etc. 6. Availability for delivery of service in the required timeframe, including: Amount of capacity immediately in stock Amount of expandability in a defined amount of time to support growth 5
Open Data Center Alliance Usage: Service Catalog Since Cloud-Subscriber has pre-selected a fixed number of Cloud-Providers, service products and options, and pre-negotiated pricing with each Cloud-Provider, the Cloud-Subscriber expects to be able to filter each Cloud-Provider Service Catalog to those components they wish to auto-populate to their internal service catalog for regular usage. However, for the Cloud-Subscriber s service design and pricing teams, the Cloud-Subscriber may wish to remove the filter from a Cloud-Provider s Service Catalog to enable review of all solutions for creation of one-off solutions. Therefore, Cloud-Provider s Service Catalogs must be able to authenticate with Cloud-Subscriber in order to support multiple roles and contexts for query. Those different roles and contexts would typically produce different sets of data (e.g., restricting fields such as pricing to the sourcing teams, security details to the security teams, and restricting the choice for end-users to those services they are permitted to discover and select). Function Map The following diagram depicts how the Cloud-Subscribers will interact with a Cloud-Provider s Service Catalog. 6
The Function Map shows the Cloud-Subscriber provisioning process across one or more Cloud-Providers. The steps are as follows: 1. Cloud-Subscriber defines corporate governance requirements for a new service. 2. Cloud-Subscriber programmatically reviews Cloud-Providers in the open cloud ecosystem using the Alliance-defined access API. Cloud-Subscriber applies a first-level filter based on corporate policy (e.g., to remove companies that do not meet minimum standards for corporate governance, financial disclosure, creditworthiness or due to bad previous service experiences). 3. Cloud-Subscriber programmatically reviews the Service Catalogs of the filtered Cloud-Providers, to select the subset of Cloud-Providers that meet the required service assurance parameters for the amount of units of service desired. 4. Cloud-Subscriber programmatically issues a price inquiry to each selected Cloud-Provider, selecting a number of instances of a Service Catalog item, with specific service assurance parameters, and any constraints and billing requirements. These constraints need to be in a predefined, well-formed syntax, and may include any of the following: Maximum latency from specific location (e.g., 20 milliseconds of network latency from New York City) Minimum bandwidth from specific location (e.g., 200 MB/sec when accessed from London, UK) Regulatory pre-approval (e.g., FSA approved) Legal compliance (e.g., Health Insurance Portability and Accountability Act (HIPPA) compliant) The billing requirements also require specification, and can include: Minimum time commit (to allow the price to be lowered versus pure pay-per-use) Pre-emption considerations (allowing Cloud-Providers to charge a lower rate in return for the ability to pre-empt the Cloud-Subscriber for convenience) The resulting response from the Cloud-Provider shall confirm availability (with lead time if necessary) and pricing to place a reservation on the service (guaranteeing the capacity), and to request the service (executing the order). Cloud-Subscriber then chooses to place reservations on one or more Cloud-Providers in the units of request, and then subsequently to activate up to 100 percent of those reservations. Optionally during this fulfillment phase, Cloud-Subscriber may choose to release the reservation on any surplus requirement. There may be a charge associated with this process, in order to prevent Cloud-Subscribers from routinely reserving a much larger quantity than needed. There also may be additional charges for reservations that are not completely requested (e.g., a reservation for 100 servers is placed, but only 50 actually are requested) and fees for reservations that are cancelled after the request is submitted. The Cloud-Subscriber may either build their own Service Catalog within the Cloud-Provider s environment (in which case this Service Catalog would be a subset of the Cloud-Provider s Service Catalog) or query Cloud-Provider s Service Catalog and populate their own service description at their location. If the Service Catalog is maintained by the Cloud-Provider, it should reflect current contract pricing and all the catalog entries should be kept up to date and synchronized with the Cloud-Provider s Service Catalog. The Cloud-Provider s catalog should be extensible to include support for the Cloud-Subscriber s own catalog extensions (e.g., customer codes or descriptions). 7
The Cloud-Subscriber s own catalog entries may be copies of the Cloud-Provider s entries, combinations of the Cloud-Provider s products or new items not offered by the Cloud-Provider. The Cloud-Provider will provide the option for Cloud-Subscriber-managed account access controls, Cloud-Provider-managed account access controls or a third-party access control point, providing a customer with maximum flexibility around access controls and roles. The access controls must be able to restrict by service item and by attribute to constrain the scope of the request to services that the Cloud-Subscriber s administration team has pre-agreed to, and to restrict certain fields (e.g., price) to specific role-holders (e.g., sourcing team). General Requirements The Service Catalog shall describe the cloud services that a Cloud-Provider offers. There are three essential components to the Service Catalog: 1. A data model (in a self-describing format such as XML or a specific markup language) holding the information for the Service Catalog to describe standard and extended attributes of Cloud-Providers and service offerings. 2. A standard set of structures to describe the Cloud-Provider and Cloud-Provider s products and services. 3. An API to interact with the Service Catalog. Over time, the set of standard product definitions will increase at both the product level and the attribute level. It is expected that also over time the extended attributes will become standardized as features and functions of products themselves become commonplace. The following diagram shows the high-level relationship between standard product definitions and their standard attribute descriptions and how other products will use standard and extended attributes to describe custom features. In this figure, the Cloud-Provider information consists of standard Cloud-Provider attributes and extended Cloud-Provider attributes. It is the intent of the Alliance to define the standard set of Cloud-Provider attributes, and over time, add to these from either commonly found extended Cloud-Provider attributes or from other industry sources. Cloud-Provider Standard CP Attribute 1 Standard CP Attribute N Extended CP Attribute 1 Extended CP Attribute N Standard Product Standard Attribute 1 Standard Attribute N Standard Attribute 1 Standard Attribute N Custom Product Extended Attribute 1 Extended Attribute N Standard CP Attributes Extended CP Attributes Standard Product Attributes Extended Product Attributes SCP Attribute 1 ECP Attribute 1 SP Attribute 1 EP Attribute 1 SCP Attribute N ECP Attribute N SP Attribute N EP Attribute N 8
Similarly, the Alliance will define a collection of standard products and standard product attributes. Standard offerings will include only references to standard attributes. The Cloud-Provider also may include custom products that consist of standard product attributes and/or extended product attributes. It is strongly recommended that custom products include references to the standard product attributes in order to allow the Cloud-Subscriber s automated discovery tools to successfully identify them and classify them for automated comparison purposes. 1. Data Model The Service Catalog shall use a self-describing format to define the standard and extended attributes of service offerings. The list of standard Cloud-Provider attributes and standard product attributes is described in subsequent sections. The data model also may include extended attributes to describe both the Cloud-Provider and their products and services. However, Alliance-defined standard products only may include references to Alliance-defined standard product attributes. The selfdescribing format of the Service Catalog will permit a Cloud-Subscriber s automated systems to capture all the information about the Cloud-Provider and products. 2. Standard Set of Structures The Service Catalog shall use a standard set of structures to describe both the Cloud-Provider and its products and services. The Service Catalog also can extend the definition of the Cloud-Provider and products by using extended attributes. This will enable Cloud-Subscribers to: Reference the Service Catalog using the same tools across multiple Cloud-Providers Find consistency of Service Catalog information within one catalog and across multiple Cloud-Providers Find consistency of service obligations for supporting each standard offering Find consistency of service descriptions since the standard attributes will be defined by the Alliance Understand the type of service and sharing characteristics (single or multi-tenant) that is being offered 2.1 Standard Cloud-Provider Attributes: Cloud-Provider name Cloud-Provider location(s) Catalog Compliance Standard (minimum Alliance level or higher) List of cloud locations URL to the WSDL or XML data model Change date URL list of cloud service gateways High-level service descriptor attributes (in the form of a WSDL or XML in the same format as the data model) Other standard Cloud-Provider attributes 9
2.2 Extended Cloud-Provider Attributes These can contain anything the Cloud-Provider chooses to include to describe them in a consistent manner. However, defined attributes must be used consistently across references to the attribute. Extended attributes will have the following common characteristics: Extended attribute name Alliance-equivalent attribute name (if this exists) Alliance-equivalent attribute level (if the equivalent attribute name exists) 2.3 Standard Product Attributes Product or service Alliance name Cloud-Provider s product or service name Change date Service performance parameters for each service (e.g., scale, performance, throughput) Service assurance parameters for each service (e.g., security, availability, elasticity, manageability, recoverability, and client SLA priority) 2.4 Extended Product Attributes These can contain anything the Cloud-Provider chooses to include to describe themselves and their products and services in a consistent manner. However, defined attributes must be used consistently across references to the attribute. Extended attributes will have the following common characteristics: Extended attribute name Alliance-equivalent attribute name (this enables a Cloud-Provider to provide custom products that are essentially the same as the standard products) Alliance-equivalent attribute level Alliance standard products may only use Alliance standard attributes. However, a Cloud-Provider may design a custom product definition that extends the capabilities of a standard definition. For example, a standard product called Web Server could have a set of standard attributes, including type of web hosting software and transactions per second of throughput. The Cloud-Provider may update underlying hardware capabilities that now cause their offering to be non-standard (e.g., adding solid-state disks for highest performance and a location-sensitive load-balancer capability). By using a cross-reference between their new extended product attribute back to the older Alliance attribute, a Cloud-Provider can remain competitive with their product line. It is expected that Cloud-Subscribers will search the custom products for references back to Alliance standard product definitions. Service Performance and Assurance parameters are specified in the Alliance s Standard Unit of Measurement Usage Model. 3. Application Programming Interface The Service Catalog shall expose an API to permit programmatic access to the Service Catalog contents. The API will: Use a standard set of actions Reference a standard set of objects A consistently defined API will enable a Cloud-Subscriber to use one set of tools to access Service Catalogs across multiple 10
Cloud-Providers. Cloud-Subscribers will be able to programmatically query a Service Catalog using an open and standard API to determine what capabilities each of their Cloud-Providers can provide. This will enable a Cloud-Subscriber s algorithmic provisioning systems to automatically determine the optimal placement of the workload. In this example, we assume that the industry has adopted the Alliance standards and the Cloud-Subscribers internal IT teams have also adopted them for internal catalogs. 4. Other General Requirements In order to avoid prescribing the protocol or format of the Service Catalog, the description here of the Service Catalog refers to containers and attributes in the form of name/value pairs. The Service Catalog consists of containers which are sets of attributes and values paired to describe each cloud platform, orderable products and services, and product or service components. These containers may have parent and child relationships to describe dependencies (such as with geographical or other issues with products and services) or to describe other product relationships such as incompatibilities (e.g., component 1 and 2 cannot both be together). The container name, attribute names, and allowed values for the attributes are defined in a central schema. The intention will be for the Alliance to work with standards bodies to create and ratify an industry standard for this schema. The schema will have a revision number and instantiated catalogs will reference the schema revision to which they comply. The catalog schema will support user-created extensions which may be used and managed by Cloud-Providers or by Cloud-Subscribers managing their own catalog. The schema is extensible and may be used by the Cloud-Provider or Cloud-Subscriber to describe other products, services or information not identified by the published standard. Extensions to the standard published schema may be ignored and processing will continue with the next valid data. The following fundamental types of containers will be supported: Templates: A Template describes a product or service offering from a Cloud-Provider and includes all the parameters a Cloud-Subscriber may select from when ordering an item from the Service Catalog. It will have allowed parent and child relationships and list any dependencies (component A requires B) and any restrictions (component A but not with B). Solutions: A Solution describes a combination of two or more product or service templates combined into a single orderable combination, listing out each of the Service Catalog templates used in the solution. The Solution definition includes all the parameters a Cloud-Subscriber may select from when ordering the solution from the Service Catalog. It will have allowed parent and child relationships and list any dependencies (solution A requires B) and any restrictions (solution A but not with B). Cloud-Subscriber may export its own set of instances described in this format from the Cloud-Provider. Cloud-Subscriber may import its own definitions (into its own catalog) that describe items which may be ordered by its internal teams that can be provisioned by Cloud-Provider. Every container will have the service level attributes populated as compulsory attributes for each of the areas the Alliance agrees are standard measurable service levels. Example: an offered OS service container may have a security service level of Gold if it meets the standards for Gold Security (and by definition, it will also meet the Bronze and Silver levels as well). The Cloud-Subscriber may either build its own Service Catalog within the Cloud-Provider s environment (in which case this Service Catalog would be a subset of the Cloud-Provider s Service Catalog), or query Cloud-Provider s Service Catalog and populate its own service description at its location(s). If the Service Catalog is maintained by the Cloud-Provider, it should reflect current contract pricing and all the Service Catalog entries should be kept up to date and synchronized with the Cloud-Provider s Service Catalog. The Cloud-Provider s Service Catalog should be extensible to include support for the Cloud-Subscriber s own catalog extensions (e.g. customer codes or descriptions). 11
The Cloud-Subscriber s own catalog entries may be copies of the Cloud-Provider s entries, combinations of the Cloud-Provider s products, or new items not offered by the Cloud-Provider. The Cloud-Provider will provide the option for Cloud-Subscriber-managed account access controls, Cloud-Provider-managed account access controls or a third-party access control point, and provide a customer with maximum flexibility around access controls and roles. The access controls must be able to restrict by service item, to constrain the scope of the request to services that the Cloud-Subscriber s administration team has pre-agreed to and to restrict visibility of certain fields (e.g., price) to specific role-holders (e.g., sourcing team). Similarly, certain actions (e.g., order confirmation) may be restricted to specific role-holders. Detailed Requirements The Cloud-Provider s Service Catalog shall consist of standard collections of attributes to describe the Cloud-Provider and to describe standard service offerings. This section details the following: Standard Cloud-Provider Attributes Standard Product Attributes Service Catalog Requirements The following sections describe each of these in greater detail. Standard Product Attributes A Standard Product data model shall have the following attributes: A unique identifier for the cloud service A short name identifier for the service (such as type and instance name) A brief description of the unit of measure for the service Service topology parameters that describe the service connectivity Service performance parameters Service assurance parameters Security Availability Elasticity Manageability Recoverability Client SLA Priority Range of orderable solutions quantities beyond 1 instance (larger blocks such as 5, 10, 25, 100, or 1000; it is desirous to have pre-defined solutions that can be ordered in quantities beyond 1) Service performance metrics using industry standard metrics These service assurance parameters may be used to specify a specific need, such as a request for services with these capabilities: Gold Security, Bronze Availability, Platinum Elasticity, Silver Manageability, Bronze Recoverability, and any client SLA priority (represented with an asterisk). 12
Service Catalog Requirements There are several key capabilities needed in a Cloud-Provider Service Catalog. The Cloud-Provider will provide a Service Catalog to describe these products and services. There is also a Cloud-Subscriber s version of this catalog that includes part or all of the Cloud-Provider s Service Catalog, along with any extensions the Cloud-Subscriber adds to its own catalog. The Cloud-Subscriber s catalog also describes Cloud-Subscriber account level information (such as specific customer pricing that may have been defined during contract negotiation) that can be included in the catalog(s) and processed by the Cloud-Provider during ordering, provisioning or ongoing operation. The Cloud-Subscriber s account level information may include user account information for user identification and access authorization. Cloud-Provider Service Catalog In no particular order, the following capabilities and attributes should be found and accessible in a Cloud-Provider s Service Catalog: Description of products and services currently orderable. Description of products and services that are still in use by the customer but no longer orderable. Ability to create a Cloud-Subscriber Catalog with one or more service offering items from the Cloud-Provider s Service Catalog, as well as include customer or third-party items. These service offering items should: Reflect pricing that may have been agreed to in a contract Reflect current state of Cloud-Provider s Service Catalog Reflect only the products the Cloud-Subscriber wants to provide to internal groups Be extensible for the Cloud-Subscriber to use to describe products and services internal groups may also use at that Cloud-Provider site Account-level capabilities such as the ability to define and report on account-specific information, such as: Invoices and payment status Types of payment vehicles permitted (PO, Visa, MasterCard, invoice, etc.) Account Contacts Contact by Roles Technical Administrators Billing Administrators Financial Approvers Relationship Managers Etc. An API with standard actions that can modify service offering Items or entire catalogs, such as: Create Creates a Cloud-Subscriber catalog or creates a service offering item to be added to the catalog Add Adds a service offering item to the designated catalog Version Allows creation of another copy of a service offering item or Cloud-Subscriber catalog (including a new version number this is useful for product revisions and new versions or for updating an entire catalog) Update Allows a Service Offering Item to be updated in a designated catalog (to correct errors or make similar types 13
of changes that don t require a new item version) Hide Keeps a service offering in the catalog, but prevents it from being ordered in fact, it is not even visible without sufficient catalog permissions Remove Removes an individual service offering Item from a catalog or removes the entire catalog Report Provides a query mechanism that generates an extract of information from a catalog for reporting purposes. The output can either be for human (HTML or print) or computer (XML, CSV). Provides support for retrieval verbs, including (Get, GetNext, GetPrevious, GetFirst, GetLast). The Service Catalog will be accessible using a standard and open API (to be technically defined in a future revision of this Usage Model). The Cloud-Subscriber s Catalog, Cloud-Provider s supported third-party products and services, and the Internet Service Provider (ISP) products and services are all logical catalogs in the Service Catalog. A Cloud-Subscriber can order from any of these, and the pricing from their master sales agreement should be reflected in the prices of each product or service item in the Service Catalog. The catalog items should then be able to feed the Cloud-Provider s provisioning process for automated provisioning of the catalog item. In either case, the ISP should provide management, monitoring, and reporting of the catalog and provisioning process. 14
Cloud-Provider Product Offerings A Service Offering Item is an orderable product or service delivered by the Cloud-Provider. In no particular order, the following attributes should be found and accessible in a Service Offering Item: Description of the capabilities of the product or service Is a collection of information relevant to the type of product or service being delivered (in other words, there isn t just one data structure for all products and services) Description of relationships between service items. For example: Inclusion of attributes such as: When ordered, item A has no dependencies One or more of item B requires that item C also be ordered Item A can t be ordered with item D Service Level Agreement(s) Available QoS level(s) Quantities that may be ordered Approval workflow (either customer specific or generic) Pricing schedule Time to provision Support availability List of regulatory compliances Performance ratings Assurance levels at which the service is available (bronze, silver, gold, platinum) List of keywords (metadata) to support search by topic (e.g., Monte-Carlo, simulation ) Cloud-Subscriber Catalogs These represent the approved products and services that different groups within a particular Cloud-Subscriber may order at this Cloud-Provider. The Cloud-Subscriber catalog should consist of the following: Approved products and services internal groups may use from the Cloud-Provider The ability to keep Cloud-Provider s service offering items in sync with the Cloud-Provider s Service Catalog Pricing that may have been agreed to in a contract Extensible so the Cloud-Subscriber can include additional products and services available with this Cloud-Provider (such as approved third-party applications or customer IT services that work with this Cloud-Provider) in order to provide its internal teams with one catalog and one list of approved products, services, and capabilities Use of the same API used with the Cloud-Provider s Service Catalog 15
API that provides an import and export function to bulk load or unload entries Indication of what authority to use for end user account control (this could be under the control of the Cloud-Provider, a customer-provided directory, or a third-party service) 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 open specifications, formal or de facto standards or common 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. The following are industry actions required to refine this usage model: Develop a Web Service Definition Language (WSDL) structure to model a product. Develop a WSDL structure to model a service. Develop a WSDL structure to model the management, monitoring and reporting of the provisioning process. Define the open standard query language to use for interrogating the catalog (i.e., the API to be used). Further elaborate the functional steps used to interrogate the Service Catalog. References Information Technology Infrastructure Library (ITIL v3) Service Design Appendix F has sample SLA and OLA. It is proposed that in this use-case we use: 1. The service level attributes and the operations level attributes as per ITIL v3 Service Design Appendix F 2. The CIM Schema as the baseline for our model for service attributes, and consider extending CIM to cover our Usage Models. (See http://dmtf.org/standards/cim for more information.) 16