The Implications of Technical Debt to Your Company’s Competitiveness

Technical debt can be a formidable barrier to sustaining competitiveness in the digital age. Everyone knows that agility and resilience are strategic imperatives for long-established incumbents exposed to “born digital” players with architecture built optimally from the ground up.

As the half-life of business models continues to compress, responding to these market entrants becomes a challenge for those organizations with layers upon layers of architecture accumulated over decades. As wave after wave of agile solutions hits the streets to address pressing market needs, this struggle is akin to trying to turn a battleship as if it were a speedboat.

With the need for adaptability, flexibility, scalability and security, this matter has moved beyond an IT discussion to a broader business imperative that directors and executives need to understand and address. It’s just a question of whether or not the enterprise can up its game in a timely manner in order to compete and thrive, given the realities of the digital age.

The Nature of Technical Debt

Exercise, healthy diet and relaxation are keys to good health. If these keys are neglected in favor of matters that may, at the time, appear to be more pressing, one may experience challenges with age. In a similar manner, technical debt accrues as developers take shortcuts, accept assumptions and make other day-to-day tradeoff decisions, resulting in the need for reworking or restructuring the computer code (called “refactoring”) of existing technology solutions without altering the solutions’ external behavior. As we discuss later, this is not necessarily a bad thing, but the sheer magnitude of refactoring can get to the point where it can be overwhelming if not addressed over time.

The term “technical debt” refers to the cost and magnitude of additional rework caused by choosing technology solutions that are easier to implement over the short term instead of the best overall solution for the long run. As these decisions are made, and as technology evolves over time, the cumulative effect of layers upon layers of code and architectural approaches positioned upon each other can result in an amount of technical debt that stifles the ability to innovate and compete.

Technical debt becomes a significant issue as the Agile developers of today focus relentlessly on delivering software quickly to enrich customer experiences, digitize products and services, inform decision-making and improve operational performance. Agile necessitates management support for refactoring to avoid the further accumulation of technical debt; otherwise, developers are prone to over-architect or over-code software. The point is that adopting Agile without a commitment to refactoring is a recipe for disaster. It bogs down systems, delays product launches, creates instability and wastes money — not the ideal way to compete in an environment that places a premium on speed.^[1]

The question arises: Why should executive management and boards of directors care? In an environment dominated by emerging technologies, disruption of business models and a critical need for resiliency, technical debt can slow an organization’s ability to respond to emerging market opportunities and demands. It is often likened to monetary debt in the sense that if it is not addressed, it can accumulate “interest” over time in the form of the extra effort required in future development to address prior design choices. Most important, as technology evolves, “repaying” the debt becomes harder and more expensive. Therefore, in a rapidly advancing technological environment, kicking the proverbial can down the road accrues additional cost.

Not all technical debt is bad. There are times when it is incurred with purpose to bring a product to market or respond to an emerging opportunity or risk more quickly. For example, a company may make a conscious decision to take on debt for a specific business outcome, such as realizing speed to market, with an action plan to “pay it back” later. Another example would be a short-term decision to quickly patch up a piece of code to release a product and fix it immediately after release.^[2]

But technical debt can become a serious issue if technology isn’t refreshed or if “shortcuts” undertaken are not subsequently addressed. All too often, the work to reduce technical debt is delayed in deference to competing priorities. That’s where the problem becomes worse, as these decisions can cause technical debt to accumulate further over time. Left unchecked, this debt grows slowly and insidiously until it becomes the proverbial ball and chain that can prevent an organization from keeping pace with its nimbler rivals.

The Archaeology of Legacy Technology

In many organizations, particularly longstanding enterprises, mapping the technology that supports mission-critical operations can be likened to an archaeology dig — one that exposes the kind of technical debt that can put an organization at serious risk.

On the surface, the shiniest, newest technology supporting websites, mobile solutions and advanced analytics may exist, but dig below the surface, and you’re likely to find layer upon layer of highly interdependent, complex systems, some dating back four decades or more. To illustrate, 92 of the top 100 banks, along with 71 percent of Fortune 500 companies, still rely on mainframe technology for much of their core processing,^[3] and Reuters estimates that $3 trillion in daily commerce flows through core banking systems that run on those mainframes.^[4] Most of these systems, made up of an estimated 220 billion lines of code, are written in COBOL, a programming language that was developed more than 60 years ago; in fact, 95 percent of ATM transactions are made possible by COBOL code.^[5]

In most cases, these platforms reliably perform the functions that they were designed to support, but dependence on this aging technology presents several risks. Among them is the dependence on an aging and shrinking workforce with the knowledge and skills to support this technology. Much of this workforce is nearing retirement, and almost all of the training and education available today is focused on more modern technologies.

The Tip of the Iceberg

Unfortunately, it gets worse. The complex, monolithic design of these aging systems and platforms and the processes that support them are not well-suited to the fast-paced, agile nature of today’s digital world. As a result, organizations dependent on them often find it difficult to respond to market opportunities or risks or to adopt emerging technological capabilities in a timely manner. In some cases, the platforms and their complex integrations also create security risks and challenges in responding to regulatory compliance demands.

Mainframes and COBOL are certainly not the only forms of technology debt. It can exist in the form of outdated versions of databases and operating systems that can result in systems that are no longer supported by vendors and may be exposed to security vulnerabilities. Applications that have not received vendor upgrades may suffer from a lack of critical functionality or reduced stability. Hardware that has not been refreshed may be vulnerable to increased likelihood of failure. The very architecture that defines the environment can also represent technical debt in the form of siloed, duplicative or fragile solutions. Each of these situations adds more to the debt that the organization has incurred.

On top of all these risks is a significant economic impact as well. Gartner reports that typical organizations spend more than 70 percent of their IT budget simply operating their technology platforms — as high as 77 percent in some industries — leaving precious little budget for enhancements and innovation. And that problem appears to be growing: The percentage of operating costs has grown from 67 percent in 2013 to 71 percent in 2017, while IT spend dedicated to transforming the organization has shrunk from 13 percent to 10 percent during that same period. While this may not be fully attributed to technical debt, a correlation is not hard to draw. Not surprisingly, the more technology debt that exists in an organization, the more acute these problems become — the heavier the ball and chain.^[6]

Paying the Piper

Why not just upgrade replace or even abandon these aging systems and wipe out the technical debt altogether? If only it were that easy.

The decision to invest in reducing technical debt must survive the very prioritization gauntlet that likely resulted in the creation of the debt in the first place. Depending on the size and nature of the debt, the effort to address it is likely to delay other business imperatives. This makes executive and board support for addressing technical debt essential.

Once the decision to deal with the technical debt has been made, there remain critical issues to consider, as well as risks to mitigate. Technology debt often exists in the mission-critical platforms that support the daily operations of an enterprise, so upgrading or replacing this infrastructure requires careful planning, effective testing and active risk management.

Fortunately, there are several approaches available to mitigate technical debt. The good news is that more modern technologies and architectural patterns^[7] promise to reduce the risk associated with paying down technical debt. The options presented below to address the debt are not mutually exclusive. In fact, these options may be combined to create an overall road map for an organization that is tailored to its specific situation and risk appetite.

• Greenfield – For some organizations, there may be an opportunity to build a new infrastructure based on modern technologies. This new infrastructure may support new products or markets, but alone, it is not likely to address the enterprise’s existing technical debt. This approach has the benefit of starting from a clean, digital-first slate, and lessons learned from deploying the new infrastructure can be applied to the legacy environment in the future. Goldman Sachs chose such an approach when it established its Marcus brand in 2016.^[8]
• Quarantine – In some cases, technical debt can simply be ring-fenced or quarantined to isolate it from the rest of the systems environment. This approach can be effectively deployed in infrastructure and supporting business processes designated for retirement.
• Preserve and Protect – For some stable infrastructure, the right approach may be to build a services layer around the system. This defers the inevitable need to upgrade or replace the systems in question and can effectively extend the life of critical systems assets, as well as provide the time to effectively plan their replacement or retirement.
• Simplify and Rationalize – For organizations that have grown through mergers and acquisitions and have not completed a rationalization process along that journey, simplifying and rationalizing their infrastructure may provide an opportunity to use this process to address some forms of technical debt.
• Big Bang – Some organizations may choose to do a full replacement and upgrade to a more modern infrastructure. This is a high-risk, high-reward proposition. Although it may be tempting to “rip the bandage off” to aggressively reduce technical debt, any organization considering this option should carefully consider and manage the associated risks, learning from the problems encountered by a U.K. bank almost two years ago.^[9]
• Phased Upgrade/Replacement – One of the most likely approaches to dealing with technical debt is a phased upgrade or migration to newer technology platforms. This approach represents a migration path that is risk-sensitive and reduces the debt over time. In some instances, this will require building a parallel infrastructure with temporary “scaffolding” to support the transition to the desired future-state environment.

As noted earlier, these approaches can be combined and aided by several more modern technologies and architectural patterns as organizations seek to deal with existing technical debt and avoid future technical debt. For example, cloud solutions offer several benefits related to avoiding future technical debt while shifting some of the maintenance burden to the cloud services provider. However, cloud computing options do not let the user organization abdicate its responsibility for monitoring and managing technical debt.

Service-oriented architectures, including application programming interfaces (APIs) and microservices, are another technology solution that can be applied in several of the above approaches. For example, APIs and microservices can be used to “wrap” and “decompose” legacy systems in the “preserve and protect” approach described above. They can be an important tool in the implementation of the “phased upgrade/replacement” approach as well. More important, the decomposition of large, complex, monolithic systems into smaller components offers support strategies that help manage technical debt, create agility and enable innovation.

To face the future with confidence, executives and directors need to understand the extent and level of the enterprise’s technical debt and ascertain where the organization is in formulating a plan to address it. This discussion is important, because technical debt impairs a company’s effectiveness in responding rapidly and continually to emerging market opportunities, competitive threats and customer demands. Organizations that built their legacy applications for operational optimization now face formidable challenges as new business realities demand ever higher levels of resilience in terms of being able to adapt their business models, processes and systems to the new realities of the digital economy; hence the need to select the best approach to modernize.

Questions for Senior Management and Boards of Directors

Following are some suggested questions that senior executives and their boards may consider, based on the risks inherent in the entity’s operations:

• Do the board and executive management have visibility into the extent and nature of the entity’s technical debt?

• • Is there an effective means of measuring technical debt?
  • Do the board and management understand its impact on the company’s business and innovation strategy? For example, is the amount spent to maintain solutions disproportionate to the amount being invested to innovate and enhance the organization’s capabilities?

• Is there an actionable road map to mitigating the risk and cost of technical debt?

• • Is there a clear target-state architecture and a road map to achieve it?
  • Is preoccupation with budgets and deadlines or other behaviors preventing the organization from addressing the risks related to technical debt in a proactive manner?

• Is there active governance in place to ensure that effective tradeoff decisions are made so that technical debt is actively managed on an ongoing basis?

• • Is there a strategy and governance process that considers the management of technical debt in support of established business goals, including innovation?
  • Is the organization agile and adaptive enough to recognize the impact of emerging technologies and changing business models and capitalize on, endure or overcome them with timely adjustments to its strategy and infrastructure? Are these assessments shared with the board?

• If answers to any of the above questions are no, are steps being taken to eliminate these and any other barriers?

[1] “Technical Debt: The Silent Company Killer,” Fatemi Falon, Forbes, May 30, 2016.

[2] “Good Technical Debt vs. Bad Technical Debt,” Fadi Stephan, Excella, March 21, 2016.

[3] “Wanted at Banks: Young Tech Pros with Old-Tech Smarts,” Penny Crosman, American Banker, July 15, 2014.

[4] “Banks scramble to fix old systems as IT ‘cowboys’ ride into sunset,” Anna Irrera, Reuters, April 9, 2017.

[5] “COBOL Is Everywhere. Who Will Maintain It?,” David Cassel, The New Stack, May 6, 2017.

[6] “Gartner, IT Key Metrics Data 2018: Executive Summary,” Linda Hall, Eric Stegman, Shreya Futela, Disha Badlani, December 11, 2017, pages 42-45, available at ID G00341718.

[7] “Architectural pattern” is a technical term for a general, reusable solution that is commonly available and addresses a commonly occurring problem. Examples in analytics and business intelligence include transactional reporting, operational analytics, business analytics, predictive analytics and prescriptive analytics. In artificial intelligence, examples are speech recognition, natural language processing, machine learning, robotic process automation, and image and video analysis.

[8] “Why Goldman Sachs Is Lending to the Middle Class,” Zeke Faux and Shahien Nasiripour, Bloomberg Businessweek, June 29, 2018.

[9] “TSB IT crisis: bank chief Paul Pester steps down with £1.7m payout,” The Week, September 4, 2018.