6 tips for CIOs managing technical debt

What is technical debt?

The phrase was coined by Ward Cunningham, a programmer who developed the first Wiki and who was an early proponent of agile programming.

Cunningham described technical debt as the tradeoff programmers make between immediate speed and long-term efficiency. Cunningham was referring to software, but the concept of technical debt can be extrapolated to every technology implementation that prioritizes a fast outcome over a correct one -- meaning it is built in accordance with security, scalability, supportability and other key architectural principles.

Unchecked prioritization of deployment speed over efficiency results in outcomes that consume more time downstream to support, repair, maintain and secure. This, in turn, leads to an environment where most staff hours are spent "keeping the wheels on the wagon" rather than developing and deploying technology that helps the business address current needs and plan for future challenges.

Cunningham doesn't oppose getting a fast, working product implemented to demonstrate proof-of-concept or to meet an immediate need. The Internet Engineering Task Force, an organization that develops the communications protocols that undergird the Internet, calls this approach "rough consensus and running code."

In other words, the problem of technical debt doesn't stem from cutting a few corners to enable quick implementation. It comes from failing to go back and modify the result to bring it into alignment with best practices.

So, why are organizations finding it difficult to manage technical debt in the first place? Here we've identified five common practices that often produce future technical debt.

1. Missing architecture

It's hard to adhere to architectural best practices if you don't have an architecture in the first place. But often, the first thing that's sacrificed on the road to speed is having a technology architecture.

A well-thought-out architecture includes not only the interfaces -- what technology components need to connect with what -- but also bigger-picture concerns such as security, scalability and supportability. If CIOs are embarking on a technology initiative without an architecture in place, they're at risk of incurring technical debt.

2. Siloed implementations

If different groups are implementing technology without a robust process for collaborating, they can run into incompatibilities that generate technical debt. For example, virtual desktop infrastructure (VDI) doesn't properly support workgroup collaboration technologies like desktop video conferencing. If one desktop organization is focused on implementing VDI and another is rolling out desktop video conferencing, the results will clash, necessitating cumbersome workarounds.

3. Short-term project focus

CIOs with software backgrounds are particularly prone to this problem. Many applications are created to solve a specific business problem that exists in the here-and-now, without thought about how that problem will evolve or what other adjacencies it pertains to.

For example, a development team might jump into solving the problem of creating a database to manage customer accounts without taking into consideration how that database is integrated with the sales/prospecting database. This can lead to thousands of staff-hours downstream spent transforming contacts and importing them from the sales to the customer database.

4. Disconnect between development and operations

One of the best-known problems in large organizations is the disconnect between development and operations where engineers design a product without first considering how their peers in operations will support it, thus resulting in support processes that are cumbersome, error-prone and inefficient.

The entire programming discipline of DevOps exists in large part to resolve this problem by including representatives from the operations team on the development team -- but the DevOps split exists outside programming. Infrastructure engineers may roll out routers, edge computers or SD-WAN devices without knowing how the devices will be patched or upgraded. Cybersecurity teams may roll out endpoint detection and response offerings without understanding how they fit into desktop support services.

5. No full-lifecycle vision

Technologies retire when something better has been developed or when a business process has improved to the point where the technology is no longer necessary.

Having an end-of-life (EOL) strategy in place when the team launches a technology initiative is a wise move -- the lack of an EOL is a red flag for the existence of technical debt.

Technology that's obsolete but not yet retired still needs maintenance and patching to ensure it doesn't comprise a security risk. If there's data stored within that technology, extracting and using it can become increasingly difficult as the technology ages.

And as privacy and compliance regulations change and tighten, the stored data may put an organization out of compliance with new regulations -- information that's stored in clear text, for example, may need to be encrypted.

6 strategies for managing technical debt

The five practices listed above are a good indicator that an organization may be incurring technical debt. The good news is eliminating these practices can go a long way to managing technical debt.

In a nutshell, a six-point strategy for managing technical debt should include the following:

1. Implement an architecture

Any time a CIO or business leader initiates a project, it should adhere to an architecture that explicitly includes mechanisms for securing, managing and supporting the technology as well as integrating it into adjacent technologies. This speeds up the development process and helps avoid technical debt associated with "after-the-fact" fixes.

2. Coordinate across teams

Organizations should have a holistic view of all the projects underway with each team having a high-level understanding of what other teams are working on, their timeframe and the potential impact of those projects.

3. Keep an eye on the big picture

Short-term projects are well and good, but there should be individuals within the organization chartered with making sure projects don't overlap or conflict with each other.

4. Take a DevOps -- and DevSecOps -- approach to everything

The first, second and third questions associated with any proposed technology initiative should be, "How will we support this?" Organizations must ensure that a proposed technology has a built-in strategy for operational support, including security.

5. Begin with the end in mind

CIOs and other IT leaders within the organization should have a clear understanding of when a technology is becoming obsolete and design it from the get-go to be retired gracefully.

6. Revisit your projects with an eye towards reducing technical debt

Take a cue from writer Michael Crighton, who famously said, "Books aren't written, they're rewritten." Even the best-planned project may carry some degree of technical debt. It's worth revisiting existing projects periodically to see how they can be revised to minimize and manage technical debt going forward.