What is Technical Debt?

If you read 30 web sites to get the definition of technical debt you will end up with 30 different definitions. One common theme though is that of avoidable cost – whether that cost is a direct financial impact, a drain on peoples’ time or risks to the company from cyber security or data loss. For applications technical debt begins when there is insufficient investment in production applications leading their hardware or software to age and increases greatly when older applications are decommissioned (dormant, read only) but not retired (software deleted and hardware repurposed, sold or destroyed).

How (Not) to Remodel a Kitchen

An analogy we use to describe how technical debt is increased by the decommissioning of old applications is that of installing a new kitchen. Like the implementation of a new application the installation of a new kitchen will include a concept phase (are we doing it, can we afford it?), a design phase (choosing appliances, counters, floors, cabinets), a construction phase, an acceptance review and finally usage. The outcome is a brand new, sleek, efficient kitchen (or application).

As part of the concept phase for a new kitchen is also the selection of a company to do the work based on their quotes and designs. In the case of a kitchen remodeling it is fully expected that the company’s price would include the not only of demolishing the old kitchen but also of the removal of the debris and old applications. It certainly isn’t expected that the rubble, old appliances and old cabinets are left on the lawn until some point in the future when you have the time and additional money to complete the clean it all up.

This is effectively how we have managed many decommissioned applications for years, keeping them hanging around in the production landscape and not cleanly disposing of them. And in many cases we are keeping the old appliances plugged in because we still have to use them on occasions.

The Components of Technical Debt for Applications

For applications technical debt falls into four main categories:

• Cost
• Risk
• People’s Time
• Knowledge of Application

The cost component is the easiest to evaluate. There are many aspects that can be immediately evaluated such as payments to the software vendor and internal IT support costs. The hardware costs for dedicated servers can be determined, but for shared servers the savings often only occur when the last application on the server is retired. Also decommissioned applications are still operating in the production landscape, so have to be patched for security vulnerabilities.

There are many risk elements with decommissioned applications, but the largest are security risks from obsolete operating systems and the potential for hardware failure leading to data loss or the loss of the original applications.

Harder to quantify but still real is the time and effort that decommissioned applications take from people across the company. Meetings and email chains discussing decommissioned applications, their schedule for retirement, security concerns and how to address them are distracting people’s time and attention from their core function. Vulnerability scans, compliance variance reports and remediation activities are often necessary. Even the time you are spending reading this post wouldn’t be needed if we didn’t have the concerns regarding these decommissioned applications.

Finally but also important is the incremental loss of knowledge of an application over time. At the time an application is decommissioned there will be multiple people in the business and IT that understand the application in detail, how to access data, what information is contained and for which countries/companies and what reports are needed. Once an application is no longer used that information degrades quickly both due to people leaving the company or simply less recollection due to the passage of time. Significant information is necessary to successfully archive an application and ensuring that the archived data is usable over time, and the cost of doing so increases as the availability of knowledgeable people decreases.

Avoiding Unneccesary Technical Debt

So what can be done better in the future to avoid technical debt?

As highlighted in the kitchen analogy a key point is that the planning and budgeting of a new application implementation must include the cost of removing the old application in a timely fashion. Too often business cases don’t cover the end of life costs nor are resources assigned to complete the work. This leads to the decommissioning and retirement getting postponed and prevents the quick reduction of technical debt and the associated costs.

Even once funding is allocated it is critically important that the decommissioning and retirement is part of the initial project planning. Depending on the specific needs of the project it is often possible to use data management strategies it is possible to maximize the elimination of the technical debt, but even when this isn’t possible careful planning can front load the savings.

As IT Garbagemen we have experience in planning the rapid elimination of technical debt and can work with project teams to bake that into the planning for the new application’s implementation.

Addressing Technical Debt (Clearing Up the Yard!)

When dealing with a backlog of decommissioned applications or multiple retirement candidates a prioritization mechanism to help identify the relative technical debt for each application is necessary. Applications are selected for archiving and retirement based on:

• Relative technical debt
• Timing of the application’s retirement
• Availability of business and IT subject matter experts to support the archiving
• Confirmation that the application is no longer actively used (even decommissioned applications may still be being used in read only mode)