Swipe to navigate through the chapters of this book
Cloud implementation is not easy. The hype says moving implementations from the premises to a remote cloud is an instant cure for many IT ills. The hype is true, but only for some implementers. Frequently, the problem is a basic misunderstanding of the nature of cloud implementation. It is both a business pattern and a technology. Cloud computing opens up business possibilities and new combinations and scales of technology, but unless business and technology work together, the results will most likely be disappointing. In addition, cloud computing is best when it supports whole systems of services. A service can be implemented on a cloud independently, but usually the greatest benefits will not be realized until several services work in a synergistic cloud implementation. Strategic planning, as ITIL best practices advocate, promotes long-term cooperative strategizing, which can help guarantee cloud success.
Please log in to get access to this content
To get access to this content you need the following product:
ITIL also defines a “service catalog.” A service catalog helps manage services in production. It is not for managing services strategically. An ITIL service catalog does not contain services that have been removed from production or not in production yet. There is another concept of a service catalog that is an interactive application that employees use to order or modify services. This kind of catalog is often closely tied to the ITIL service catalog. Occasionally, ITIL service catalogs are implemented as part of service portfolios since there is some overlap in information in the two components.
It’s worth noting that a rigorously applied service portfolio approach is an effective tool for preventing application sprawl and departmental computing silos, which can be a danger as cloud computing becomes more ubiquitous. Launching a private copy of an application or subscribing to an SaaS service is so easy and quick, small groups can quickly build a stack of applications that isolates them from the rest of the enterprise. This can lead to many of the abuses that appeared in the early days of distributed computing.
Stuart Rance. ITIL Service Transition. The Stationery Office. 2011. Page 203. The service transition volume goes into detail on shifting responsibilities.
SLAs may be part of a service contract or a separate business document. SLAs spell out penalties and incentives for levels of delivery of services. An example SLA is “For every minute of service outage over 99.9 percent service uptime per month, the consumer will receive $1,000 in credit.”
SaaS and PaaS can be more complicated. For instance, if a malefactor breaches an application by taking advantage of a defect in the SaaS application or a component supplied by the PaaS provider, the breach will ordinarily be the responsibility of the provider. However, if, for example, the malefactor phishes credentials to get into the application, it is the consumer’s responsibility. In any case, the consumer should always read their SLA carefully. The SLA determines who is responsible for what, and that could be surprising.
See www.iso.org/iso/catalogue_detail?csnumber=51986 . Accessed September 2015.
See www.aicpa.org/Pages/default.aspx . Accessed September 2015.
- Slipping the Surly Bonds
- Sequence number
- Chapter number
- Chapter 12