Turning High Technical Debt Into Low Cost

Planning for the long run may seem like sound wisdom. But in the fast-paced tech world, the long run feels like a day that never comes. New technologies or digital experiences always attract managers looking for an operational advantage. The discussion often turns to replacing a current system in their organization.

In many instances, managers often have to confront technical debt before the new technology is adopted. Technical debt is the cost of accepted tradeoffs of maintaining current systems to achieve an immediate launch or budget target. The debt arises from a number of instances, from a programming decision from a software engineering project or from a cost-saving decision to delay upgrades for an outdated system. In app development, for example, launching a simpler version of the product to ship quickly leads to the omitted features, creating a technical debt that must be addressed when the new features are added. Sometimes technical debt “feels” like a cost-saving move when compared to the technically better choice long term.

Technical debt is a rising topic among managers because the number of potential root causes from launching an enterprise solution are growing. Companies are adopting machine learning, AI, and cloud solutions to replace many outdated systems that currently manage services and processes. The technical debt associated with older systems is revealed as hidden operational costs that have grown over time and must be addressed.

The Rise of ‘Data Debt’

Many tech transformations are being influenced by data management decisions as much as they are by software design choices. Take data privacy regulation. Data retention within systems must be identified to meet privacy compliance requirements. Data management must highlight how compliance is being observed.

In fact, a variant of technical debt has emerged among IT professionals -- data debt. Data debt is a buildup of data management tradeoffs.  Data debt usually occurs wherever data undergird operations, such as quality control or threat intelligence for cybersecurity. Like technical debt, data debt happens with delayed investment in maintaining or managing digital assets -- in this instance, operational data.

Data debt creates a familiar yet distinct difference in tradeoffs compared to those in instances of technical debt.  Whiletechnical debt is more of an umbrella term addressing the technologies used to deliver a product and service, data debt is anumbrella term addressing data touchpoints, such as silos, duplication of observations, and inconsistencies from sources.  The rise of machine learning, along with the current high-profile adoption of AI, makes the potential risks from poorly invested data management more complex to avoid.

IT managers will see more data debt issues as investment in AI rises. Open-source large language models (LLMs) such as the LangChain framework and Meta’s newly launched Llama2 introduces the capacity to create AI models and applications with fewer parameters and, consequently, smaller model size than the training model behind ChatGPT. Open source LLM offer more manageable AI development for AI-enhanced apps that operate with your proprietary data. It allows more transparency over train and test data, removing reliance on data access from third-party servers and APIs that can alter and disrupt model performance.

Managing an internal AI platform also shifts challenges from using data. Many LLMs are developed using vectorstores, a data storage medium for indexing unstructured data and documents. Vector stores hold under for embedded data -- a dataset created from the unstructured data using LLM. Vectorstores are designed specifically to ease document access for training and testing models. But an enterprise planning a model may be using documentation stored on older mediums. Thus, advanced development often reveals data debt situations for data being accessed from older data storage.  

How to Minimize Technical Debt

How can IT teams best approach the minimization of technical debt in their respective organization? 

One key step to take is to first establish a means of reviewing technology with stakeholders. This can mean a standing review meeting to gather an overview of current tech, its operational status, and any potential plans for upgrade, update, or replacement. Doing so sets up documentation of policy, conventions, and processes across the organization and enhances a shared understanding of how to spot opportunities to reduce technical debt over time.

Use the review meetings to highlight when code maintenance was last conducted on critical software systems. Many of these briefings trigger an audit of data management associated with refactoring code, rewriting the code, or gradually improving the code over time. An audit is an opportunity to gather background information regarding the last review of data in a tech stack or algorithmic process. Once gathered, the team can establish policies, conventions, and processes that can best reduce debt or quickly eliminate other technical obstacles.

In examining tech, the review team must identify which processes consume (or waste) the most time. This helps teams identify potential bottlenecks before they happen and plan accordingly.

When engineering new features into a software or data model, look for technical debt conditions. Building and implementing those features may require you to resolve some of that debt.

The selection of features can also impact decisions about using historical data, questioning if the data is really necessary. One question teams can ask themselves is this: What information has changed since the decision to use the data was made? Almost everything associated with technology changes, from features to user behavior, so some older decisions may not be as valuable today as they were when they were made.

Teams can then ask if stakeholder access to data history makes sense. How far back does regular access need to be -- six months? A year? Three years? The answers can then turn to the methods and tools that are often used among analysts and stakeholders. Some tools and data storage may really need an update, while others may still be useful with minor feature and plugin upgrades.

A few historical key metrics shown in Excel or Google Sheet may really be enough for some analysts and managers. In other instances, a Markdown document containing R and Python code would provision updated metrics provided through an API. A savvy tool choice can uncover other technical debt and data debt gaps associated with usage throughout an enterprise.

Addressing technical debt is more essential these days. Besides the increased opportunities for technical debt to occur, seeking the right skills to find operational efficiencies and implement decisions can be a challenge.     

The imperative to reduce technical debt will remain front and center for many IT teams and CIOs in the near future. Recent high-profile layoffs in the tech industry combined with “The Great Resignation” has left corporate teams feeling shorthanded to handle any tasks, let alone technical debt reduction projects.

But no matter the source, size, and impact, IT teams must manage and reduce the technical debt they encounter. With a high commitment level to seek best practices and solutions, teams can become technology leaders with measured steps that reduce the influence of technical debt on changing tech stacks behind the most critical use cases. The result is solid technology decisions that make businesses more cost effective in the long run.

What to Read Next:

Reimagining the Technology Deficit

CIOs: Stop Spending on Bad Tech

CIO Lessons Learned from Southwest Airlines’ Winter Plight