Technical Debt and Cloud Adoption

Managing technical debt is a growing problem among many CIOs. Often forgotten about and hardly addressed, technical debt can accumulate over time to become a major issue for businesses. Adopting cloud is seen as the answer to paying off that technical debt. But, it’s not quite that simple.

What does the term ‘technical debt’ mean?

Technical debt arises when companies fail to invest in the normal maintenance of their IT systems (applications or infrastructure systems) over the years. This eventually becomes a cost for these companies, and they have to remediate by investing heavily in large projects to catch up and stay up to date. Companies often don’t like to invest in areas that do not directly impact their business goals. The maintenance tasks considered not important or urgent get neglected because the focus is placed on the areas of high value to the business. Cumulated years of neglect can lead to organizations being in unusually complex technical debt situations.

While certain types of technical debt can remain low priority issues for a long time, it becomes a problem when the business asks for new functionalities in applications that cannot be delivered in the existing old systems. Organizations can suddenly find themselves in a position where they have to upgrade everything immediately. they have to create a large project or programme to bring everything to a new standard in record time — an impossible feat. 

Technical debt risks will increasingly come up on company risk registers: In highly regulated industries with enhanced security risks, or even risks associated with regular compliance, businesses can be labeled non-compliant due to poor technical debt management. Furthermore, many companies in these industries have many different applications and a lot of integration requirements. In these cases, isolated large-scale upgrade programmes should be avoided. These large programs become a significant one-off cost and are more expensive than maintaining systems regularly. Not only it is a financially costly procedure, but it places a strong strain on a company’s limited resources.

Ideally, IT want all their manpower spending all their time on developing new functionalities and, more generally, on value creation for the business. However, to remediate technical debt in order to meet strategic goals or to reduce levels of risk, these resources are taken out of value-driving projects and placed into maintenance projects.

This is what organisations are forced to do, but it is what they shouldn’t do. What they should really be doing is to make this part of the company’s regular maintenance program. They should have an investment program that is governed on a yearly basis; ideally per business unit, per application, where it is part of the regular maintenance.

Enablers of effective management of technical debt

The biggest pain of technical debt is not being able to perform actions that can improve a company’s strategic position. In order to avoid costly, resource-straining, bulky technical debt remediation programmes, there are new technologies, tools and ways of working that can be harnessed to be able to aim to retire technical debt.

• Cloud is supposed to take care of the problem of technical debt. The problem of replacing hardware vanishes because the cloud is built in such a way that it is upgraded regularly, without looking at the infrastructure underneath it
• DevOps and agile: In a cloud native IT department working in a DevOps way, the person who creates the code, creates and develops the application also takes care of the technical debt. Granularity of ownership helps to pay back technical debt; as operations are handled by the developers, the problem is managed proactively
• New ways of working: By getting closer to IT, the business is participating in the progressive technical upgrade and will understand that regular maintenance and expenditures are a part of business

First steps to manage Technical Debt

1. Create a risk assessment framework
   One of the mandatory first steps is to create an effective risk assessment framework that will be used to look at the IT landscape, with infrastructure and applications, to monitor what is out of date and what is not. Today, the best approach is to perform this at an application-level downwards. That is, looking at the application portfolio and the stack underneath it, up to the infrastructure to identify risks at any level. The risk can exist at the application layer itself, at the operating system level or in the machine.
   This exercise is particularly hard but critical for integrated systems is to figure out the dependencies between applications that are all rather dependent on each other. With the risk assessment framework comes the risk analysis and the prioritisation of activities.
2. Secure funding
   The risk assessment should come with a business case associated with the prioritisation of investments. Companies who have accumulated a lot of technical debt need to set up a programme to invest in.
   When technical debt is managed in a gradual way, the steps to follow are less rigid, although sometimes this is not possible if severity is too high.

Conclusion
Wavestone has a toolset that analyzes both the infrastructure pieces and the applications in one go. This gives our clients a view in terms of risk, and available transformation budgets. Another aspect that many of our clients are really interested in is the identification of quick-wins. This answers the question of “what applications can I easily re-host part into the modern landscape?”

Our framework comprises of analysis and development of the business case, which includes the investments required to empower our client with a global, all-rounded view of their technical debt and how to manage it. Often, clients struggle pushing such a program internally, where our consultants, many with an extensive background in infrastructure and application aspects, can effectively push these ideas and this prioritization within the organization..