All Posts in Shadow IT

|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: Organizational Design|Last Updated:

Ever wonder what separates successful IT departments from the ones that generate nothing but gripes?

Not what separates star-performing IT from “the pack,” but what separates the competent from the rest?

150 factors make the difference, but they aren’t all created equal. Squint at the list hard and 18 float to the top. (Why 18? Because that’s how many actually floated to the top. I didn’t start with a number in mind.)

Some background: Back in the last century when I wrote the  IS Survival Guide I organized the factors needed for IT to work into four buckets. Over time these evolved into the framework I use today: Business integration, process maturity, technical architecture, and human performance.

The 150 factors on my list of what makes the difference come from drilling down into these four categories. Selecting the 18 “critical success factors” from that list was less than scientific but more than arbitrary — it was the result of experience and lots of correspondence over the years.

This week’s column defines the big four and their overall scope. Starting next week we’ll dig into the critical success factors and what to do about them if your organization comes up short. So without further ado:

Business Integration

Business integration covers everything about how IT fits into the enterprise as a whole. It happens at three levels: strategic (meaning enterprise-scale), tactical (divisional), and business-infrastructural (overall “lifestyle” technologies) integration. And yes, I’m abusing the language using it this way. Live with it.

Those are the whats of business integration. The hows are governance and the business/IT relationship.

Process Maturity

Process … more accurately, processes and practices … are how an organization does its work. IT’s processes and practices fall into five broad categories:

  • Delivery management: Primarily on the applications side of IT, how the organization makes sure IT actually does deliver what it’s supposed to deliver. Delivery management breaks down into three levels: Program management, initiative management, and project management.
  • Application support: This includes everything having to do with designing or selecting; building or installing, configuring and integrating; enhancing; maintaining; and (when the time comes) retiring business applications.
  • Information management: Making sure all structured databases and unstructured data repositories contain what they’re supposed to contain, and are organized so as to maximize their maintainability, integrity, and value.
  • IT Operations: If the systems are down, nothing else matters. If they’re sluggish, something else matters but not much. IT Operations is where IT makes sure the value it’s already delivered is there, ready to use when it’s needed.
  • Personal technologies: The ERP suite is strategic and runs the company. The CRM suite is strategic and drives revenue. But employees live their lives on their PCs, smartphones and tablets, using the office suite, email system, and telephones. Handle these well and employees will forgive a lot. Handle them badly and your reputation is shot.

Technical Architecture

Yes, IT might be “about the business,” but in the end, someone has to make sure the company has the right technologies in place, organized well, and put together to facilitate the company’s next step instead of acting as a barrier or bottleneck. Notwithstanding all that’s written about shadow IT, non-IT IT and so on, when it comes to the stuff that can’t just be a standalone “island of automation,” that someone is IT.

Technical architecture encompasses the applications portfolio, the company’s structured and unstructured data repositories, and all the platforms and technical infrastructure they reside and run on. And how they all fit together.

Human Performance

IT might be “about the business,” and its job might be to provide the technology the company needs (and by the way, its job is now bigger than that, but that’s a different topic for a different column).

IT might get its work done through well-organized processes and practices, but in the end it’s the people who work in IT who make the difference between success and failure.

Human performance isn’t about whether the people who work in IT perform. It’s about everything that has to come together so IT has great people working in it, with as few barriers as possible standing between them and success.

These four factors — business integration, process maturity, technical architecture and human performance — are what IT has to be good at if it’s going to be considered competent.

How does IT become good at them? That’s what the list of critical success factors is for. We’ll start digging into it next week.

Comments