Application Strategy

Modified on Thu, 12 Jun at 12:42 PM

Overview

To effectively plan and execute IT transformation projects which involve applications, it's essential to thoroughly understand the application estate and how the applications are used. It's therefore important to develop a clear strategy for processing the discovered applications early on in the project to ensure that stakeholders have a clear understanding of the application requirements within the project.

High Level Process

Application Discovery → Applications created with Pending and/or Accepted status
Application Normalisation → ACE:AI creates consistent naming and versions
Review Pending Applications:
1. Reject irrelevant ones
2. Accept key business apps
3. Rationalise duplicates/versions

Application Discovery

When applications are discovered via connectors (e.g., SCCM, Intune), they appear in either the Pending or Accepted state. Once processed they will have one of the following statuses:

Accepted – In‑scope for your project (consumes a license)
Rationalised – Forwarded to another version or product
Rejected – Out‑of‑scope or unnecessary

You can view these using the Rationalisation Status buttons in the Applications module ribbon.

The table below shows the common ways in which applications are discovered by ManagementStudio:

Source	Type	Initial Status	Comments
SCCM Connector	Based on software usage	Pending	The SCCM connector shows which applications have been run by which users on which devices. Where multiple versions of an application have been run, an application record will be created for each version. This is generally seen as an excellent source of knowledge as it is based on which software title each user has run, rather than the full set of installed applications. The SCCM connector identifies which users have run which applications on which devices. If multiple versions of the same application have been used, a separate application record is created for each version. This data is generally regarded as the most useful source as it reflects actual application usage per user, rather than simply listing all installed software.
Intune Connector: Managed Apps	Shows Managed applications from Intune	Accepted	The Intune connector can import Managed Applications. These are applications which have been setup to be deployed by Intune. They are assigned to users and/or devices.
Intune Connector: Discovered Apps	Shows installed applications	Pending	Where details of installed applications are useful, the Intune Discovered Applications should be enabled in the Intune Connector. This creates a large number of application records so should be used with caution.
Excel import	Allows a list of known applications to be imported	Accepted	Where a list of known applications is in Excel or CSV format, this can be imputed into ManagementStudio as a one-off exercise.
AD Groups	Links existing apps with users or devices via AD group membership	n/a	If Active Directory groups are used to deploy applications, the group names can be imported into application records and links auto-created between the applications and the members (users or devices) of the deployment groups.

The reason that applications from the SCCM Connector and Intune Discovered applications are created with the Pending status is because they require a level of triage by the project team to mark them as either in-scope or out-of-scope. This evaluation ensures that only relevant applications are considered for further action (e.g. preparing for deployment to the new environment) helping the project team understand the scope of works and put a plan together around the application-related work.

Application Normalisation

Application Normalisation in ManagementStudio is the process of standardising software names and versions to create a consistent and accurate application inventory. This process makes it easier to analyse, rationalise, and manage applications. The normalisation process also add a category and description.

Further information here
Usage instructions here

Review Pending Applications

Pending applications will be processed differently depends on the project goals. The process outlined below is typical, but won't apply to all scenarios:

Step 1: Rejecting Applications

The overall goal when building an Application Strategy is to understand which users and which areas of the business require which applications. Whilst rejecting applications doesn't directly achieve this, it is still worth considering as it's relatively quick and can clean up the view of the Pending Applications.

Which applications should be rejected?

Application Type	Explanation
Business applications no longer in use	If these applications are not being replaced with alternatives they should be rejected. If an alternative application will be used the old application should be rationalised to the replacement application.
Application components	An application component is a not a standalone application, but a component within a standalone application. An example would be a help system or an update manager within a full product. Application components should be rejected.
Core applications (either on the build or available to everyone)	In many cases there is little benefit in understanding who needs the core applications because everybody will have these, so the core applications should be rejected. Some organisations may, however have a requirement to see the core applications and links with devices. This article show the best practice for this scenario: How to Setup Core Applications

Usage instructions here

Step 2: Rationalise and/or Accept the Applications

Where an application is in-scope it should either be:

Accepted if the version discovered is the version which is in-scope
Rationalised if a different version is required to the discovered application (note that multiple versions of a discovered application can be rationalised to a single "master version")

Follow one of these processes: