Application Rationalization Approach Tool How to Compile a List of Applications

Compile 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. In other words, how do we build a portfolio of applications?

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 answer 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 the number of functionality. They can also be large, size-wise and functionality-wise. Some applications are tied together via interfaces and collaboration, and some applications work solely on their own and can only communicate via manual interfacing.

So if it is a piece of software it can be an application, but not all software are applications. Such as embedded software in devices (such 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 in 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 may be 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. You can create consensus in a group of people in a short time and will not lose too much time discussing what is what.

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

Commonly used definitions of applications are:

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 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 about what is what. So if you compile a list of all applications, in other words, creating your application portfolio, you will first focus on identifying the applications. Later on, you will spend time inventorying all their important attributes to create an application passport or an application 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 import/export files of financial systems. But you have also got professional financial software, reporting software, and a service bus, so you might want the excel sheets to 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 unique application landscape, but with an overlap of 20% to 80% with other municipalities.

Tools for application rationalization

If you are going to use a tool to support your application rationalization, this tool must be useful and effective; it must enable you 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. 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 tools should support the creation and administration of these kinds of entities.

Example list of applications

Suppose you have defined applications and their modules, groups, and types, you might get a list of something like this (excluding all the attributes) identifying applications uniquely. Every column in this table holds the information of an application found in the organization:

Download the list as Excel Sheet here

In the list internal consistency is tried to accomplish. Every attribute in this list should also be defined. If this application list has some state of completeness you can use it to create your application landscape map.

Read more about a suitable tool for Application Rationalization

If you want to know more about using the cloud application Dragon1 EA Tool, check out the application solution page Application Rationalization on this website.

Next time on Application Rationalization

Thank you for taking the time to read 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.

My next blog will be about the dashboard for application rationalization in the Dragon1 EA Tool.