Review and Prioritize Applications in the Inventory

  • Article

Applies To: Windows 7, Windows Server 2008 R2

Before moving from the inventory phase to testing your applications for compatibility with Windows 7, you need to decide the application priority and which applications and versions will be officially supported after the deployment is complete.

  • Review the application inventory

  • Prioritize applications

  • Identify applications for specific roles

Review the application inventory

Reviewing the complete inventory for unnecessary applications or versions of applications is fairly straightforward:

  • Application redundancy. Does your organization have more than one application performing the same tasks? Use the application inventory to reduce application redundancy. For example, if your organization has multiple applications used to create graphics, you can select a single application and a single version of that application as a standard to reduce support costs. If you identify a version of your required application that is compatible with Windows 7, you can also reduce deployment testing by focusing on this single application and version.

  • Application relevancy. Does your organization have multiple versions of an application including outdated and unsupported versions? Depending on the application and your infrastructure, you may want to check on version-to-version dependencies before moving to an entirely new version of a particular application.

  • Application necessity. Are there applications that are irrelevant to the day-to-day work being done in your organization? If there are applications that are not relevant to the organization, you can reduce deployment testing and post-deployment support by eliminating those applications from your inventory of supported applications.

Prioritize applications

The next step is to divide the applications into groups based on the relative importance of that application within your organization. To understand this, you need to work with the business owners of each application. Although the individual terminology may vary, here are some common priority levels to consider:

  • Business critical. An application that stops your organization completely if it fails is considered business critical. Business critical applications often have service level agreements (SLAs) that state that support staff must respond to a failure within 15 minutes or less.

    If your organization has a disaster recovery plan or a business continuance plan in place, the business critical applications should already be identified in those plans.

    Some criteria for identifying business critical applications include:

    • The application represents a primary function of the organization, such word processing or page design software to a publishing company.

    • The organization will suffer a significant financial impact if this application fails.

    • If this application fails during non-business hours, designated personnel are notified within minutes.

  • High priority. High-priority applications perform a vital role in a department or across an organization. A failure in a high-priority application may disable a department or a single business function in the organization. If a high-priority application fails, the organization can continue doing business, but one or more departments may be seriously hindered. A typical SLA for a high-priority application would be measured in hours.

    Sometimes, you can identify a high-priority application by the number or percentage of computers it is installed on, although 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 is actually used by very few people. If your organization has a disaster recovery plan or a business continuance plan in place, the high-priority applications may already be identified in those plans.

    Some criteria for identifying high-priority applications include:

    • The application is used by a large percentage of users within the department or organization.

    • Without the application, it would be difficult for the department or organization to conduct business normally.

    • Without the application, daily operations would be affected and there may be a measurable financial impact.

  • Important. An important application is one that is used frequently but does not cause a stoppage of work if it fails. An example would be a spreadsheet or word processor application that is widely used but not related to a fundamental business function. SLAs for important applications may be measured in days.

  • Optional. Approved applications that have limited use and are not directly related to a business function are optional applications. An application in this category is usually not covered by an SLA.

Assigning priority levels to applications is often a subjective process and may be subject to periodic revision. This is a valid reason to maintain a team or committee to monitor the applications in your organization even between operating system deployments.

After prioritizing your application inventory, you should also take some time to identify older versions of applications. Removing old versions of applications can greatly reduce the amount of application testing that must be performed prior to deploying Windows 7. Consider whether the older versions can still be supported by the manufacturer.

Gathering an application inventory is a good opportunity to check for improper license use, such as in cases where the application is installed on too many computers.

Identify applications for specific roles

The concept of user roles can be helpful in determining the components of specific operating system images for deployment. By assigning users to specific roles, you can more easily define the applications to include in the operating system image. For example, if you define a user role of accounting, you can specify that, in addition to the operating system, the users in this role will receive Microsoft Office and the organization's standard accounting software.

Some possible roles might include:

  • Human resources

  • Information worker

  • IT support desk

  • Marketing

  • Developer

  • Executive

There are, of course, applications that are standard across all operating system images. Examples might include e-mail and antivirus applications. These applications will be part of a core image and should all be tested extensively for compatibility and stability with Windows 7. Deployment images for the other roles are based on the core image, adding other applications used by the role.

Deployment roles can also be prioritized to lower the effort required for testing application compatibility. Role-based configurations for critical operations should receive the most testing, and lower priority images can receive lower amounts of testing. Role configurations with only minor differences from the core image can receive minimal testing. This prioritization can be use throughout the deployment as well. Roles that contain applications without compatibility issues can be deployed sooner, and those with issues can be deployed later after testing and mitigation have taken place.