Pretty soon after you’ve started out on your Application Portfolio Management journey you may run into a problem:
What is an Application anyway?
Looking down that long list of items in your spreadsheet, or imported from your CMDB, it’s likely it will contain a lot of things which don’t look like applications.
Some are obvious, like servers or laptops - those aren’t software at all. And 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.
So if you’re struggling to sort the wheat from the chaff (as the English expression has it), here are some guidelines to help you answer that question with confidence.
Let’s start with some industry definitions. And here’s 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. But 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, 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 are defined the business model and the tasks it involves – billing customers, onboarding employees, compiling the accounts.
But even a good working definition isn’t always enough to reliably categorise software. So we’ve compiled five criteria or tests for accurately assessing your applications and getting your application portfolio in order.
Criteria One: Where is it in the Software Stack?
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 organisation 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.
Next, let’s look at the items at the top of that stack - your SAP ERP system, your Microsoft CRM system, your Workday HCM System. These definitely are Applications. They are concerned with performing specific business functions and interacting directly with an end-user.
But 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 fulfil 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. But there’s a difference between them and, say, our Microsoft CRM system: Out of the box they are not specialised 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 analyse overdue customer payments, server outages or the number of missing cats in your neighbourhood. 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.
So what about low-level software like the humble spreadsheet or SharePoint list? By the criteria above, aren’t these also application platforms that can configured into task-specific applications?
Well, actually 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. So 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 Criteria Five below.
Criteria Two: Is it All of Something or Part of Something?
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.
And one big reason why it’s so important is that, sooner or later, somebody will want to know how many applications you have. And telling somebody how many houses you own is very different from telling somebody how many bricks you own.
So 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.
But 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 whether, if you have multiple implementations of the same item of software (more on this in a moment), 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.
Criteria Three: Is it a Product or an Instance?
The third test to apply is whether the list entry describes a technology product or an implemented instance of one.
What does that mean?
Well, 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 code base. That copy has a particular relationship with 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.
If that doesn’t make sense, think 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.
And for APM, it’s primarily instances we’re interested in.
But wait - 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 standardised; upgrades and patches are deployed centrally; the application is maintained by a particular team in a set of standardised 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.
But 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 standardise 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).
But besides the 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.
Criteria Four: Which Parts of the Software Architecture?
In Criteria One we looked at the fact that software can be visualised as a vertical ‘stack’, with one layer sitting on top of another.
But 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 favourite SAP ERP example, has all three – a user interface, a logic layer which 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, definitely has a data layer, and (arguably) has logic (if you include its load processes). But 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.
So for something that has a data layer but no UI we might classify 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. But it definitely has logic which 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 characterise 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.
Criteria Five: Where Does it Matter?
Reading this far, you will have got the idea that classifying applications can be complex. And looking down your long list of applications, this can be enough to make heart sink.
So if you’re going to spend time getting the data right, makes 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. And 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.
But here we do risk getting into a chicken-and-egg dilemma: After all, to decide which apps to ignore for cost or risk, I 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.
Now 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 prioritise your data remediation efforts and break a big complex task down into a series of more manageable ones.
Get Started and Refine
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. So understanding modelling 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.
But by the same token, avoid at all costs getting bogged down in the theory as an ends in itself. Architecture modelling is only useful when it drives business decisions. So 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.