“The task of art today is to bring chaos into order” T. Adorno

1.       Overview

Application rationalisation is the radical reshuffling of an application portfolio as part of an application strategy, a plan that implements changes to applications to achieve a business outcome.

Many organisations try to achieve this by reducing the overall number of applications but many fail to deliver the expected benefits of reduced cost and increased efficiency. This article outlines the problems and how to overcome them with a logical and effective process.

2.       Why bother with applications rationalisation?

Essentially if you don’t use any software applications then you do not need to have any IT infrastructure and associated costs. Therefore the logic would indicate that if you reduce the number of applications then you will also reduce your overall costs of IT. The relationship can be summarised by the “software iceberg” diagram as shown below. You see the visible costs of the software licenses and support but it is much harder to relate these back to all the supporting costs.

Over time there is a tendency for IT requirements to change, business processes are revised or eradicated and organisations change so that the supporting software applications become irrelevant or of less value to the organisation. In addition there is a tendency towards duplication of applications, for example one retail organisation admitted to having 12 different software applications for performing essentially the same task but their business units had each chosen different products from different suppliers.

As organisations move towards new platforms such as cloud there is a natural tendency to remove the complexity of application where similar or duplicate exist. If this isn’t done they will replace an old inefficient infrastructure with a new inefficient infrastructure. There are many examples of transitions which go ahead and transfer applications that are no longer used to the cloud.

3.       What are the barriers?

Whenever you try to create order from chaos you will face barriers. There appears to be an inbuilt inertia and opposition to change. This is exactly so with application rationalisation. If you do not have a plan to anticipate and deal with these barriers then at best you will have only a partial success and waste your time and resources without delivering the benefits you are expecting.

In many case users will not want to give up applications. Department heads and their workers will resist the changes because they are used to older application and are comfortable with them. You may need to prove that people are not using applications even when they say they are. In other cases you may have to prove the applications can be replaced without reducing the workers effectiveness. An approach which relies heavily on questionnaires and feedback from users will never deliver full efficiency you need concrete facts to base your rationalisation program on.

Getting factual evidence can be difficult. A recent conversation with major organisation revealed they did not know how many PCs or servers they had, what operating systems were running on them, what applications they were running and who used them – the person in the conversation had the title of Chief Information Officer. Most organisations will have problems creating a full and accurate list of their applications, how many are installed, how many they are entitled to use and how many of the licensed copies are actually being used on a regular basis. Unless you can create an accurate view of this information then you don’t even know where you are starting from, never mind where you want to get to.

Another barrier to practical application rationalisation is the amount of high level strategy or “consultant speak” that surrounds the whole area. A search on the internet will reveal a number of strategy documents and articles that are excellent in explaining why you should rationalise and the theoretical benefits but there is relatively little substance in how you can do the practical implementation. What is really needed are guidance on the key steps to complete a rationalisation project.

The final aspect to consider is the amount of time and resources such a project will require. Do you have the skills never mind the time to do the work and more importantly where do you start and how can you prioritize the workload.

(Continue)

Request the full white paper at here.