The Cloud does not mean greater agility - Cloud is NOT a utility
While I'm popping Cloud bubbles, let's talk about another couple: Cloud agility and Cloud as a utility.
Some time ago on Linkedin Cary King said
I assume that, because of the economic advantages of cloud computing, the role of IT will change from manufacturers to expert stewards of the organization’s information in support of the company’s knowledge workers. I conceive at this time that the life or “death of ITIL” is beside the point. ITIL will, no doubt, change to better support the new realities. Many processes in ITIL will grow ever more important with consolidation, virtualization and cloud (e.g., Capacity Management, Demand Management, Financial Management, Vendor Management and IT Procurement).
It seems to me that a change from centralized planning to a deliberately decentralized emphasis on innovation will become the ideal choice. We must organize IT for constant change and agility. It is no longer possible to consider entrepreneurial innovation as lying outside of management or even as peripheral to management. The IT organization function is to put knowledge to work – on tools, products and processes; on the design of work; on knowledge itself.
Big outsourcing will, soon, become uneconomical. Each function within IT can be outsourced individually. I conceive that each group within IT will need to adopt entrepreneurial skills and the Tom Peter’s view of a Professional Services Firm. That services will no longer be manufactured, rather assembled from the necessary service providers. Service providers will “buy” individual services internally or externally as needed. The same sort of evolutionary changes that occured in manufacturing more than 20 years ago...
I agree with Cary's general thrust, but I'm not sure about the assumption that he and many others make that simply having the option of the Cloud means we are going to be fizzing around moving systems all over the internet and there will be more change and a greater need for "agility".
We will no more willingly change our service provider than we currently change a technology platform. Either way it is a big ponderous decision with a big complex migration, complex at every level from legal to testing. Recently I was appalled to hear someone say that if we didn't like a Cloud service provider we could change to another one "in twenty minutes". That would be the tech lunatics running the asylum.
Let's be clear. Cloud is not a utility. Water and electricity are utilities. One supplier's water is much the same as another's. (The fact you only get one pipe to your house yet suppliers are somehow going to 'compete' is another discussion entirely). But your data is your data. When you switch from one Cloud platform to another, you need to:
- ensure the legal contracts and terms of service are acceptable
- ensure sovereignty and privacy requirements are met
- ensure the SLA commitments are met
- train support staff in any differences in incident and problem resolution
- get some sort of news feed into your change process so you have some hope of forewarning your service desk before the functionality changes or the supplier drops support for the aging infrastructure you still run or they change the API and screw all the interfaces to your legacy systems
- set up a process to get a copy of your data regularly or to ensure your data is in escrow
- analyse any differences in platform. If it is SaaS the differences could be huge - you may have to migrate data to an entirely different data model and retrain users and support staff. If it is PaaS or IaaS then not so much, but whatever the case you MUST...
- test before you go cavalierly switching systems
The reality is that the Cloud providers have you as locked in as the software vendors did before, and they know it.
So the only "agility" that the Cloud gives is the ability to run up servers without planning or budgeting. Anyone who wrestles with the business being utterly dependent on hundreds of desktop-based spreadsheets or Access databases knows exactly where this is headed: unmanageable chaos. And when it ends in tears guess who they call and expect to get them out of the hole they've dug - just as happens with Access systems and spreadsheets now.
After the warehousing system that the Distribution department so nimbly implemented all by themselves has been out for eight hours the Chairman of the Board is on the phone to the CIO. When he discovers that there is no copy of the data in-house he calls in the auditors. They want to see the contracts with Crack-Space. "Contracts? The terms of service were online. We clicked OK". Nobody printed them and now you can't see them as Crack-Space are off the air. Within two weeks, so is your ex-employer.
[From comments:
There is no doubt that much IT will be provided in a commodity outsource model in the future. that's what Cloud is: a commodity outsource model. Commodity because there is much less customisation to the specific client. it is one size fits all, with a little bit of flex in commercial and support arrangements. But it is still outsourcing with all the inherent risks.
All this talk of leaping about without due controls should be of great concern to any manager of any organisation. if IT managers want to entrepreneurally risk investing in speculative new ideas, they should mortgage their own ****ing house to do it, not risk the funds of the shareholders who employ them. the whole reason we have governance and risk management built in to companies is to prevent the recurrence of past disasters. It's called "learning" and I wish IT would do a bit more of it instead of waddling wide-eyed into every bright new idea that comes along and whining about controls that cramp agility and creativity.
Companies clearly can be nimble when they want to. When the governors decide a risk is necessary then it can be taken. The point of Service Strategy (and ISO38500) is to get that decision taken at the level it should be. the point of Service Portfolio is to understand the impacts on other services. if we are going to do this new exciting agile thingy, where does the resourcing come from?
ITIL is neither agile nor not-agile. It's a framework. You can drape a monolothic bureaucracy over that frame or you can put (hang?) a whippet-thin bunch of hairy web-freaks on it. What they do is the same. How they do it differs. The tone of ITIL is geared towards the former group (corporate mainframe background pretty much guarantees a cultural bias) but that doesn't make it any less relevant in other contexts. the need for service management is universal. the procedures differ.]
[From a great comment by Marc Buzina:
I often see the agility argument - for me it is a question of where to go. Omitting thoughts about risk, security, reliability, management and what to do in case of failures is really making me more agile. It greatly reduces the time to failure, which is what Rob showed with his fun example.
If your business has this great new idea that can only be realized with a cloud provider you either have:
a) Misaligned Business / IT (IT is less agile than business requires)
b) A business idea which does not fit the company (the whole company was never so agile)
c) An idea that requires a very specialized environment for system, so I may question the validity of the idea.
if a) you can go ahead and use the cloud provider, just as long as you respect your own risks and know your limitations. Since up to now you were no good at aligning IT to your business, you will not be better at that when you try to align your new provider.
if b) you should setup a new company. Your idea will not work properly here.
if c) question your idea.
Summary: A solution which claims to be technical (cloud is not, just as Rob says, it is commodity outsourcing) will not solve organizational issues.]
Made in New Zealand 
Comments
Cloud will be a utility
One clarification to what I have been saying:
Water
Sewage
Electricity
Phone
There is a natural progression to society's ability to make more and more complex technologies into utilities. Eventually Cloud will be a utility, once we evolve the social, organsiational, managerial, procedural and technical sophistication to control it. We haven't yet.
Cloud may already be a utility
Hi,
I'd like to add that one of the biggest issues, here, is that there is no standardized definition of what a cloud is, as related to the specific service offered on or by the cloud.
Google's cloud and what's available on it will be different than MS's, or IBM's, etc.
The cloud, really is nothing more than Software as a Service with a more diverse set of offerings than a few years ago. Those offerings, depending on the offerer, can be at different levels of maturity, quality, performance, etc. (You get what you pay for.)
There are already multiple cloud-based offerings that are charged back exactly like utilities.... Per Transaction Billing, Per Period Billing, Per Service Billing, etc.
Are all offerings that evolved? No, but not all will need to be. Are all offerings simple? No, many are complex, such as in the case where you're buying use for a business solutions platform, like Salesforce's "The Force" (which they describe as 5 allegedly integrated clouds. The truth is that some are more integrated than others.)
In cases where you put your data on a cloud, you'd better be very sure of the Service Agreements around your data and any data you generate or use to make your service valuable.
Just like in Real Estate, which cloud you select will come with the implicit clause "Caveat Emptor."
All I can offer is... "Due Diligence, Due Diligence, Due Diligence."
My Best,
Frank
The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices
the need for speed
See also this great post from ITSM Professor:
Models are a basic concept that may be missed during the initial design of a process. Even organizations with advanced ITIL knowledge may fail to fully utilize this valuable concept. Models = efficiency, models can easily lead to automation, and models are a much needed helping hand at a time when we’re all being asked to do more with less.
I'm a big fan of standard change, but this post reminds me I don't give enough prominence to process models in general.
Industrialization of IT will overcome the cottage industry
I’m not a cloud service provider, neither do I work for one.
The main thesis of what I wrote is that the end-to-end, home grown “manufacturing” of IT is likely to rapidly change as a result of increased standardization of compute capability and commoditization of processes, especially back office processes. It seems to me that CFOs will continue to want to cut operating costs, particularly for those commoditized processes, that make up some 40% of their business so that their profitability is improved. Business processes that contribute to top line growth will be under less pressure.
An anticipatable outcome of such pressure would seem to be a shift from the currently existing, legacy, highly customized back office business systems to a set of commoditized, and outsourced services. Perhaps apps. CFOs will, increasingly, wish to see CIOs present evidence of the cost of their individual services – as opposed to a single overhead item. CFOs will, I believe, want CIOs to implement “pay-for-what-you-use” chargeback to further cut costs with increased demand management.
I would disagree that Cloud is not a utility. Compute power and compute storage can be just as standardized and commoditized as is electricity (with how many different currents and plugs in a normal European vacation) or trains (how many gauges of trains are there?). IaaS and PaaS can be seen as utiliies. Virtual Machines can be, and are, swapped about quite a bit in internal clouds.
As part of their stewardship responsibility, IT will have to exercise all the contractual and financial due diligence that one would normally expect. Hence, my note that processes such as Vendor Management and IT Procurement are likely to be rather more important in the future. Just as you point out, there should be no “fizzing about” without careful contract negotiation with each provider in advance. This would seem to enable significantly increased agility – the ability to scale up new systems much faster and without capital investment. No more waiting for buying and installing equipment and software needed for the platform.
SaaS, it seems to me, is the combination of PaaS, a software rental agreement, and a special support agreement, quite similar to the application service provider of years past. I agree that a commitment to a SaaS managed service does seem to be somewhat more of a long term commitment, in part because the data is not readily transferrable. It might, I think, be best if buyers of SaaS separate out the cost of PaaS, special support and financing arrangement as they do the financial analysis of the investment.
Stewards of information service provision will, I expect, want all of the IT Service Management good practices be thoroughly and consistently executed, whether ITIL or not. It seems to me right now, in fact, that for those who provide services, evidence of their consistent execution will be required as part of the vendor selection process. Application of Six Sigma and outside-in Lean thinking will rapidly grow because of the industrialization of IT.
The question I have is whether these services will be provided by internal IT or some subcontracted external service provider. Economies of scale and increased specialization as processes become more commoditized would seem to outweigh other considerations.
If electricity was like IT
I'm with you Cary on almost all of this. But not in 2010. What we have now is a world away from the vision you paint. We're still in the experimental stage. I have the greatest respect for the pioneers out there figuring out how all this stuff should work but don't expect me to recommend that any mainstream client of mine should adopt any of it right now (although I have recommended total Cloud to one client already, or more precisely reviewed and confirmed their strategy to go totally Cloud-based which in their case was the right approach)
i think we agree that the idea that ITSM is no longer necessary shows a lack of understanding of what ITSM is. I still can't agree that Cloud is a utility. Delivering safe reliable electricity to the door is a vastly simpler undertaking than delivering safe reliable computing with the same low levels of customer governance. If electricity was like IT I'd be doing annual audits of my power company's management systems, construction standards, and building security; I'd be making sure they didn't mix my power with my neighbour's; and my UPS would cost a hundred million dollars and require 20 staff to develop and maintain it.
@Skeptic
Indeed, electricity providers are doing:
- Audits
- Monitoring
- Capacity Tests
- Distribution Management
- Strategical study (military consequences)
It's not because you don't see the complexity, as a user, that this kind of things do not exist. Power-grids are as life-critical as some IT installation are today.
So, we should look at it the other way round: utility services are those which hide complexity to the user point of view.
Regarding their performance: there will always be good and bad services.
Electricity is simple enough
you misunderstand my point. Electricity is simple enough that i can leave all that to the provider. IT isn't. I need to closely govern the IT provider, because what they supply is not a simple commodity, it is MY data
It looks simple
Electricity is not that simple. Google is building a new data center in Finland in an old paper mill. When the paper mill was built, it had to build its own supply of electricity like all similair factories did. There was no reliable electricity available for the paper mill and they had to hire electricity managers and experts. Google will probably use as much electricity as the factory used but they can buy it from the "cloud".
There is another aspect to this. A lot of IT projects exceed their budget and fail. That is also a risk. And if you buy your system development from Crack-Space Ltd, you can lose a lot of money.
And then there is a third aspect. Let's assume that a business unit finds a new and revolutionary way to make money but it needs an IT system and the business knows there is one available in the cloud. The problem is that the corporate IT center operates ITIL V3 Service Lifecycle. The new system is not in the IT business strategy but the IT Director promises that they will introduce it at the next strategy planning session and that it will be added to the service portfolio by 2015 and the system hopefully will be available late 2016. The business has two choices, either take the risk of the cloud or lose the business opportunity. Here is a good article on that (from a tweet by @Joe_the_IT_guy): http://www.cio.com/article/637772/Cloud_Computing_Waiting_Too_Long_for_Standards_Will_Cost_You?page=2&taxonomyId=3112
Aale
PS Congrats for the award, you earned it.
fallacious argument
Google can buy it because it is just electrons. they all look the same, whoever you buy them off. You have no particular affection for any one electron. there is no similarity to entrusting someone with your strategic data assets, none at all.
I don't like your other point either. You're painting a caricature ITIL. You're setting up a non-existent scenario so that you can then mock it. the whole point of service portfolio management is to collaborate as a team to determine what are the top priorities for investment right now. If it is a new and revolutionary thing then the business (of which IT is a part) should assess it and determine how they are going to resource it right now. Either defer something else or find additional funding. it's simple business management and it's how service strategy works and you know it is. C'mon Aale. If an IT department is behaving as you describe it is precisely because they have NOT adopted service portfolio and service demand principles and are operating in isolation from the business.
It was your example
Rob
I just copied your example in another setting. Wasn't it an non-existent scenario set up just to mock Cloud? I just tried to mirror it.
I'm not so optimistic about a flexible service strategy. Getting a strategy approved takes some effort. ITIL service strategy model reminds me of the 5 year plans of Soviet Union but maybe we shouldn't get into THAT conversation.
The fact remains that all IT projects carry risks. IT projects are delayed and fail, that is a real risk, just like entrusting your strategic data assets to someone. The real choice can between not having the data or having it somewhere else. The last time I worked for a corporation all our working IT systems were against corporate policy.
Aale
Planning in the commodity of Power
The main difference between electricity and IT is that IT is an ever changing environment where it is futile to talk about 5 year plans. For electricity you make plans for the next 25-50 years (regarding the whole supply chain).
How long do you think it will take for ROI on a nuclear power plant, or exploration of a new deep sea gas resource or plastering the sahara desert with ? If you are not sure that nuclear electrons can be sold well for the next 20 years, you will never build it. And just as Rob says, at the receiving end you can not distinguish between nuclear and solar electrons.
That is the reason why all this comparing IT to the basic house-hold utilities is pure nonsense. And even in your sample "strategy", I ask you, why on earth should a service strategy consider a single system? If that is what youre startegy people talk about, go get some others...
Regards
Marc
Time to market
Marc
Analogies and humor are difficult. In Rob's example the buyers of cloud services were not very bright, I tried to write in the same style.
Of course electricity is different from data and I did not mean household utilities. My point was that large users like paper mills had to to take care of their own power but today even major users like Google can trust others to deliver it. Times change.
I just read about a fresh local study on strategies. According to it, 75% of CEO's feel that detailed strategies are a burden. Agile strategy is the new buzz word here and nothing in ITIL looks very agile to me.
The real point what I tried to say was that there is a thing called time-to-market. Cloud has it risks but it may be able to offer business something right now while IT might need a lot of time and money to do the same. Maybe IT solution is safer if and when it works but there is a delay and the outcome of an IT project is uncertain.
Aale
commodity outsource model
There is no doubt that much IT will be provided in a commodity outsource model in the future. that's what Cloud is: a commodity outsource model. Commodity because there is much less customisation to the specific client. it is one size fits all, with a little bit of flex in commercial and support arrangements. But it is still outsourcing with all the inherent risks.
All this talk of leaping about without due controls should be of great concern to any manager of any organisation. if IT managers want to entrepreneurally risk investing in speculative new ideas, they should mortgage their own ****ing house to do it, not risk the funds of the shareholders who employ them. the whole reason we have governance and risk management built in to companies is to prevent the recurrence of past disasters. It's called "learning" and I wish IT would do a bit more of it instead of waddling wide-eyed into every bright new idea that comes along and whining about controls that cramp agility and creativity.
Companies clearly can be nimble when they want to. When the governors decide a risk is necessary then it can be taken. The point of Service Strategy (and ISO38500) is to get that decision taken at the level it should be. the point of Service Portfolio is to understand the impacts on other services. if we are going to do this new exciting agile thingy, where does the resourcing come from?
ITIL is neither agile nor not-agile. It's a framework. You can drape a monolothic bureaucracy over that frame or you can put (hang?) a whippet-thin bunch of hairy web-freaks on it. What they do is the same. How they do it differs. The tone of ITIL is geared towards the former group (corporate mainframe background pretty much guarantees a cultural bias) but that doesn't make it any less relevant in other contexts. the need for service management is universal. the procedures differ.
Time to market?
Hi Aale, Hi Rob,
I often see the agility argument - for me it is a question of where to go. Omitting thoughts about risk, security, reliability, management and what to do in case of failures is really making me more agile. It greatly reduces the time to failure, which is what Rob showed with his fun example.
If your business has this great new idea that can only be realized with a cloud provider you either have:
a) Misaligned Business / IT (IT is less agile than business requires)
b) A business idea which does not fit the company (the whole company was never so agile)
c) An idea that requires a very specialized environment for system, so I may question the validity of the idea.
if a) you can go ahead and use the cloud provider, just as long as you respect your own risks and know your limitations. Since up to now you were no good at aligning IT to your business, you will not be better at that when you try to align your new provider.
if b) you should setup a new company. Your idea will not work properly here.
if c) question your idea.
Summary: A solution which claims to be technical (cloud is not, just as Rob says, it is commodity outsourcing) will not solve organizational issues.
IT knows best?
Marc
We seem to be in complete agreement. a) is just what I mean. Do not think that is so uncommon situation and cloud might offer a solution. But who is the subject in your case? Are you saying that if IT and business are not aligned it is the fault of the business and they will not be able to align with the cloud provider? What if it was the fault of the IT?
The situations of b) and c) are tricky. Here it looks like IT is telling business what they should do. Hmm, IT could be right but could be quite wrong.
I'm no cloud salesman, I'm in this argument just because I did not find Rob's arguments fully convincing and wanted to see if he could do better.
Aale
the organisation's responsibility
You're hearing marc's voice as IT's voice. he's talking from a business perspective: it is the organisation's executive and governors who have the responsibility to determine if something is in the organisation's best interests. It is also their responsibility to understand the technical IT implications of what they seek to do, including the long-term risk and supportability issues. if a business unit wants to go their own way, then it is the organisation's task to decide whether to support and resource them or to kick their arses into line. IT can only lead the horse to water, it can't make it drink - IT's role is advisory. ISO38500 makes that clear and so does the ISACA/ITGI Board Briefing on IT Governanceand whilst ITIL's Service Strategy doesn't make anything clear I'm sure it's in there somewhere.
if IT and business are misaligned, the blame lies 50/50. I don't think I've blogged on that yet but I sure intend to one of these days.
Is it always 50/50
Yes, I read Marc speaking as IT and I have been trying to show the business side of the argument.
The 50/50 rule is not always right. All variations of blame are possible. I wonder if you referred to my Pink 11 presentation when you tweeted about Castle ITIL used in a different meaning? My Castle ITIL is used for defense against business. I know they should not act like that but in your excellent book, RealITSM you describe the three D's of Demand Management. Do you think the 50/50 is ok also in case of Delay-Deny-Duck defence?
Aale
Indeed Business Perspective
Hi Aale,
My comment was indeed from the business perspective, even if it is a rare view: ultimately business is responsible for all of its outcomes, including the use of IT - so no matter how you split the "blame" (I hate blaming) it is 100% business blame. IT is and should be a service provider / advisory (as skep mentions) to the business.
Lets simulate your situation. You have a new product that can not be supported fast enough by your internal IT.
Let us assume your IT / business is well aligned first. This would mean that the new product requires the whole company to be more agile than it is - so we have to be aware of a large cultural change requirement for this new product (obviously the product is not pure IT). You can do it, but usually adapting "just" the IT department to be quick enough is quicker than adapting the whole company culture...
OK, now the other way around: Your IT / business is misaligned. And since business came up with a product that can go quickly to market we can assume that we have an agile business with a dinosaur IT department. How can such a company evolve? In my opinion this can only occur if business management is weak in governing IT (yes, that is a business job, usually given to someone called CIO - he may sound as if he is IT, but he should not be!).
So now this rather weak management goes out and gets into business with a new service provider. Usually cloud service providers are very good in marketing & sales (otherwise you will not get such a new idea of the ground in the first place) - so they have strong management on their side. So who will be the leading partner in this enterprise? And the cloud providers have no interest what so ever in aligning their IT to business - the need standard only.
I do believe that Skep painted a oversaturated picture with Crack-Space Ltd. But he really is right, that this whole business is about my data - and for most companies the data is what they live on. I should be fully aware of the risk I take when I rely on someone else to safeguard my business. And in all cases I need a backout plan.
Marc
P.S.: Skep - you groked my comment even deeper than I myself did at the moment of writing it. Chapeau
sack their manager
I saw "castle ITIL" in a column by Aidan Lawes. I'm pleased to see it in general use anywhere.
You're right all variations of blame exist. I guess I meant that it averages to 50/50 :) On the other hand if a department is not doing their job properly - whether it be IT or any other - is that not equally their bosses fault? I've been vocal in the past (including back when I had a real job) about how someone's non-performance is as much a reason to sack their manager as it is to sack them. That's the point of ISO38500 (and SOx): accountability flows to the top.