Client Virtualization - Hard Look at ROI

Client Virtualization at first blush can have compelling impact on ROI when you view it through the eyes of the vendor. The real truth lies within the details and overall impact on your install base. When trying to determine what the true ROI and/or TCO is from both a CAPEX and OPEX perspective it is best to understand the total impact of the solution selected.


How do you realistically calculate TCO or ROI?
People often ask me - do I start with CAPEX or OPEX. The real answer lies within both. Depending on the type of virtualization being implemented for clients you will want to look at the entire lifecycle of the client, application and overall business directives. Remember - that sometimes TCO/ROI is not enough to build a case. This particularly rings true when for example the implementation would have a significant impact on end users ability to perform their job function (Road Warriors, Doctors, Teachers) and their level of connectivity.

Watch Out for Shifting Costs
Virtual Desktops and Applications do have a significant value in certain situations to aid with compliance, reduce application lifecycle costs, and eliminate down time. However there are additional costs that are added that must be considered when building the case to determine if a particular solution or architecture is right for your business.

Each vendor will provide a nice TCO or ROI calculator based on what is "known" today for a typical desktop deployment. However, virtualization of Desktops and/or Applications is anything but typical. It adds additional overhead and complexity that must be added to the calculations such as:

• Reduces Systems Management Ability to Diff (Byte level) updates of applications - increases application data load on networks. This varies per Virtual Application and Systems Management Vendor - needs to be included in your selection test.
  
  
• Increases Storage Requirements both in the data center and on the endpoint - this requires additional hard drive/NAS/SAN, etc and computing processing power. For example, prior to Application or Client Virtualization the user typically only had a single copy of the OS or Application on the endpoint. Now they can have multiple copies of the OS, different versions of the same application, and/or programming framework (.Net or JVM). This in turn will also increase storage requirements in the Data Center for storing those multiple copies & impact on network for download, patch and update.
  
  
• Increases Management Overhead in other areas - while Virtualization decreases some of the areas of management overhead (Packaging/repackaging) and Test - it does increase the complexity of the overall management overhead. Why? Because prior you had only a single application to patch, update, inventory and manage on a single OS. Now there are multiple OS for single users and multiple apps. Each application will need the same level of care for Patch, Update, Inventory and Management in order to ensure compliance with regulatory, business, and security directives. Part of the ROI should be calculating what the maximum number of applications and/or OS you will support in your client environment and what the costs (with new virtualization factors) will really be.
  
  
• Increases Operational Expenses in Other Areas: Before the line between server and desktop was very clear and well drawn with the exception of Citrix Presentation Server (Now XenApp). With the introduction of Desktop Virtualization - many companies are coming to realize that they will need more seasoned experts in the troubleshooting cycle to assist the help desk (solution centers). These individuals have to be Virtual Host experts and be able to determine what server originated what version of what applications and OS to troubleshoot individual issues, audit application access, and understand total impact. Network, Database, Server Virtualization Experts etc will all need to be part of level 2 support (not just escalations any more) and/or Service Desk will need more of these experts. This in turn will drive up Operational Costs.
  

• Impact to End User Productivity: Depending on the application this one can have mixed results. It is critical to understand who the target users are and what the overall impact this type of technology will have on their job function prior to deciding to virtualize their desktops or applications. For example, their is a big push in Healthcare to provide Clinical Desktops for Physicians, Nurses, and RTs as either virtual desktops or applications. This has had mixed success depending on the implementation and stability of technology. For high bandwidth, high throughput scenarios - it typically works great until the network or electricity is down and/or the Physician tries to access the application remotely from a clinic or home office that has low bandwidth. There needs to be back up procedures and access built into the equation for critical applications as part of the overall DR plan for each user. AND the costs of down time needs to be calculated not just from an hourly dollar amount but overall business impact (liability, customer care, and employee satisfaction). Don't forget - it was the Users not IT that killed the Vista deployments due to overall impact on their job performance...

There is more to reviewing the overall ROI/TCO than what you can extract from a vendors calculator. Remember - they are not going to build in any factors that do not reflect their solution in anything but a positive light (they want to get your business). It is up to YOU the customer to determine what the hidden factors are and calculate them into the overall equation. I have seen customers that depending on their business model - have elected to only move a subset to virtualization and/or selected just a component once they realized that the traditional model was still less expensive from People, Processes, and Technology perspective (for both CAPEX and OPEX).

Regards,
Jeanne Morain
jmorain@yahoo.com

Application Virtualization Journey - Begins with a SINGLE Step

Many of my favorite customers have asked me where to begin with application virtualization. A few have been very proud that they selected their first 15-20 applications to migrate over and now believe they are ready to go. My best advice to all of you is to STOP - take baby steps when approaching application virtualization.

Why? Because it is not that simple and creates as many issues as it solves (if not more). Don't start out with 15-20 applications - pick 1 or 2 and their dependent applications. Look for those that have the highest ROI for the company to enable you to do the following:

1) Build your Business Case - Applications like CRM, Custom Applications that can't be migrated over to new OS, etc make a perfect test case. They are typically complex, with many dependent pieces and have lots of calls to the underlying Operating System. Pick ones that have no other option and a low user population - don't ever start with Outlook or Office. Remember -similar to Business Service Management - if you try to swallow a fish whole - you WILL choke on it! Cut it up into bite pieces, get rid of the bones and unnecessary elements and you can have a delicacy to be savored.

2) Identify Risks to the Business - With anything there are risks - that rings especially true for NEW technology. The earlier a technology is in their release cycle the more stability, performance and defects will be uncovered. Lessons learned only come from the experience of discovering what you didn't already know or assume before. The application (and dependent components) should enable you to deploy a complete cycle to not only test your ROI assumptions but to discover hidden costs and risks. Hint: Network, Performance, Disk Space, Integrations Required with existing tools, etc should all come up during your initial pilot. Some risks are minor - others can be significant depending on implementation architecture and route taken. More to come on this topic....

3) Formulate Routes to Value (requirements) - Similar to Business Service Management - how the solution is architected really depends on the objective one has in mind. With Application Virtualization there are several possibilities - the requirements should vary based on the end goal. For example, are you deploying Application Virtualization to reduce storage capacity for your Virtual Desktop Infrastructure? OR Are you deploying it to migrate a legacy application to another OS? OR Are you deploying Application virtualization to reduce system dependencies for your Cloud/SaaS implementation of a single application? OR Is it to reduce the footprint of your Citrix Server Farm?

The architecture that works best for each scenario will vary depending on the end objective. An agent based tool such as AppV may work better for OS Migration due to contracts already in place with Microsoft, while an agentless tool such as VMware's ThinApp would be the best solution for Cloud/SaaS deployment (nothing to install on endpoint), etc

4) Solve a REAL Problem - Although Vendors have interesting opinions - they are not as relevant as customers. Why? Because YOU are the ones that have to put your job on the line to deploy their technology. YOU know your environment and pain points far better than ANY vendor. Having deployed to millions of endpoints - I can safely say that no two environments are EXACTLY the same (although there are similarities). Customers never ceased to amaze me with how they used technology to solve problems it was never intended to (why? Because vendors didn't even realize it existed). Don't buy the Hype cycle around Migrating to Windows 7 or other events that will drive you to bite off more than you can chew at the given moment. Yes - Application Virtualization can help you migrate (don't get me wrong) but just because you CAN doesn't mean you Should. If you are not ready yet (Educating your Workforce, Development Team, Understanding Risks & Rewards, etc) - it is better to step back and take a test run before you bite off more than you can chew.

Real Problems I have seen that are compelling are DLL Hell (Finally isolating those badly behaving applications), Reducing the Footprint of your Citrix Farm, Reducing Reboot time and time needed for back outs on 24x7 facilities (such as call centers), enabling Test/Production on the same machines for longer beta cycles, and many others.

5) Educate your Company/Team - Pick application(s) that will enable you to educate your user population on the value they will gain before you leap. When I say User I mean all users (includes IT, Support Staff, End User, Executive Team, etc). By having a small pilot with no more than 500 users - you can quickly understand what types of questions virtualization will bring that you did not anticipate (FAQs and Training needed for the masses), You can also determine the impact to current reporting and provisioning tools, License compliance for Regulatory or Software usage (are there new tools or reports that are needed), Service Level Agreements (if there is a patch for a security hole, reducing trouble ticket turn around, reducing call volume into help desk - good for ROI too), and last but not least your end users.

Each week I will try to share Lessons Learned along the way - from my experience - to enable customes to drive vendors and the market to evolve. Similar to Business Service Management, Server Virtualization, and other new markets - Application Virtualization is needed and has a compelling ROI - the People, Processes and Technology all need to evolve for the real benefit to be realized and mass deployments to occur. Today - there is not one solution that has it all - so proceed with caution and select the right one for your company.

Regards,
Jeanne

Multiple Versions if IE Not Supported - What it means for Application Virtualization

Lack of Support for Running Multiple IEs Impact on Application Virtualization

Background
One of the benefits that Application Virtualization provides is enabling customers to migrate legacy applications across operating systems without impacting the end user or incurring significant costs in testing and rewriting the application to be compatible with the new version of the OS. This has become particularly important for those that believe XP Mode (lack of interaction between applications on the new OS) will not be sufficient enough to enable Win 7 Migrations (as many skipped moving to Vista).

Microsoft has stated they will not support multiple versions of Internet Explorer on the Same OS - particularly when used with application virtualization. - http://support.microsoft.com/kb/2020599/

What does that Mean for Application Virtualization?
The actual magnitude of impact really depends on the architecture that the solution uses. There are several different architectural approaches to application virtualization. Depending on the approach - this could be a significant risk for customers beyond the intentional virtualization of Internet Explorer.

There are essentially 4 types of architectures that exist currently in this market.

1) File redirection - The files are redirected to a different portion of the OS but are still technically installed on the machine.

2) Agent Based Virtualization (Agent installed in OS) - agent is installed in the Operating System and redirects calls to isolated applications. The agent needs to be sequenced etc to determine how much memory consumption and other system resources to allocate based on precedence.

3) Agentless Virtualization - The file system and code to run the application is embedded within the virtual application. The Virtual Operating System is contained within the Application to provide everything the application needs to run independant of a full OS (registry keys, specific components) and communicates with underlying OS.

4) Virtual Client/Agent Hybrid - The fourth architecture is based off of a virtual client that leverages some form of file system and manages all the components independently. It combines the approach of having the agent (without installing it in the OS) and the virtual OS.

How does this translate to impacting product support?
For most application virtualization solutions it literally means that only 1 copy (ideally the one that is shipped as part of the OS) is supported. We all know this is not realistic or possible particularly when newer versions of IE may break mission critical applications.

One would either have to uninstall the version of IE that comes with the OS and use only a single version of the virtual IE across platforms. There is still quite a bit of benefit in this approach. The biggest benefit is reducing costs across migrations from one OS to the other but also being able to support multiple OS with the same version of IE without having to do a significant amoutn of regression testing. It would be equivalent to what is done in most IT shops today for physically installed IE - say when IE 7 came out but many still used 6.

Now it does also lend the ability to run a side by side pilot of a beta version. Meaning that for a small group during the pilot phase - although there would not be broad based support chances are the benefits of having existing pilot users have access to the current version while the new version is being tested is more valuable and less risky then trying to not allow them access. However, the key thing here is nothing installed means nothing to back out and less corruption issues with the base OS.

Architectural Risk
Although the architectures that fall in the 3 & 4 category (Agentless and Hybrid) have the biggest benefit to customers in terms of portability and reduced risks from not having anything installed on the endpoint - there are some significant risks and considerations that come into play with this approach given Microsoft's support policy.

For products like ThinApp that have written their own virtual operating system - the risks are far less. The reason being is according to the written statement is 1 version of IE per operating system. Although I am not a lawyer - having done EULAs in Product Management for a little under 15 years - I do know there is some leaway in language. Microsoft specific support policy states only 1 version of IE per OS. Now given a product like ThinApp that has it's own virtual OS one could say that the virtual IE is running on it's own OS (VOS). The likelihood of having significant impact on the underlying OS would not be as great depending on how the package is created to interacted with the base OS. Remember - for critical applications it is in YOUR best interest as the customer to check with your OS vendor on what their policy is - I can not speak for either Microsoft or VMware on this one.

Then what is the big deal? Hidden Risks
Certain Application Virtualization solutions actually use IE as their virtual file system in lieu of writing their own. That means that with each application - one is running an instance of IE on the base OS. The support policy would extend beyond just intentionally virtualizing IE to migrate to a new OS but would apply to all applications that are being virtualized.

What should a customer do?
Ask the vendors you are considering about their architectural approach so you can make an informed decision as to whether or not this is an issue for your organization. ie)Is it a critical application that has key MS components or is manufactured by MS (like Outlook or Office) that you must have support for or is it a home grown solution based off of Java or some other component that does not require any support from Microsoft.

Either way it is better to understand the pros and cons of ALL the architectural approaches prior to deciding which application virtualization solution to use. Although a few are close - there is not one single solution that has actually achieved the Nirvana that many customers asked for in order to obtain the true Universal Client.

Leap with caution as the technology and market matures to understand what should and shouldn't be done versus can/can't. Remember just because you can do something - doen't mean you should. I have seen some questions on applicability of Application Virtualization - I am a firm believer that it is required to unchain applications from the OS and achieve the True Universal Client. But like all technologies just needs time.

Stay Tuned - next week regarding Implementation Considerations and Hurdles when deploying Application Virtualization within the Enterprise.

Regards,
Jeanne

Questions? Need tips or advice on your App Virtualization or VDI deployment with your current architecture - contact me at: jmorain@yahoo.com