Introduction

Based on the author?s industry experience, decommissioning is often not seen as a fundable business priority at the highest levels of an organisation. He has found that the timely decommissioning of ICT systems, incorporating applications, platforms, networks and devices, can be a perennial and frustrating challenge for technology managers.  More so, the accumulation of legacy ICT systems inhibits organisational modernisation, innovation, agility and the speed to market demanded by new revenue opportunities. Ironically the bias for capital funding of new revenue opportunities can starve an organisation of the funds needed to decommission, rationalise and ultimately modernise its ICT systems. Decommissioning can be treated as an operational overhead and relegated a low priority until other factors (e.g. risk of failure, legal liability, real estate constraints, power and supportability) cannot be ignored.

The ?true cost? of maintaining a system of low business value, high risk/cost of failure and poor strategic fit can be underestimated.   It often neglects the real cost of ICT technology debt, architectural complexity, real-estate value, and environmental impact (e.g. energy usage and associated carbon emissions).  Unlike discretionary new investments, the decision to decommission is not a question of whether to invest or not, but rather discretionary only as a matter of timing.  Eventually, all systems need to be decommissioned, and in the meantime the direct and potentially hidden costs to maintain legacy systems are an ongoing business overhead.

The business case for decommissioning a system can be nontrivial and its form can vary from organisation to organisation.  Making decisions focussed on Total Cost of Ownership can be overly simplistic and mask other less apparent business factors and opportunities.  According to Murphy, P. (2011), decommissioning has some unique business requirements and there is a need to look beyond just cost-benefit analysis as this is too narrow a viewpoint. On this basis, this paper takes a more systemic approach to decommissioning decision making by incorporating systems? assessment of Business Value, Strategic Fit, Ease of Decommissioning and Risk Manageability.

The paper starts with a review of the opportunities and the challenges for decommissioning.  It then introduces a framework for assessment and a case study use of the framework undertaken in partnership with the City of Melbourne Council, Victoria, Australia.  The paper concludes with 10 key recommendations for improving decommissioning outcomes that ultimately could improve corporate profitability, delivery and sustainability. 

Scope

There are many publications covering systems? lifecycle management.  However, in the author?s experience, the complexity of decommissioning decision making is often underestimated. A generalised technology lifecycle from an ICT user?s perspective is shown in Figure 1. As highlighted, this paper focuses on the Decommissioning Decision phase in the systems? lifecycle.

Figure 1: Systems lifecycle and the scope of this paper

The Opportunities

A traditional cost-benefit business case for decommissioning will be comprised of the systems? apparent cost of ownership versus the costs to decommission either in the systems? entirety or as part of a functional migration to an alternative system.  The usual cost of ownership, so-called ?hard? costs, include licensing, support, maintenance, infrastructure and associated support staff.  For an older system, ?hard? costs may already be small as previous savings efforts have reduced these costs to an essential minimum. A business case determined on ?hard? costs alone is often found not to provide a worthwhile return on investment and therefore decommissioning can repeatedly be forestalled.

A prudent corporate business case necessitates justification based on the financially ?hard? costs, however, there can be other financially ?soft? and ?intangible? value. The ?soft? and ?intangible? value are potentially intuitively compelling but often based upon subjective justifications only. This additional value should nonetheless be of business interest and can provide additional business justification over hard cost savings alone; see Figure 2.

Figure 2: The decommissioning iceberg - above and below the line business savings

Definitions for hard, soft and intangible savings:

• Hard. The financially tangible direct and bankable cost savings that could be recognised if a system was decommissioned, either in its entirety or functionally migrated to an alternative system.  These savings will reduce an organisation?s committed budget expenditure.
• Soft. The expenditure that is often uncommitted from a financial budget perspective, but in all likelihood could or should be spent to mitigate growing risks. These discretionary, but likely, future savings can be difficult to materially recognise in a financially focused business case.
• Intangible. The costs and upside value that is intuitively apparent, but buried amongst other shared systems costs, dependencies, processes and complexity. The lack of traceability and attributability of these costs makes them virtually impossible to include in a business case.

Examples of hard, soft and intangible savings value are shown in Table 1.

Table 1: Example hard, soft and intangible decommissioning value

Challenges ? Why can it be so difficult?

This paper is less concerned about the idle server platform running in the corner of a data centre or under an employee?s desk; the rationale to identify, migrate, and switch-off any such systems should be relatively trivial, cheap and obvious.  Instead, this paper is focussed on the ageing platforms that still have business dependencies making them technically, operationally, organisationally, commercially and legally difficult to be removed.  There may also be customer dependencies to be managed. Addressing all these aspects in an effort to turn off ageing systems is challenging. Figure 3 lists many of the likely and associated considerations.  This list is by no means exhaustive.

Figure 3: The challenges of ICT decommissioning

There are three other areas ? data lifecycle management, financing and risk management ? that warrant further discussion.

Data Lifecycle Management

Sound data lifecycle management is key to decommissioning ageing systems. Establishing exactly what data is located where, and how different systems process it, can require significant effort.  Organisational data ownership can be unclear and in effect be shared across product, application, process, IT infrastructure, legal and customer groups.  Without clear data ownership, organisations can be challenged by data preservation requirements, which may be mandated, perceived or unknown, and as a result, they find it difficult to know what data can be purged and what needs to be maintained in an archive.  With no one group having clear ownership, an organisational default can become a practice of keeping everything ?just in case?. 

Without clear data systems knowledge and ownership that can determine whether to purge, archive or migrate data over time, the best an IT infrastructure team can do is maintain and expand a system to avoid it failing or underperforming.  The inadvertent demand to retain old data drives up applications support costs, processing infrastructure requirements, data backup window sizes, network capacity and software licensing costs. The challenges of data lifecycle management and the long term storage of data are further described by Lambrechts, J. (2014) and Hormann, P. (2014).

Financing

Finding a funding source for an ongoing decommissioning program can be a perennial challenge. Who should pay? Is it a capital or operational expenditure? What are the financial incentives and motivations? Who benefits from the financial rewards?

Capital Expenditure versus Operational Expenditure

Our system of business valuation and taxation generally promotes and rewards the use of capital expenditure to build new revenue earning investments. Funds to build a new or augment an existing system are usually classed as a capital expenditure.  For example, capital expenditure can be used for systems infrastructure / software purchases, site preparation, development, delivery, installation and associated labour and training.  The resulting system costs are depreciated from a taxation perspective over the expected lifetime of the asset.  Importantly a system that has already been capitalised up front cannot be capitalised again at the end if its lifecycle.  As a result, decommissioning activities are usually classed as an operating expense.

Operating expenditure is typically the recurring annual costs for running a system. These costs include staff, training, spares, licenses, maintenance and support agreements, and data centre hosting (e.g. real-estate, energy, cooling) charges.  Operational expenditure is often scrutinised for waste and a company is rewarded when it is reduced.  If an exercise in systems decommissioning is difficult, and therefore costly, and the apparent operational cost savings are small over business case evaluation periods, then it is easy for a decommissioning project not to be funded. This is despite the inevitability that all systems must have an end, whether planned or as a result of a failure event.

As an exception, it may be possible to capitalise the funding for decommissioning where an old system needs to be removed to ?make ready? for the building of the new; not unlike the demolishing of an old building as site preparation for the construction of a new building.  From a CFO?s perspective, it can be financially prudent to bundle the decommissioning of an old system with the capitalisation of its physical or functional replacement. However, the costs of the ?make ready? can be seen as punitive to the business case of the new. This is especially the case where easy to access data centre space exists elsewhere and there is no reward or recognition to do otherwise. The efforts to work around the ?make ready? costs can then drive a suboptimal outcome from a business and technical perspective that adds to the inadvertent sprawl of systems.  An unfortunate consequence is that old systems will be left running and in place until their physical locations are required by a project that can?t find more convenient space elsewhere. 

Importantly, build budget overruns cannot be allowed to consume funds assigned for systems decommissioning.  As such any funds, be they capital or operational, that are budgeted for decommissioning should be explicitly quarantined to avoid forestalling systems decommissioning in whole or in part to another time. This is especially the case where funding is strictly limited, the process for requesting new funds can be onerous and punitive, or decommissioning can be side-stepped through official or unofficial descoping practices.

Funding Sources

A business funding source for system decommissioning may not always be obvious as ongoing costs and risks are owned by one part of the organisation such as an IT department and the business need by another part such as a product manager.  While a product manager may perceivably ?need? a system while it is free of charge to them, this may not be the case if their product?s profitability was tied to the system?s real costs and risks.  Alternatively, the benefits of decommissioning can be shared by many, but are not separately compelling enough for one part of an organisation (e.g. IT) to fund the opportunity on its own. 

There are a number of potential ways to fund decommissioning initiatives; five example approaches with their pros and cons are summarised in Table 2. Others such as a sinking or accumulation fund may also be worth considering.

Table 2: Decommissioning funding sources ? five key approaches

Worthy examples of raising funds for decommissioning (amongst other savings opportunities) are Microsoft?s formative equipment recycling fee described by DiCaprio, T. (2012) and more recently Microsoft?s internal carbon fee described by DiCaprio, T. (2015):

• Recycling Fee - introduced to cover the costs of recycling old electronic hardware as part of a policy for retired technology.  The fee is collected at the time of equipment purchase and is centrally managed via an IT Asset Disposition program. 
• Carbon Fee - helps raise awareness and drive accountability to enable a transparent and environmentally sustainable business model. It provides both an incentive and financial support for internal stakeholders to take responsibility for cutting energy costs and reducing the organisation?s carbon emissions through investment activities such as systems decommissioning.

Risks

Ageing systems can often be out of mind and out of sight, especially where much of the original costs have been progressively pruned and the system appears well down a corporation?s long-tailed systems list.  This is not to say that the system is not important, but if it is not a high-ranking core system (e.g. by total cost of ownership), then it is not likely to have a dedicated system owner and can be relegated a low priority from a management attention perspective.

A system without direct oversight and understanding can unknowingly become unsupported or unsupportable. Unwittingly systems costs such as licensing, support and maintenance, and other potential risk mitigating controls can be defunded without an essential understanding of the growing business risks.

Managing risk requires the understanding of the likely failure modes, the likelihood of failure, and the business consequences in the case of a failure.  A system with a high potential to fail, or with a large impact on the business in case of failure, should be subject to effective risk controls that bring the system to an acceptable level of manageability. Risk controls could include managing system hardware and software, unplanned incident contingencies, preventative maintenance, availability and performance monitoring, system backups, documented disaster recovery processes, availability of spares, security patching, and logical/physical capacity planning. Risk controls should not be taken for granted, and their ongoing efficacy (including funding) should be regularly tested and evidential data collected.

An example risk assessment matrix based on Queensland CIO, (2016) is shown in Figure 4. It shows a generalised system without any controls having a risk likelihood of ?4. Likely?, a consequence of ?4. Major? and an overall risk rating of ?High? (C). With the addition of risk controls the overall risk is reduced to ?Medium? (B), but is still short of business determined maximum acceptable ?Low? risk rating (A). 

Figure 4: A Risk Assessment Matrix ? example (based on Queensland CIO, 2016).

If the costs of sufficient risk controls are operationally unaffordable and the maximum acceptable risk has not been achieved, then there is further justification for systems decommissioning where the cost of the risk controls are potential ?soft? savings.

A decommissioning assessment framework

As part of this study, a detailed decommissioning assessment framework has been developed.  The framework is focussed on gathering a wide range of both subjective and objective measures and turning these into a quantifiable score across a range of business criteria. Its key components include:

1. Questionnaire ? a list of 90 questions to be completed by the system owner.
2. Question context ? further explanation about the question.
3. Assessment scoring guide ? a ?how-to? for determining a score
   • 0 = poor (or unknown), to
   • 5 = good
4. Business Criteria ? i.e. Business Value (BV), Strategic Fit (SF), Total Cost of Ownership (TCO), Risk Management (RM) and Ease of Decommissioning (EoD).
5. Question assessment ? the numeric score assessment based on the questionnaire.
6. Question score weighting ? a relative adjustment of importance between questions.
7. Score summary table ? the final weighted and normalised results. 

Figure 5 shows a blank example of the framework questionnaire, assessment and results table. The application of the framework is demonstrated in the following case study undertaken with the City of Melbourne Council.  Readers are encouraged to generate their own assessment framework and are welcome to contact the author for further help.

Figure 5: ICT Decommissioning Assessment Framework - sample

Case study - City of Melbourne

Background

The City of Melbourne IT systems architecture is comprised of about 100 key applications. There is also a long tail of other applications that are not actively managed by the IT team.  Over recent years there has been a significant effort to rationalise and virtualise old systems with a high degree of success. There are, however, some old applications and associated platforms that remain running because of residual business process requirements and the need for ongoing data retention and accessibility. Like many councils, the City of Melbourne has mandated data preservation requirements; but it struggles with developing and implementing policies, processes and technologies to do this consistently well. By default, it is seen as easier and perceivably cheaper to continue to manage and sustain old systems.

In this study, four applications have been reviewed within the City of Melbourne?s IT portfolio. Two applications, PPR and CPC-Pro, are 15 to 20 years old and considered as problematic decommissioning candidates. Another, Vantive, is of similar age but has recently been decommissioned after a successful business justification was completed. Lastly, MS-Exchange is a modern platform and included as an assessment framework cross-check of a system that should intuitively remain current for the foreseeable future.

Methodology

The following steps were undertaken to complete the decommissioning assessment:

1. A questionnaire for each application completed by City of Melbourne system owners.
2. Assessment of the questionnaire responses by an independent assessor.
3. Applications / Systems which rate poorly against the business criteria for retention are ear-marked for its decommissioning.

Findings

The results of the analysis are shown in Figure 6 and Figure 7. System criteria scores closer to zero are indicators of positive decommissioning potential, while scores closer to five indicate a system that?s worth retaining; at least for the time being.

Figure 6: City of Melbourne decommissioning assessment results (radar chart)

Figure 7: City of Melbourne decommissioning assessment results (bar chart)

A system of high value would rate all fives, while an obvious system candidate for decommissioning would be rated all ones. As can be seen from the results, none of the systems are easy or obvious decommissioning targets.  A business case based on only TCO in each case is likely to fail as there is little ?hard? cost saving to be made and where the decommissioning exercise is likely to be medium to high in difficulty (and therefore high cost).

Observations about the results:

• MS Exchange is a relatively new and modern application and can be seen to rate highly in all categories.  It offers good business value, is of good strategic fit, a reasonable TCO, is well risk managed, and could be reasonably easy to exit (e.g. migrate to a cloud-based email platform).
• PPR, CPC-PRO and Vantive all show low TCO (rated as 5 on the scale) where support, licensing and platform costs have been already minimised.  They also have been evaluated with a medium level of difficulty for decommissioning, meaning the exercise requires some level of functional and data migration to a newer equivalent, and a fair degree of investment.  All 3 are showing poor strategic fit, which is not unexpected given the systems? age of greater than fifteen years.
• Vantive particularly differs from PPR and CPC-PRO in regard to its lower strategic fit and increased risk management issues. As a result, and in the timeframe of writing this report, Vantive has been justifiably and successfully decommissioned.

As can be seen, the future of PPR and CPC-PRO are indeterminate. At a minimum, and if they are not to be decommissioned as yet, then investment is required to improve the risk management of these systems for the sake of minimising the likelihood of systems failure. The cost of the risk management may nonetheless make these systems decommissioning candidates in the more immediate term.

Recommendations

Here are the authors 10 recommendations for decommissioning success:

Conclusion

Decommissioning offers many benefits to an organisation which can be both financially tangible and intangible.  It is an essential part of managing ageing systems and a continuous process for ensuring an organisation reduces its costs, minimises complexity and can deliver to market in a timely manner.  However, decommissioning is not always easy and does not come for free. It is not a once-off effort. It is not a quick and easy opportunity to reduce cost. Rather, decommissioning is an ongoing evolutionary process of modernisation that should be an innate capability of any organisation.  Indeed, organisations such as NSW State Records, (2015) understand the multidimensional benefits of decommissioning value include obsolescence in their design processes to ensure a system?s end-of-life is planned and easy.

Lastly, efforts by management and staff to decommission ageing systems should not require an act of heroism. The act of decommissioning should be seen as delivering as much value as turning on new systems and as such should be recognised, rewarded and celebrated for the benefits it delivers.

Acknowledgements

This industry report has been written and reviewed with the help and grateful appreciation from the following people and organisations:

• Colin Fairweather ? CIO, City of Melbourne
• Simon Weller ? Enterprise Architect, City of Melbourne
• Steve Hodgkinson - CIO, Victorian Department of Health & Human Services
• Dr Kerry Hinton and Dr Leith Campbell ? School of Engineering, University of Melbourne
• Matthew Lunn
• David Koetsier

References

DiCaprio, T. 2012, ?Becoming Carbon Neutral ? How Microsoft is striving to become leaner, greener, and more accountable?, Tamara DiCaprio - Microsoft Corporation, June 2012. Available at http://www.microsoftgreen.com/2016/03/28/how-microsoft-is-empowering-a-modern-sustainable-workplace/

DiCaprio, T. 2015, ?Making an Impact with Microsoft?s Carbon Fee?, Tamara DiCaprio - Microsoft Corporation, March 2015. Available at http://download.microsoft.com?/download/0/A/B/0AB2FDD7-BDD9-4E23-AF6B-9417A8691CF5/Microsoft%20Carbon%20Fee%20Impact.pdf

Hormann, P. 2014, ?Data Storage Energy Efficiency in the Zettabyte Era?, Peter Hormann and Dr Leith Campbell - Australian Journal of Telecommunications and the Digital Economy, Vol 2, No 3 - October 2014. Available at http://telsoc.org/ajtde/2014-10-v2-n3/a51

Lambrechts, J. 2014, ?Information Lifecycle Governance (ILG) - Maximise data value, reduce data growth, cost and risk?, Jan Lambrechts - Australian Journal of Telecommunications and the Digital Economy, Vol 2, No 3 - October 2014. Available at http://telsoc.org/ajtde/2014-10-v2-n3

Murphy, P. 2011, ?Application Retirement ? It?s Time to put the Elephant in the Room on a Diet?, Phil Murphy with John Rymer and Sander Rose - Forrester Research, February 2011. Available for purchase at https://www.forrester.com/report/Application+Retirement?+Its+Time+To+Put+The+Elephant+In+The+Room+On+A+Diet/-/E-RES58077

NSW State Records, 2015, ?Decommissioning Systems ? The Benefits?, State Records Department, NSW Government, December 18^th, 2015. Available at https://futureproof.records.nsw.gov.au/decommissioning-systems-the-benefits/

Queensland CIO, 2016, ?ICT Risk Matrix? Queensland Government Chief Information Office. Accessed on November 4^th, 2016 https://www.qgcio.qld.gov.au/products/ict-risk-management/ict-risk-matrix

Wikipedia, 2016, ?Asset Retirement Obligation? ? Wikipedia. Accessed on October 8^th, 2016 https://en.wikipedia.org/wiki/Asset_retirement_obligation