One of the biggest challenges I repeatedly come across when working with large customers attempting desktop transformation projects, is the internal structure of the organisation. I don’t mean that the organisation itself is a problem, rather that the project they are attempting spans so many areas of responsibility it can cause significant friction. Many of these customers undertake the projects as a purely technical exercise, but I’m here to tell you it’s also an exercise in organisational change!
One of the things I see most often is a “Desktop” team consisting of all the people who traditionally manage all the end-points, and a totally disparate “Server” team who handle all the server virtualization and back-end work. There’s also the “Networks” team to worry about and often the “Storage” team are in the mix too! Bridging those gaps can be one of the areas where friction begins to show. In my role I tend to be involved across all the teams, and having discussion with all of those people alerts me to where weaknesses may lie in the project. For example the requirements for server virtualization tend to be significantly different to the requirements for desktop virtualization, but when discussing these changes with the server virtualization team, one of the most often asked questions is, “Why would you want to do THAT?!” when pointing out the differing resource allocations for both XenApp and XenDesktop deployments.
Now that’s not to say that all teams are like this and – sweeping generalizations aside – I have worked with some incredibly good ones, but increasingly there are examples where the integration of teams causes massive tension. The only way to overcome this situation is to address the root cause – organizational change. Managing desktops was (and in many places still is) a bit of a black art, combining vast organically grown scripts and software distribution mechanisms into an intricately woven (and difficult to unpick!) tapestry. Managing the server estate has become an exercise in managing workloads and minimising/maximising the hardware allocations to provide the required level of service and reducing the footprint in the datacentre. Two very distinct skill-sets!
The other two teams which tend to get a hard time during these types of projects are the networks and storage teams – this usually manifests itself when discussing streaming technologies and their relative impacts on the network and storage layers. What is often overlooked however is that any of the teams can have a significant impact on the end-user experience – when the helpdesk takes the call from an irate user it’s going to require a good look at all of the areas to decipher where the issue lies. The helpdesk typically handle the call as a regular desktop call and don’t document the call in a way which would help the disparate teams discover the root cause, which only adds to the problem! A poorly performing desktop/application delivery infrastructure can be caused by any one of the interwoven areas, and this towering of teams makes troubleshooting very difficult, as there is always a risk that each team doesn’t have enough visibility of the other areas to provide insight into the problem.
Organizations that do not take a wholesale look at how they are planning to migrate that desktop tapestry into the darkened world of the datacentre are the ones who, as the project trundles on, come to realise that the project will never truly be the amazing place that the sales guy told them it would be. Given the amount of time, money and political will invested in these projects, it is a fundamental issue that organizations need to address.
So what are the next steps? Hopefully everyone will have a comprehensive set of requirements defined which can drive forward a design, something along the lines of:
1) Understand the current desktop estate:
- Define what all the current scripts are for and if they would be required in a VDI environment
- Understand the GPO structure and why all those settings exist
- Customer champions have been identified to assist with acceptance testing
- Examine the application sprawl (There are some great Citrix partner products out there like LakeSide SysTrack or LiquidWare Labs StratuSphere which can aid in this process)
2) Examine the current server virtualization platforms
- Understand the storage tiers and performance profiles
- Define the requirements around the VDI infrastructure (Write Caches, Streaming traffic, VDI density and XenApp CPU allocations)
- Delegation of administrative control to the desktop teams for the VDI pools/clusters
3) Examine the current networking infrastructure and capacity of the datacentre
- Explain that the project will effectively move all users’ desktop PCs and applications into the datacentre
- Define the security requirements that will need to change to accommodate the new desktops
- Understand the streaming technologies and the impact on the network
4) Discuss the requirements with the storage team
- Understand the current storage provision and how it is currently used
- Examine the possibilities for streaming technologies and their relative impacts on the storage
- Define how to address the requirements
5) Define the future desktop
- Define the software distribution mechanism in the new VDI world
- Define the delivery of the users experience
6) Cross-train the teams!
Seriously – the biggest step forward is to get all the teams working on creating the best user experience – together! Understanding why the desktop teams do the things they do will help the server team scope out the solution and vice versa. In the end we all want the same thing – an easy to manage, consistent and above all great service for the users. If we can crack the teamwork nut, we will be a big step of the way there. Virtual teams is a good start, but those teams need to be aware of the importance of the project and not be side-tracked into a “This is not my day job” attitude. Once the organisation is offering a great service, it’s much easier to position IT as a service offering value add to the business rather than a cost centre. Nobody wants to be the black-hole budget in these times of budget scrutiny…
The views expressed here are mine alone and have not been authorized by, and do not necessarily reflect the views of, Citrix. With many thanks (As always) to James Gordon for his valuable reviews.