At both BriForum and VMworld, I had a few conversations with people about a problem looming in the near future within their IT departments--Who manages virtual desktops?
Most medium to large companies that I've worked with or for over the years have had a very thick, dark line separating the Desktop Team from the Server and/or Network Team. In mid-to-late 90's, this wasn't a big deal--you had server hardware and desktop hardware, and that was all. Right around that time, though, the "desktop" started to become less of a cold, hard piece of steel and more of an abstract concept. As software like PCAnywhere and Citrix WinFrame (and many others) started to make desktops available from locations more than a couple feet away, the idea of a "desktop" became even further separated from the actual desktop piece of hardware.
Today, for most of the people that pay attention to our site and the many others out there, providing a desktop is more akin to your cable company providing you with a TV signal than it is to managing each physical processor, hard drive and monitor of a physical desktop. We don't necessarily care what you use to view your desktop, as long as it can talk to our backend system (think thin client:cable box). The thing is, when your cable goes out, you know who to call, and the cable company knows how to fix the problem. For us, though, that's where our troubles begin: Now that the "desktop" isn't just a device, who manages it?
Years ago, IT Management drew a line around the data center and said "Desktop Team, you get the client operating system and everything that runs on it. Server Team, if it says Server in the title or runs on that server OS, it's yours."
That works for most corporate IT scenarios, except for when it comes to virtual desktops. By following the rules laid down, the Server Team is left managing the desktops provided to users who access them via SBC, because the applications they use run on a server OS. That means that two departments have to have an intimate knowledge of all the applications in the environment, instead of just the single Desktop Team. It also means that the Server Team better get along well with the Desktop Team.
Add to this VDI and the very thick, dark line starts to turn gray and hazy. As Chetan Ventakesh of Atlantis Computing once commented on BrianMadden.com:
"Desktop people don't own the server hardware. The one BIG issue in my mind that no one talks about…is that the desktop IT guys have very little control and leverage over the infrastructure that runs their desktops when it comes to VDI. With VDI, the desktop IT team simply owns and controls the content inside the VM - the VM itself and everything under it is locked away from the desktop IT team."
This is the very topic that I had so many conversations about at BriForum and VMworld. Once you introduce virtual client operating systems running on physical server hardware, how can either support team fully manage the solution with the confines of the classic set of rules?
Chetan goes on to say, "This lack of control translates to an inability to dial-up/dial-down critical resources (memory/disk/IOPS) that affect the committed SLA and ultimately the end user experience. This can be frustrating for the desktop teams where they are asked to fix things they can't control. Its going to take some new enlightened organization and practices to be able to get around this one!"
So what we end up with is finger-pointing and positioning, two things that are already abundant in most IT departments. What we need is a new solution, but that's a complicated issue. Some ideas, good, bad, or ugly:
- Is it just a matter of spreading around some responsibility to each of the groups? That would require cross-training each team, but doesn't that result in redundancies and relaxed accountability?
- Maybe it's time for IT departments to remove the thick, dark line and bring everyone under one roof. Try telling this to the server people who've "worked up" from the Desktop Team, but it does make sense, operationally. Still, those redundancies are there again, as well as the relaxed accountability. Sure, each person still has their primary role, but if 30 people have the ability to modify a server's settings, is that better than 10 or 15?
- For the bureaucratically-inclined, maybe there's an opportunity for a new department here - a Virtualization Department. Take your best virtualization folks and your most server-inclined desktop folks and put them in their own room.
- Give the Server Team responsibility over any desktop hosted on server hardware? (I've run into this one before - the Desktop Team at a former employer would put a desktop machine in the data center and claim it as theirs because it's on desktop hardware. Imagine how happy I was when I found one of these "desktop servers" running a rogue DHCP server.)
- Give the Desktop Team responsibility over any desktop and the hardware it runs on? (Similar consequences to the above option)
I honestly don't know which option is the best, if one even is. And that's really the point of this article - to get everyone thinking. What is the next step? Have you already dealt with this issue, and if so, how? I'll collect any and all feedback for a follow-up article, so please comment below.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.