This research note is restricted to the personal use of cross@alvarezandmarsal.com.

A Primer on Application Cost of Ownership

Published: 5 May 2017 ID: G00326273

Analyst(s): Andy Kyte, Luis Mangi, Stefan Van Der Zijden

Software is vital — and expensive. Not just to subscribe to, develop or

license in the beginning — it keeps costing money over the whole of its life.
Application leaders need to master the four modelling tools that can be
applied to application costs in order to maximize value for money.

Key Challenges
■ Business and IT units generally have poor granularity and transparency into the cost of
delivering application services.
■ As digitalization increases, so does the percentage of business costs attributable to software,
and business and IT units both need better application cost management.
■ Large and complex application software systems tend to become more expensive to operate,
support and maintain as they get older, but few IT organizations have any real idea of the future
cost of managing their current applications.
■ In the rush to implement new application solutions, there is a tendency to pay too little attention
to the lifetime total cost of ownership (TCO).
■ Solutions that are welcomed when they are delivered can rapidly become an unwelcome cost
burden, negatively impacting business value.

Recommendations
Application leaders involved in strategy and governance:

■ Develop the discipline of application cost management by using our four modelling tools.
■ Improve the granularity and accuracy of current-year cost modelling for significant applications
by working closely with IT finance teams.
■ Improve the prediction and reporting of current-year nonrecurring application costs by reporting
upgrades and enhancements separately from operational costs.
■ Nurture application governance teams by allowing them to develop and maintain models for the
expected future costs of their significant applications.

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

■ Calculate the expected total cost of application ownership by utilizing whole-of-life cost
modelling when developing a business case for a new application.

Table of Contents

Introduction............................................................................................................................................ 2
Analysis.................................................................................................................................................. 3
Develop the Discipline of Application Cost Management...................................................................3
Improve the Granularity and Accuracy of Current-Year Cost Modelling..............................................6
Improve the Prediction and Reporting of Current-Year Nonrecurring Application Costs..................... 7
Develop and Maintain Models for Expected Future Costs................................................................. 7
Summary........................................................................................................................................10
Gartner Recommended Reading.......................................................................................................... 10

List of Figures

Figure 1. The Four Application Cost Models........................................................................................... 5

Introduction
"Cost containment" is a major theme for most IT organizations. And for the majority of these
organizations, a major share of their IT budget is spent on applications (for detailed analysis of
application spending, see "IT Key Metrics Data 2017: Key Applications Measures: Cost and Staff
Profile: Current Year").

Many IT teams have already taken dramatic action to standardize and simplify their infrastructure
and operations costs, but that well is starting to run dry as CIOs look for the next wave of cost
reductions. This puts a lot of pressure on application leaders.

Application leaders face four key challenges when they address application cost containment.

1. Lack of granularity and transparency about application costs: IT financial controls frequently
lack the ability to provide cost models at the application level. If there is no clear understanding
of the existing cost of providing an application service, it makes it very difficult to assess the
value of making changes to how that service is provided.
2. Lack of visibility into future costs: Applications need continuous reinvestment in order to
maintain technical integrity and to reduce the risks associated with technology obsolescence.
Major upgrades (such as operating systems, databases and commercial off-the-shelf [COTS]
software upgrades) need to be planned and financed. While delaying an upgrade might save
some costs in one financial year, these are not real savings since they create a deferred liability.

Page 2 of 12 Gartner, Inc. | G00326273

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

3. The investment pipeline is adding new application costs faster than legacy costs can be
removed: Even though there may be strident demands for IT cost containment, there will also
be significant demands for investments in new business initiatives with substantial IT projects.
Some of these IT investments may be made initially outside the control of the IT organization,
through "business unit" IT initiatives. But these initiatives can frequently add substantial IT costs
after the initial investment as the IT organization is expected to pick up future costs associated
with operations, support and maintenance. At the same time, there will be IT-managed
application investments that are frequently made with little initial concern about future
operational cost impacts.
4. Getting rid of an application does not necessarily lead to cost savings: Many of the costs
associated with provisioning an application service are shared costs. So, for example, we might
have five applications that all use a common database management system, and we might
attribute 20% of the costs of providing that database technology to each application. Getting
rid of one application does not save any of the costs associated with the database. All that
happens is that the cost of the other four applications increases as they now take on more of
the burden for funding the database. This means that, in order to actually reduce the cost of the
database technology, it would be necessary for all five applications to be replaced or modified.
If these applications are funded by different business units, then it can be nearly impossible to
coordinate the changes needed.

These challenges — and many other difficulties in measuring and managing application costs — do
not excuse application leaders from the task of application cost management. As the old
management adage says "If you can't measure it, you can't manage it." The advice given in the rest
of this note is intended to assist application leaders in developing an approach to application cost
management. The approach we advise here is not exhaustively comprehensive. There will be many
specific situations where the framework will need to be adjusted to meet the requirements of
particular cost challenges. The key here is to get started, which will be facilitated by adopting a
relatively simple approach. As you gain experience in cost management, you will be able to make
decisions about where you want to improve the framework.

The approach documented in this research note is primarily intended to be used with "traditional"
applications. Clients who have made the migration to "product management," and are engaging in
lean and agile development methodologies to facilitate continuous delivery, will be able to use some
of the techniques documented here, but will need to extend these to the very particular
circumstances of the continuous delivery model as they are implementing it.

Analysis
Develop the Discipline of Application Cost Management
If you don't know where the budget goes, how can you be sure that you are delivering value for
money? IT organizations in general, and application leaders in particular, have insufficient insight
into the distribution of the operating expenditure (opex) budget between individual applications. By

Gartner, Inc. | G00326273 Page 3 of 12

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

contrast, IT organizations are generally pretty good at tracking capital expenditure (capex) since this
is generally distributed to project managers whose budget are specifically tracked.

It is not sufficient to know the big numbers because the challenge is one of granularity. The CFO is
hardly likely to be impressed by an application leader who says "I know that we spend $85 million
running all the applications — but I don't know how that is distributed between individual
applications."

Application leaders already feel rushed off their feet with all the work that they have to manage, and
many of them believe that the task of trying to develop cost granularity for a large estate of
applications will be the straw that breaks the camel's back.

Such a defeatist attitude serves nobody well. It is certainly true that managing application costs
requires time, resources and tools. Rather than seeing the problem of understanding cost
distribution as impossible, application leaders need to break the problem down into manageable
improvement steps.

One of the major challenges posed by the application portfolio can be its sheer size and complexity.
How can one person possibly understand cost allocation across a portfolio of 1,000 applications?
The action here is to focus initial activities on a small number of large and complex applications.
Most portfolios demonstrate a strong "Pareto principle" in that 20% of the applications account for
80% of the costs. So instead of trying to understand the costs of 1,000 applications, start by
modelling the costs of the 50 largest and most-expensive applications. Don't be too concerned
about trying to identify the exact 50 most-expensive applications. If it walks like a duck, quacks like
a duck, flies like a duck and swims like a duck … it's probably a duck.

Having identified a set of applications that will serve to pilot cost collection, the application leader is
faced with a challenge — how to start? While collection of direct costs (those that are directly
attributable to a single application, such as the vendor maintenance charge for a COTS application)
is relatively straightforward and mechanistic as much of the cost of a large complex application is
shared (including infrastructure, integration, network, business intelligence, first-line support and
disaster recovery, for example). The key here is to understand that any attempt to start allocating
actual costs to these shared overheads is far too difficult for a cost management program to take on
in its early stages. Instead, the program needs to work on a model (with emphasis here on "model")
of overhead allocation. While simple overhead allocation modelling may be beyond the capabilities
of many IT specialists, it is a simple exercise for cost accountants, and it is to specialists in this
discipline that application leaders need to turn. For further analysis on cost collection for application
work, see "Minimize, Maximize, Optimize: A Framework for Analyzing Application Work."

There is no "right answer" when deciding which shared costs should be attributed to applications,
or how the shared cost should be apportioned between applications. For example, integration
services might have their costs distributed among the applications that consume those services, or
could equally be reported separately as "integration costs" completely separate from the application
cost models. The same principle applies to services such as data warehousing and business
intelligence. Costs might be distributed to a number of applications, or managed centrally and
separately from the individual applications. Whatever decision is made about such costs, it is
important to maintain consistency and transparency, and to avoid double counting. Once again,

Page 4 of 12 Gartner, Inc. | G00326273

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

working with qualified cost accountants will help to develop the consistency that is necessary for
costs to be credible.

Where should all this cost data be stored? Ideally, the IT finance function will have a financial
management tool that can be used to hold all this data within the overall chart of accounts for the IT
budget. In the first instance, however, this might present too many challenges in terms of
familiarizing staff with the tool and generating the reports from it.

There is no harm in starting with a simple spreadsheet. After all, the initial pilot could be for just 50
large applications. Part of the pilot evaluation should be a consideration of what other tools might
be appropriate as the cost management program is extended. Whatever is done with tools, it is
important to remember that the principal goal of the application cost management program is to
drive value-for-money decisions — it should not be a goal to "implement a tool."

Once the general principles of the application cost program have been established, application
leaders need to develop capabilities in the four cost modelling activities, as seen in Figure 1.

Figure 1. The Four Application Cost Models

Source: Gartner (May 2017)

The following four sections of this document describe each of these models in turn.

Gartner, Inc. | G00326273 Page 5 of 12

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

Improve the Granularity and Accuracy of Current-Year Cost Modelling

"Current-year cost" describes the outlay associated with providing the live operational application in
the current financial year.

These costs should be broken down as follows:

■ Cost of operations: For on-premises applications, this is the allocation from the overall cost of
infrastructure that is attributable to this application following overhead allocation rules
established by cost accountants. This should include the apportionment of disaster recovery
and business continuity costs attributable to this application. For software as a service (SaaS)
applications, this cost is the vendor invoice for the application in the current financial year (the
SaaS fee covers more than basic operations, since it also delivers some maintenance and
support services, but for this exercise, the whole SaaS fee should be considered to be opex).
■ Cost of support: This should be broken down into first-line, second-line and third-line costs:
■ For first-line costs, the allocation should initially be based on the number of calls to the first-
line desk for this application as a percentage of the total cost of providing the first-line
function. If the data is available, it may be possible to allocate the costs by using the total
number of support minutes consumed by this application as a percentage of the total
number of minutes consumed by all applications.
■ For second-line costs (the subject matter experts), it is important to distinguish between the
costs attributable to the IT budget, and costs borne by the business units. Second-line
costs are generally extremely fuzzy since there is little or no record of the number of calls on
second-line support or the amount of time spent on those calls. Where the burden is
believed to be significant, it may be necessary to initiate a program to improve data
collection.
■ Third-line support activities are frequently undertaken by the software maintenance team
and may be indistinguishable from maintenance costs.

Note that SaaS applications incur internal first-line, second-line and third-line support costs
over and above the charges from the SaaS vendor.
■ Cost of corrective maintenance: Corrective maintenance is the activity related to fixing
functional errors (aka "bugs") in the software (see "Estimating the Future Cost of Application
Maintenance"). When the application is a COTS solution, there will be an annual payment made
to the software vendor that is generally known as a "maintenance fee" that should be included
here. However, even when a vendor charges such a fee, there will also be internal costs
associated with maintenance, such as reporting the error to the vendor, then receiving and
testing patches. There are also maintenance costs associated with SaaS applications (for
example, collecting evidence of a bug). It is very important not to include any costs associated
with software development activities in the cost of corrective maintenance. In particular, it is
important to avoid including costs of "minor enhancements." These are nonrecurring
development costs and do not form part of the current-year costs.

Page 6 of 12 Gartner, Inc. | G00326273

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

Improve the Prediction and Reporting of Current-Year Nonrecurring Application

Costs
Application costs vary from year to year. Some costs are reasonably constant. For example, the
cost of operations, support and corrective maintenance (bug fixing) will likely stay relatively steady
over time. Other costs will vary. It is very important to report these nonrecurring costs separately
from the recurring costs.

There are three primary sources of nonrecurring costs:

1. Licence Variance: This may occur because the number of users goes up or down; because
modules are added or subtracted; or because of price changes imposed by the vendor. These
may affect the annual support fees that will be payable to the vendor in both the current year
and the future.
2. Adaptive Maintenance (Upgrades): This is necessary to maintain the support viability and
integrity of an application. All applications need periodic upgrades to their infrastructure,
operating system or database technology. COTS application upgrades also have to be
managed as vendors release new versions. Examples of other adaptive maintenance activities
include implementing newer versions of content management services for an application or
changing the version of an integration tool.

SaaS application upgrades (including upgrades to the SaaS platform) are undertaken by the
vendor as part of the subscription fee. However, that does not mean that all SaaS application
upgrades are free of cost to the user organization. There may be costs incurred for making
changes to integration capabilities, training users, modifying configuration options and
validating the upgrade. These additional costs may be difficult to predict, since the actual
content and impact of SaaS upgrades may not be announced a long time in advance, but they
certainly need to be reported as they are incurred, and application leaders need to make
provision for future costs based on past experience with the vendor (see "Establish Governance
of External APIs to Avoid Unpleasant Surprises").
3. Enhancements: These changes to an application's functionality are not "running" costs — they
are intended to enhance the business value of the application. As such, they must always be
reported as nonrecurring software development costs (see "Are You Overcounting Run-the-
Business Costs?"). In highly regulated industries, application leaders should separate the cost
of enhanced functionality that is imposed by regulatory compliance from the cost of
discretionary enhancements.

Develop and Maintain Models for Expected Future Costs

Applications are intangible assets of the business. The future cost of sustaining an asset (in other
words, "the liability cost of the asset") should be part of the financial modelling employed by the
financial management team. IT organizations are generally lax about providing any predictions
concerning the future cost of applications, even though these can be quite considerable.

Gartner, Inc. | G00326273 Page 7 of 12

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

Many IT managers consider any such predictions to be futile. They see no point in considering costs
beyond the end of the next financial period. But failure to understand future costs simply stores up
problems for the future, particularly when it comes to the difficult discussions that must be held with
business managers about funding. It is much better to maintain a set of transparent predictions
about likely future costs, even as it is recognized that these predictions are estimates based on
imperfect information.

When considering the future cost of ownership, a key question concerns the time horizon that
should be used. IT organizations generally lack experience of future cost modelling, and so tend to
restrict any such exercises to a two- or three-year planning horizon. But such short-term planning
rarely offers any meaningful insights into the overall shape of future portfolio costs. The
recommended minimum period for developing a future cost model is 10 years. For large and
complex applications, a 15-year horizon is more appropriate. Clearly the cost model becomes
fuzzier as it looks further out, but that is no reason to shy away from the difficult questions posed by
the longer horizon. It is important to recognize that such modelling is not a one-off exercise: It is a
discipline that should be repeated annually. As new information becomes available, the model can
be refined. And by being able to see variance from original estimates over many years, the team
responsible for future cost of ownership modelling can improve their estimating techniques.

Predictions about future cost of ownership have three elements:

1. Variation in operating costs: Future costs for provisioning an application may vary from the
current year costs either because of changes in business use of an application or because of
changes in the cost of providing the service. For example, an application that is currently being
used by one region may have its use extended to other regions, meaning higher costs for
operations and support. Conversely, a predicted drop in business use of an application may
result in lower operating and support costs. On the technology side, a change in the cost of
provisioning the application service, such as migrating the application from an internal data
center to the cloud, changes in vendor licensing or changes in staff salary costs, may result in
operating cost variances in future years.
2. Predictable upgrade costs: Upgrade costs are part of the nonrecurring costs of ownership for
an application. In some years, there may be no upgrade costs for an application: In other years,
there may be several upgrades (including OS, database and COTS version). In the absence of
specific information about future upgrades, the FCO modelling team should use the frequency
and costs of previous upgrades as the basis for their estimates.
3. Potential functional enhancement costs: Most large applications are the subject of a number
of functional change projects every year. But most of these functional changes have fairly short
lead times: Attempting to predict functional changes that might be required in five or 10 years is
a futile exercise. However, that is not to say that the potential future enhancement costs cannot
be modelled. Applications tend to have a reasonably consistent demand profile for functional
changes over time. This means that it is reasonable to use the historic pattern of enhancement
project spend on an application in order to extrapolate the potential future costs. Such an
extrapolation should not be a simple straight line: the more changes that you make to an
application, the harder (and more expensive) it becomes to change it in future. A reasonable
working assumption for the future functional enhancement costs is therefore likely to be the

Page 8 of 12 Gartner, Inc. | G00326273

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

smoothed historic annual spend with a 10% compound annual growth rate (CAGR) applied,
where the 10% represents the additional costs as the application complexity increases.

Calculate the total cost of ownership of the application by utilizing whole-of-life cost modelling
before investing in a new application (whether building, buying or subscribing). The project team
needs to provide a model of the total cost of ownership (TCO) of the application over its predicted
life. The goal here is not to provide a single authoritative figure, but rather to indicate an expected
range of costs and the reasons why costs might vary between the lower ranges and the higher
ranges.

Such a model needs to include the following elements:

■ Cost to go live: This will typically include all of the upfront expenditure, including the cost of the
original project and any initial license fees payable to vendors.
■ Annual cost to operate: This should be the target operating cost for the application, including
the costs of providing disaster recovery and business continuity management. If this cost is
expected to vary over time (for example, as more regions are moved on to the application), this
variance should be clearly shown. The more-likely case is that the project team doesn't have a
clue about what the future operating costs might be. In this case, it is best to be honest and to
provide a range of possible operating costs where the upper bound is an order of magnitude
greater than the lower bound. Given that such a range is likely to concern those responsible for
financing the project, they may be inclined to ask what steps could be taken to ensure that the
actual annual operating costs could be at the lower end of the range. One such step would be
focusing design activity on performance. This might have the consequence of increasing the
cost of the design phase, with the payback being a substantial reduction in future cost.
■ Annual cost of support and maintenance: This should be expressed as the additional
workload expected on first-, second- and third-line support and maintenance teams as a result
of implementing the application. Given that the cost of support and maintenance is greatly
impacted by the number of errors in the system at the point of going live, it is a good idea to
express the annual support cost as a range that is dependent on the error rate delivered by the
project team. For COTS applications, this should also include the maintenance fees payable to
the vendor.
■ Predictable nonrecurring costs (upgrades): This should be based on a model of the stack
components necessary to support the proposed application, using historic information about
frequency of vendor releases and costs associated with implementing upgrades.
■ Potential future enhancements and extensions: The key here is to assess the potential
volatility of business requirements for the application over the life of the application. Some
applications are comparatively stable, and will have fairly low future projected costs for projects
to add or amend business capability. Other applications will be highly volatile in nature, with a
continuous stream of business requests for new features and functions, more integration, more
reporting and analytics, and access on more device types. Once again, it is a good practice to
show the cost of potential future changes as a range, since the actual rate of demand for
change and the difficulty of implementing the changes are largely unknown and unpredictable.

Gartner, Inc. | G00326273 Page 9 of 12

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

■ Post-decommissioning regulatory data retention costs: Some applications manage data

that may need to be retained for a period of time after the application itself has been
decommissioned. Depending on the volume of data and the retention period, there could be
substantial costs associated with that data retention.

The total cost of ownership cannot be a simple number — it will always need to be expressed as a
set of component elements, many of which show a potential range of costs.

The emphasis with calculating TCO is on predicting the sum of costs likely to be incurred for an
application that does not yet exist. There is little value in attempting to generate a TCO for existing
applications by attempting to measure previous expenditure on the application — and then adding
that previous expenditure to the predicted future cost of ownership to generate a whole-of-life cost.
Few IT organizations have the granularity of historic cost data to make such an exercise viable or
meaningful.

Summary
Software is expensive, and the many challenges and opportunities of digital business all demand
more software. IT organizations need to develop a much better understanding of the costs
associated with running software over the entire life of a system. Developing this understanding
should not be a one-off project, but a commitment to develop the discipline of application cost
management in order to increase transparency and improve value for money. By using the four cost
models — current-year cost, current-year nonrecurring cost, future cost of ownership and total cost
of ownership — application leaders can apply effective techniques for understanding and
communicating the potential costs involved when application decisions are taken.

No one role or individual can take ownership of all application cost activities. The IT management
team should assign responsibility and accountability for different elements of application cost
management, and ensure that the appropriate level of coordination and knowledge sharing between
the different elements are in place. Effective cost management is the responsibility of all
management and technical staff but, without common models, there can be no sharing of data and
best practices.

Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

"Define Your Objectives Before Selecting Chargeback, Showback, Bill of IT or ITFM"

"Best Practices for Data Retention and Policy Creation Will Lower Costs and Reduce Risks"

"Toolkit: Total Cost of Ownership for Application Services and On-Premises Software or SaaS"

"Application Portfolio Management and Total Cost of Ownership Approaches to Business Unit IT
Strategies"

"Application Deployment Options Through the Pace Layer Lens"

Page 10 of 12 Gartner, Inc. | G00326273

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

"Best Practices to Drive Cost Optimization in Application Support"

"Run IT as a Business Using Six Pillars of Effective IT Financial Transparency"

Gartner, Inc. | G00326273 Page 11 of 12

This research note is restricted to the personal use of cross@alvarezandmarsal.com.

 This research note is restricted to the personal use of cross@alvarezandmarsal.com.

GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

© 2017 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see “Guiding Principles on Independence and Objectivity.”

Page 12 of 12 Gartner, Inc. | G00326273

This research note is restricted to the personal use of cross@alvarezandmarsal.com.