Could cloud take out one-third of your processing costs?

I make you two promises.

First, this blog will have more dollar signs and numbers with commas in them than any other blog about cloud computing. This space is all about the business end of cloud. I leave the technological discussions to others who can do them more justice.

Second, even as we discuss the numbers, we won't get bogged down in them. My goal is to help you frame the justification for earnings-accretive cloud projects, and maybe even find the flaws in the business cases propping up ill-conceived proposals. So we'll show the numbers, we'll discuss the numbers, but we'll keep it at the strategic level. This blog does nobody any good if it's too dense.

So how do I come up with cloud being able to take out more than a third of your processing costs?

As an industry average, let's say that 40% of your infrastructure directly supports your test, development, and other pre-production enviornments. (We can quibble about the precision of this number; one survey of self-reporting companies might report higher, another lower. But 30%-50% is the range I've seen in print and, after taking a few minutes to go through my old customer files, I can validate that based on my own experience.)

Next, let's say that these servers are 10% utilized. Here, I think we're being generous. This is a key business driver for cloud: that you only need to pay for the horsepower you're using, so you're by definition 100% utilized. Even in a virtualized domain, you're always going to have that "white space" or "headroom" requirement. You'll also have load balancing issues and a hypervisor layer adding extra complexity (read: labor costs) to your software stack. In the cloud, these latency and complexity issues are spread around to the point of being negligible to the individual firm.

Back to the math: The difference between 10% and 100% utilization is 90%. And 90% of 40% is 36%, or more than one-third.

To put it in dollar terms, if you're spending $10 million/year on server depreciation, server maintenance, operating system support, middleware support, sys admin labor, floorspace and the 3Ps (power, pipe and ping), then $4 million of that supports your pre-production. Of that, 90% is essentially wasted due to inefficiency. With the efficiency promised by cloud, you'd only have to spend 10% of that $4 million, or $400,000. That means you'd save $3.6 million -- or 36% of your $10 million budget.

And that's enough math for now.

Of course, we're assuming a perfect-world solution. No cloud will be perfectly efficient. And let's remember that this is a business, and your provider is going to want to negotiate: "Hey, we can save you $3.6 million -- we'll charge you $2 million for the service and you'll still come out ahead."

And some costs aren't going away. The data center isn't going to shrink just because you got rid of a few servers, so the rent or depreciation on the building -- not to mention the taxes, insurance, contractors and critical systems maintenance that are part and parcel -- aren't going anywhere. (You should save some on utilities.) Some machines, due to regulation or intramural politics or whatever other machines, will need to be kept in-house. And The developers and DBAs on the application labor are just as much a fixture of the data center as the front door. At some point, IT will become such a commodity that your whole ERP system could fit on a machine the size of the ThinkPad I'm writing on now. When that day comes, your entire apps team will still be showing up Monday morning and expecting to be paid on Friday.

We haven't even considered the cost to implement. True, there's no capital expenditure, but the providers might come up with some "initiation fee" that could drop on you like a six-digit quantity of bricks. There's the depreciation writeoff. And there are the costs associated with resource actions should you, after an organizational assessment, determine that enough of the sys admin and machine operator workload has evaporated into the cloud. The cost part of the cost-benefit analysis needs to be well understood before greenlighting any project -- cloud plays being no exceptions.

Still, the benefits are there to be had. To be more granular, IBM's cloud CTO Kristof Kloeckner estimates that cloud can save you:

- 73% on utilities for end-user computing,
- 40% on support for end-user computing,
- 50%-75% on hardware capex and software licensing, and
- 30%-50% on labor (largely by reducing re-work stemming from config and modeling errors).

For more on IBM's value proposition, click:

ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/diw03001usen/DIW03001USEN.PDF

Have a better day,

Bill

Define quote-unquote success

So you just signed a statement of work hiring contractors to help you transform from the parochial, siloed organization you are to the lean, plugged-in, "cloud" organization you want to be. How will you know when the job's done? And once it is, how will you know if you succeeded or failed?

There are three steps you need to take verify that your company has benefited from implementing a cloud solution.

First, identify key performance indicators. KPIs can include such puddle-deep thoughts as "Reduce IT infrastructure costs," "Improve operating costs," "Improve business process efficiency," or "Improve customer service and satisfaction." The trick is to get away from the warm-and-fuzzy and into hard numbers.

The second step is to capture metrics that support these KPIs. The surest ways to "Reduce IT infrastructure costs " are, of course, to reduce the number of servers and the number of people. Each box and each belly-button has an incremental cost. Do you know what those costs are? That's where it all falls apart, you see. Not a lot of gthe IT departments I've worked with excel at determining how much they'll save by taking one server off the floor. They do tend to understand the savings of taking back a system administrator's badge, but at some point you run out of people who actually know something about computers. A person who gets the same amount of money deposited in her checking account twice a month is easy to understand from a cost perspective. But what about that incremental server? How much does that standard hardware build cost? How much does that standard software stack cost? Oh, you don't have hardware or software standards? Or you do, but you don't understand how to burden the network or storage components? Or you're not sure how to distinguish between physical and logical servers? Or you're not sure how the software is licensed? If you have any of these problems, I'd recommend gaining a clearer understanding of your costs before you proceed with cloud computing projects or any other supposed cost savers, or you'll never know for sure if you've made good decisions.

The last step is the investment analysis. I don't like the term "ROI". I've got an MBA with a finance specialization and I'm not sure what it means so, I'm here to tell you, the sales rep from your vendor doesn't have a clue. A colleague of mine from IBM's IT Business Management community of practice tells me that there are at least 23 accepted formulas for "return on investment". (The one I mean when I use the term is also called "return on invested capital," and applies more to corporate financial reporting than to anything I ever found in a data center.) So what do your decision makers mean by ROI? Net present value? Internal rate of return? Payback period? What's your discount rate? What's your hurdle rate? Again, if you don't have a handle on these, good luck getting anything -- cloud or otherwise -- greenlighted. I assure you, the number-crunchers who work for the lines of business know this stuff inside-out and will have a much easier time justifying their pet projects to the CFO than you will.

Whether you use ITIL or CoBIT or PRM-IT or whatever process mapping system you choose, there's a big block that deals with how well you understand your costs. If your capabilities in this area are not as mature as they should be, this could be a huge barrier to your ambitions to grow into the cloud.

For more on this, click http://www.ibm.com/ibm/cloud/ibm_cloud/.

Have a better day,

Bill Freedman
bfree@us.ibm.com

Kicking off

Welcome, and thanks for joining the discussion.

To briefly introduce myself, I work for IBM as a business management consultant. I handle a lot of the number-crunching, CFO-facing stuff. Basically, I'm called upon to do three things:

1. work directly with clients to develop business cases, chargeback models, and other stuff that involves working with spreadsheets (i.e., the junk that everyone else in IT spend their careers avoiding);
2. develop intellectual capital as part of IBM's Global Deployment Center; and
3. lead the global core team for the roughly 1,000 IBMers worldwide who comprise the IT Business Management community of practice.

Because of my misspent past -- my first career was in journalism -- the PWGPMTM (people who get paid more than me) asked me to start a blog about where business management processes intersect with the new "cloud" approach. Since they're not actually paying me to do it, though, and this is being done on my own time, they're going to have to live with the risk of Freedman being a loose cannon. I will make the bosses this one assurance: I won't write anything that will reflect negatively on IBM customers; if I have to cite a real-world example, I'll do everything I can to mask who it is I'm talking about.

So let's take a look at this intersection.

As for business management, I know exactly what that is: governance, alignment, costing, charging. I don't know too many companies that are doing it correctly, but I know what it is. (My experience is skewed, of course. The companies that do have a handle on it wouldn't be hiring consultants to help them, right?)

As for cloud, I don't know anything about it. Here's what one IBM document has to say about it:

Cloud is a synergistic fusion which accelerates business value across a wide variety of domains.

Huh?

Here's what I think it is: turning fixed costs into variable costs.

This has been around forever. "Cloud" is just a way of marketing it. I hope it works this time.

We used to call it "on-demand". We used to call it "the utility model". We still call some of it "application service provider". But it's all the same thing. Rather than buy all the components you need for your hardware, then construct a building that can provide all the power, pipe and ping you need to run those machines, then roll your own applications, you pay someone else to handle it for you.

Metaphorically: You don't own the utility grid anymore. Just the light switch.

This is not a new idea. Don't get me wrong, I'm not dismissive about it at all. I think it's great if we can get to it and I dedicate this blog to those of you who, through your comments and links, collaborate with me in making this space the home for all who'll be building business cases to support the cloud model at your own companies.

For an overview of what IBM is doing, click here: http://www.ibm.com/cloud/.

If you have any comments on what you see there, or here, please click the "Comment" button and let's talk it out.

I look forward to a fascinating conversation with you.

Warmest regards,

Bill Freedman
bfree@us.ibm.com