Overcoming technical debt in commerce: How to increase agility in your business with composable commerce

Technical debt is a growing problem that businesses can no longer afford to ignore as the hidden costs of taking shortcuts or using workarounds continue to rise rapidly. Achieving the agility needed to meet ever-evolving customer expectations means that addressing tech debt must be a strategic priority not only for technical teams but also for business leaders. Let’s take a look at the intricacies and nuances of technical debt, particularly in the commerce landscape, and explore how a composable approach helps businesses manage and minimize it. 

Technical debt is the incremental cost and loss of agility to your company due to legacy technologies becoming unfit for purpose. This typically arises when businesses cut corners to save time or money when implementing new systems or maintaining existing ones. It also occurs when systems aren’t integrated correctly or code is overly complex. In other words, when tech debt is rampant, companies become less agile and, as a result, less capable of delivering on new requirements, such as customer demands and security measures, to stay competitive.

Technical debt may not be making headlines — but it certainly should be. After all, the cost of accumulated software technical debt reached USD 1.52 trillion in 2022 in the US alone. CIOs estimate that technical debt amounts to 20 to 40% of the value of their entire technology estate before depreciation. In addition, the average organization spends 23 to 42% of its development time due to technical debt. This amounts to a lot of time in which people are blocked by the status quo and not able to produce new things. Given that technical debt exists in every application, it’s a pervasive issue in every single business across industries and geographies. 

Given the negative impact of technical debt, why aren’t we talking more about it? And why isn’t it a top requirement when analysts and buyers of enterprise software consider technology solutions such as digital commerce? There are three answers to these questions:

#1 No connection or visibility to business value

Technical debt is, rather unsurprisingly, seen as a technical issue. When you see the direct implications of tech debt, you’re looking at typical tech-related problems such as downtime, bugs and developers quitting. That makes it hard to establish a direct link between technology and business value, be it of positive or negative impact. 

There are obvious examples in which the link between tech debt and business value is clear and quantifiable; for example, new features or increased safety measures delivered to customer experiences. A bug or product defect would be a visible outcome of technology impacting business outcomes, albeit with a negative connotation. 

There are, however, other technology elements that are less visible but still crucial in any organization. For instance, architectural elements such as infrastructure and frameworks provide value in the long run, but they’re invisible to business peers and customers. This inherent invisibility makes it challenging to prioritize architecture investments and improvements.

Technical debt is that off-the-balance-sheet cost that hurts the business, such as unproductive spending and inefficient use of developer resources, but remains an invisible element that a vast majority of organizations overlook  — or simply don’t know how to address. Starting to connect the dots between technical debt and business implications, such as reducing agility to meet dynamic customer needs, is the first step to tackling the issue. 

#2 Lack of measurement

Although it’s possible to quantify technical debt, many companies don’t engage in this practice. The lack of documentation makes it difficult for business leaders to understand the negative impact of technical debt and how it affects business goals. 

Without understanding where the problem lies, many executives take shortcuts to address technical debt by, for example, hiring more developers. However, recruiting more tech talent becomes unsustainable over time due to a lack of available workforce and budget constraints. In addition, a mad dash to hire developers and architects increases the need for coordination and team communication, which, in turn, may not necessarily have a positive impact on delivery time for new releases or efficient IT spending. 

#3 Historical investments in technology that is now considered legacy

Technical debt can be traced back to investments in legacy technologies that might be tied to vendor lock-in or internal unwillingness to change. This would undoubtedly require investment, both financially and in terms of time, which many companies aren’t prepared to commit to —  especially in today’s challenging economic climate. 

The consequences of technical debt in digital commerce are far-reaching, as the lion’s share of present-day businesses continue to rely on legacy systems born during the dot-com bubble of the 1990s. These systems are characterized as monolithic applications, which are built as an indivisible unit that is rigid and slow to update. This means even minor code changes require refactoring the entire software stack, leading to downtime and lost business. 

Moreover, it ties developers to bug-fixing and maintenance tasks instead of doing their actual jobs: Developing and deploying game-changing features. Plus, legacy systems require significant ongoing maintenance and (forced) upgrades, which are costly, time-consuming and risky. This diverts resources away from strategic initiatives and limits the ability to innovate. In other words, businesses experience reduced agility and have less wiggle room to update and adapt their infrastructure, invariably accruing tech debt over time. 

Evidently, high technical debt hampers a business’ agility needed to meet customer expectations and deliver business value. And, considering how important agility is to remain competitive in an increasingly omnichannel, mobile-driven, global and dynamic marketplace, it’s time for businesses to tackle technical debt head-on. 

After all, if you could reallocate your existing budget so that more of your spending goes toward meeting the needs of the business, refining the customer experience and adapting quickly to market opportunities, how would that impact your ability to achieve critical business objectives? That’s what you can achieve with composable commerce: 

• Because a composable approach is made of flexible and interchangeable components that run in the cloud, it’s much easier for businesses to replace specific components. That means it’s easier to keep the tech stack agile and adaptable to meet constantly changing business needs. 

• Composability also leverages a multi-tenant and versionless architecture, so you don’t need to worry about maintenance or upgrades, minimizing work that leads to tech debt. 

• The ability to extend and customize features empowers your business to innovate on top of a commerce platform. This ensures adaptability to evolving business needs, which helps minimize technical debt significantly.

Technical debt is frequently underprioritized, inadequately managed and allowed to escalate to an unsustainable level. Technology leaders often encounter difficulty in securing support from business peers for initiatives aimed at addressing these challenges. That snowballs into bigger and deeper problems as time goes by, affecting a company’s ability to serve customer needs and grow. That’s why tackling tech debt requires actionable steps throughout your organization, which include:

• Define tech debt in the context of your organization. While we presented Gartner’s definition of tech debt, it’s important that you define what tech debt is in the scope of your business, and have that as the guiding North Star across business and technology peers. 

• Treat tech debt as a business issue. Leaders must translate what technical debt means into business implications and treat it as such. 

• Get internal buy-in and set up a business/technology collaboration. Addressing tech debt strategically requires that business and technology teams have common goals and work together to achieve them.    

• Dedicate resources. Reducing tech debt requires effort, energy and, yes, money. Mobilize the people, time and budget needed to kickstart the process. 

• Assess and prioritize tech debt items. Understand that not all technical debt is a priority or created equal. For instance, security-related tech debt trumps solution usability and therefore should be prioritized in your organization. Plus, even if your business added tech debt for the sake of speed and innovation, it should be actively managed by, for example, putting it on a strategic roadmap for mitigation in the upcoming quarters. 

• Apply a methodical approach. There are different ways and methods to tackle tech debt, one of them being Gartner’s “plan, address, ignore and delay” PAID model to target high-impact and high-probability items for tech debt remediation. 

• Start small and incrementally. Handling tech debt is a process. Creating IT megaprojects via a big-bang approach poses a high execution risk as priorities and budgets often change. Instead, consider bite-sized, predictable increments that deliver constant improvements and value. This can include, though not limited to, migrating from legacy to composable architecture.   

Adhering to these principles can help your company formulate a strategy to address technical debt within a few weeks, with implementation starting shortly thereafter. Consider integrating tech debt metrics, such as including them in financial models, tools, and databases throughout the business.

As mentioned earlier, we believe that considering technical debt as part of your vendor evaluation process for digital commerce makes perfect sense. Why? Because you can assess how much technical debt you’re inheriting from your technology provider. There are four questions you should ask in the evaluation process: 

1. Does the technology provider have a reliable roadmap of innovations and product enhancements that will benefit you? 

If the answer is no, the vendor has likely accumulated too much technical debt to prioritize innovation and product enhancements. That means the evolution of the market and customer expectations will quickly outpace the vendor’s capabilities. 

2. What are the quality standards of their code? 

Go deeper into the vendor’s software to understand their quality standards on code and the architecture side. In addition, assess the vendor’s readiness for refactoring, which is a key for modifications to overcome debt. And finally, evaluate if they support fully automated test cases to manage those incremental changes. 

3. How does the vendor manage technical debt? 

Ask the vendor how they formally categorize technical debt, how they handle it, and how much of their R&D budget they use to pay down that debt. See their product beyond shiny demos to understand if they're backed with tech debt-laden product coding or not. 

4. Does the technology provider enable your business to innovate without limitations? 

Every business selecting a digital commerce platform is likely to customize and extend features to create unique customer experiences. If the vendor doesn’t enable your business to innovate on top of its platform, the technology gets outdated very quickly, and you don’t have a way around to mitigate that technical debt that will invariably increase. 

In other words, when considering a potential migration to composable commerce, it’s vital to understand the ability of potential vendors to innovate and evolve, especially in the context of tech debt. 

A technology solution may take shortcuts, workarounds or even rewriting code to deliver something of value at speed for your business. It happens quite often, actually. But what shouldn’t happen is when your business is trapped in a commerce solution plagued with tech debt, such as in the case of legacy, monolithic platforms. As a result, your vendor’s tech debt becomes yours, which makes it a lot harder to manage it, let alone minimize it.  

At commercetools, we have evolved our architecture over the years and have had our fair share of shortcuts that led to our own internal tech debt. However, with a composable infrastructure under the hood, it’s possible to manage it to a point where it doesn’t affect our ability to evolve our infrastructure and deliver value to our customers. In fact, commercetools delivers over 200 releases and 13,000 deployments each year, including commercetools Foundry for B2B and B2C, commercetools availability on Microsoft Azure, B2B-specific capabilities, and so much more.

At the same time, our customers can extend our features and APIs according to their needs. Not only does this enable businesses to stay competitive but also to manage their tech debt, as they can quite literally add, customize, replace or even drop functionalities as they see fit. Reducing tech debt is a direct result of having such a flexible and extensible infrastructure. 

In conclusion, a composable architecture gives you the ability not only to keep tech debt under control but also gives you free rein to deliver the agility needed as a way to boost customer and business value. 

Are you ready to combat tech debt while innovating more? Download our white paper Composable Commerce for Business Leaders and learn how.