Scattered clouds

So where is this "cloud" physically ... in meat space.

I went to find out. First, I started with a very helpful grid courtesy of John L. Willis's IT Management and Cloud Blog at http://www.johnmwillis.com/cloud-computing/cloud-vendors-a-to-z-revised/. That provided the names of the known vendors and what they provide.

The next question was, Where were they providing these services? That is, where were the actual data centers located? I got that from a combination of company web sites, regulatory filings, my own industry experience and a fantastic online resource called Data Center Knowledge at http://www.datacenterknowledge.com/.

Here's what I came up with ...

Now, I don't guarantee that this is 100% correct. It's just a first pass. I'd appreciate any comments or corrections.

Have a better day,

Bill

Brain cloud

In a comment on an earlier entry, a reader who wishes to be known only as Alec referred to the "knowledge concentration" that a third-party provider brings. He was talking about the ASP model, but acknowledges this holds for cloud providers as well.

This knowledge concentration means that deployment "requires about 10% less effort than a customer-hosted one of the same size and complexity," according to Alec, whose statement also suggests this might hold for incident management.

But I think there's even more to it than that.

If your labor is 10% more efficient, then that's time that they can be spending on value-add projects rather than keeping the lights on. Most business cases I've seen would grant that this is a 10% savings, but that would only be true if your cloud provider's cost per person-hour were the same as your badged employees'. But you're not fishing from the same pool. If your data center is in a rural or semi-rural area where skilled workers are hard to find, then you're paying a premium for them. If you're in a major metro, you're paying a premium just on the burden rate -- and then you can consider higher salaries. But cloud infrastructure is in places with affordable labor markets where there's a concentration of IT skills. So that adds to the bargain.

And we're not just talking about the tape monkeys and board jockeys here. The higher up you go up the skills ladder, the better the payoff is likely to be. Unix admins? LAN admins? Hypervisor gurus?

Also, if your cloud's team is 10% more efficient than your home-grown team, that means that your systems are back up and running 10% faster. What's that worth in terms of productivity? Customer satisfaction? Revenue? (By the way, don't count revenue in a business case. It's misleading as all get-out. But I think it's fair to include EBIT or EBITDA, depending on whether you're presenting a cash- or accrual-basis case, respectively.)

One last point about cloud labor costs versus in-house: Growth. What are you projecting for wage inflation next year -- 3%? 3.5%? Whatever it is, it's just a projection. You really don't know. You'd be remiss not to add a risk factor to that. Depending on the size of your shop, three or four longstanding employees who know where all the bodies are buried could blow that estimate straight out of the water.

And then what are you paying them to do? You're paying them to deliver an adequate standard of service. Adequacy is defined by a service level agreement between you and ... uh ... you. There's no real penalty for violating it, except that you get an earful from the end users.

But with a cloud provider, you have a contract. You know exactly how much it'll cost next year to maintain a specific service level. If that SLA is violated, you get an agreed-to rebate. Otherwise, you know what you're paying and know what you're getting.

Lost on the Op-Ed page

First, sorry for the disappearing act. I was given the brief to start this blog in my spare time, then they took away my spare time. I've got the work-life balance to post at least every few days now going forward.

But I'm not going to blog just to blog. One thing that prompted me out of remission was an op-ed piece in the New York Times by Harvard Law's Jonathan Zittrain. As with many Ivy types, he makes some remarks that are obvious given a moment's thought, are expressed very well, and not quantified worth a damn.

http://www.nytimes.com/2009/07/20/opinion/20zittrain.html?_r=1&scp=1&sq=lost%20in%20the%20cloud&st=cse

Zittrain's thesis is that the cloud is a dangerous place. It's great to have all your data backed up offsite but -- and this is why we need Harvard on the job, to think of these things for us -- What If Something Goes Wrong?

The infrastructure could fail. The keepers of that infrastructure might even betray your confidential information. Right to privacy -- a dubious enough concept in the real world -- is practically non-existent online. Under the Patriot Act, the government can grab your data without a warrant just as easily as it could tap your phone. And then heaven help you if you're actually sending packets outside U.S. borders!

All good points, Professor Zittrain. The op-ed piece was directed at a general readership (although most Times subscribers would probably bristle at that characterization) and was focused more on personal computing. So it's not surprising that they're nothing that any decent CIO hasn't already thought of.

The questions, then, are how real are these risks? How can they be mitigated? And most important: How much could they cost you?

Real? Sure they're real. System failure is definitely real. Industrial espionage is a possibility. Beyond that, maybe we're just descending into paranoia.

Zittrain suggests some public policy solutions to mitigate: Fair practices law could compel cloud providers to send your data back to you upon one-click request and delete it from their own devices. Other privacy protection statutes could be enacted. And of course cloud customers can take matters into their own hands by improving their encryption and deploying other security options.

At what cost, then? Legislation is expensive, but doesn't tend to hit the CIO's p&l statement. Industry groups have lobbying firms on retainer; it may be time for industry groups to put Zittrain's public policy initiatives on the front burner. Security can be costly; I've had clients whose firewall servers consisted of $50,000/year of software stacked on $5,000 (one-time) worth of hardware. But that just reminds me of what's been written on bumper stickers about school district taxes: "If you think education is expensive, try ignorance."

Zittrain hits on one critical hidden cost of the cloud, and on this point I think he's quite right and actually displays the kind of foresight that Harvard people are supposed to display on a regular basis: The cloud could shackle innovation.

"Both the most difficult challenge -- both to grast and to solve -- of the cloud is its effect on our freedom to innovate," Zittrain writes. "The crucial legacy of the personal computer is that anyone can write code for it and give or sell that code to you -- and the vendors of the PC and its operating system have no more say about it than your phone company does about which answering machine you decide to buy."

(Answering machine? They still sell those?)

The point, again directed at the personal computing public, is well taken in the corporate world. If you have people on your team who love to tinker and are good at it, the cloud will put opportunities out of their reach.

They won't be able to write spaghetti code. They won't be able to forget to tell anyone about it and never enter their changes into the CMDB. They won't be able to cause outages just by going on vacation. They won't be able to negotiate outrageous raises because they're the only ones who understand the "improvements" they made. They won't be able to retire at 39 and come back as $400/hour consultants at 40.

Instead, such monkeying around can only be done by people who do the same system administration and operation tasks day in and day out for a variety of customers with similar requirements, applying their professionalism and knowledge concentration seemlessly and invisibly.

Hmm, maybe the standardization benefit outweighs the innovation cost.

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