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 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, especially in IT, are software pieces supporting human tasks by automating activities, whereby humans operate the applications. Applications can be minimal 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, which is called middleware (which 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 to use standards and best practices to know what you are using has once worked elsewhere. You can create consensus in a group of people quickly 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, 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. If you state only the 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 identify applications uniquely 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 dossier to look for rationalization options.

Suppose in the organization hundreds of thousands of Excel sheets are used as financial applications, financial reports, and import/export files of financial systems. However, you also have 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?

Many 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 use a tool to support your application rationalization, it 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 just the ability to administer an application's ID, name, and description.

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 creating and administrating 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 is complete, 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 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.

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