TABLE OF CONTENTS
What is ACE:AI?
ACE:AI - Asset Confidence Engine: Artifical Intelligence
ACE:AI aims to reduce the amount of time and effort required in managing applications. It's typical for 1000s of applications to be present in ManagementStudio, due to the vast number of applications in use in the enterprise, and the numerous versions detected (this assumes an Inventory Connector such as the MECM/SCCM Connector is in use).
Prior to ACE:AI , it took an application specialist many days to review the discovered applications in ManagementStudio's "pending" area, then make decisions about which are legitimate business applications, which versions of these should be rationalised, and which applications were non-business (out-of-scope). This was especially challenging where there was limited knowledge of applications.
ACE:AI attempts to vastly reduce the amount of time and effort involved in this process, and also reduces the skill-level required. ACE:AI collects information about what application decisions (accept or reject) were made by other customers. These are stored in the cloud. When a customer is processing their application estate, ACE:AI makes suggestions about each application based on the previous customer decisions. If 18 out of 20 customers (90%) previously accepted an application, ACE:AI will suggest that the next customer accepts that same application with a confidence rate of 90%. The same principal is applied where an application has been rejected.
The new customer's decisions are recorded in the cloud, ensuring that the system is constantly improving.
In addition, where ACE:AI finds multiple versions of an application, it will suggest that those versions are rationalised, according to the version threshold settings defined in the Admin area.
The end result is that a large number of applications can be easily quickly and rationalised, which provides a concise and accurate understanding of the organisations current application requirements. This is a powerful starting point in understanding the requirements for a transformation project, or BAU process involving applications.
Data Transmission
| Sent Data | ManagementStudio Cloud Server Protocol: SSL over HTTPS General: CustomerID (32-bit GUID) Apps: ManagementStudio transmits application vendors (e.g. Adobe, Microsoft), application names (e.g. Reader, Excel) and the "Accept" and "Reject" decisions made against those applications. Application versions are not transmitted. OS: Operating System Name and Build Version OpenAI API ManagementStudio transmits a list of all application names from all customers stored in ACE:AI (e.g., "Adobe Reader, Microsoft Excel, Google Chrome") to the OpenAI API requesting translation (where non-alphanumeric vendor or name is detected), category assignments and application descriptions. The CustomerID is NOT transmitted. In-house application names are NOT transmitted. |
| Received Data | Protocol: SSL over HTTPS The ManagementStudio client receives a hashed global list of all applications in the ACE:AI catalogue, with the rationalisation suggestions (accept or reject) and confidence ratings. The client also receives a list of their applications, with the corrected (normalised) vendor name, application name, category and description. |
In-house Applications
During the onboarding process, each customer's application list undergoes manual review, and rules are established to exclude in-house applications using exclusion filters. These applications are NOT added to the global application catalogue in the ACE:AI database, and are NOT transmitted to the OpenAI API. For instance, with the fictional customer MyCorp, applications with the vendor 'MyCorp' (in-house developed applicaions) are excluded.
Main Functions
1. Application Normalisation
Many vendors are inconsistent when naming and versioning their software titles. Application normalisation is the process of removing all those inconsistencies to present a clean, easy to manage set of names and versions.
The ACE:AI engine provides a way to automatically (or manually) normalise the application estate using a pre-defined ruleset.
Example:
- The software vendor Adobe uses different ways of branding its products such as "Adobe", "Adobe Corp.", "Adobe Inc."
- The ACE:AI engine recommends changing all these to "Adobe" and can optionally
2. Application Categorisation and Description
The ACE:AI engine can lookup categories and descriptions for recognised applications using the ChatGPT API. These can be applied manually or automatically on a schedule. Note that within the ACE:AI settings the categorisation options are part of the Normalisation section.
3. Application Vendor & Name Translation
The ACE:AI engine leverages the OpenAI API for accurate application vendor and name translation. This is performed automatically where vendors/names using non-alphanumeric charaters are detected.
4. Application Accept/Reject/Rationalise
The ACE:AI engine takes decisions made by existing customers about applications. It then builds a confidence rating of these decisions, and suggests that other customers make those same decisions. This can be a manual or automated process.
In-scope application Example:
- 100 customers choose to mark Bloomberg as a valid business application
- A customer installs a new instance of ManagementStudio in an organisation where Bloomberg is in use
- The ACE:AI engine recommends that Bloomberg is "Accepted" as an "in-scope" application and can optionally auto-accept this application
- As different versions of Bloomberg are discovered, they can be auto-rationalised to the "Accepted" version
Out-of-scope application Example:
- 95 customers choose to mark Spotify as a non-business application
- A customer installs a new instance of ManagementStudio in an organisation where Spotify is in use
- The ACE:AI engine recommends that Spotify is "Rejected" as an "out-of-scope" application and can optionally auto-reject this application
Rationalisaton Example:
- As different versions of existing appliactions are discovered, they can be auto-rationalised to the "Accepted" version
5. Operating System End of Life Reports
The feature generates reports on Operating System end-of-life support dates using the ManagementStudio Algorithm. These are available in the built-in Device report ACE - OS End of Life Report. The end-of-life dates can be manually added to a Device Datamining Report by ticking Add OS End of Life Days in the Device Reporting Tier.