We often hear that ‘change is the only constant’. This is certainly true in the world of software development. New products constantly come on stream and managers must make decisions on which of these to implement. Often they simply wait. The result can be ‘technical debt’. The purpose of this article is to explain the concept of technical debt. We will also look at how IBM i modernization can assist in dealing with it.
Table of Contents
What is Technical Debt?
Let’s begin with a definition: Technical debt is the cost to the organization that builds up when important applications, infrastructure, and systems are not updated at optimal times. As systems get older, it costs more and more to update them. Businesses in technical debt also face increased risks, including security vulnerabilities and a lack of competitiveness. Fortunately, IBM i modernization is a cost effective and efficient strategy for dealing with the challenges posed by technical debt.
Why Does Technical Debt Occur?
Here are some of the main reasons behind technical debt:
Time pressures: It is often too easy to just use what we are used to. Especially because investigating new solution can be time consuming in itself.
Overly complex system design: It can be challenging to update very intricate systems. Yet, many developers opt for complex designs, often at the request of special interest groups within the company. Hence, technical debt can sometimes be imposed from outside the developer team.
Disregarding of standards: Many companies have strong policies in place to ensure that IT assets are at least somewhat future-proof. Unfortunately these can all too easily be ignored sometimes.
Lack of developer skill: Some developers can be very unsure about whether they will be able to effectively use new systems. This can easily turn them into activists for hanging on to legacy code and applications.
Insufficient testing and onboarding: Very often development teams only scratch the surface of what certain products can contribute. That means that all functionalities are not tested and developers are not trained to be optimally productive.
What Are Some of the Consequences of Technical Debt?
As with financial debt, it is a very bad idea to ignore technical debt in the hope that it will simply go away. It won’t. Instead it can lead to significant negative outcomes. Including the following:
- Technical debt can make it harder to come up with new ideas and put them into action. When you put time and money into fixing something old, it’s hard to try something new.
- It can be harder to respond to threats from competitors when you have technical debt. Your technical debt limits how quickly you can change and adapt to stay competitive.
- Technical debt can make it difficult to find the right people for projects. It can be hard to find developers who are willing to work with older technologies when they can work for your competitors on cutting-edge technologies.
Over the next few sections we will look at how we can effectively deal with technical debt.
Step #1 – Acknowledge the Issue
The first step in dealing with technical debt, is to acknowledge the issue and to draw up a workable roadmap for getting back in the clear.
This can be challenging in some settings as managers will often baulk at what they believe will be significant cost blowouts. However, as we shall see, technical debt reduction need not break the bank. Especially, if it is done on the back of a well thought out IBM i modernization program.
Step #2 – Identify Signs of Indebtedness
An effective response is only possible if we are totally clear what we are responding to. It is, therefore, important to accurately measure the current state of indebtedness.
Measurement can include gauging how long it is taking tasks, how much remedial work is necessary and how much developer time is spent on keeping systems running. This should then be compared to what would have been possible in a modernized setting.
Accurate measurement can be difficult, and even painful, exercise. However, it is important that this step is done honestly so that any later actions are based on accurate information.
Step #3 – Set Priorities
A key outcome of the assessment process will be to indicate where the most pressing needs are. This will typically be the contexts in which you are losing the most money or where efficiency is most impacted.
A plan to ‘pay down’ technical debt should, obviously, ensure that the most pressing needs are dealt with first. Getting these on a list of priorities is a good step towards ensuring that technical debt is addressed in the most efficient and cost effective manner.
It is important to remember that setting priorities involves long term thinking. This means that we do not simply respond to what seems most urgent at the moment (the proverbial squeaky wheel). Instead we should take care to focus interventions in areas where they will make the most long term difference.
One way to ensure that priorities reflect long-term thinking is to ensure that people from across the enterprise are involved in setting the agenda.
Step #4 – Find Solutions
It is important to remember that there are probably many different ways of dealing with the particular combination of technical debts that you are dealing with.
In situations where you have a problem to solve it can be all to easy to simply reach for the ‘latest thing’. However, feverishly trying to stay on the cutting edge can sometimes have the perverse effect of entrenching technical debt even more. Yes, in some cases products may be necessary but this is not always the case.
In this instance, creative problem solving may involve finding ways to bring existing products or repurposing them. This is where IBM i modernization be a very valuable strategy (as will be explained below).
Step #5 – Plan to Remain ‘Debt Free’
Most of us are very aware of the perils of the ‘debt cycles’ where people, or companies, move in and out of debt, despite their best efforts to remain debt free. Any debt reduction strategy must, therefore, contain clear thinking about remaining debt free.
In the world of information technology the keys to remaining ‘debt free’ is to schedule regular reviews and testing. This will ensure that products are working as they should and will help in identifying areas where current configurations are falling behind.
How Can IBM i Modernization Help?
A significant proportion of the modern economy runs on aging IBM i infrastructure. This can be described as a massive instance of technical debt.
It may seem like the solution to this situation might be to ‘rip it all out’ and starting over. However, this approach brings the risk of cost-blowouts, relying on untested technologies and business disruption. It should also be remembered that constantly upgrading to unfamiliar products can impose a significant learning curve on developers, which is a kind of technical debt in itself.
The basic premise behind IBM i modernization is to bring IBM i assets ‘into the modern world’ by retaining their strengths and adding modern functionalities.
One might say that IBM i modernization involves a best-of-both-worlds approach. It can help companies to hang on to what is best about their current assets and making sure that it can deal with the latest technical demands.
The best modernization strategies will focus on delivering upgrades in a user-friendly way that will not be reliant on deep technical knowledge or superior coding ability. In fact, for a an upgrading strategy to be successful, it should major on bringing controls and interfaces into environments that modern developers are most comfortable with.
It should be obvious that there could be significant cost benefit associated with making use of IBM i modernization. It also has the advantage of keeping disruption to a minimum (since you will still be relying on the same underlying infrastructure). This is obviously invaluable from a business continuity perspective.
Ready to get started taking care of technical debt?
While paying of technical debt may seem like a daunting prospect, there are ways to ease the pain. A tried an tested method is through the use of IBM i modernization. This is where LANSA comes in.
Over the years LANSA developed a suite of resources that can take much of the pain out IBM i modernization. This includes the ability to bring legacy applications into new web and app based environments. LANSA products have been designed with ease-of-use in mind. A key feature is the fact that LANSA prides itself on making low-code solutions available. This means that developers can be brought up to speed very quickly and can do updating tasks without having to write complex code.
We would like to strongly encourage you to check out how LANSA can help your company pay down technical debt through IBM I modernization. You can start the journey by going to https://lansa.com