ITSM approach for cloud

Cross Functional Services: HCL

ITSM Approach for Clouds

Table of Contents 1.

Introduction ................................................................................................. 4

1.1. Emergence of Cloud Computing .................................................................... 4 1.2. Changing landscape of internal IT Infrastructure ............................................. 4 1.2.1.

Mainframe based Infra ....................................................................................... 4

1.2.2.

Heterogeneous Server based Infra....................................................................... 4

1.2.3.

Heterogeneous and distributed DC Infra ............................................................... 5

1.2.4.

Virtualization: Pre-cloud Era ................................................................................ 5

1.3. Changing Needs of IT Service Management .................................................... 5

2.

1.3.1.

Growing Complexity of Service Management equations .......................................... 5

1.3.2.

Growing Service Management needs.................................................................... 6

Cloud in Enterprise it Landscape .................................................................. 7

2.1. Internal/Private Cloud .................................................................................. 7 2.1.1.

Service Management Equation in private cloud ...................................................... 7

2.2. Hybrid Computing with One Cloud ................................................................. 8 2.2.1.

Service Management Equation in Hybrid model ..................................................... 9

2.3. Hybrid Computing with Multiple Cloud ...........................................................10 2.3.1.

Service Management Equation in Multi Cloud .......................................................10

2.4. Community Cloud and Service management Equations ...................................11 3.

HCL’s ITSM approach for clouds ................................................................. 12

3.1. Foundation: HCL Best Practice .....................................................................12 3.2. Using HCL Gold Standards ...........................................................................12 3.3. ITIL background.........................................................................................13 3.3.1.

How ITIL updated with technology ......................................................................13

3.4. ITIL is applicable ........................................................................................14 3.5. Transforming ITIL Processes for Clouds.........................................................15 3.6. Process Engineering....................................................................................15 3.6.1.

Understanding process design ............................................................................15

3.6.2.

Same process across multiple vendors ................................................................15

3.6.3.

Multiple Processes across multiple vendors ..........................................................16

3.7. Process Integration.....................................................................................17 3.7.1.

4.

Process integration framework ...........................................................................17

Cloud and ITIL implementation.................................................................. 19

4.1. Preface to ITSM approach to cloud ...............................................................19

PROPOSAL

4.2. Service Delivery Chain in Cloud ....................................................................19 4.2.1.

Service Based view ...........................................................................................19

4.2.2.

Layer based view..............................................................................................20

4.3. Holistic picture with HCL Cloud Computing Architecture...................................21 4.4. Service Management Scheme and architecture: .............................................22

5.

4.4.1.

Key questions to ask .........................................................................................23

4.4.2.

Importance of Managed Object ..........................................................................23

Illustration of scheme and architecture ..................................................... 24

5.1. Business situation ......................................................................................24 5.2. Service scheme overview example ...............................................................24 5.3. Service Management architecture Example....................................................24 5.4. Process Design and Implementation Example ................................................25 6.

Typical scenarios debated .......................................................................... 26

6.1. Whose Incident it is? ..................................................................................26 6.2. About Continuity ........................................................................................26 6.3. Proactive Problem Resolution .......................................................................27 6.4. Service Economics......................................................................................27 6.5. Change management .................................................................................27 6.6. Service Level Management ..........................................................................27 6.7. Compliance and control ...............................................................................28 6.8. Application Operation..................................................................................28 6.9. Business Service management.....................................................................28

HCL Confidential

3

1. Introduction PROPOSAL 1.1.

Emergence of Cloud Computing

Cloud computing grew out of the concept of utility computing. Essentially, utility computing was the belief that computing resources and hardware would become a commodity to the point that companies would purchase computing resources from a central pool and pay only for the amount of CPU cycles, RAM, storage and bandwidth that they used. These resources would be metered to allow a pay for what you use model much like you buy electricity from the electric company. This is how it became known as utility computing. The fundamental concept of cloud computing is that the computing is "in the cloud" i.e. that the processing (and the related data) is not in a specified, known or static place(s). This is in contrast to the traditional computing where the processing takes place in one or more specific servers that are known. However, it must be noted that, the server location, place and controls are still known to someone who is a part in service delivery chain. Nonetheless, cloud computing is still a complex and dynamic IT Service production and distribution system where different layers of service producing infrastructure are controlled and managed by different entities.

1.2.

Changing landscape of internal IT Infrastructure

1.2.1.

Mainframe based Infra

Enterprise IT infrastructure’s formal first generation started with mainframe era. Those IT Infrastructures were based on local data center in large corporate office. Hardware of early computer systems was complex to operate and maintain, and required a special environment in which to operate. Many cables were necessary to connect all the components and methods to accommodate and organize these were devised, such as standard racks to mount equipment, elevated floors, and cable trays (installed overhead or under the elevated floor). Also, old computers required a great deal of power, and had to be cooled to avoid overheating. Security was important – computers were expensive, and were often used for military purposes. Basic design guidelines for controlling access to the computer room were therefore devised.

1.2.2.

Heterogeneous Server based Infra

With the advent of client-server computing, during the 1990s, "servers" started to find their places in the old computer rooms. The availability of inexpensive networking equipment, coupled with new standards for network cabling, made it possible to use a hierarchical design that put the servers in a specific room inside the company. The use of the term "data center," as applied to specially designed computer rooms, started to gain popular recognition about this time. The boom of data centers came during the dot-com bubble. Companies needed fast Internet connectivity and nonstop operation to deploy systems and establish a presence on the Internet. Installing such equipment was not viable for many smaller companies. Many companies started building very large facilities, called Internet data

HCL Confidential

4

centers (IDCs), which provide businesses with a range of solutions for systems deployment and operation. New technologies and practices were designed to handle the scale and the operational requirements of such large-scale operations. These practices eventually migrated toward the private data centers, and were adopted largely because of their practical results.

PROPOSAL 1.2.3.

Heterogeneous and distributed DC Infra

Contemporary IT Infrastructure of enterprise includes wide range and variety of servers, storage devices, network devices, security devices and software components. Large enterprise will have multiple sets of data centers connected together over variety of technologies such has dedicated link, VPN links, MPLS etc. Datacenter design, build and operate has become a specialized discipline.

1.2.4.

Virtualization: Pre-cloud Era

Virtualization helps reduce complexity by reducing the number of physical hosts but it still involves purchasing servers and software and maintaining your infrastructure. It’s greatest benefit is reducing the cost of that infrastructure for companies by maximizing the usage of the physical resources. While virtualization may be used to provide cloud computing, cloud computing is quite different from virtualization. Cloud computing may look like virtualization because it appears that your application is running on a virtual server detached from any reliance or connection to a single physical host. And they are similar in that fashion. However, cloud computing can be better described as a service where virtualization is part of a physical infrastructure.

1.3.

Changing Needs of IT Service Management

Changing IT Infrastructure landscape led towards changing needs in IT Service Management landscape. A formal help desk, for example, came only in late 80s and early 90s.

1.3.1.

Growing Complexity of Service Management equations

I am using the terminology “service management equation” as the state of relational equilibrium between the service producing systems and the people (organizations and groups within) in the service delivery & support chain. It will always be multidimensional. This term shall become increasingly significant as we talk about service management for clouds. Further, it is important to understand the difference between service delivery and service support – the two disciplines described in ITIL V2 books very clearly. Client server computing also brought the huge surge in application portfolios. Practically anything and everything could be computerized. Number of vendors also grew rapidly. Variety of service started getting outsourced. With the growth IT service portfolio, growth of users and growth of service providers, the complexity of IT Service grew steeply. One element in the service landscape could unknowingly impact the service from other element.

HCL Confidential

5

PROPOSAL

1.3.2.

Growing Service Management needs

As the complexity of service management equations grows, the need to manage those equations for the purpose of managing the services becomes even more urgent and imperative. For example – growing number of products and services is creating a strong need of managing the compatibility matrix among those components. While product compatibility matrix is very well understood and analyzed, the service compatibility matrix in its real meaning has rarely been appropriately analyzed. The basic flaw in IT Service Management world is that technology management is deemed as service management and thus the deployment of tools to manage the technology is deemed as the process implementation. This Flaw is even more expanded with clouds as more and more tools are coming in to manage clouds. Technology management is a part of service management as it is the core part of producing the service; however, it is not the service management. Does FedEx focuses on cargo aircraft fleet management alone to manage the service? A true service management will focus on managing the outcome, viz how a customer (individual and organization) is realizing the benefit from the technology and will continue to realize benefit so long as service is active or contracted. The purpose of this document is to explain HCL’s approach on IT service management for Clouds.

HCL Confidential

6

2. Cloud in Enterprise it Landscape PROPOSAL 2.1.

Internal/Private Cloud

Internal or private cloud emulates cloud computing on private networks. Private cloud (also called internal cloud or corporate cloud) is a marketing term for a proprietary computing architecture that provides hosted services to a limited number of people behind a firewall. Advances in virtualization and distributed computing have allowed corporate network and datacenter administrators to effectively become service providers that meet the needs of their "customers" within the corporation.

Marketing media that uses the words "private cloud" is designed to appeal to an organization that needs or wants more control over their data than they can get by using a third-party hosted service such as Amazon's Elastic Compute Cloud (EC2) or Simple Storage Service (S3).

2.1.1.

Service Management Equation in private cloud

There is a little change in the service management equation in this environment over the legacy service management schemes. The little change would be “more little” or “less little” depending upon what cloud offers internally. If it is a IaaS/PaaS cloud then most probably application developer will be the cloud customer and this will warrant some adjustment/variations in equations with that group only. If it is SaaS, then the service delivery mechanism to end user will change. However, noting that end user will still use the same end points, change could very well be invisible to customer. We believe that the support mechanism will not change and internal IT service Desk will remain unchanged.

HCL Confidential

7

PROPOSAL

2.2.

Hybrid Computing with One Cloud

Rather than abandon the existing data centers and use the public cloud exclusively, or, conversely, rely on private cloud only, and ignore the public cloud, the enterprise may consider using a combination of private and the public cloud. This is called the hybrid model. This allows a company to keep control of its key IT services while leveraging cloud computing in places where it makes sense. For example, many companies have found it economical to use Amazon's Simple Storage Service (S3) to store things like images, videos, and documents. The hybrid model also lends itself to an incremental approach.

Even if you think it makes sense to move most or all of your applications to the cloud, it might seem too risky to move everything all it once. With a hybrid model, you pick the low hanging fruit (like file storage) to move to the cloud first. Then after

HCL Confidential

8

you become more comfortable with that deployment model, you can move more significant parts of your application to the cloud.

PROPOSAL 2.2.1.

Service Management Equation in Hybrid model

There will be appreciable change in the service management equation.We are adding one additional set in the existing service equation. I am using some modified ITIL terminology to explain this impact. EU SLA: The SLA between the IT and the business within the enterprise. Ens user services will be governed by this SLA SLA: SLA between a managed service provider and IT Organization. It may be same as EU SLA in full IT outsourcing UC: The contract between a product and product support vendor and IT organization Internal OLA: OLA between internal groups within IT organization to support EU-SLA External OLA: OLA between internal groups and groups of Managed Service provider to support EU-SLA

HCL Confidential

9

2.3. Hybrid Computing with Multiple Cloud PROPOSAL This is an expanded version of Hybrid model where the cloud service providers are more than one. It could be a common situation that  Enterprises are using the IaaS/PaaS service from Amazon for its application management group  Same organization is using Salesforce.com for CRM applications that it being used by its end users  Same organization is using E-Mail services for its end users from Google

2.3.1.

Service Management Equation in Multi Cloud

Service Management Equation dramatically scales up in complexity although the basic rules remain the same. When multiple companies are part in the service delivery chain then multiple groups in different companies will be actors in customer owned service delivery processes. It is not unusual that some of the service delivery processes are partly internal and partly external and therefore the process ownership could be heterogeneous. Multivendor ecosystem in traditional IT Service environment has been in existence since long. As we move towards the cloud, this ecosystem will by default exist and would be even more complex because vendors could be unknown and hidden behind opaque layer.

HCL Confidential

10

PROPOSAL

2.4.

Community Cloud and Service management Equations

A community cloud may be established where several organizations have similar requirements and seek to share infrastructure so as to realize some of the benefits of cloud computing. With the costs spread over fewer users than a public cloud (but more than a single tenant) this option is more expensive but may offer a higher level of privacy, security and/or policy compliance. Since it is a scaled down version of public cloud, same service management equations apply.

HCL Confidential

11

3. HCL’s ITSM approach for clouds PROPOSAL 3.1.

Foundation: HCL Best Practice

HCL has methods and techniques that have consistently shown results superior to those achieved with other means. Our best practices are designed to achieve highest performance level in industry, we use these as a standard to equal or exceed industry standards Our best practice is derived from well established and proven industry framework such as ITIL V2 and V3, CoBIT, CMM etc. These Frameworks are not the best Out Of the Box. There is, no practice that is best for everyone or in every situation, and no best practice remains best for very long as people keep on finding better ways of doing things. Value added implementation of the industry recognized framework constitutes “HCL best practice” Everybody has access to these frameworks but what makes out best practice the best is the implementation. In HCL approach there is a huge focus on process management. Processes are treated as the assets; because entire service outcome rely on processes –poor process will produce inconsistent services; inefficient processes produce costly service and amateur process fail to produce professional service.

3.2.

Using HCL Gold Standards

HCL’s Gold Standard is a practical, strategic, and modular methodology for the positive transformation of IT Service Management. One thing is certain. Tomorrow’s IT will not look like today’s IT. Tomorrow’s IT will move steadily toward the insulation of customers from the complexity of the IT infrastructure. To achieve this level of infrastructure abstraction you require automation, integration, and above all else, an intelligently designed and managed flow of processes.

HCL Confidential

12

PROPOSAL

HCL Gold Standard addresses all the three aspects of service viz Operate, Governance and Technology.

3.3.

ITIL background

There are varieties of IT service management frameworks available in the market and ITIL is among the most prominent and popular. ITIL V1 was born was GITMM (Government Information Technology Management Method) in 1986-87 but really became popular when V2 was published in year 2001. It was a technology independent service management framework and was addressing the needs of IT service management where all IT operations were managed by in-house IT departments. IT Outsourcing to managed service provider became popular and increased rapidly after 2001and thus changing the legacy organization structure. Most of the guidelines on ITIL implementation are based on single enterprise having multiple silos.ITIL process and functions are applicable across different “towers”. ITIL is definitely binding those silos with one process. IT Organization has multiple suppliers for managed services. Although ITIL has capability to bind the silos across different companies, but implementation of ITIL is difficult in such situation because of lack of “implementation guidelines” for such business situation.

3.3.1.

How ITIL updated with technology

Lifespan of service is hugely longer than the lifespan of technology. In relative term, service does not change but technology changes; however, the technology impacts the notion of service as it impacts the manner in which the service is delivered. ITIL has kept itself current with the emerging technology trend.

HCL Confidential

13

 ITIL Ver 1: Mainframe era. Technology class oriented guidance  ITIL Ver 2: Internet era and distributed/client server computing. Guidance organized around service management discipline  ITIL Ver 3: Ubiquitous computing era. Guidance organized around service lifecycle state

PROPOSAL

In next section we shall clarify how ITIL is applicable for clouds.

3.4.

ITIL is applicable

Cloud computing grew out of the concept of utility computing. Essentially, utility computing was the belief that computing resources and hardware would become a commodity to the point that companies would purchase computing resources from a central pool and pay only for the amount of CPU cycles, RAM, storage and bandwidth that they used. These resources would be metered to allow a pay for what you use model much like you buy electricity from the electric company. This is how it became known as utility computing. The fundamental concept of cloud computing is that the computing is "in the cloud" i.e. that the processing (and the related data) is not in a specified, known or static place(s). This is in contrast to the traditional computing where the processing takes place in one or more specific servers that are known. However, it must be noted that, the server location, place and controls are still known to someone who is a part in service delivery chain. Nonetheless, cloud computing is still a complex and dynamic IT Service production and distribution system where different layers of service producing infrastructure are controlled and managed by different entities. On the other hand ITIL books document best practices for managing the complex and dynamic business of delivering IT services. They are not a theory nor a standard, nor a detailed how-to, but a collection of what actually works. In other words, the core guidance and concept of ITL can be tailored to design the Service Management processes for IT Service management environment of clouds. HCL knows how to apply ITIL for cloud. HCL best practice includes several aspects and guidance for implementing ITIL in CCE and multi vendor environment. Just because you have cloud, does not mean that things are not going to go wrong. And if they do go wrong, what processes are you going to use to fix them? Are you going to call them something different from incident management, from problem management? Do you make changes in cloud? Are you not going to call it change management? The argument that ITIL does not apply to the cloud, is in fact a cop-out from the people who are developing cloud solutions to basically get rid of controls because this is a new technology – not realizing that ITIL is technology independent framework. Cloud will of course demand strong “built-in controls” around Event management and that is again prominently defined in Operation part opf ITIL V3

HCL Confidential

14

3.5. Transforming ITIL Processes for Clouds PROPOSAL ITIL for Cloud vary in scale and complexity as one logical process span across one or more systems. In order to transform the service management processes that were designed for legacy IT Infrastructure based service, two basic techniques are used and those are described here.  Process Engineering  Process Integration

3.6.

Process Engineering

Process engineering technique breaks the core of processes into multiple sets of tasks surrounded by key characteristics input, output, rules and roles Tasks are mapped to roles across different organizations, input and outputs of the tasks are governed by the OLA – where input becomes the “right” of the task performer and output becomes the “obligation” of the task performer If the process runs in the multiple systems then rules govern the protocol of data and action sharing

3.6.1.

Understanding process design

In order to design a process first gain an understanding of basic process components such as  Task: An assigned piece of work often to be finished within a certain time. Do not confuse with activity. For example In Incident Management Process one task is “register customer call” is a task  Input: Something (information/event/data etc) that is fed in for the purpose of transformation into another form or characteristic. Trigger is a special kind of event input that initiates the task execution. For example in Incident management process Customer call or e mail (trigger), Incident data (issue description, symptom etc are input  Output: Something that is transformed from input by virtue of the task execution. For example Ticket number is out put of the task explained above. The final output of Incident Management Process, however would be a resolution.  Rule: Prescribed guide for regulating the task execution. This includes policy – A guide for thinking. Rule is mandatory prescription and policy is non mandatory direction. “Ticket can not be created without a valid badge ID” is the rule and “Severity value of ticket will be governed by SLA document” is the policy  Role: Part played by the task performer. Do not confuse with title or designation. In above example the person who created the ticket, performed the role of Help Desk Analyst

3.6.2.

Same process across multiple vendors

If a same process runs across multiple vendors then a task output will be the point of entry for the vendors’ part for the next task.

HCL Confidential

15

PROPOSAL

Task connection points will be the handshake measurements will be done along these lines.

3.6.3.

between

two

vendors

and

Multiple Processes across multiple vendors

Connection points as stated above will break and connected via a separate process altogether.

SLA/OLA Measurement for Vendor 2

SLA /OLA Measurement for Vendor 1

Vendor

Vendor

Vendors will be measured by individual processes.

HCL Confidential

16

3.7. Process Integration PROPOSAL Process Integration is one of the key techniques to implement multi vendor ITIL. Process Integration is a technique of attaining close and seamless coordination and interaction of processes. Integration makes connection of two or more processes in harmony and logical manner as the tasks within the process are connected in logical manner.Process can share the data and even actions with each other. Integrated Processes are significantly more effective than sum of individual process in isolation.

3.7.1.

Process integration framework

HCL has established a process integration framework based on the process relationship defined in ITIL. The driving theme of the framework is  Each process is obligated to deliver some input (trigger or data) to other process. For example in many conditions, if Incident is resolved with a work around, Problem management process ought to be triggered. Incident management is obligated to provide this trigger along with the data of symptom, diagnosis and observation about the incident.  Is process has right to expect some input from other process to be effective. For example capacity Management process must receive utilization data from Event management process.

HCL Confidential

17

In the above diagram the named connection defines the input and output interface between the processes. Each process creates and maintains the data during its operation a, that can be shared with other processes.

PROPOSAL

HCL Confidential

18

4. Cloud and ITIL implementation PROPOSAL 4.1.

Preface to ITSM approach to cloud

In ITIL there are two different kinds of approaches for IT service management. I will call first approach as service factory approach which is a prominent theme of IT IL V2. You can think of data centers as IT service manufacturing factory where variety of machines and gears are used to produce IT service. This service is delivered to consumer station via network pipes. You simultaneously follow two sets of processes to produce the service and support the service and that is how service delivery and service support disciplines are described in ITIL V2 books. The service life cycle approach talks about the states or phases in cyclic manner and focus on the process to manage the state. This is what is prescribed in ITIL V3. In order to implement IT service management for cloud we combine this two approaches and add a pragmatic implementation focus. Cloud eco-system is by design a multi-vendor and multi-service provider. Therefore, all the basic principles that we described in multivendor ITIL do apply here as well.

4.2.

Service Delivery Chain in Cloud

4.2.1.

Service Based view

Typically Cloud Service Delivery Chain will include the following  Service Creator  Service Aggregator  Service Delivers  Service Consumer  Service bill payer

This chain can be more complicated as shown below because  Within the Service Aggregator role, there could be one or more service integrator (Or Aggregator can also do some level of integration)  Within Service Deliverer role there could be Service integrator role (Or Deliverer can also do some level of integration)

HCL Confidential

19

 Within each role there could be possibility of “outsourcing”, For example Service deliverer may outsource the service support

PROPOSAL

The situation is analogous to product business where there are different roles like designer, manufacturer, distributor, stockist, dealer, retailer etc; however the big complexity is because of difference between product and service.

4.2.2.

Layer based view

If we stack the layers in service deliver infrastructure in cloud computing, regardless of the location – just view from the logical abstraction the view will be as shown below-

HCL Confidential

20

PROPOSAL

4.3.

HCL Confidential

Holistic picture with HCL Cloud Computing Architecture

21

4.4. Service Management Scheme and architecture: PROPOSAL The picture is very complicated but we will create a picture of services in the ecosystem to develop the service management scheme that will lead to the service management architecture. Some process lifecycle will be local and some will be global. Service Management scheme is derived from a good understanding of Service Equation as defined in section 1.3.1 Scheme will provide the ecosystem approach for all the processes for all the role and architecture will be elaborated for specific set of processes applicable to specific role Generic Approach Consideration  The Service changes its form as soon as it crosses the boundary of a role  Service provided by “creator” to “aggregator” is different than the service provided by aggregator to deliverer and so forth  “Component up” view of service will start from creator and will gradually fade as it passes the boundary of role –likewise the “ Service Down” view will fade towards creator

Sample Example Service Creator  IaaS, PaaS or SaaS creator would create respective offering. Their critical success factors would be Event, Incident, Problem, Availability and Capacity management  Their CMDB will be primarily component based.  Self help portal to aggregator/deliverer will bring in significant efficiency and value addition in service Service Deliverer  All operational process with multivendor process management will be critical success factor  IT Service Continuity will be

HCL Confidential

22

Service Aggregator  Service Architecture, standards, portfolio and service catalogue management will be the critical success factors.  Service Continuity will be owned by aggregator and would be most complex because of distributed supplier  CMDB will be “service instance” based and a layer above that.  Supplier management will bring in competitive advantage Service Bill payer/Consumer  Business alignment and Service Strategy would be critical success factors along with organization design, architecture standards and

contractual obligation and underpinned with aggregators contract  CMDB will be service based with no visibility to components - In fact it will be more a OMDB of Managed Objects  Request fulfillment and Access control automation will bring in significant value addition and efficiency

PROPOSAL

4.4.1.

policies.  Service Level management and service catalogue Management will be bring in values.

Key questions to ask

Before you develop any service management scheme you must have answers to the following key questions  Who are the consumers/users of the service – For example, the business situation and the scheme and process considerations will be entirely different when your customer is a Service Deliverer and further passing on(with value addition) vs a customer who is using the service himself.  What is my role in Service delivery chain? – You may have multiple role and the scheme as well as the process scope will differ from role to role.  What exactly is the service? – If you are able to define Service exactly with its attribute, you will be able to understand what need to be managed. Often the product is termed as the service, for example “Virtual machine “is not a service(it is a product). To make it a service you need to bundle it certain level of functionality, availability, performance, support response, resolution etc. A complete bundle will be deemed as service by customer. However, if you are “creator” then product is more closure to service by itself.  What are the primary and supporting processes I need?  What is the process boundary and ownership  What are the process interface

4.4.2.

Importance of Managed Object

Traditional ITSM has been relying on CMDB for effective service management. However, in cloud environment, Managed Objects will become more important for aggregator and deliverer role and OMDB will be the central focus. A managed Object would be the abstracted representation of technical infrastructure as seen by and for the purpose of management. CMDB Manages CI. Focus is on CI’s administrative attribute and administrative state. Typical CI status are asset lifecycle status – received, deployed, maintenance, retired

HCL Confidential

23

OMDB manages Managed Objects. Focus is operational management attributes and operational state Typical MO States are initializing, running, hung, shutting down, off-line, dead

5. Illustration of scheme and PROPOSAL architecture

5.1.

Business situation

ABC IT Organization has chosen external IaaS cloud service from a service deliverer company XYZ. The Service Consumer is the Infra Group of ABC IT Within ABC IT, Infra group prepares platform and thus becomes aggregator and deliverer of PaaS to application management team Application Operation Group operates and support applications and thus become the service deliverer For end user, it is not Cloud; it is local data center run service

5.2.

Service scheme overview example

Service equations will relate the following elements  ABC IT Organization: No Change in the equation, see section 2.1.1. They continue to be accountable to business and responsible to end user for the same set of service  ABC IT Service End Users: No Change in Equation. They continue to receive the same set of service in same manner  Application Management Team of ABC IT: Change in the equation. Instead of only internal OLA, they will deal with external OLA also. This additional burden will be more than compensated by gaining flexibility and getting relieved on platform capacity planning  Infra Team of ABC IT: Change in equation with respect to OLA but gains in outsourcing the hardware capacity planning.  XYZ IaaS Provider: New entry in service equation ABC organization’s end users services will be governed by traditional ITIL processes. IaaS will not be visible in Service catalogue but it will be in CMDB Event management will be applicable to VM “managed object” and layers above (applications) For Incident management IaaS issue resolution owner will be ABC IT Infra Group Capacity management will focus on Business capacity and application sizing SLM will be governed by HCL multivendor SLA-OLA framework

5.3.

Service Management architecture Example

ABC IT Infra Group and external IaaS provider will have Service Deliverer and Service consumer relationship. Service catalogue will have entry like  Provisioning instances  Provisioning images

HCL Confidential

24

 Provisioning storage  Managing assets in asset DB

PROPOSAL

Each delivered instance will become a “service item” Each service item will have attributes like Instance name, IP address, Created date, Running Duration, Status, Owner etc Self Service Catalogue will be “functional service” list that will allow consumer to do the management functions

5.4.

Process Design and Implementation Example

Self Service from IaaS provider will provide the following  Managing Instance  Change the name of the instance  Extend the expiration date  Reboot the instance  Delete the instance  Create an image based on the instance  Managing security keys  Managing IP  Managing VLAN  Managing Image  Provisioning Image  Account Administration For CMDB of ABC IT, IaaS data will form a MDR and typical record will include  Name of the instance  Expiration information  Operating system of the instance.  The primary IP address associated with the instance.  The secondary IP addresses associated with the instance.  Server size of the instance.  Storage disk size of the instance.  Host name of the instance.  Image from which the instance has been created.  Date of creation of the instance.  Status of the instance.  Originator that requested the instance.  Price charged for the instance per UHR.  Running time elapsed since the instance has been provisioned (in hours).  Instance tags.  Notifications about the instance event. Hardware profiles will not be the part of Service Asset and Configuration Management (SACM) system

HCL Confidential

25

6. Typical scenarios debated PROPOSAL The debate is based on the questions that are commonly asked. I will draw some analogy from other industries to make a point of view and opinion

6.1.

Whose Incident it is?

Scenario: We have a priority one outage. How do you check Cloud’s current availability? Can your service desk operator open an incident ticket in their system or must they hang on an 800 number? Can you open it right away so they look at it in parallel with you or will they only accept it once your technical staff has traced the problem out into the Cloud? Can your diagnostic systems open the incident ticket automatically? How do you track the status of the incident? How much information can you see? Who has it, what do they think, what are the estimated times … Etc. Answer Cloud did not change any equation in these scenarios. Just think of your Telecom service as Cloud and in fact they are. What do you do if the telecom service is down and that is causing priority one outage in your organization? In other words these are the questions to be asked not after you started using cloud service but before you signed the contract. Every contract has some support SLA so there will be one for cloud service as well. The answer lies in the following  End to end Incident Management of end user organization and its Service Desk  Incident Management of Service Deliverer and its support center with defined boundary and how it interfaces with process above and process below  Problem and Availability Management of Service Creator and its command center

6.2.

About Continuity

Scenario: You are preparing the disaster recovery plan (DR) for the new system that includes IaaS. Do you have access to your IaaS's DR plan? Who do you talk to and what is the process to dovetail their plan with yours? If either party changes their plan what does that trigger? Answer This question is challenging the basic premise of cloud service. Cloud is one of the emerging tools for DR itself. In fact there is no concept of DR for cloud because it is by design disaster tolerant. You will base your DR plan based on “granted” fact that cloud service provider is the right vendor in the business. Probably, what is “disaster” in traditional term would be “catastrophe” in cloud context. For Cloud Computing would rather be a catastrophe to impact your service and business does not think of catastrophe, it is an implied risk in business all the time. (What if all the doctors are sick in your hospital?) The answer lies in the following  Your Service Strategy and your service sourcing strategy

HCL Confidential

26

 Your DR plan based on above strategy

PROPOSAL 6.3.

Proactive Problem Resolution

Scenario: The XaaS provider has a problem. They are fast running out of resources and your service will be impacted within hours. How do they know who to contact? How do they contact them? What will be your response? Answer This question is again conditioned by the mindset of traditional computing. There are many things that might be happening in your data center but those things rarely happen in cloud environment. And when those rare occasion come; cloud service provider has established methods to deal with the. It is their business to deal not yours.

6.4.

Service Economics

Scenario: Your organization wants to move from per-user cost allocation to pertransaction. Do the reports from the service provider tell you enough to do this? What is involved in getting the reports changed? Answer Variety of cost models are available to pick from. The situation is very similar to Telecom service providers who offer variety of service plans and switching option.

6.5.

Change management

Scenario: The service provider is planning a major upgrade of their SAN. Do they need to notify you of the planned change? What influence should that have on your forward schedule of change? What contingencies are required at your end? What contingencies have they agreed to have in place? Answer Service providers will routinely upgrade their service delivery infrastructure and they will routinely communicate about their plans to do so. For example telecom companies have been upgrading the links and circuits and hubs. Airlines are upgrading their aero planes with new entertainment systems routinely. WiFi on board has been a routine upgrade. They planned these in such a manner that the service is not impacted.

6.6.

Service Level Management

Scenario: Your customer wants an improvement in their service levels, e.g., increased availability or expanded support hours. How do you determine the knockon improvements required in your agreement with the service provider? How do you negotiate that and what algorithm will they use to price it? XaaS is supposed to be about increased flexibility but outsourcing has a history of decreasing flexibility at a business level with situations like this. Sometimes the increased charges are

HCL Confidential

27

prohibitive because the pricing terms for changes were never agreed up front, and you have to go back to the customer to say you can’t deliver.

PROPOSAL Answer

This more a business/commercial question rather than service management question. Service providers keep on rolling variety of promotions and you might as well feel that you got stuck with “old” opportunity against new opportunity.

6.7.

Compliance and control

Scenario: The auditors are in town. They want to see the physical facilities. How many sites will you need to show them? Can your auditors have access to the XaaS providers’ buildings? What needs to be done to arrange this? The Cloud may well spread your infrastructure to new countries. You will need to check whether your existing auditors can service that. They will of course want to know about the security, privacy, continuity and other capabilities of your XaaS providers, too. Will ISO 20000 or other certification for the providers suffice? If not, what information is required and are you confident of the availability, timeliness and quality of the answers from the XaaS provider? They could fail your audit for you. Answer Different industry has different kind of compliance requirements. Services are designed to meet those requirements. Many solutions are evolved as the new law comes into force. Regulatory compliance requirement provide sufficient time to redesign product/service to meet those requirements. Products and service producers are sensitive as well sensible to market needs. One example is acceptance of electronic signature in financial industry.

6.8.

Application Operation

Scenario: A new version of the application is in stress testing. Your application testers are getting a puzzling performance bottleneck. What tools are provided for them to see into the Cloud? Who from the XaaS provider will work with them to assist? What will it cost? What does it cost to generate really large temporary datasets or transaction rates for volume testing? Answer During the application portability assessment, these questions are brought up and addresses by the service providers

6.9.

Business Service management

Scenario: Your Company has changed its strategy and is now expanding into Europe. What about data privacy regulations you dismissed as irrelevant? Answer See the answer to 6.7

HCL Confidential

28