Pretty soon after you’ve started out on your Application Portfolio Management (APM) journey, you may run into a problem: What is an Application anyway?

Looking down that long list of items in your spreadsheet, or perhaps imported from your CMDB, it’s likely it will contain a lot of things that don’t look like applications.

Some are obvious, like servers or laptops - those aren’t software at all. Everyone will agree that your ERP system is an Application, but many will fall into that murky area in-between. Is a spreadsheet an application? An ETL Tool? A PDF writer? And in the meantime, your CIO is demanding to know how many applications you have.

If you’re struggling to sort the wheat from the chaff (as the English expression says), here are some guidelines to help you answer that question with confidence.

Let’s start with some industry definitions. First the bad news: None of those definitions fully agree or align with each other, meaning that if you’re going to make any headway at all, you’ll need to make up your own mind.

TOGAF, for example, defines an Application Component as “an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, provides services, and makes them available through interfaces. For example, a business application such as an Accounting, Payroll, or CRM System.”

In this case, “an encapsulation of application functionality aligned to implementation structure” means the application does something and is implemented on some kind of technology platform like an operating system or a server.

Unfortunately, TOGAF doesn’t define what application functionality is, leaving us with a kind of circular definition: An application does what an application does.

Technopedia is a little more helpful: “Application software is a program or group of programs designed for end-users. These programs are divided into two classes: system software and application software. While system software consists of low-level programs that interact with computers at a basic level, application software resides above system software and includes applications such as database programs, word processors, and spreadsheets. Application software may be bundled with system software or published alone. Application software may simply be referred to as an Application.”

This gets closer to what we want, but still doesn’t quite nail what makes an application an application - except that it isn’t system software.

The definition in the Ardoq metamodel tries to be specific about what it is that makes an application different from other types of software:

“An Application is the configuration of lower-level software or Technology to provide a specific Business Capability or Technology Capability, or to assist in the performance of a defined Task or Business Process, or in the analysis of specific Information.”

In other words, an application is designed or configured to perform a specific task other than the running, maintenance, or change of the application itself, or of its underlying technologies. In a business, those tasks defined the business model and the tasks it involves – billing customers, onboarding employees, or compiling the accounts.

Even a good working definition isn’t always enough to reliably categorize software. We’ve therefore compiled five criteria or tests for accurately assessing your applications and getting your application portfolio in order.

The first step in deciding what is and what isn’t an application is understanding that software doesn’t exist in isolation but as part of a vertical ‘stack’.

At the lowest level of that stack is the software that any IT system needs to run: Operating systems, databases, run-time environments, and even virtual machines that directly emulate hardware.

This type of software is generic and concerned with the organization of processing and storage resources, rather than with performing any kind of specific business task. For this reason, this category is sometimes called System Software. When bundled together, or deployed on standard hardware, it may be called a Technology Platform or an Infrastructure Service.

Whatever you call it, it doesn’t qualify as an Application. So you can strike Windows Server, Linux, SQL Server, Apache HTTP Server, and more off your list of Apps.

Then, look at the items at the top of that stack: your SAP ERP system, your Microsoft CRM system, and your Workday HCM System. These are without a doubt Applications. They are concerned with performing specific business functions and interacting directly with an end-user.

That still leaves an awkward middle level: those items of software sometimes called Application Platforms or Tools. Into this category, we might group Business Intelligence tools like PowerBI or Process Automation tools like Appian.

These types of software fulfill many of the criteria of a business application: they perform a definite task and have a user interface to interact directly with end-users in performing business activities. There’s a difference between them and, say, our Microsoft CRM system: Out of the box they are not specialized to perform any particular task, process, or analysis. Instead, they must be configured to do so.

So PowerBI may be used for marketing analysis, but with a different dataset, it could equally be used to analyze overdue customer payments, server outages, or the number of missing cats in your neighborhood. Unlike your CRM System which knows out of the box it is processing customer data and tracking qualified leads, your BI tool has to be told.

Distinguishing these types of platform application or tools from preconfigured business applications is very important for APM because it’s all-too-easy to classify this category of software by the business process or task they’re currently used for rather than by what they’re capable of doing. This has big implications for identifying software re-use.

What about low-level software like the humble spreadsheet or SharePoint list? By the criteria above, aren’t these also application platforms that can be configured into task-specific applications?

Well, yes. Every time you set up a spreadsheet or a List, you’re configuring it with the data and logic to perform some particular task. You should consider adding these to your inventory too. But wait! Before you set about trying to document every spreadsheet or list out there, we suggest reading through the remaining criteria.

The next filter to apply to your list of candidate applications is to ask whether they are single applications, groups of applications, or parts of applications. Again, this is often harder to decide than you’d expect. Nonetheless, it’s important.

One big reason why it’s so important is that, sooner or later, somebody will want to know how many applications you have. Telling somebody how many houses you own is very different from telling somebody how many bricks you own.

If you do need to model the constituent parts of an application, we recommend using a hierarchy (e.g. Application X has children Module X1 and Module X2). However, if you do this we recommend only using the component type Application to describe one level. Otherwise, you’ll end up counting bricks and houses.

Even if you have a hierarchy, how do you decide which level is the application, and which level is just part of one?

One way to do this is (if it’s a commercial offering) to look at whether it’s a marketed product. What’s actually for sale here? Does it have a consistent name or version number? Can it be bought in isolation, or only in addition to another item?

Another approach is to look at whether it can operate independently: Does it work at all in isolation, or only as part of something else?

As we saw above, all but the lowest-level software is dependent on other software to run; but in many cases, one item of software is dependent on the specific data or function provided by another item of software, or is designed to perform (or extend the ability to perform) the same task.

A final test is to see if you have multiple implementations of the same item of software (more on this in a moment), if it has been described consistently. For example, for two business units who have independently purchased the same SAP ERP software, whether one has documented all the modules as individual applications, while another has grouped them all into a single list entry.

The third test to apply is whether the list entry describes a technology product or an implemented instance of one.

Software is a copy. When you install an application onto your phone or onto one or more servers, you install a copy from a master codebase. That copy has a particular relationship to you, your phone, and the tasks you use it for. In the same way, specific teams in your business use specific instances of applications to perform their daily tasks.

Think of it like a car. 🚗 The software product is like the make/model of your car, whereas the implemented application is your specific car, complete with bumper stickers and that coffee stain on the passenger seat. For APM, it’s primarily instances we’re interested in.

Does that mean you need to record everybody’s unique installation of software on their laptops as separate instances?

No. For our purposes, an instance can represent the installation of software running on multiple servers, or deployed across all enterprise laptops. The important thing is that it represents an installation that is managed as one thing. For example, the deployment process is standardized, upgrades and patches are deployed centrally, the application is maintained by a particular team in a set of standardized environments (for example, Production, Development, Test), and it has probably been purchased under a single contract or set of related contracts. If IT billing is in place, it’s probably listed as a single line item on the bill.

It also means that when you do have a situation in your organization where the same software has been purchased and/or installed separately – for example, like the different business units both using SAP ERP above – you can log them separately. This enables you to identify opportunities to consolidate, or at least standardize on a given version.

In terms of naming different instances, a common approach is to add a suffix with the name of the owning department or business unit to distinguish them. For example, SAP ERP (France) and SAP ERP (Canada).

Besides recording the instances, there are also good reasons to record the technology product itself as a separate component type. This can cause confusion, but on the plus side, it enables you to keep a central record of all software versions and their associated properties such as support dates (for example, take from Technopedia or your Software Asset Management tool), and standards compliance without duplicating this data across multiple instances.

In Criteria One we looked at the fact that software can be visualized as a vertical ‘stack’, with one layer sitting on top of another. Software also has what we often think of as a ‘horizontal’ structure: The architecture of an individual application itself.

The simplest standard model of the architecture of an individual application is the so-called three-tier model. It breaks any application up into presentation (i.e. its user interface), its logic (i.e. its processes, rules, and queries), and its data (i.e. its database or store).

This is a good model to test your list items against.

A classic application, like our favorite SAP ERP example, has all three – a user interface, a logic layer that defines the processes and business rules, and a database. However, other items on your list don’t meet all these criteria.

A standalone database like a data warehouse or operational data store, for example, has a data layer, and arguably has logic if you include its load processes. However, despite the Database Administrator will have an Admin interface, a data warehouse is not generally considered to have a UI. That’s what Business Intelligence tools are for. For something that has a data layer but no UI, we might classify it as a database.

On the other hand, a web service or integration - running on an Enterprise Service Bus, for example - doesn’t have a UI either or a database in which to persist the data it transmits. What it does have is logic that determines which data to serve up when, and to who. We might variously call this an integration, a web service, or microservice.

Finally, we might also find an application that definitely has a UI and maybe some logic, but no database in which to persist data. It might even be a façade, a front end designed to provide a new ‘skin’ over one or more existing applications. We might call this a portal.

However we choose to characterize each of these types of software, an important point is that - as per Criteria One – they are all built or preconfigured to perform a specific business task or activity or to process particular information.

Reading this far, you see that classifying applications is complex. Looking down your long list of applications, this can be enough to make your heart sink. If you’re going to spend time getting the data right, make sure you spend it where it matters, and learn to ignore the stuff that isn’t going to drive the outcomes you want.

How to do that? Well, start with some measure of the candidate application’s importance - or materiality - to your mission. This should be driven by the business objectives of your APM exercise.

If the business objective is to cut cost, for example, then your ERP system is likely to be high up on the list, but you’re probably less worried about the Excel sheet; if on the other hand, the objective is managed risk or regulatory compliance, then the Excel may become very important if it performs a critical function or processes sensitive data.

Here, we do risk getting into a chicken-and-egg dilemma: After all, to decide which apps to ignore for cost or risk, you need first to assess all apps for their cost or risk.

The answer is to do that assessment in multiple passes with progressively higher levels of accuracy and excluding those that fall outside your area of concern on each pass. So a first pass cost review might simply ask you to assess those apps which cost more than $10,000 per year to run vs those that cost less. Then you can take the subset that costs more, apply further range estimates to them, such as those that cost more than $50,000 per year to run, as well as those that cost more than $150,000 a year to run.

None of this says you can simply ignore a portion of your portfolio, but what this triage of your applications enables you to do is to prioritize your data remediation efforts and break a big complex task down into a series of more manageable ones.

The criteria above are guidelines, but the only real way to measure the success of your APM effort is whether it is delivering the business outcomes or objectives it’s intended to deliver. Understanding modeling theory is very important in delivering accurate analysis. Taking too cavalier an attitude to the theory will simply lead to bad decisions down the line.

By the same token, avoid at all costs getting bogged down in the theory as an ends in itself. Architecture modeling is only useful when it drives business decisions. Our advice is to understand the above, then get going and refine from real-world feedback. You’ll much faster arrive at a place where you have confidence in your data, your analysis, and the decisions it drives.

Sample data from the application portfolio management is missing.

Sample data from the APM can be restored by deleting the workspace where the sample data is missing. Then you will be able to reload the missing data when clicking on the “Best Practice Modules”

Best practices for information architecture.

The article on mapping applications integrations can be applied to business process modeling, for example.

Best practices for data governance.

The following knowledge base articles provide good foundations and techniques for data governance.

Best practices to reduce the Application Portfolio complexity

The article Getting started with Application Rationalization provides great insight on how to reduce application portfolio complexity, make an informed investment or divestment decisions, improve overall IT efficiency and lower the total cost of ownership.

If you're still scratching your head about it, reach out to us! You can do so via our website or by using the in-app chat. We're happy to help.