Cloud computing is a popular topic right now. Some see it as a saviour technology for cost cutting but there is too much thought given to how you will connect at a technical level with a Cloud service provider. Just as important is how you will connect at a process level and at a business level.  IT development and solutions staff are prone to waving these considerations away as an issue for the operations people and the “suits”, but the process and business considerations are more important than the technical ones.

We are speaking here about Cloud computing as the provision of distributed services across the Internet: the ability to process “anywhere”. This is the generally accepted, current definition of the term. This includes SaaS (software as a service, which was what “the Cloud” may have originally referred to) as well as infrastructure that moves around the network, including outside the bounds of the organisation to providers of on demand resources.

Using one proposed ontology: software, platform, processing, data and communications are provided as a service. Or we can lump that together in another popular term XaaS. Cloud computing is one of those hyped terms that gets applied to everything so, to be clear, we are not referring to internal grids or hosted computing or the myriad other things that seem to get lumped into “Cloud".

ITIL & Cloud

Since ITIL is the lingua franca – the accepted common language – for IT operations right now, let us use the ITIL framework to consider operational inter-operability between the Cloud service provider and the customer.

Here are some scenarios to consider:

Scenario 1: We have a priority one outage. How do you check their 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 have 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.

Scenario 2: We are preparing the disaster recovery plan (DR) for the new system that includes XaaS. Do you have access to your XaaS'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?

Scenario 3: 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?

Scenario 4: Your organisation wants to move from per-user cost allocation to per-transaction. Do the reports from the service provider tell you enough to do this? What is involved in getting the reports changed?

Scenario 5: The service provider is planning a major upgrade of their SAN. In theory there will be zero impact. Yeah, right. 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?

Scenario 6: Your customer wants an improvement in their service levels, e.g., increased availability or expanded support hours. How do you determine the knock-on 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 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.

Scenario 7: 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?

Cloud computing is a popular topic right now. Some see it as a saviour technology for cost cutting but there is too much thought given to how you will connect at a technical level with a Cloud service provider. Just as important is how you will connect at a process level and at a business level.  IT development and solutions staff are prone to waving these considerations away as an issue for the operations people and the “suits”, but the process and business considerations are more important than the technical ones.

We are speaking here about Cloud computing as the provision of distributed services across the Internet: the ability to process “anywhere”. This is the generally accepted, current definition of the term. This includes SaaS (software as a service, which was what “the Cloud” may have originally referred to) as well as infrastructure that moves around the network, including outside the bounds of the organisation to providers of on demand resources.

Using one proposed ontology: software, platform, processing, data and communications are provided as a service. Or we can lump that together in another popular term XaaS. Cloud computing is one of those hyped terms that gets applied to everything so, to be clear, we are not referring to internal grids or hosted computing or the myriad other things that seem to get lumped into “Cloud".

ITIL & Cloud

Since ITIL is the lingua franca – the accepted common language – for IT operations right now, let us use the ITIL framework to consider operational inter-operability between the Cloud service provider and the customer.

Here are some scenarios to consider:

Scenario 1: We have a priority one outage. How do you check their 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 have 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.

Scenario 2: We are preparing the disaster recovery plan (DR) for the new system that includes XaaS. Do you have access to your XaaS'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?

Scenario 3: 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?

Scenario 4: Your organisation wants to move from per-user cost allocation to per-transaction. Do the reports from the service provider tell you enough to do this? What is involved in getting the reports changed?

Scenario 5: The service provider is planning a major upgrade of their SAN. In theory there will be zero impact. Yeah, right. 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?

Scenario 6: Your customer wants an improvement in their service levels, e.g., increased availability or expanded support hours. How do you determine the knock-on 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 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.

Scenario 7: 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?

Cloud computing is a popular topic right now. Some see it as a saviour technology for cost cutting but there is too much thought given to how you will connect at a technical level with a Cloud service provider. Just as important is how you will connect at a process level and at a business level.  IT development and solutions staff are prone to waving these considerations away as an issue for the operations people and the “suits”, but the process and business considerations are more important than the technical ones.

We are speaking here about Cloud computing as the provision of distributed services across the Internet: the ability to process “anywhere”. This is the generally accepted, current definition of the term. This includes SaaS (software as a service, which was what “the Cloud” may have originally referred to) as well as infrastructure that moves around the network, including outside the bounds of the organisation to providers of on demand resources.

Using one proposed ontology: software, platform, processing, data and communications are provided as a service. Or we can lump that together in another popular term XaaS. Cloud computing is one of those hyped terms that gets applied to everything so, to be clear, we are not referring to internal grids or hosted computing or the myriad other things that seem to get lumped into “Cloud".

ITIL & Cloud

Since ITIL is the lingua franca – the accepted common language – for IT operations right now, let us use the ITIL framework to consider operational inter-operability between the Cloud service provider and the customer.

Here are some scenarios to consider:

Scenario 1: We have a priority one outage. How do you check their 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 have 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.

Scenario 2: We are preparing the disaster recovery plan (DR) for the new system that includes XaaS. Do you have access to your XaaS'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?

Scenario 3: 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?

Scenario 4: Your organisation wants to move from per-user cost allocation to per-transaction. Do the reports from the service provider tell you enough to do this? What is involved in getting the reports changed?

Scenario 5: The service provider is planning a major upgrade of their SAN. In theory there will be zero impact. Yeah, right. 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?

Scenario 6: Your customer wants an improvement in their service levels, e.g., increased availability or expanded support hours. How do you determine the knock-on 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 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.

Scenario 7: 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.

Scenario 8: 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?

Scenario 9: Your company has changed its strategy and is now expanding into Europe. Remember all those data privacy regulations you dismissed as irrelevant?

Sorry to present you with such a long list of questions. There are answers, but you won’t find them in the ITIL books. They are policy decisions that need to be taken in the context of your organisation. Some of them can be decided in-house and some will need to be thrashed out as part of an agreement with the service provider(s).

You will be pioneering. Gartner says that Cloud computing is in its infancy and will need seven years to fully mature. There are a very small number of agreements in place for Cloud computing, and no test cases of them ending in tears. There is no common architecture, no standards, and precious little operational guidance.

There was one other type of scenario: total disaster. The service provider goes broke. Their CEO falls out with your CEO. This is a known risk of the Cloud (or any external service provider) but probably beyond the scope of an ITSM process discussion. At a business level, there had better be escrow and other mechanisms in place to give you some hope of getting your data back quickly enough for you to stay in business.

Blinded by the Shade

It is all too easy for IT to see a technical solution as a solution. The process, business and cultural problems are generally larger than any technical ones. Here we have only looked at the ongoing operational issues of a Cloud platform. We have not considered implementation, data migration, staff redundancies, training, or resistance; and a raft of other hurdles to be overcome to get there.

Operations ought to be a stakeholder in any considerations of “going Cloud”. Try to raise these operational issues early and raise them high, because developers and ex-technical managers are apt to see them as administrative concerns to be resolved after the decision is taken. See my recent article on Dead Cat Syndrome for discussion of the wider problem of development-operations disconnect. Get your senior managers to raise the business issues. Once these factors are in the equation, the benefits of a Cloud infrastructure might not seem so attractive nor the business case so compelling.