What is ACE?
ACE (Application Confidence Engine) attempts to crowdsource opinions on whether an application should be accepted or rejected. This results in a suggested status and a confidence percent based on how many others have either accepted or rejected the specific application.
ACE Status
Here we can sync with the ACE Could server for the latest application recommendations and manually run an examination of our application portfolio.
Config
Run ACE Examination Now (Schedule #1 & #2)
Starts an ACE examination that will update the rationalisation and normalisation recommendations available from the GRid Context Menu. Also, will run any automatic actions that have been enabled in the ACE Engine
Sync with MS ACE Server
Will upload a list of Applications and their Status to ACE and download a list of recommendations.
Periodically Sync MS ACE Server
Will automatically refresh the recommendations about once a week.
ACE Service
Recommendation Version Threshold
When calculating a rationalisation recommendation in the UI (i.e., the ACE Recommendations on the Grid Context Menu) this is the version threshold to use when deciding if an application that has an accepted recommendation should also be rationalised to an existing application of a similar version.
Auto Accept Recommendation
Auto accept applications that are recommended as Accept by ACE, have at least X Users, and are Y days in Pending. The Version Threshold is used to either rationalise these Apps to existing versions of applications in the accepted queue or accept them as a new application.
Auto Reject Recommendation
Auto reject applications that are recommended as Reject by ACE, have at most X Users and are Y days in Pending
Auto-Normalise
Normalisation is the process of cleaning up Applications names and making them more consistent across multiple products from the same vendor.
- Vendor: Adobe Inc. Adobe Incorporated, Adobe Ltd. would all normalise to simply Adobe.
- App Name: The vendor and versions are removed from the app name to avoid Apps being named “Adobe Adobe Reader 11 11.2”.
- Version: The version is cleaned up into the standard version format of Major.Minor.Build.Revision e.g. 10.1.2.3. This allows for clearer versions and better comparisons in rules later.
Note: Auto normalisation is only run on applications in the Pending Queue, but can be manually run on applications in any queue using the 'ACE Recommdations' on the Grid Context menu.
Automatic Rationalisation Rules
Rationalisation, Acceptance, and Rejection make use of rules to determine if an Application should be acted upon. It should have reasonably high ‘Days in Pending’ thresholds set to give the Apps Team adequate time to make these decisions for themselves and only fall back on these rules to keep Apps moving when the Pending queue has been forgotten or neglected.
Auto-Rationalisation
Auto-Rationalisation can rationalise (supersede) applications from Pending into the Accepted queue. There are two different checks an application can meet that will result in it being rationalised.
Rule 1. Rationalise UP
An application can be rationalised to the same or higher version in the Accepted queue for a given version threshold and must also be in Pending for X days.
e.g., Adobe Reader 10.1.0.0, 10.2.0.0, 10.3.0.0 (Pending Versions) -> 10.6.0.0 (Accepted Version)
Rule 2. Rationalise DOWN
An application can be rationalised to the same or lower version in the Accepted queue for a given version threshold and must also be in Pending for X days.
e.g., Adobe Reader 10.5.3.0, 10.5.4.0, 10.5.5.0 (Pending Versions) -> 10.5.2.0 (Accepted Version)
Note: It is recommended to set the version threshold lower for this rule so that only minor versions of applications can be rationalised to a lower version.
Auto-Acceptance
Auto-Acceptance can auto-accept applications that are X days in Pending, have over Y Users, and have no matching version in the Accepted queue.
It is recommended to keep the Version Threshold high (Major.*.*.*) so that only new major versions of applications can get auto-accepted.
For Example, it can be set to auto-accept applications that have over 10 Users, have been 3 weeks in Pending, and have no matching Major version.
Auto-Rejection
Auto-Rejection can auto-reject applications that have X Users and are Y number days in Pending.
For Example, it can be set to auto-reject applications with less than 5 Users and are in Pending for 3 weeks.
Version Thresholds
Version Thresholds are used extensively to group variations of the same application together and select the highest version from these groups.
In the example below the 5 versions under 'Major.*.*.*' would be reduced to two groups (10.x and 11.x) and then the highest version in each group brought forward.
*.*.*.* | Major.*.*.* | Major.Minor.*.* | Major.Minor.Build.* |
---|---|---|---|
10.0.0.0 | 10.0.0.0 | 10.0.0.0 | 10.0.0.0 |
10.0.0.1 | 10.0.0.1 | 10.0.0.1 | 10.0.0.1 |
10.0.1.0 | 10.0.1.0 | 10.0.1.0 | 10.0.1.0 |
10.1.0.0 | 10.1.0.0 | 10.1.0.0 | 10.1.0.0 |
11.0.0.0 | 11.0.0.0 | 11.0.0.0 | 11.0.0.0 |
| |||
Highest Versions by Threshold | |||
11.0.0.0 | 10.1.0.0 | 10.0.1.0 | 10.0.0.1 |
| 11.0.0.0 | 10.1.0.0 | 10.0.1.0 |
|
| 11.0.0.0 | 10.1.0.0 |
|
|
| 11.0.0.0 |
|