All Posts in Technology

|In: Cloud|Last Updated:

I don’t get it.

Amazon will now sell businesses virtual PCs for $35 per month. I’m trying to figure out how this makes sense.

Let’s run the numbers. You can buy a pretty decent desktop computer … from Amazon, to take one variable out of the comparison … for $400. Plus a monitor, keyboard and mouse, but they’re the same either way — a wash.

For the Amazon offering, unless you’re planning to run it directly in your frontal lobes you’ll need a cloud client to run it on. Typical cloud clients run around $350.

Imagine you expect the desktop PC to last 3 years … a typical rotation … but because you’re using a cloud-based PC you expect your cloud client device to last twice as long. That’s probably too generous, but I’m a generous guy.

The raw numbers say that over six years you’ll spend $800 for a traditional PC. For the Amazon alternative you’ll spend $350 + 12*6*$35 = $2,870.

Presumably, what you get for the additional $2,000 and change … $333 per year … is …

I don’t get it. Because you’ll still have to handle software installations, user support, and so on. The big benefit is that if a cloud client dies, there’s no disruption when you replace it. (And, by the way: Dear Microsoft … this is 2013 and it’s still an awesome pain to migrate from one PC to another. Why haven’t you fixed this yet? Love, Bob)

Probably, this is the wrong comparison. What we should be comparing Amazon Workspaces to is running your own VDI infrastructure. It’s a much more plausible comparison, because without Amazon you need to server capacity to run the virtual desktops, and storage capacity for user data.

Enter a nice piece written by Network Computing’s Art Wittmann earlier this year (“Calculating the True Cost of VDI,” 4/15/2013). Wittmann’s bottom line comes to $900 to $1,000 to provision a cloud-client system. The picture is complex enough that I’m not going to try to put a side-by-side comparison together.

Building a side-by-side comparison is complicated by quite a few little details, like how many times you’d replace the data center hardware over the six-year span we’ve allowed for VDI desktops (if it’s every three years add $320 per desktop for this, spent in year 4 of the cycle), and whether you or Amazon will upgrade the desktop OS, and if it’s Amazon whether the upgrade license is at no additional charge.

If you’re running low on space or AC, factor that in too.

Oh, one more quibbling little detail: If it’s your server, your local users get to operate at wire speeds. If you use Amazon’s service they’ll share Internet bandwidth. Yes, VDI is pretty efficient in its bandwidth use. You still need to determine whether you’d need to beef up your network.

Or add to it, because now that everyone is completely dependent on the Internet connection, you’ll need two, from two different ISPs, connecting to two different points-of-presence at opposite sides of your building. You should have this already, of course, and if you don’t, stop reading right now and make the proper arrangements.

I’m far too lazy to perform the detailed analysis, although if you’d like to put one together and send it my way I’d be happy to share it with the rest of the KJR community.

My guess is that managing your own VDI will win, but not by a lot.

But what this really points out is that after all these years of VDI being touted as the just-makes-sense alternative to putting real PCs in front of employees, the raw economics still favor the real PC.

VDI’s “value proposition” (if you aren’t an initiate: “Why you might want to buy it”) has always been the same. It isn’t hard cash. It’s headache reduction.

But reducing IT’s headaches doesn’t improve revenue, costs, or risks.

It’s long past time for a hard-edged look at the trade-offs between using VDI-provisioned desktops and real PCs. Not just how the costs compare … I trust regular KJR readers don’t need me to explain why total cost of ownership is such a useless metric yet again … but how they compare with respect to the business benefits they enable as well.

But this will probably prove impossible, because much of the benefit of real PCs comes from “shadow IT.”

It’s something most IT departments still try to stamp out, because IT only sees the headaches it causes. Its benefits are, by definition, hidden in the shadows where they’re devilishly hard to dig out.

Comments

|In: Industry Commentary|Last Updated:

It’s a scandal! It’s a waste of taxpayer dollars (roughly $1 per taxpayer)! It’s proof, if I’d just take my partisan blinders off, as one commenter put it in response to last week’s column, that the federal government is totally incompetent at project management!

Bad project execution is a partisan issue? Seriously?

One failed project no more proves the federal government is “bad at project management” than NASA’s three blindingly successful Mars rover missions prove it’s good at it.

For that matter, the myriad, usually buried-in-the-back-yard private sector project failures tell us Healthcare.gov’s problems probably have little to do with the .gov part. Big projects are risky, for well-known reasons.

Any number of commentators have emitted strongly-held opinions about this mess, whether or not they know anything at all about software development, systems integration, or project management.

And yet, few of the mistakes that mattered were either intrinsic to government or were project management failures. What they were was entirely unoriginal. For example:

Integration engineering: It is by now well known that Healthcare.gov integrates information from more than a dozen back-end databases, synchronously, in real time. It is the big flaw.

But project management isn’t software engineering. Project managers make sure the tasks in a project adhere to the budget, schedule … and specifications. They don’t pass judgment on the specifications, unless they also happen to be software engineers.

The design was questionable at best. When a system has to consult a bunch of other systems … Healthcare.gov retrieves applicant information from quite a few other government databases … its response time can’t be any faster than the slowest of them. And as those systems weren’t designed to handle the additional processing load from Healthcare.gov, this was risk piled on risk.

My guess, based on no knowledge at all of this project, but plenty of experience in how these things happen: Either an engineering purist insisted on design elegance, or a non-technical manager overruled the experts for political reasons. Regardless, this problem had nothing to do with project management.

Agile? Quite a few commentators have suggested this should have been an Agile project. They’re wrong.

First, see above. Agile wouldn’t have avoided bad integration engineering. Second, Agile shines when planners can break a big effort into small chunks; when the whole organization has to “learn its way into” how the software should work; and when user-interface design dominates the effort. In the more common software development situations, that is.

But not Healthcare.gov. It had a detailed spec. It’s called the Affordable Care Act. Its business logic is complex. This is where you do want waterfall, not iteration and high levels of user involvement.

Slavish Adherence to Deadlines (SAD?): This was a sponsorship issue, making it a project management problem but not a problem of having bad project managers.

It’s banal and ubiquitous: In big projects, when early phases go long, everyone tells each other they can make up the time in later phases. Eventually, the only phase left to make it up in is testing.

And as everyone in the software business knows, you always test software, and test it thoroughly. The only question is whether you test it before it goes into production or after.

Deadline-adherence is a choice. Sometimes, as in Y2K remediation or product rollouts, the deadlines are real. Usually, SAD comes either from politics trumping engineering or the next topic, which is …

Optimism bias: I’m speculating but it’s a pretty safe bet. Throughout any big effort, sponsors … who are supposed to be professional optimists because otherwise they’d never do anything as crazy as sponsoring the project … often pressure project managers to commit to an aggressive schedule, or accept risks they shouldn’t.

Among the reasons is the time-honored tradition of Solving for the ROI. Another is the sponsor’s reputation for delivering the goods.

With Healthcare.gov, on the front end contractors knew that price and schedule would be key to winning the business. At the back end, everyone in the Obama administration’s decision hierarchy had committed to a date.

I doubt any of them lied, except to themselves. They succumbed to optimism bias.

Learning?

There’s nothing to learn from this little contretemps. Nothing at all.

The problems with the Healthcare.gov project are well-known, entirely preventable mistakes. If you want lessons to learn, maybe these: Make sure your sponsors know how to sponsor, and make sure key engineering decisions get a thorough vetting.

But really, I sure hope neither of these are lessons. Reminders, perhaps … of lessons learned long ago, over and over and over.

Comments