Getting Started with Application Compatibility in a Windows Deployment
This article explains how to begin the process of evaluating the impact of application compatibility in your deployment project. You will learn how to make an inventory, prioritize applications, and identify which applications are to be included in a specific role-based deployment image.
Getting Started with Application Compatibility in a Windows Deployment
If you have worked on an operating system deployment project in the past, you might remember application compatibility (app compat) as the source of many of the greatest challenges you came across. It can require the most effort, take the most time, and generate some of the most serious blocking issues. If you are working on an operating system deployment project for the first time, you might have heard horror stories about app compat; or perhaps you have heard nothing, and the scope of the work might be a complete surprise. Whatever your situation is, with proper planning, the project can become significantly more predictable and manageable.
Understanding the Application Compatibility Challenge
At the core of the application compatibility challenge is the law of large numbers. Organizations can have tens of thousands, or even hundreds of thousands of desktops. Each endpoint can have dozens of apps installed, and you might not even be aware of what is installed (particularly if users are local administrators). So, by the time you consider each of these desktops, it is possible to have hundreds, thousands, or even tens of thousands of unique apps installed across all of your desktops. And that is just Windows apps! When you consider web applications, you then have to account for every unique website in the world, because it’s plausible that quite a few web apps from various locations inside and outside of the organization have worked themselves into a productive workflow somewhere within the company. The numbers really start to explode, and if you’re not careful you can end up absolutely paralyzed with fear because of the massive number of moving parts involved!
This article focuses on the first two steps: discovery and rationalization. At the end of this process, you can generate your budget and plan to move forward with the project, so it’s very important to execute these steps well.
In the past, "Application Discovery" has been called "Application Inventory": the shift to using the phrase "Application Discovery" is very intentional. We found that the word "Inventory" drove customers to believe that they had to find absolutely everything that was running in the environment, and feed that complete list into a rationalization process. And you know what? You could kind of get away with that for installed Windows applications. (The largest inventory of installed Windows applications we are personally aware of is 130,000 applications. That’s too big, to be sure, but it’s not so big that rationalization isn’t possible.) However, a platform migration to a new version of Windows also normally includes a new version of Internet Explorer. How big is the list of unique URLs navigated to by everyone across an organization? Huge! Many customers also upgrade the version of Microsoft Office they are using during the migration (Chris Jackson discusses the mathematics of doing a complete inventory and rationalization of Office documents in his TechNet Magazine article "Microsoft Office: The Mathematics of Office Compatibility." As you can see, it really often doesn’t make sense to find everything. At the same time, you do want to discover those items that represent genuine business risk during the migration!
Performing manual discovery
In an ideal world, business units should be coming to you. After all, they are the ones asking you to insure these applications against failure in a rapidly moving technology environment. So, doesn’t it make sense that they at least tell you what they would like for you to insure? Chances are, though, that’s not happening (yet), so you’ll have some work to do.
Automating the discovery process
Since application discovery involves matching software against business value, it’s a process that can’t typically be completely automated. However, in many environments, business users and department coordinators might not be aware of everything that is driving the business. If you are taking your first steps toward software asset management practices within your organization, then managing the risk of missing something is a sign of a healthy partnership between business and technology.
As you collaborate with the business to determine which applications should be classified as managed applications or supported applications (managed applications are specifically regression tested prior to change; supported applications do not have regression testing, but they do have support provided should they happen to fail in the new environment), you will need to make some hard decisions to determine which applications belong on which list.
Identifying business-critical applications
Some business-critical applications are easy to identify and some are not. If your organization does business through an Internet presence, word processing, image manipulation, and page-coding applications might be considered business critical. Business-critical categorization will vary by job role, too. To a call center, an application that monitors server stability might be considered critical, while other departments would place no value on it.
Identifying high-priority applications
High priority applications might be easy to identify in your own department, but difficult to identify in other departments. Sometimes you can identify a high-priority application by the percentage of computers it is installed on, though this can be misleading. For example, an application that was developed internally to monitor the amount of toner in the company’s laser printers might be deployed to every computer but actually used (or considered essential) by very few people. If your organization has a DRP or a BCP in place, the high-priority applications might already be identified in those plans.
Mapping Applications to Roles
The concept of user roles can be instrumental in determining an optimal operating system deployment plan. Users within a given role tend to use much of the same software, and being able to begin deployment after completing the app compat work just for that role, rather than waiting until you have completed work on all of your organization’s software, can not only fuel the morale of the team (who now have a success metric to be proud of), but also drive important learning into subsequent roles that otherwise might not have benefited from the deployment.
There are, of course, applications that are standard across all roles. Examples might include email and antivirus applications.
The process outlined in this document should produce an application catalog for your organization that is prioritized in terms of testing required, specific user roles, and which applications will be deployed with Windows 8. This catalog gives you the raw information needed to progress to the next steps in the process. Using the information in your application catalog, your next steps should include:
There might be other tasks involved as well, depending on your organization’s needs and culture. The decisions you make regarding the priority of applications and testing might also be affected by the structure of your organization. For example, you might want to include a step to reevaluate the list of applications to be deployed with the operating system to see if there are new applications that should be added.
About the Author
Chris Jackson, aka "The App Compat Guy," is a Principal Consultant and the Technical Lead of the Windows Application Experience SWAT Team. A widely recognized expert in the field of Windows application compatibility, Chris has created technical documentation, training, and service offerings used inside and outside of Microsoft based on years of real-world experience with enterprise customers and independent software vendors.