What is an application anyway?

Essentials of Application Portfolio Management – Part 1:

As an IT leader, you might feel the pressure of increasing rates of change, rampant complexities of systems and infrastructure, compliance overhead, etc. The first step is to get your house in order, and you can do this by mastering the art and science of Application Portfolio Management – how to manage application assets. The first principle of APM: What is an application?

Imagine you start your first day as newly appointed team lead for an IT department responsible for a number of software applications or systems. Your first question to your colleagues might sound like this: “So, what are our applications?” If the answer does not come immediately, and with some trepidation and frantic searches on the intranet, this is a clear sign of lack of application discipline: no reliable application inventory seems to exist.

Other, more subtle, indicators of lack of discipline are the inability to break down costs or provide up-to-date roadmaps for each application on demand. Before describing application portfolio management (APM), and why it is important, it is prudent to define what we mean by an “application” so we agree what we talk about.

Application names facilitate collaboration

Applications are combinations of software and IT services that exist in the boundary between “User Land” and “IT Land”, and have, if we are fortunate, a unique name, which allows us to distinguish one application from another. 

Users ‘use’ the application in User Land and refer to the application using the name in daily parlance: “Have you noticed this neat feature in Confluence?” In User Land, nobody is in doubt what you mean when you say “Confluence”. In IT Land, however, the application covers a whole lot of complexity: Servers, systems, components, contracts and licenses, etc., which no user and few outside stakeholders need to be concerned about.

The definition of ”application” is thus user-centric, and we use a name that is distinct and recognised by all stakeholders, but favours the user’s point of view. So do not communicate in acronyms if your users use the full name!

The application, or more specifically the application name, is a device to facilitate communication between the IT team and the application’s outside stakeholders. Users can use the name to report incidents, IT Finance to allocate costs, and the board of directors to direct investments. For the IT team, one of the important uses is to anchor each system, component, hardware and software. If a component is not related to an application, directly or indirectly, either the component is redundant or should be registered as an application. In many organisations, it is also common to have applications not anchored in any IT team.

Our definition is deliberately very loose, but most users, customers, and other stakeholders, have no doubt about the meaning of a carefully chosen application name. This is especially true for traditional software applications with a graphical user interface. We know exactly what is meant by Microsoft Excel or even Excel, and most of the engineers in the responsible IT team will know exactly which components are part of delivering the Excel application service.

Platforms and APIs can also be applications

Applications can have other types of interfaces, e.g., voice as in the ‘Siri’ application. Stretching your imagination, if your user base is primarily developers, the APIs you offer can be considered applications. Certainly, this is the case if APIs are at the core of your business model or offering, but in many situations, APIs are stuck on something larger and more significant in the minds of your users. For example, Excel has APIs, but we would argue that it is best to manage Excel and Excel APIs as one single application entity with one name as reference.

As a final example, consider the concept of platforms. Many applications run on top of platforms – that is perhaps their defining characteristic. A platform should, however, only be considered an application if it delivers direct value to users, and users interact with them directly independent of any other application running on top of them. In this sense, Microsoft Windows is both an application and a platform.

You always have applications in your IT portfolio

Now that we have the concept of an application nailed down, you might wonder whether you have any applications at all in your portfolio. Some teams might struggle with this outside-in definition, and thus disregard the APM discipline as unnecessary. However, if your team does not have any obvious applications, but only components or infrastructure, you will have a very hard time justifying your team’s existence because you cannot show any direct value or any outcomes for users or customers.

We suggest that you take a closer look at your IT systems, and try hard to identify applications. If your job is to engineer and provide a private cloud to host applications internally for your company, then it might not be obvious that you have any applications. You do however have a Portal or an API, so that software engineers can create and manage cloud resources. That means you actually have at least one application: a portal or an API. Every component in your remit should be anchored in these user-facing applications.

Right-size what you consider to be an application

Identifying too few applications is a problem, but so is having too many applications. When two applications in your candidate list actually are two sides of the same coin, then your list should be reduced. Maybe you have two or more versions of the same software, e.g., Excel 2013 and Excel 2016 – one or two applications? In this case, we argue that you have one application, which exist in different versions and in different states of their life cycle.

Alternatively, consider multiple interfaces to the same system – one combined application or one application per interface. To decide on these problems, never resort to what is most convenient for your team, but use your insight into the concerns of your users and other stakeholders, and ask yourself which option would fit their needs the best. The list, collection or inventory of applications in your remit is called an Application Portfolio, and just like a stock portfolio, you are obliged to manage all the application assets to the best of your ability to derive the most risk-balanced value of the entire portfolio and not just the individual applications. In the next instalment of this series, we will go deeper into the discipline of Application Portfolio Management.