Monthly Archives: June 2012

DNA thought developing

Hello everyone

Just quickly picking up on the DNA thread. If you remember I was building quite a basic picture of what happens in a ‘typical week’ on the average IT service desk. It was really an exercise to see how people cope with the balance of planned/unplanned activities and how cloud computing may (will ) have an impact to such activities.

You may recall my wrap up picture of the Monday to Friday DNA week.

As depicted above I tried to ring fence low level tasks that may be replaced/amended/affected by a cloud strategy. It was desperately basic and lacked any real methodology or plan. However, I knew that and wanted to start right at the ground level on the KISS premise. For sure we can all make things complicated quickly!

Pushing this forward I stumbled upon ( or someone suggested ) an excellent paper from IBM entitled The Future of the IT Department.  Visit

The argument IBM makes is that at some point the advent of cloud will demand a change to how the overall IT Department will function and deliver service. All this is music to my ears of course because it has got my juices flowing again on the risk of standing still in the IT Service aspect of IT delivery. Of course it is a tough one to know what to do because there are few experts out there and all the traditional models we had before are potentially redundant. I therefore like the IBM patented Component Business Model for the Business of IT. Yes IT service is a business and not just a function residing in the dungeon of a back office cost overhead.

So originally i had started looking at just the IT service fulfillment aspect from the lens of the traditional service desk but the IBM report has made me look a lot wider to how the cloud journey is going to change the IT department landscape.

Graphically they have a framework to establish the IT department structures and functions both BEFORE and AFTER

I wasn’t planning to throw any thesis at you in this blog because IBM have done a pretty dam good job IMHO but I would like to see if anyone has any views on the approach to break down an IT department’s functions and services into components as suggested by IBM. I suspect for many they do not and have a much more one dimensional view of the IT department i.e. Development, Support, Operations, Security, Architects. I think that to really get into the cloud impact assessment a much more three dimensional and deeper analysis is needed and the IBM Model is a great resource to look at how you can get there.

As always any comments for or against would be helpful.



One new quote that I couldnt resist

Im reading an excellent ( slightly geeky ( book called Turing’s Cathedral by George Dyson and uncovered an excellent quote that made me 🙂 when thinking about the current state of IT and cloud ……


Here it is…

“The planning for this machine will require such foresight and self contained rigour as one would need in order to be able to leave a group of 20 ( human ) computers, who are reliable but absolutely devoid of initiative…….John Von Neumann

Words underlined struck a note with me when considering our journey to the cloud. I deliberately didnt call out the word DEVOID because its a paradox that cloud computing needs humans to functcion correctly. I will leave it open whether humans will feature much in the world of cloud at some point in the future.



The DNA of an IT Service Desk – Close out thoughts


So I have mulled over all the comments I have read ( thank you to each and every one of you ) and there are 5 main themes that loom large for me.

1. Before implementing any cloud service ( public or private ) examine the ‘impact’ of the decision on the internal processes and communications within the IT service desk to identify opportunities for streamlining, changing, starting/stopping, training (perhaps ) and impact to the IT Service itself. Basically DO THE DUE DILIGENCE

2. Start looking at the service desk in the four buckets – Planned, Unplanned, Projects, New Requests – as a way of learning how things ‘tick’. The DNA workshop idea is a very simple ( and possibly narrow I appreciate ) way of focusing attention on a typical week. Why not build it into your communication approach with the Service Desk team?

3. Definately involve business stakeholders in this analysis. Dont treat cloud, service desk and the impact to the users as stand alone events. They arent.

4. Consider the vision of what the ‘next service desk’ will look like. Some of you mentioned that the first cloud service taken up was a Service Desk one. Smart move to me as it irons out all the legacy mini hidden processes with legacy tools and gives the users a simple self service approach that leads them into other cloud apps.

5. Challenge the time it ‘takes to do stuff’. Not because you want to be awkward but in the context of a new user joining the organization. Imagine a brand new company and the first day. What would be reasonable to deploy an iPad into the corporate network? How long should it take to build and deliver to desk a new notebook? Should a software request take a week? Knowing your ‘timings’ is often different from what the service catalog might say! Or the service desk for that matter!!

Anyway it has been fun.