Companies drive their strategy through the use of data & information which is accessible through applications. Without applications, you can’t properly access these sources to make meaningful decisions. Therefore, it is no surprise that application management is an important discipline.
Many companies already have a so-called “Application Portfolio”. This can be seen as a catalog in which all applications and/or components reside. New applications need to be registered in this catalog and it also serves as a place to look up information about these applications. Although the main purposes of Application Portfolio Management systems are clear to the majority of organizations which implemented them, in the “data-driven era”, these systems lack the capabilities which are needed to strengthen your business strategy. Useful tips to benefit from good Application Portfolio Management.
Context
A solid Application Portfolio Management holds metadata about the application (components) such as the name of the application, the (business) owner, the type of application, various characteristics of the type of infrastructure on which it is running, the cost center which pays for it, the teams involved, etc. Some of the main achievements of proper Application Portfolio Management include the following:
- Make decisions about whether or not to invest in an application or not.
- Get insights into the costs of IT infrastructure.
- Present an overview of the vendors which are in scope for the applications.
- Get a list of software licenses that are currently in use.
Although these are great benefits for organizations to (constantly) steer their business in the desired direction, there is much more to explore when using a more advanced Application Portfolio Management tool and/or process. In this article, we’ll explore various tips which build upon the previous examples. Furthermore, extra tips help you to integrate your Application Portfolio Management tool into modern workflows to stay current with today’s way of working.
Accessibility
First of all, make sure your Application Portfolio Management (APM) tool can be accessed using an API that can be used by anyone in the organization. Often, they only offer their information through a web portal. Information needs to be sought manually and presented in an unstructured (fixed) format such as HTML tables and/or graphics. Too much information is hidden in “extra tabs” and it’s impossible to filter the information you’re looking for.
API first
If everyone in the organization would be able to call the API and query for specific information (such as all applications within the same cost center or all applications which have infrastructure hosting costs higher than amount X) this would be much more useful. Be able to present this information in structured formats such as JSON, XML, or CSV so the requester can process it in his own way and in the desired format. Yet even more useful: offer presets of often-used queries in your centralized source code management tool. For example the export of a Postman collection. This also serves as an example and avoids multiple people having to write the same queries.
Business strategy perspective
From a business perspective, there is a lot to explore. If you don’t use a Business Intelligence tool, there’s a lot of information you can get when collecting and aggregating the metadata which is stored in an APM.
Problematic scenarios
Unused applications are a burden. Applications that cannot be integrated with other applications are a headache. Some applications are bought multiple times while not needed (perhaps just buy more licenses and get a discount). Other applications are never uninstalled or canceled. They all contribute to the loss of money and other valuable resources. The above-mentioned statements will result in a cluttered application portfolio which needs to be assessed.
To go short, this simple list helps to avoid these scenarios:
- Create a full and complete inventory.
- Try to determine the value of each application (component).
- Keep and extend the most useful ones.
- Change/update/upgrade the applications which do not perfectly fit anymore, but which are still useful for your business.
- Get rid of the applications which are not needed anymore (unused ones, no new users, idle infrastructure, no active users, etc).
To dig a big deeper into the problematic scenarios, the following concepts will help to get your thoughts in the right direction.
Examples
Suppose you want to collect information about the effectiveness of your applications, you can request information such as: “How many active (personal) users have this application”? Perhaps you need to combine the information from the APM with a user management tool like Active Directory to fetch the roles and permissions. Or another one: “What is the total cost of infrastructure for this application”? Add to that the total number of FTE that work in developing and maintaining the application so you would get an idea of the costs of the application itself.
Security
As of today, security is “everyone’s responsibility”. No one can be forgotten when it comes to securing applications and their data. As mentioned in a previous article, the CIA classification rating of an application is very important. On top of that, make sure people can check out the “risk score” of an application.
This can be a combination of multiple fields that hold specific security-related meta-data. Think of the implementation (or lack of) of Logging and Monitoring solutions, the CIA rating itself, and the number of critical security flaws in a given time period. But also the notion of SAST and/or DAST Scanning, the use of secure (web) protocols as well as the usage of secure connections and encryption of data. On the other hand, be sure to link this to more “business-like” metadata such as the number of (active) users, both internal and/or external, the service levels as well as the size of the total IT system.
All these contribute to the so-called “risk score” of an application. Although this information is highly sensitive, managers use these to make decisions about application assessments, security measures to be taken, etc. It also helps other people to have this information (or at least a summary) about the position of their application relative to the others.
Licenses and vendors
Another smart question to ask the APM system is: how many applications consume licenses that costs X amount of money per year? Combined with the total amount of revenue reveals how well these licenses contribute to the profitability of the actual application.
From a “vendor lock-in” point of view, it can be tempting to request information such as: which applications make use of at least one license from vendor X. Compare the result count with the total number of applications to get an indication about the “potential strength” of the specific vendor since he/she is involved in the majority of all applications. And if this happens to be the most critical application (in terms of business criticality) you might reconsider your licensing strategy or vendor selection strategy.
IT Architecture
Another great topic is to extract IT architecture-related information which lies hidden in the APM. Register your components all in the same way as well as your sub-components. Example queries from an IT architecture point of view would be:
- Select all application components which share the same parent component. Perhaps all sub-components have different types of IT infrastructure resources and/or target platforms. You might decide to unify them all to ease the deployment process.
- Get all applications with a risk score of 5+ that do not have a Solution Architect in the DEV team. This can lead to wrong decisions or delayed processes in terms of future features in which (the right) architecture plays a crucial role.
- Obtain all applications which are flagged as “legacy but critical technology”, and “low cloud readiness” but are registered for recently created cost centers. Track the process of those applications to see how they evolve over time since they might be very important for the future of the company.
- How many applications (definitions) are not linked to actual running infrastructure (such as Virtual Machines or Kubernetes clusters)? This gives an indication of the mismatch between the CMBD and the (production-like) situation that reflects the actual situation.
- Collect all applications which are consumed using the SaaS deployment model and monitor this over time. If the strategy of the company is to increase the number of SaaS offerings, then it’s wise to keep a close watch on the number of these issues over time.
Integrations
Connect the APM with workflow management software such as Jira or Azure DevOps. It would be very nice if architects would get a notification (or ticket on their collective board) when there is a new version of the application they use. For example Enterprise Architect or other centralized tools they use to do their work. In this way, the APM tool becomes much more interactive than just a static tool in which people have to register their software and forget about it.
Use a single (generated) ID such as a GUID to uniquely identify an application across all the tools which are in use. This makes it very easy to track changes or issues with applications much easier and there is no need to figure out whether the application “Archimate” is the same as “Archi” or “Arch” which leads to confusing situations in all phases of the development process.
Conclusion
An Application Portfolio Management (APM) tool helps to keep track of your applications from an administrative perspective. Yet, if you look a bit deeper, you can also use your APM tool for more advanced things like taking (strategic) business decisions based on various factors. It helps to answer questions from an architecture perspective and it also provides inside information about the (current) levels of security in your organization. When thinking from a developer’s perspective, you can integrate your APM with other tools or collect structured results which are ready to be processed and made available to a wider audience. Your APM then really fits into the category of “Business IT” companies.