Management

How Federal Agencies Can Identify and Address Technical Debt

As government seeks to move beyond the crisis phase of the coronavirus pandemic response, IT leaders must overcome the hidden costs of technology development.

Evan Doty

Evan Doty is a senior field solution architect at CDW focused on hybrid cloud and Microsoft Azure. His areas of expertise include LAN and WAN network design and implementation, Windows system administration, project management, call center management and deployment, and IT vendor management.

Peter Dunn

Peter Dunn is Federal CTO for CDW Government.

In the early stages of the coronavirus pandemic, many federal agencies rapidly deployed endpoint and remote collaboration solutions to meet the needs of the moment.

While these solutions were critical in enabling government workers to work from home and maintain their missions, they were rolled out with little forethought because of the exigencies of the pandemic.

As the situation evolves and agencies contemplate a hybrid work future, agency and IT leaders need to think long-term about their technology investments. Now is an opportune time to address technical debt — the cost and investment required to upgrade legacy systems to meet current requirements — and try to get out from under it.

Understanding Where Technical Debt Comes From

The General Services Administration has been warning agencies about technical debt as far back as 2015, noting that it refers to the “‘hidden’ costs associated with a system’s architecture and codebase (for example, changing requirements addressed with a ‘quick fix,’ bugs deferred in favor of new development, design weaknesses, or aging third-party libraries).” Technical debt, the GSA notes, can “make software resistant and costly to change, and prone to outages, intermittent failures, and even security breaches.”

Technical debt is a somewhat controversial subject, and IT leaders and software developers have different perspectives on where it comes from, why it starts and what causes it. Still, it’s critical for agencies to address.

Often, IT leaders don’t think about the long-term costs of deploying a new piece of software, for example. Leaders want to solve problems for their agencies’ mission areas. However, if they are stuck in firefighting mode, they can’t take a more methodical approach and ensure they’re on the right path with a clear, long-term strategy for maintaining and updating software.

For example, if agencies have a mandate to move applications to the cloud, leaders might opt to simply migrate everything over without optimizing or changing much. This can lead to issues down the road, particularly from a security perspective. In addition to the apps, agencies may wind up porting over lax security protocols, such as granting too many admins access or not having a policy for retiring user accounts.

Software developer and author Martin Fowler created a matrix for determining how technical debt is created, including whether the debt is reckless or prudent and whether it is deliberate or inadvertent. These facts can help agencies address the debt in the most productive way.

How Agencies Can Best Identify Technical Debt

The best way to think about technical debt is to treat it similarly to financial debt. There is no simple answer to determining whether it is good or bad. Instead, agencies can try to determine what some of the indicators are for where it came from. That can help ensure that agencies are monitoring and planning better.

This applies not just to software but to other IT elements as well. For example, imagine an agency is setting up a new data center. The agency’s IT leaders might be planning for power, heating and cooling, but might not know that they need to drill through a wall to access the uninterruptible power supply. They likewise might not know that the wall they have placed equipment beside cannot be drilled through.

Consider an agency IT leader that just got approval from agency leadership to adopt a zero-trust approach to its networking. The IT leader got 2 percent more in its budget to do so but did not consider the cost to maintain the new technologies or systems and how they might grow over time.

The IEEE paper “Towards an Ontology of Terms on Technical Debt” identifies 13 types of technical debt and a set of key indicators for each, including debts related to architecture, code, documentation, infrastructure and requirements.

It’s critical to identify technical debt so that it can be addressed. However, that cannot truly happen unless IT leaders stop acting as firefighters and think strategically about their investments.

EXPLORE: What will be the long-term effects of pandemic responses on federal IT?

Addressing Technical Debt in Government

Often, to address technical debt effectively, IT leaders need to triage. CIOs and their teams should poll mission units and program managers to identify the 10 most critical applications or systems they operate. Then, ask a simple yes or no question: Can I retire this?

If it’s a critical, modern app like Office 365, the answer is probably no. If it’s a less mission-critical app, the answer might be yes. For those that the agency will retire, the next question becomes whether the agency will actually retire it or refactor it.

The biggest step IT leaders can take is to get out of firefighting mode and become more proactive than reactive.

IT leaders at one agency cannot drag their feet on addressing technical debt in the hope that other agencies will figure things out and pick up the slack. If IT leaders across government are not working together to address the issue, common problems will be missed, and best practices won’t be identified. Now is the time to start paying down technical debt and thinking strategically.

This article is part of FedTech’s CapITal blog series. Please join the discussion on Twitter by using the #FedIT hashtag.