Cloud is a distraction to IT's day job

ImageThis started as a comment but I made it a post - it is important. I've talked before about how IT Management is 1% innovation and 99% perspiration. Innovation is not our day job. For the small number of IT people who are in charge of conceptualising new services or setting architectural directions, then Cloud is very exciting. In some cases it is even relevant to them.

For the rest of you, get back to work and stop looking over on that far horizon just because it looks cool - we have a business to run.

You're an undisciplined rabble of kids who run out the gate to dance shrieking around anything shiny or noisy that comes along the road. If the Cloud is coming to us, the CIO and the architects and the designers will let us know soon enough. If you wanted to play with the cool toys you should have studied harder in school.

© canstockphoto


The CIO has let us know

The former CIO of the United States published an Op-Ed in the New York Times today entitled, "Tight Budget? Look to the ‘Cloud’."

Here is the link:

It's not so far off--though the US ought to improve its broadband networks. The CIO makes an interesting point: that the advent of cloud computing will liberate IT from its preoccupation with risk management and give it some room to innovate. ITSM (and ITIL) will move out of the enterprise and into the cloud service providers. The ostrich has taken off, and the bird in the photo have come home to roost. There's no need to clip anyone's wings--as much as you enjoy telling people to get back to work. The smug attitude that IT doesn't innovate and only provides service deserves to die quickly, or the cognitive health of its victims. I write this entirely without rancor, in silence, except for the tapping of the keys.

Yet another misconception about ITSM

This only illustrates a fundamental (but common) misunderstanding of what ITSM, or indeed ITIL is about.

The concept that outsourcing to Cloud reduces ITSM involvement is incorrect - it does, however, provide the opportunity for the corporate IT function to focus its energy on areas of ITSM (and ITIL) which it has not been given enough attention in the past (potentially due to lack of time due to firefighting). Namely the areas of proper end-to-end design (e.g. proper Availability Management is not measuring server uptime, it is about the businesses capability to execute its Vital Business Functions), governance, strategy, etc.

You can outsource the day to day techie aspects of incident/problem/change etc around the technology, but you still have to have the right structures for things like Major Incident Management - which is above the technology level and about communication and direction based on understanding business impact of the decision. True, in day to day practice most people come in contact with those daily practiced processes mostly, and so make the mistake of identifying ITIL/ITSM with only those (bread and butter) processes - which is fine, but they would need to take caution when making generic statements based on a subset only.

So you still will need the management layer no matter what you outsource into the cloud because you do not outsource the core business - and ITSM is about making sure you make the right, business driven decisions in IT! Anyone saying otherwise is not looking at the full picture of ITSM (or even ITIL).

Spot on Peter (and hope

Spot on Peter (and hope you're well, my friend).

Reading this post again made me wonder if the reason for the fuss about the cloud is less about true innovation - it's not exactly a new idea anyway, is it - and more that it appeals to business leaders fed up with having to deal with IT that demands to be visible. And in this context Skep is absolutely right to focus on the 99% (or whatever) who 'keep the lights on'.

In my view it's not about 'IT as a utility' per se, although elements such as storage and processing power are already becoming commoditised, but I suspect it is seen more as buying a business outcome that IT has traditionally not delivered upon.

It is a touch of the emperor's clothes of course, ITSM has just as much importance as Peter says, more governance-focused than operations, but we'd do well to understand the Cloud's popularity in the context of Ian Clayton's 'Outside-In' mantra: is it that the remote Cloud suppliers speak to the longings of the Cs who just want stuff to work without the fuss?


Sorry but: rubbish.

In the vast majority of established organisations (not a startup) no more than 5% of the IT expenditure goes on "innovation"... if that. (Unless of course you call anything being built "innovation"). That's not "smug" - it's fact. Our primary job in IT is to keep the lights on and to do "normal" implementation and upgrade of services.

The idea that pushing servers or systems into the Cloud reduces "preoccupation" with risk is madness. This demonstrates the epidemic failure to understand what governance is about (clearly it extends as far as Mr Kundra). You can contract out the execution of risk mitigation (Cloud). You can't contract out of accountability for risk (governance). The more we outsource the more important risk management becomes, not less. I'm appalled anyone would suggest otherwise.

Equally ITSM won't "move out". ITSM is about management. Once again some of the execution happens within the outsource providers, but every single ITSM process needs some management retained within the organisation. We've discussed this previously on this blog. "Ding dong ITIL is dead: the Cloud killed it" only shows a profound lack of understanding of what ITSM is for and what it does.

Someone in Kundra's position should be more responsible about what they say. So "cloud computing will be a $149 billion industry by 2015" eh? Well IT spend is US$3.6 trillion this year according to the same all-knowing Gartner, with 5% growth projections, which makes the projected 2015 spend on Cloud amount to 3.4% of total IT spending, four years from now. Woohoo. I've read Kundra's stuff before, when he actually was CIO of the USA, not the former CIO. He struck me then as a self-promotional bag of wind, and he still does. Like so many of these guys, he's more interested in sounding visionary and exciting than in actually making sense.

Get back to work.

[update: my tweet:
old formula: get high-flying CIO job, bluff for 2 years, get out before reality catches up, be the "former CIO" for years

Circumscribing IT

You write, " Our primary job in IT is to keep the lights on and to do "normal" implementation and upgrade of services."

I believe this describes ITSM (information technology service management). I also believe that it short changes research and development and computer science to limit all of information technology to a service.

You seem to be arguing for the separation of IT, understood as ITSM, from research and development and computer science. If you are, then I agree with you. It behooves managers everywhere to get this straight and to inform their staff that they are not being paid to innovate.

But the synecdoche that IT is ITSM does a disservice to information technology--unless ITSM leaders, especially prominent and articulate spokesmen such as yourself--spread the word that IT and computer science and engineering must be sharply distinguished. That may be the problem with "tech cowboys": their managers write job descriptions that misleadingly suggest their staff will be working with exciting technologies, with the unexpressed implication that they will play a role in their development, when in fact they will be providing services. Period. Who hired those tech cowboys in the first place? How were they misled into believing their jobs involved something other than service? Did they uniformly mislead themselves? With all the focus of ITSM on behavior, surely the architects of ITSM have an answer.

If "IT is ITSM" not just a synechdoche, what would you make of the National Institute of Standards and Technology, especially the NIST Technology Portal: ?
Are they limiting their focus to providing services, or are they actively involved with the development of technologies and standards around therse? I don't see them insisting that NIST's job is to provide a service. I see them concerned with the development of new technologies and services. They even have an Information Technology Laboratory. If we limit IT to ITSM, NIST would have to jettison its laboratory. It would not have a division of applied and computational mathematics. They would not be investigating cloud computing.

Maybe you're right: IT should be understood as ITSM, and it should never be conflated with computer science and engineering. In that case, it is up to the ITSM industry to make the point that IT does not hire innovators. IT managers should make this point up front so that they avoid hiring people they later feel the need to denigrate as cowboys.

That is precisely my point.

That is precisely my point. Some companies pay a small group of bearded chaps to keep an eye on the future and what might be useful. Others leave it to their peers and competitors, and adopt what works.
The other 95%-100% of staff are not paid to innovate, they're paid to get a job done. I completely agree all this waffle about innovation is misleading bullshit.

PS. Cowboys aren't cowboys because they innovate. They are cowboys because they refuse to be managed or accountable.

Fair enough

The conclusion then is that anyone who wants to do research and development should stay out of Information Technology. Based on my experience, that sounds like sage advice.

Educators are obligated to inform students about their employment prospects. If students study computer science and want to become software developers, they should be aware of the growing perception of information technology as a service profession. This has to be spelled out. Developers will be rotated into the help desk. Their future managers will have various rationalizations prepared--the point is that whatever those rationalizations are, students should be aware that the jobs they throught they were preparing for no longer exist as such. If you don't want to be on call, or if concentrating on software development for hours at a time is what drove you to become a software developer, some manager who knows better is going to see to it that your train of thought is interrupted, early and often. The reasons given for rotating all staff to the help desk or for instituting compulsory re-education camp attendance or treating staff as if their IQs are at least as low than their managers may be unassailable--that's not the issue. Those reasons would not be interesting even if they were forthcoming. The issue is ensuring that students and prospective employees make informed career decisions.

On that basis, my advice to students would be to stay out of information technology.

Another take on innovation in IT

Some real data on innovation in IT is here:

It contradicts many of the assertions in this thread. IT as a source of product innovation is increasing at least in some quarters.

Charles T. Betz

Stop promising innovation to everyone

I don't think this contradicts my point at all. IT as a whole, as a black box, needs to measure its value in terms of innovation delivered, sure. That is an important measure, and it is of increasing importance as the pace of the world increases.


1) that doesn't mean IT has to stop measuring itself in terms of value for money, and in terms of protection and stewardship of existing assets.

2) just because It as a whole needs to be increasingly innovative doesn't change the fact that 60% of us are there to protect and manage the existing systems, and 35% of us are there to create designed solutions. it is the job of the other 5% to identify innovative new directions, evaluate their potential, and input innovation to the other 95% as proposals.

Telling everyone in IT that they need to innovate is
(a) a distraction from their day job
(b) a source of dissatisfaction due to the cognitive dissonance of having to deliver on other measures of value and risk.

Innovation is exciting, creative and cool. People who get to work on it are so lucky. Actually they're not lucky, they're talented. Stop promising it to everyone - you just screw the place up.

In house IT does need to innovate

I was responding in particular to the following statements:

You: "if you want to be an innovator, stay at MIT, dont go into IT. Get a job at Google, not some insurance company in Omaha."

Stanislaw: "anyone who wants to do research and development should stay out of Information Technology."

These are global statements that seem to say that 0%, not 5% of IT staff might find themselves doing innovation. I beg to differ. Even for the Omaha insurance company.

I'm also reminded of Turing's immortal quote on computing:

"as soon as any technique becomes at all stereotyped it becomes possible to devise a set of instruction tables which will enable the electronic computer to do it for itself."

This inexorable truth is the harsh reality for those who might, on your advice, resign themselves to a life of working in "non-innovative" roles. Why accept that when such roles are destined for the automation hopper?

Charles T. Betz


You are correct that the "stay out of IT" was an exaggeration. However I don't think you will dispute that there is more innovation going on at Google. That said, I'm betting the vast majority of Google employees have non-innovative jobs.

I dispute that life is a simple choice of innovation or drudgery. Jobs can be challenging, rewarding and even creative without necessarily being innovative.


I must correct typos, and then bow out--I have exhausted the subject. I see you have addressed these issues elsewhere on your site.

"...students should be aware that the jobs they [thought] they were preparing for no longer exist as such."

"... as if their IQs are at least as low as their managers may be unassailable..."

These humiliating errors, which expose to the Internet a mind clouded by tenebrous vapors, have completely undermined whatever shred of credibility I might have mustered.

Back to Nifelheim!

developers on the service desk?

If you register for the site I think you might get to edit your own comments :)

Developers don't innovate. Cutting code is not innovation. Designing systems and services is rarely innovation. True innovation is often implemented by external consultant experts.

So yes, if you want to be an innovator, stay at MIT, dont go into IT. Get a job at Google, not some insurance company in Omaha. Hey even at Google, how many of their staff do you think can call themselves innovators?

Only the top 5% get innovator's jobs so study hard kids.

And in all my years I have never ever seen a developer rotated onto a service desk.

I read it on this blog

"I am all for devs carrying pagers, performing L3 support, triaging critical incidents, and rotating through ops team, because it's the only way for them to learn how to write production-ready software."


The only way for [developers] " learn how to write production-ready software"? Citations and key performance indicators to that effect, please.

devs in Ops

If you look closely you will note I didn't write that comment.

The idea of "devs in Ops" is amusing. It would be like those TV series about city-girl bimbos sent to work on a farm.

I'm sure it happens in tiny wee Agile teams but its rare in the real world

Right: I wasn't quoting you.

It does not follow from what was quoted that you did say it, and I was aware that someone else said it. Noted.

I was pointing out a few things.

One: someone said it on this blog. That's already an indication that the attitude is not uncommon.

Two: the attitude that no one is above ops isn't specific to that comment. Funny how it works out in these quasi-communistic schemes (there's an inflammatory phrase for you!) that more highly skilled workers are recruited to do less skilled work, and never the other way around. But again, I don't believe that any justification is forthcoming or that it would be interesting if it were.

Three: the questions about key performance indicators were really rhetorical. I have no expectation that they would be answered or taken seriously.

I think your 95% figure is probably correct, and may be generous. And I see that you have been saying this for some time. Some of us have taken a vow of poverty to go into R&D. But that reflects an economic reality: IT departments are increasingly adopting a service orientation. I think there is a tension between high-performance computing (HPC) and IT as ITSM. Why do I say this? One reason is that the directors of federally funded research computing centers have told me, point blank: "HPC has to be kept separate from IT." Also, I have seen HPC and research computing facilities evaporate when they were consolidated with IT, especially under managers who favor ITSM or one of its derivatives. This is not an isolated phenomenon. The mindset that you keep the lights on, and the mindset that you get involved with Edison's invention of the light bulb are different. HPC has some of the latter. When it ends up under IT, it tends to suffer, because--and this is my experience--the kind of one-off development normative and necessary in research is frowned upon in IT.


"more highly skilled workers are recruited to do less skilled work" And people call me bigoted. What makes you think dev are more highly skilled than Ops? Most developers I've met wouldn't make a good service desk analyst's a... ...ssistant.

And watching vendors' super-techs under the blowtorch of a critical sev 1 outage is often revealing. They may be able to build pretty software but supporting it under pressure requires an entirely different set of skills. Not less or more, just different.

I reckon a lot of the resentment towards ITSM is that yesterday's prima donnas - the hackers - suddenly find themselves put in their place.

Fine then, differently skilled

Then reread with "more highly skilled" as "differently skilled." And if they are only differently skilled but not better, why the need to put differently skilled persons in their place? What does this need have to do with service management?

I find your comments telling.

You would think that someone advocating a service orientation would exemplify the virtues of the customer service staff: endlessly patient, welcoming, poised, non-judgmental, focused on solving problems, eager to guide customers to a solution and unwilling to seize on inessential matters.

But what do we see instead? A pronounced resentment toward so-called "hackers" and a meanness of tone suggesting schadenfreude toward displaced workers--specifically, those you are working to displace. Why do you enjoy putting "hackers" in their place? How does this exemplify the ideals of service management?

In my own case, I happen to be extremely patient under pressure and utterly fearless in the face of complexity. I don't feel as though customer service work is the best use of my time, but on the occasions when I have been called to do it, I have been extraordinarily patient. People say that I persist and that they would have given up in frustration long before I do. I once was relied upon during service outages for those reasons.

The attitude that would lead to a desire to put workers in their place can fairly be called disgusting. But I understand why you would blame hackers for perceived resentment to ITSM: it is more convenient to place the blame elsewhere, than to accept responsibility for at least some of it. This is a behavioral issue. And service management begins with behavior.

According to the ideals of service management, pointing out bad behavior is not as helpful as indicating the desired behavior. I want to be helpful. Therefore, I will rewrite your remarks according to the ideals of service management to help you improve your future behavior.

"In my experience, developers and operators are differently skilled. There is no empirical evidence to suggest educational or cognitive differences between developers and operators. They both undergo the same levels of training, and the very best work to improve by consciously staying out of the autonomous stage of learning, in equal numbers among developers and operators. Operators excel at problem solving under crises, have excellent customer service skills and thrive on having their priorities changed. Developers operate on what Paul Graham calls the makers schedule: it takes them at least half a day of sustained effort to make progress, and they are more sensitive to interruption."

Dev in Ops

I am trying to find the main point you are trying to make and pick up that thread only. I apologise if I mistook it for something else.
Which I think is about dev in ops.

Fundamentally, yes the attitude in the "dev" world tends to be markedly different from the "ops" world.

People in "ops" are asked to deliver stability, value for money and their performance is measured against this.
People in "dev" are asked to delvier something new, with low cost and quickly - and likewise, they are measured against this.

There is a natural tension in this all between the two worlds. If in your development you cater for the requirement of monitoring, debugging, recovery methods, high availability mechanisms etc, that all costs money and takes time - and does not add to the "something new", the core reason the business asks development to get involved. So from their perspective they will want to do as little of it as they can get away with. This is normal. On the other hand, you have someone coming along and introduce something you are not sure about, upsetting the key metrics you are actually measured against. No wonder this drives tensions between the two worlds. Not to mention that budget is usually not in one hand so both sides expect the other to cover the cost of accomodating their needs.

The only question is what can you do to balance the need between new functionality and stability.
You can create acceptance criteria and corresponding checklists. Acceptance criteria is coming from Ops to say "this is what we need you to fulfill so we can accept it in production". (Different organisations have different tolerance thresholds on HOW MUCH of the checklist can be unfulfilled while management decides that it is "good enough" to go, but that is a different discussion).

So how do you get Dev to accept that they have to work against that checklist? Because of course by default (see above) the dev team will see this as a waste of their time and they want to concentrate on delivering the core functionality. You can decide that the only thing you do is be very strict as an organisation and keep rejecting a go-live until the dev team fulfills all criteria. The problem with this is that it is very costly and takes a lot of time. How much better would it be if the dev team would just accept that they need to design the operations requirements straight from the beginning (and deliver proper testing and documentation etc)? This is where you may decide to cross-rotate teams.
You cross-rotate ops to dev so they can set their criteria in the knowledge of what goes on in the dev world - for example they specify it is a format which can be taken up in early stages of requirements analysis. You also cross-rotate dev to ops so they have more appreciation that what they develop is not needless. Dev representatives often talk to the business users and they get the feeling that what they are working on will be used. They should get the same feeling about the work they put in to help ops.

Cross-rotating (for me) or involvement in each others tasks is not about lack of need for a division between the two world. It is to make the transition smoother. Like skeptic, I do not believe that simply putting an ops person in the dev world (or vica vera) they would immediately do a good job (given time they could of course learn). This is normal. But having a healthy level of knowledge about each other helps work together with less amount of negative feeling about each other and ultimately it will make both sides work easier.


Peter, your first few paragraphs are one of the best expositions of the "tension" between dev and ops I have seen in a while. And I agree - to an extent - about the solution. I don't think rotating dev and ops jobs works so well, per se. They are - as Morgan points out - differently skilled. Communication and rapport between the groups is the key, as I espouse in Dead Cat Syndrome. And I lay the responsibility for making it happen at Ops' door.

Ops will find the task easier if senior management encourage a cultural attitude that dev and ops are equal peers, instead of the common idea that ops are the menial lackies of the brilliant and creative developers, obstructive bureaucrats stifling development's art. ITSM doesn't assert superiority of ops, it just demands equal rights.


Skeptic, just to clear the misunderstanding - I am not saying cross-rotation works well either. I would try 10-15 different things before this. What I tried to explain is why, if someone does it, makes sense.

I personally think that while you can make it work, the return on that investment (i.e. giving up the time from doing the work they are good at) is much smaller than a lot of other solutions.
But there IS a return on that investment.

I personally don't even think ops should be equal to dev. Or more rights. Or less. I think they are so different and at the same time both needed (not necessarily in every org, but in most big ones certainly) that I just don't see how you can start the comparison. It is misleading. You need proper governance and management above both functions to make sure they work well and deliver according to the organisation's priorities.

Whither ITSM?

" You can contract out the execution of risk mitigation (Cloud). You can't contract out of accountability for risk (governance). The more we outsource the more important risk management becomes, not less. I'm appalled anyone would suggest otherwise."

But that's the point: once computing becomes a utility, there is virtually nothing to distinguish IT services from facilities services or electrical services. There is very little IT in it. How much governance can you propose around wall sockets? At that point would it deserve volume upon volume of explication?

By the way, most people who contract out computing services want those cycles--they aren't paying for "execution of risk mitigation" per se. That sounds like paying for due diligence for its own sake--presumably they want to compute something for less than it would cost otherwise.

get real

Oh... crap. People who seriously suggest computing will one day be as simple as electricity are hard of thinking.

Every kWh is like every other. your data is your data. Mine is mine. Computing will never ever ever be a commodity utility in the same way that electricity or water are. Get real. Computing will always be the entrusting of one of your most valuable corporate assets to someone else.

stop drinking the KoolAid.

Some things need to be called by the right name

and the right name on this is rubbish.

The primary job of IT will be more risk management than anything else: everyone can see the direkt effect of services, that is not too hard. ITs job is to think about indirekt effects: What if questions that need to be answered before important decisions are made.

More risk awareness is a good thing: it avoids desasters and yes, it slows innovation, but constant radical change is a danger by itself. I am all for innovation in IT (sorry Rob, I think that it is wrong to spend only 5% or less on IT innovation. If everyone does it, it does not make it good, it makes it common). But there is a need for a strong barbed wire fenced protection to our major systems. Would you like to have the life monitoring system in intensive care outsourced to some startup cloud business wich hosts somewhere in the world? Would you be happy if they innovated, so that your heart-attack will not be recognized? Not everything is so important, but for many businesses a major part of IT is and that is where most money is spent and where most risks should be assesed and changes need to be properly analysed, investigated & tested.

Cloud computing

Great photo!

Priceless. Nearly choked on

Priceless. Nearly choked on the clouds in my coffee.

Syndicate content