Monitoring the cost and value of legacy applications

2 January 2020
Knowing how to work with Function Points is a must in any company. They help control the costs of your legacy applications and calculate their value. Serge Leblond reviews the use of this metric.


There is no getting away from the fact that legacy applications become more complicated over time

A large company’s application portfolio contains several thousand applications of all sizes and of several generations of technology. Over time, this legacy expands and becomes increasingly heterogeneous.

The applications grow in number with more and more functionality redundancies due to mergers/acquisitions or to similar requirements expressed by different groups of users. The requirement coverage becomes patchy. Some applications are used less and less often and are even abandoned completely in some cases, while others become technically obsolete. They form a disparate group which is increasingly difficult to manage.

The technical debt of the IS rises over time. This is the difference between the current situation of the application portfolio and an optimal situation where all of the software meets all the functional requirements (requirement coverage) and non-functional requirements (compliance of software package upgrades, upgrading due to development of standards and best practice, reduction in the technical quality of components, ageing infrastructure). The technical debt will rise if nothing is done to hamper the development of such constraints. It will firstly represent an expected cost for reducing it (for example, upgrading the software due to new security recommendations) and secondly it will have an impact on the maintenance cost (for example, a software package version not supported by the publisher will be more difficult to maintain).

This growing complexity of the IS leads to an increase in maintenance costs and a fall in value for the company.

In this context, it is essential to introduce specific indicators connected with these developments in order to keep control over the application portfolio.

An application’s maintenance cost and value are metrics which depend on many factors, but both can be tied in with the functional size of applications.


How to measure the functional size of an information system

Although the concern with software sizing dates back to the early days of IT, the Function Point method (FP for short) was created in 1979 to measure the functional size of an application or an IT project separately from the technical or organisational aspects. This metric quantifies the functional “area” covered by an application or project as well as their upgrades, as seen by the user. It was standardised by the IFPUG in 1987 and became an international standard (ISO 20926:2003 standard). Other measurement methods subsequently appeared, all derived from the IFPUG. The main ones are Mark-II, NESMA FPA, FISMA and COSMIC. Each of these methods contains counting rules for breaking down a functional scope of components and graphs for expressing these components as numbers of function points.                                                                                                                                  

To measure the functional size of a scope, you need its application map which is a representation of the different elements of the information system arranged according to a business perspective into key functional domains called zones (for example, customers, reference systems, accounting, etc.) and operations inside the domain called quarters (for example, analytical accounting, general accounting, etc.).

The application is the key element of application mapping: its limits are defined (or boundaries with the other applications and with the users), as well as the flows of exchanged information and the interactions existing between them.

This urbanisation approach must be based on common rules that are constant over time to ensure consistency as a whole.

The map must be shared among the various stakeholders and be updated to reflect the latest information system upgrades. Mapping modelling tools (for example, MEGA and ARIS) can be used.

Measuring the application’s functional size involves breaking down the functionalities available to the user into data type or processing type functional components and allocating each component a number of function points according to its complexity. The rules for component breakdown and for allocating a complexity level, as well as the correlation between the complexity level and the number of function points, are specified by the function point method. The application’s functional size corresponds to the sum of the function points of each component.

The number of function points represents the functional extent of the application. As well as technical complexity or quality indicators, it clearly presents the information system’s content. For example, the chart below shows the breakdown of applications by functional size of an information system analysed by the AUSY expertise centre using function points. It includes over 1,500 applications, more than 40% of which measure under 250 function points.



Example of a breakdown of an information system’s applications by size in function points



Example of functional sizes of a banking institution’s applications


Using functional size in the monitoring of costs


Functional size is one of the most influential factors on the cost of constructing and maintaining the scope of an application. Among the requirements an information system must meet (user expectations and needs, constraints to be satisfied), the functional requirements can represent almost two thirds of the construction and maintenance effort for an application, the other factors being the level of service and the construction and maintenance process.

Reducing a legacy’s maintenance costs can come about through:

  • analysing the costs on a functional like-for-like basis
  • reducing the legacy’s functional size.

Analysis of costs on a functional like-for-like basis

The function point is a standard, constant metric throughout the life of the application. It is useful for analysing or comparing the evolution of maintenance costs (user support, corrective maintenance, upgrade maintenance, preventive maintenance) and is used in several indicators for monitoring the activity and maintenance costs, for example:

  • maintenance cost by type of maintenance for 1,000 function points
  • maintenance cost by technology for 1,000 function points
  • number of maintenance operations for 1,000 function points
  • number of anomalies by type for 1,000 function points...




Example of maintenance indicators


Reducing the legacy’s functional size

The proportion of useless or redundant functionalities in legacy applications increases over time:

  • During mergers / acquisitions, applications from both IS are retained with similar parts and generate functional redundancies.
  • The unused functionalities are not removed and continue to be maintained by IT.
  • The functionalities requested by several groups of users are developed several times (for example, the customer repository managed by several different applications).


The functional measurement of the applications concerned will:

  • bring to light the unnecessary or redundant functionalities
  • quantify the corresponding functional size and set optimisation targets for the portfolio
  • measure functionality removals and monitor compliance with the set targets.


AUSY participated in a plan for optimising a large company’s application portfolio. The following steps were taken:

  • the functional size of an application scope was measured (rapid counting methods were used)
  • functional size reduction targets were set per domain
  • dashboards were created and gains achieved were measured in function points
    • redundant functionalities and applications were removed
    • a re-use policy was introduced
    • obsolete functionalities were removed.

Scheduled over a 2-year period, this plan reduced the size of the application portfolio by 12%, which led to the same proportion of reduction in IT costs for maintaining that scope.


Functional size and value

Depending on the objectives, the value of an application can be measured using several approaches, such as:

  • volume of use
  • impact on policy or strategy
  • impact on costs and company turnover...

The outcome of function point scoring is a consistent breakdown into elementary functional components which makes it possible, by assigning a degree of importance to each component, to obtain a breakdown of the value by key functionalities. The breakdown of the obtained value, tied in with the breakdown of the application’s construction and maintenance cost, provides a ratio which can be consolidated and monitored during the application’s upgrades.


Monitoring an application’s upgrades

The cost – value ratio changes during the life of the application. Each upgrade represents setting up and maintenance costs which will not always be proportionate to value creation and which will impact the cost/value ratio of the current version.

When deciding whether or not to proceed with upgrades, the function point method can be used to estimate the cost and analyse changes in the value.


Other uses of the functional measurement of an application

The functional size makes it possible to control an application portfolio and its upgrades. It also makes it possible to:

Estimate the legacy’s maintenance and upgrading costs

As the application’s construction and maintenance costs are partly connected with the functional size, measurement by function point is used to estimate the legacy maintenance cost and the impact on this cost of commissioning new projects.

Analyse the impact as part of upgrades and overhauls

The scoring outcome is presented in the form of a standardised and consistently granular list of functionalities belonging to the scope.



It is ideal when an upgrade is requested for assessing the impacted functional size and scope and therefore estimating the cost.

Interact with suppliers

The function point to be constructed or maintained is a standardised work unit which can be shared with the supplier and can be a basis for a contractual agreement. The work units purchased by the company are more representative of the service provided to the business than the technical and organisational constraints for accomplishing it.

An aid for ‘urbanists’

The function point is a useful metric for ‘urbanists’. It makes it possible to monitor the rate of re-use as part of a functionality factorisation approach and to monitor the functional size according to the various mapping breakdowns.

Monitoring business line software packages

Embedding a software package into an application requires some specific developments:

  • for developing the requested functionalities not covered by the software package
  • for interfacing the software package functions with the rest of the application portfolio
  • for customising and adapting the software package functionalities to an organisation’s specific needs which are not covered by the software package’s standard functionalities.

The extent of these specific developments or parameter customisations represents a significant additional cost in the TCO (Total Cost of Ownership) of the end-use application.

The function points make it possible to calculate the proportion of the software package’s standard functionalities used and to monitor the trend in the specific rate during the life of the application.


Functional size – key property

The analysis of the functional size provides a global approach based on a standardised, and therefore reproducible, method. It is also a way of engaging with the various company stakeholders (users, payers, purchasers, decision-makers, etc.).

Regardless of the methods used to define the mapping, the functional size is a key property of the application and its upgrades. First of all, it clearly presents the functional extent of each application and its development and secondly, by providing a breakdown of costs and value by key functions, it makes it possible to monitor the Cost/Value ratio and prioritise the application’s developments and upgrades.

The AUSY “IT Metrics” expertise centre has capitalised on a large amount of experience feedback on the analysis of legacy applications (tooling, capitalisation bases, qualified metrics), in both the industrial sector and in conventional information systems. 


AUSY expertise centre

The AUSY “IT Metrics” expertise centre has existed for over twenty years. It brings together several experts plus consultants trained in IT metrics as part of the AUSY university training course.

Its consultants help various companies of every size to set up and conduct measuring campaigns and create dashboards..


And you may be interested in our function point analysis.

Let’s have a chat about your projects