How Organizations Can Reduce Technical Debt
Technical debt is what happens when software engineering teams take shortcuts to developing projects and, in turn, create more work for themselves because they took the least optimal solution or approach in the long-run.
How can organizations reduce technical debt? Before we answer this question, let us take a step back and dig deeper into how technical debt arises.
Let us imagine a software development team, which has limited resources. They resort to taking a shortcut (e.g. point-to-point integration) to complete a project. They quickly achieve their short-term goals of delivering the project on-time and meeting the needs of the business. Sounds great, right? No, on the contrary, the team is creating technical debt in the long-term.
Now that we have established the meaning of technical debt and its negative impacts, how can organizations reduce technical debt?
In order to reduce technical debt, organizations must first identify the source(s) of the debt and its causes. There are a number of factors that can lead to technical debt, including
- constrained resources
- limited time
- lack of incentive to focus on long-term negative impacts
After identifying the source of technical debt, organizations can reduce it by adjusting their technological approaches and organizational mindset. Organizations must ask themselves: Are teams using short-sighted approaches, such as point-to-point integration, to complete projects? Are teams tackling business needs on a project-by-project basis without thinking about how they (or other teams) can leverage their current work for future projects? If the answer to these questions is “no,” this presents a prime opportunity to reduce technical debt.
A company’s journey to reducing technical debt
In order to illustrate how to reduce technical debt, imagine a finance company with an IT team of 300 people. For an upcoming project, this team must replace 2 legacy systems and then connect them to an SAP database, a SaaS application, an ERP system.
In the short-term, the team delivers this integration project on-time and within budget using a shortcut – point-to-point integration – in which they create one-to-one connections between all of the systems and applications. They complete the project and the business is happy with the results; the team then moves on.
Six months later, the business comes to IT with another project: rip and replace the two legacy systems and add a new SaaS application. By this time, the head of the same project has left the company. New members do not have visibility into what is happening under the hood.
Due to the point-to-point integration shortcuts, the architecture of the project now looks like spaghetti code, making it difficult for the team to quickly rip and replace the legacy systems and connect them to the SaaS applications.
This is a warning sign that this company needs to reduce technical debt.
The proliferation of endpoints makes it difficult for the team to estimate the amount of time and effort it will take to complete the project and, most importantly, the impact of the changes they will make. They have incurred technical debt and must add extra work to their deliverables to complete the new project on-time and on budget.
It’s now time for the team to take a step back and recognizes that previous shortcuts necessitate a new approach to reduce technical debt.
Step 1: Identify the source of the issue to reduce technical debt
The team agrees that they need to reduce technical debt. They set out to identify its source. After analyzing the source of the technical debt through interviews and surveys with team members , the team finds that one of the major drivers of technical debt is the lack of time.
IT team members, faced with strict deadlines, resort to custom coding point-to-point integrations in order to deliver projects to the business quickly. Although the team recognizes that point-to-point integration is a short-sighted approach, they justify it because of these time pressures––creating more technical debt.
Through this step, the IT team correctly identified the source of the issue – time – and completed the first step to reducing technical debt, they can now move on to step 2.
Step 2: Adopt a new technology approach to reduce technical debt
The team already knows that custom point-to-point integration is the source of the issue. In order to reduce technical debt, they must adopt a new approach to integration that facilitates long-term thinking. An approach that drives teams to think about not only delivering projects on-time in the short-term, but also building a long-term vision for future projects.
How can some of the code or assets for current projects be used for future projects or other teams? In other words, how can they drive reusability across the organization to address time constraints and push teams away from short-sighted approaches, such as point-to-point integration?
To answer these questions and reduce technical debt, the team turns to API-led connectivity––a methodical way to connect data, devices, systems, and applications through reusable and purposeful APIs. With this approach, rather than connecting things point-to-point, every asset becomes a managed, modern API that is discoverable through self-service and controlled through governance.
The APIs behind these assets are all developed to play a specific role, whether it is unlocking data from systems (System APIs), composing data into processes (Process APIs), or delivering an experience to users (Experience APIs). Through these APIs, organizations can make their assets discoverable and available for the business to self-serve.
API-led connectivity allows organizations to drive their vision for reusability. IT teams can quickly compose, recompose, and adapt these APIs to address business needs, which, in turn, allows them to reduce technical debt because teams will not resort to custom code shortcuts.
To illustrate the power of API-led connectivity in reducing technical debt, let us refer back to the finance company example. For their first project, instead of replacing the 2 legacy systems and connecting them to a SaaS application through point-to-point integration, they can simply implement API-led connectivity through unlock these key systems with APIs.
This allows teams to make a step change in reducing technical debt. So that, three years later, when the team needs to replace their 2 legacy systems again, they can simply unlock those two systems through System APIs and easily connect them to their existing stack.
Step 3: Alter the organizational mindset to reduce technical debt
We know that API-led connectivity depends on System, Process, and Experience reusable APIs, which are used to compose new services and capabilities, and, most importantly, allow teams decentralizes and democratizes access to enterprise data.
In order to better implement API-led connectivity, teams need to alter their organizational mindset to fit the approach. This can be done through adopting a Center for Enablement, or C4E.
A C4E is an approach that allows organizations to transform their IT teams from its traditional function as a sole technology provider to a strategic business enabler. In this case, the Central IT team at this finance company will be charged with producing reusable assets and unlocking key systems, including legacy systems, SaaS applications, and more through System APIs.
Then, Central IT and other teams can reuse these API assets to compose process level information, or Process APIs, from these systems. And, finally, app developers can then self-serve and discover these reusable assets in order to build an experience for their users through Experience APIs. In other words, app developers will create the end applications.
Reducing technical debt is possible
Through the three steps above, organizations can reduce technical debt by first identifying its main source. And then, equipped with an API-led approach to integration and a Center for Enablement, teams will have the necessary tools to tackle resource and time constraints through reusability, discoverability, and self-service––allowing them to take the right steps to reduce technical debt.