Exporteren (0) Afdrukken
Alles uitvouwen
EN
Deze inhoud is niet beschikbaar in uw taal, maar wel in het Engels.

Analyzing Application Compatibility Data

Before you can move from the inventory phase into actual testing of your applications, you will need to make some hard decisions regarding application priority and about which applications and versions will be officially supported after the deployment is complete.

The first review of the complete inventory is fairly straightforward:

Application redundancy—Your organization has more than one application performing the same tasks.

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

Application necessity—Your organization has applications that are irrelevant to the day-to-day work being done in your organization.

You can use the application inventory to reduce application redundancy. For example, your organization might have multiple applications used to create graphics. By selecting a single application, and a single version of that application as a standard, your organization can save money spent on support. If you identify a version of your required application that is proven compatible with the version of Windows operating system you are deploying, you can also reduce deployment testing by focusing on this single application and version.

The next step is to categorize the applications into groups based on the relative importance of that application within your organization. To understand this, you will need to work with the business owners of each application. Some applications are considered business critical, such that your business will halt if the application fails or is unavailable. Other applications are very important, but there are ways to keep some business going if they fail. 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. If in doubt as to whether an application falls into this category, consider whether the organization can make any money while the application is unavailable, and whether personnel can continue working at all without the application. If this application fails in the middle of the night, how long it would be until your pager goes off? Business critical applications often have service level agreements (SLAs) that state that support staff must respond to a failure within 15 minutes or less.

High Priority—Applications that 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.

Important—An important application that is used frequently, but will 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 are in limited use and not directly related to a business function. An application in this category is usually not covered by an SLA, and support would be considered “best-effort.”

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 application portfolio even between operating system deployments.

After you have prioritized your application inventory, you should also take some time to identify applications that can be eliminated. Removing old versions of applications can greatly reduce the amount of application testing that must be performed prior to deploying a new operating system. 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.

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, although other departments would place no value on it at all.

If your organization has a disaster recovery plan (DRP) or a business continuance plan (BCP) 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 off-hours, someone’s pager will go off within minutes.

Identifying high priority applications

High priority applications may be easy to identify in your own department, but difficult 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. 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 by very few people. If your organization has a disaster recovery plan (DRP) or a business continuance plan (BCP) 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 the majority of the work shift.

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

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

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

Identifying applications for specific roles

The concept of user roles can be helpful in determining the components of specific operating system images for deployment. By separating your user base into specific roles, you can more easily define the applications to be layered on top of 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 carried over to the actual 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 remediation have taken place.

Vindt u dit nuttig?
(1500 tekens resterend)
Bedankt voor uw feedback

Community-inhoud

Toevoegen
Weergeven:
© 2014 Microsoft