To align with ITIL recommendations, enterprise IT services should be a customer-facing representation of the available technology services. An organization's IT services catalog should, in turn, provide all the information a customer should need to review, select, and acquire cloud solutions. Although both top-down approaches (from the business view) and bottom-up approaches (based on a technology and an available technology services view) have been used, industry best practices indicate that the bottom-up approach is far more efficient, because it is based on something tangible—the technology or technology services available to an organization.

A mapping of technology services to a cloud solution requires standards regarding both architecture and delivery. Without this standardization, a mapping across the IT external and internal boundary is not possible, (for example, if IT doesn't maintain a standardized build and delivery method for RHEL, the customer would receive a different build every time a RHEL gold service is ordered). A failure by the organization to set and enforce standards across the entire technology space, both regarding architecture and delivery would be contrary to the exact purpose of IT service management.

The challenge of the cloud computing solution task is primarily in the structuring and organization of available services to allow for a standardized, efficient, and reproducible mapping. This is referred to as service design in ITIL. During service design phases, all aspects of the solution must address new and evolving business needs. Business aspects often considered for cloud solutions include:

• Business process and the definition of the functional service needs, for example, telesales, invoicing, orders, credit checking
• The service (or solution) being delivered to the end user or business by the service provider, for example, email, billing
• Service level agreements that specify the level, scope, and quality of service to be provided
• Infrastructure—all of the IT equipment necessary to deliver the service to end users which includes servers, networks, switches, client devices, and so on
• The environmental requirements needed to secure, and operate the infrastructure
• Data is necessary to provide the service and deliver the information required to execute the business processes
• The application needed to manipulate or modify the data and provide the functional requirement of the business processes
• The operational level agreements (OLAs) and contracts, as well as any foundational agreements needed to deliver the SLA-dictated quality of service
• Support services necessary to execute all required operations
• All processes or procedures needed in the execution and operation of the delivered service
• Internal support teams that provide level 2 and level 3 support to end users and any of the service components
• External third party suppliers which are necessary to provide level 2 and level 3 support to end users or service components

The cloud is not the answer for everything. Components must first be considered in isolation. If the cloud presents advantages for the component in isolation, the component should then be considered among its other relationships, interactions, and dependencies to other components and services. If advantages remain the same or increase, the cloud becomes a viable option. This approach will result in an effective, well-researched, and easily communicated solution that aligns technical, strategic, and economic business needs within acceptable risk profiles.

Following ITIL recommendations, each solution component should be documented using configuration management artifacts across nine categories:

• Description: Describes the individual solution components by the use of standardized diagrams and a short textual description.
• Life cycle: Defines the organization's specific lifecycle for solution components. That life cycle is different (lagging) from the vendor life cycle because vendor products may need to be customized to meet internal standards.
• Provisioning: Describes the technical provisioning of solution components, the provisioning process required by solution components is covered in the artifact processes and runbooks.
• Configuration management: Document a solution component's requirements with regards to the implementation in a configuration management framework. This includes both CMDB templates as well as configuration management reports.
• Security: The technical and process aspects of a solution component's security requirements that must be met during the deployment and operating phase.
• Monitoring: Functionality required for monitoring the operational status of the solution components.
• Processes and runbooks: One-time activities related to a solution component, such as provisioning. The runbook focuses on normal activities along with any anticipated abnormal activities associated with the specific solution component, such as house cleaning, backup/restore, auditing, failover. Both the process descriptions and the runbook should cover the complete lifecycle of a solution component, including provisioning, operations, and decommission.
• Financials: Technology-based cost for Capital Expenditure (CAPEX) and Operational Expenditure (OPEX). This does not include any IT service-oriented cost items such as system administrator support, as they can vary depending on the associated IT service offering.
• Blueprints: Detailed descriptions of the technical implementation of the solution component. For the engineering teams, the blueprints define how a component is to be developed for customers, they include detailed technical information about the component.

The solution itself should be documented in the following 12 categories:

• Description: Describes the individual solutions by the use of standardized diagrams and a short textual description.
• Non-functional requirements (NFR): Solution requirements defined in a standardized and unambiguous fashion. There are two categories of NFRs:
  • Capabilities, which describe the features and functions provided by the infrastructure components
  • Qualities of service requirements that expand the infrastructure capabilities to cover additional end-user expectations
  • Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are referenced for failover within a data center as well as failover between data centers
• Required solution components: Solution components required by a solution.
• Life cycle: The solution life cycle is mainly based on the life cycle of the individual solution components required by the solution.
• Provisioning: Provisioning of a solution consists of the provisioning of individual solution components. However, some solutions might require the prior provisioning of other solutions.
• Configuration management: Document a solution's requirements with regards to the implementation in a configuration management framework. This includes both CMDB templates as well as configuration management reports.
• Security: The security of a solution should be built into the individual solution components and not added on a solution level. Most solutions don't require any additional security considerations.
• Monitoring: The monitoring of the overall solution is essentially a collection of the individual solution components monitoring functionality. If applicable, the solution level monitoring should define how events from the different solution components are correlated and de-duped. These definitions must correspond the scenarios outlined in the resiliency assessment artifacts.
• Resiliency assessment: The description of all possible technical failure scenarios (operational errors are out-of-scope). This includes a description of the failure, how the failure is detected by the monitoring components and what remediation is possible. The impact of the failure is then captured regarding QoS type NFR, mostly downtime and data loss. The worst QoS NFR of all scenarios defines the QoS NFR for the solution as a whole.
• Process and runbooks: A collection of the corresponding artifacts on solution component level. Because of the mapping of solutions to IT services, there are IT services-specific process steps which are placed as a wrapper around the component processes.
• Financials: Technology-based cost for CAPEX and OPEX for each component used by the solution.
• Blueprints: This artifact lists the blueprints associated with the solution. There is no solution-specific blueprint for a solution that consists of solution components and doesn't provide technical functionality outside of the solution components.

It is essential that the ITSM framework supports the mapping of IT services to solutions and maintains the relationship between solution components, solutions, and delivery patterns. This can be done in the following manner:

• Customer orders an IT service
• IT service is mapped to a solution
• Solution components and composite solution components required for a solution are identified (solutions can't be deployed as a unit. Solution components are what is deployed)
• Solution components are deployed as individual components
• Solutions are re-constructed from solution components and mapped to IT services