How Detailed is Your Enterprise Application Catalog?
Over the past several years, I have been involved in many application projects. Whether the project was centered around packaging, virtualization, or compatibility testing for operating system migrations (as my specialty is now) a variable for success was and remains – the enterprise application catalog. You’ll read synonyms for this as well (including package store, app store, app catalog, app inventory, etc.) but the key commonality is solid information about the application’s owner, assets, and documentation.
Unnecessary delays in application projects are often rooted in poorly detailed and incomplete catalogs. It is hard to test an application if the application installer is unable to be located. That would seem to be a very unlikely problem at first glance, yet the larger an organization grows; when the organization merges with other organizations, or when users are granted administrative control of their devices and workstations, organizations wind up spending the first significant portion of their application project simply funding out what they actually have.
It is also hard to verify that an application has been signed off on UAT (User Acceptance testing) if the application has no owner or responsible user. Before undergoing any type of major application management transformation project, portfolios need to be reconciled as thoroughly as possible. It is most crucial to get this house in order during the shift to Windows 10 and Windows as a Service (WaaS) as application compatibility management will be ongoing and iterative. I would encourage you to read Chris Jackson’s blog post on the subject (https://blogs.msdn.microsoft.com/cjacks/2016/09/12/windows-10-app-compat-strategy/) if you have not already done so.
COTS
The inventory of what we call COTS or Commercial Off-the-Shelf (or ISV Apps - Independent Software Vendor Apps) is often flawed in that it is assumed there need only to be thorough to the point of identifying vendors and vendor contacts for the applications. Microsoft Windows Analytics (via Upgrade Readiness - /en-us/windows/deployment/upgrade/upgrade-readiness-get-started) can easily automate the collection of this information as well as additional supportability and adoption metrics, but what the tool cannot do is assign proper categorization, determine appropriate application owners, or designated subject matter experts (SMEs) for testing. That information is internal and will be needed for those critical off-the-shelf vendor applications which may need frequent testing.
LOB
Line-of-Business applications or LOB apps, are those applications that are developed internally within your enterprise organization. Cataloging this information is critical starting with flagging it as internal either explicitly or implicitly by using your company name as the vendor. Segmenting the applicationss for which your organization owns the code/IP from those owned by vendors is the first major step in adopting a modern approach to rationalization. A significant amount of rationalization can be achieved with analytics but most of the critical testing will likely apply to LOB applications.
Identifiers (Name, Vendor, etc.)
Applications are often erroneously tracked due to anomalies and discrepancies with the application name and the vendor being either mis identified or not identified at all. For example, when applications are being tracked for supportability at ReadyforWindows.com they are using the application name and vendor that is either associated with how the application is registered upon installation (in Program and Features) as well as how primary executables are identified and verified via digital signatures. Many organizations will elect to use the identifier from the executable file since in many cases, software may not always properly register itself in the “Programs and Features” Control Panel.
In addition to an official name, organizations may also identify the application by an internal or tribal name. For example, Office 365 ProPlus may also be identified internally as Office 2016 for continuity purposes. This is usually not a problem so long as the official name is associated in the same record as the official name is what will be compared with analytical and static analysis compatibility software. Sometimes this tribal name may include references to a legacy vendor which owned said application in the past but has since been acquired. For example, when Invincea was bought by Sophos and was OEM rebranded by Dell, newer versions were branded with the OEM vendor, yet organizations still referred to it tribally by the old vendor name for the purposes of alleviating confusion and maintain vendor lineage.
Version Separation
It is also recommended that the applications version not be tied directly into its name as it is very likely that your inventory will include more than one version of the same application. This is especially crucial with vendor supportability determination. Again, analytical tools like Upgrade Readiness will take care of this job for you.
Owner
The Owner is one of the more critical pieces of information as the owner is either also the primary application subject matter expert, or is responsible for designating who that person is.
Testers/SMEs
The testers and subject matter experts may also be application stakeholders, or simply just representatives of the business group dependent on the application. In most cases when the owner and testers are not the same person, it is still likely the application owner who ultimately signs off on the validation of the application as being properly validated and production ready.
Licensing
Often applications have some type of license validation or software protection platform. Whether it requires a specific activation server or a license key, not having this information will obviously delay application testing if not included with the application record.
Installation Logistics and Documentation
In many cases, an application installer may be customized with a transform and repackaged or scripted to simplify deployment with a software distribution system. In many cases, these packages can be deployed as-is, however there may need to be scenarios where the application is traditionally installed and the original installers will need to be located along with any necessary installation documentation.
Source Code
If the application is an in-house developed LOB application, it should be noted if there is source code being maintained as this will be a critical variable should the application run into issue with compatibility or if the application is slated for further modernization. It is not uncommon to not have source code available. Companies acquire other companies. Companies re-structure their organizational charts and curtail redundancies during mergers and acquisitions. Along with employees leaving, sometimes source code leaves as well. It is a well-known open secret. It is just as important to confirm the absence of source code as much as it is to confirm its existence.
Risk Rationalization
To quote from Chris Jackson’s blog post referenced earlier: ((https://blogs.msdn.microsoft.com/cjacks/2016/09/12/windows-10-app-compat-strategy/) categorization according to criticality should be part of the ongoing portfolio rationalization. Whether it is in the form of 4 category taxonomy or a more “stoplight-oriented approach, a general recommendation chart is shown below for current recommended practices for category distribution:
| App Compat Risk | Characteristics | Typical Distribution |
|---|---|---|
| Critical | Typically, complex custom development or highly customized commercial software. App failure can lead to loss of life or irreparable organizational harm. No acceptable workarounds for failure are identified. | 2% |
| High | Typically, complex custom development or highly customized commercial software. App failure can lead to significant loss of productivity or ability to execute organizational mission. Workarounds can take days or weeks to implement, and/or come at a significant cost. | 18% |
| Medium | Typically, commercial software that is current or a recent version, and is commonly used at other organizations using the target platform; or custom development following straightforward patterns. App failure can be addressed with reasonable workarounds that take minutes to hours to implement and which use standard helpdesk procedures. | 50% |
| Low | Typically, commercial software that is up-to-date and supported on the OS you are moving to, or is custom development that was created and/or tested on the target platform. Vendor is accountable for remediating compatibility issues, or organizational mission can be accomplished without the software on a temporary basis. App failure can be addressed with simple workarounds through standard helpdesk procedures. | 30% |
Putting it all Together
If, after reading this, you find you are not working with a complete and thorough inventory of an application portfolio [and you are a primary stakeholder of the application portfolio] the best advice is to get on top of this issue prior to a migration to Windows as a Service as this will be critical to getting current and staying current through ongoing Windows 10 releases.