Lessons From Beyond the Clouds

My Adventures in the world of thin client computing


We sometimes forget that IT strategy should be driven by business imperatives, and that those business imperatives don't change just because the technology does.

So when we start to look at Cloud and SaaS from  an ITSM perspective we should always keep those business imperatives in mind. It also helps to remind ourselves that the problems the business want the cloud to solve are existing ones.

One of the most interesting projects I've been involved in recently replaced all the client's desktop computers with thin client devices, accessing all applications over a combination of an intranet and the internet and a mixture of internal and external hosting. The thin clients and the infrastructure were all provided  as part of an outsourcing deal.

It was a fascinating experience with novel technology and as you might expect there were major hiccups along the way. What struck me time after time though  was that the challenges and issues from an ITSM perspective were all old familiar friends, but seen in a new light. As the French say

Plus ca change, plus c'est la meme chose

Let us begin with what the business were trying to do, and this was very much a business led change. 


They wanted:

• Reduced and predictable running costs and total lifetime cost
• Scalability 
• A stable platform to enable rapid roll out of new services 

A longer term requirement was to enable their internal services to be made available to other partners and directly to their customers.

Lots of implications obviously follow from these high level objectives. Not all of them were perhaps realised at the time, and others were over emphasised during the roll out of the project at the cost of reducing the overall benefit delivered. Other objectives were also added on during the life of the project, such as integration with the business's green policy.

What about the service management perspective?

Many of these will already be familiar to you, I'm sure.

Service Transition

A major issue, as with so many projects, was that the project team made decisions with a significant impact on the  quality of service that could not be delivered without seeking the approval of the service management team, 

Testing

Many supposedly key aspects of the service were contractually specified as requirements for service acceptance and as targets for the service once it had gone live, but no effort was made to design and build tests during the project stage. Had an attempt been made to develop tests, and integrate them with UAT then someone might have noticed that many of the targets and service levels were nonsensical or ambiguous .

Targets

What do I mean by the targets being nonsensical? Pay attention because this is extremely important. I mean they were:

• Impossible to measure. I mean logically impossible, not just difficult
• Not relevant to the actual quality of service
• Not measuring what people wanted them to be measuring
• Not within the control of the supplier(s) to deliver

In many case these flaws could be traced back to targets being inherited from previous contracts and SLAs. Although the thin client solution highlighted their short-comings the truth is they were never good measures to begin with.

Those that were impossible to measure were often ones that were not relevant to the new architecture. For instance those measuring performance at a component level that no longer existed, or which were now hidden inside the cloud.

Often these were also measures that even if they could be measured couldn't be consistently mapped on to the customer or user experience. As an example because of  the way the system was designed to dynamically reconfigure itself it could run perfectly well one day with two portal servers unavailable, but the next day just one portal server failing could bring the entire service to a halt.

A far to common failing of targets is the seemingly universal flaw in logic which goes like this:

"I want to measure X. I can measure Y. Therefore Y must tell me about X"

How stupid is that, but we do it all the time. Do you measure average call waiting time on your ACD system? What is it that you actually want to know, measure and achieve? 

Write them down. Now.

Yes, I am looking at you, write down what you actually WANT to know.

Some suggestions:

"Do customers ring off because they get frustrated with waiting?"

"Does the call queuing system work effectively?"

"Do I need more staff on the help desk?"
"Do my users have reasonable expectations of the service?"

"How long does it take from a user first ringing the service desk until they speak to someone who can help?"

"How many customers are unhappy about how long they've had to wait for their call to be answered?"

"How many times does a customer call the desk before their call is answered?"

Now ask yourself if average time to answer recorded by an ACD system answers any of those questions.

A classic I came across on this particular project was that it was two years before the service desk provider let slip that they only counted waiting time after the caller had listened to the "Welcome" message. Their target was to pick up calls within 20 seconds. The welcome message typically lasted 45 seconds. Go figure.

And if you want a service delivered over the internet you can't hold your application supplier responsible for the poor transaction response time experienced by a user living on a canal boat moored in a cutting.  It didn;'t stop the user complaining though.

Contracts

Something I've never understood about ITIL, especially considering OGC's wider role, is that it has never addressed that in the UK most IT services are dependent on outsourcing, and contracts are therefore key.

Where do I begin? Well to follow on from the previous section too many contracts are written with what went wrong the last time in mind, which might be wholly irrelevant today. 

Secondly far too often the parties agree on the words, but not on the meaning of the words, and again I'm afraid that ITIL does not address this. We can all agree that a service change should go to the CAB, but that is of little use if we don't agree what we mean by a change to the service.

Language and the Dramadriehoek

Pardon my Dutch. Customers, users, the retained organisation and different suppliers are rather like the Americans and the British. They are divided by a common language, which unfortunately they insist on talking to each other. Those of you, who unlike me, have mastered another language will know the peril of the "familiar friend" that expression you can easily translate into another language, but then has a wholly different meaning. 

Mail me for the sick joke that I could insert here but won't. It was told me by a Collector* in HMR&C**. 

The great challenge for ITIL and ISO 20k has to be understanding how you map supplier terminology onto customer and user terminology throughout the value network.

The Retained Organisation

Another opportunity to spit over you whilst attempting to say "dramadriehoek" The ITIL missing link is the role of the retained organisation/intelligent customer.  You need to understand what role you expect the retained organisation to fill, and  you need to realise that it will change over time. The RO should not be man marking the supplier and providing support when they make mistakes. THe RO should be setting the framework for supplier/customer/user interaction.

Service Credits and SLAs

Welcome to a basic lesson in economics. If I set myself up to deliver service A, and you apply constraints C which have I implications on how I can D Deliver the service...

...You get ACID, which is never good.

Punishing your supplier financially only works in a narrow subset of situations. Forget the sunk cost fallacy, what matters is how you can move forward.

Forget the mistakes of your past... what is it that matters now?

----------

* A very very senior British Customs Officer

** If you want  a good night out go to a Burns Night with  the British customs.The man himself was a "Gauger" A well known founder of itSMF was once found lying in a hedge after one such event. I know it was a good night because after five years I finally understood every word the Scottish CFO at the Passport Office said to me. Pity I didn't understand him earlier when he was teaching me accountancy.