Application TCO dilema

Business Applications are the primary mechanism for delivering IT value. Applications are expensive to purchase, but even more expensive to maintain.

You have strategic plans, balance sheets, portfolio management cycles…and budget reviews.

Application TCO is one of the recognized mechanisms to manage the IT budget, and it’s also one of the major headaches for CIOs and IT departments.

Challenging questions:

  • How do you evaluate the TCO of your portfolio?
  • Do you have a classification of applications by type of TCO calculation?
  • How do you measure the ROI of an application?
  • How many years is your applications life-cycle analysis?
  • Which depreciation methods you apply?
  • What costs can be associated with software development over a 3, 5 or 10-year maintenance cycle?

To keep up to date the data related to an applications portfolio is so much difficult, to have clear the TCO of each one of its assets is a nightmare.

I have found that one of the common strategies of the IT organizations is to create the legacy department that takes care of all the applications that are not valuable from the IT point of view and that continues evolving there forever; making the OPEX to be prolonged for years. TCO is measured at high level, but not in detail.

It’s true you have to rationalize and concentrate on the more important assets of your portfolio, but take care with this strategy because the speed of transformation and new amount of “legacy” applications grows more and more, and suddenly you will find that a big % of your portfolio is “legacy”.

Then, after some years in this situation, the only way to handle it is with a transformation program, let’s call it: “Remove legacy applications program”.

If we look in other areas of IT (for instance platforms or end user computing) they all work with very detailed list of assets and with a rigorous understanding of life-cycle, TCO, TCO forecast… the same organizations than have a mess on applications.

Leave a Comment