Application Rationalization Approach / Tool – How to compile a list of applications to rationalize?

Compiling a list of applications to rationalize
One of the most important tasks in doing application rationalization is compiling a list of all applications that are in view for potential rationalization.

But then these questions pop up: What are applications? When is something an application? Why should we make a certain application part of the list? Where do we have to look to find applications?

In this blog I will try to give an answer on these questions.

What are applications?
Applications in the organization and especially in IT are pieces of software supporting human tasks by automation of activities, whereby the applications are operated by humans. Applications can be very small in size (bytes) or small in number of functionality. They can also be large, size-wise and functionality-wise. Some applications are tied together via interfaces and collaborate, some applications work solely on their own and can only communicate via manual interfacing.

So if it is a piece software it can be an application, but not all software are applications. Such as embedded software in devices (as microprocessors or USB sticks) or the Operating System on your computer or software that facilitates communication between other applications: this is called middleware (which on his turn also needs to be rationalized).

When is something an application?
Applications and their parts and groupings are defined very differently. And no absolute truth maybe there to find out. So it is important then to make use of standards and best practices, so you know for sure that what you are using has once worked somewhere else. And you are able to create consensus in a group of people in a short time and will not lose too much time discussing on what is what.

Turning it around, if you fail to define ‘application’ or make it clear what it is otherwise you will be in the situation that there is continuous discussion about what is what. And you cannot refer to successful rationalizations from the past using a certain set of definitions for types, groups and parts of applications.

Common used definitions of applications are:
Definition 1: Application (Unknown) - An application, or application program, is a software program that runs on your computer.
Definition 2: Application (TOGAF) - A deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application.
Definition 3: Application (ArchiMate) - An application component is defined as a modular, deployable, and replaceable part of a software system that encapsulates its behavior and data and exposes these through a set of interfaces.
Definition 4: Application (Dragon1) -
A) Logical indication or recognition of software.
B) The application of computer software to automate or support certain activities, tasks, processes, products and services.
C) The act of putting something to a special use or purpose not necessarily being software.
Depending on the context a certain definition of application applies.

In my opinion it would be wise to name applications software applications if it is, so it is more clear we are dealing with software. Because if you state only application, you really do not say what is applied.

Why should we make certain software applications part of the list?
First of all it is important to uniquely identify applications, so there is no miscommunication of what is what. So if you compile a list of all applications, in other words, creating your application portfolio, you will first focus you on identifying the applications. Later on you will spend time inventorying all their important attributes to create an applications passport or an applications dossier that you use to look for rationalization options.

Suppose in the organization there are hundreds of thousands of excel sheets that are used as financial applications, financial reports and as import/export files of financial systems. But you have also got professional financial software, reporting software and a service bus, then you might want the excel sheets be part of the list of potential applications to rationalize.

Where to look to find applications?
A lot of organizations have CMDB (Configuration Management Database), often dictated as best practice by ITIL and Service Management approaches. However that database is not always up-to-date. A good practice is to interview department managers, employees, suppliers, partners and clients of the organization to get a grip on the applications used.

Other sources or start points for applications are reference architectures for your branch of industry and fellow organizations. For instance in the Netherlands there are 400+ municipalities all having their own unique application landscape, but with an overlap of 20% to 80% with other municipalities.

Tooling for application rationalization
If you are going to use a tool to support your application rationalization, this tool must to be useful and effective; it is important that it enables to define the various types, groups and parts of applications. The tool must offer more than only the ability to administer the id, name and description of an application.

On average, there are 60 attributes on applications to be defined and very useful for rationalization. And also certain attributes are qualified to be considered entities of their own, such as application groups, application platforms, application functionality, application architecture, application modules, application services and application interfaces. Application Rationalization tooling should support creation and administration of these kinds of entities.

Click on this link for an example list of applications:

Thank for taking the time reading my blog on “How to compile a list of applications for rationalization or software application portfolio”. I hope I’ve inspired you by making a start yourself.

Deze blog is geschreven door Mark Paauwe. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

Patrick Blok op zondag 10 november 2013 20:07


Indeed clarity around the definition is needed. Why would you explicitly state software applications? Does it really matter? One man's software is the other man's hardware.

For us an application is IT with business functionality (i.e. supporting a business process), the boundaries are defined by wether or not it has it's own independent life cycle.

Regards, Patrick

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.